Go to article content Hopr

Hopr payment channels fund relay claims through winning tickets

Updated Monday, October 19, 2026

Hopr payment channels hold wxHOPR on Gnosis Chain to fund the rewards that relays claim through winning tickets. Each channel has a payment direction, so one node's outgoing channel is the other node's incoming channel. A ticket represents a potential relay reward; the channel balance supplies funds for settling that claim. HOPRd v5.0.0 on Piz Palü manages channel funding through the node's Safe and can redeem winning tickets automatically. A rising ticket count therefore differs from an increase in available tokens. A node earns incoming tickets for its own forwarding work while spending from outgoing channels to pay the next relay.

Bottom line: A falling outgoing channel balance can reflect onward relay payments even while the same node earns incoming tickets.

Channel direction follows the payment

When a node pays a neighbouring relay, its outgoing channel supplies the funding, while the receiving relay sees that channel as incoming. The payment contract handles one-way channels. A reverse payment uses a channel in the opposite direction, even when the same peers communicate both ways. During a multi-hop transfer, a relay earns tickets for forwarding and pays the next hop through its own outgoing channel. These relationships explain why an outgoing balance can fall while the node continues earning incoming tickets.

Proof of relay unlocks a payment claim

To claim a relay reward, a node needs cryptographic material that depends on cooperation with neighbouring nodes in the forwarding chain. Proof of relay connects the payment claim to that work. Consecutive relays exchange the parts needed to unlock their payments, making each dependent on the other's participation. A relay that keeps a packet without forwarding it can't unlock its payment.

This mechanism answers whether the relay has earned a usable claim. The ticket's winning status answers a different question: whether that claim produces a token payout. An earned ticket can still lose. Keeping these tests separate explains how successful forwarding can produce tickets without immediately increasing the Safe's balance.

Why doesn't every relay ticket pay a reward?

A ticket pays only when it wins, because the protocol uses probabilistic payments to settle relay work with fewer blockchain transactions. The winning probability determines how frequently tickets pay, while the payout determines the value of a winner. Most tickets can carry no redeemable reward while occasional winners carry a larger payment.

Expected value describes the average implied by those inputs, not the outcome of any particular batch. Lowering the winning probability while increasing the payout proportionally preserves that expectation. It also makes payments less frequent and individual outcomes more uneven. Ticket parameters can change, so a published illustration of probability doesn't establish the settings of a running network.

Safe funds and allowance set the funding ceiling

A node can open or top up channels only while its Safe holds enough wxHOPR and the channels contract has sufficient remaining allowance. The Safe balance measures tokens available there. The allowance measures how much the approved contract may still transfer. Neither value establishes the other, even though both affect channel funding.

The node address separately needs xDai for on-chain transaction fees. Additional wxHOPR doesn't supply that native gas balance.

Opening and topping up channels consume a finite allowance as they draw wxHOPR from the Safe. Returning channel funds to the Safe doesn't restore the allowance consumed by earlier funding transfers. This explains why a replenished Safe can still fail to support another top-up.

An approve transaction replaces the existing allowance with the submitted total. It doesn't add that total to the previous approval. Its spender determines which contract receives authority over the tokens, up to the approved amount. The relevant spender must match the channels contract for the selected network.

---

Expected batch rewards and an observed balance

The expected reward for a ticket batch is an average over possible outcomes; it doesn't establish the amount already credited to a Safe or channel.

All inputs in this worked calculation are hypothetical: ticket count N = 142; winning probability p = 0.02 (2%); payout per winning ticket V = 7.5 wxHOPR. The formula expected_reward = N * p * V gives 21.3 wxHOPR before transaction costs.

The actual reward depends on how many tickets win and which winners settle. The outgoing channel balance measures funded tokens available for payments, so this expectation alone can't explain its movement. Changing the ticket count, probability or winning payout changes the expected value.

View full-size image

Data capacity sets channel funding in v5

In HOPRd v5.0.0, ChannelLifecycle expresses funding as data capacity and converts it into wxHOPR using ticket price and winning probability. Capacity describes the intended amount of relay traffic. It isn't a token denomination. The node funds whole winning tickets, so the resulting deposit also reflects that constraint.

The funding.sizing_mode setting changes the conversion. Deterministic sizing funds expected usage. Probabilistic sizing adds a safety buffer against running out before a top-up. Copying capacity values while omitting their sizing mode can therefore produce a different funded balance.

A token amount printed beside a capacity setting describes the network inputs behind that conversion. It doesn't fix the deposit for every ticket configuration. The channel's recorded wxHOPR balance establishes its actual funding; a capacity setting alone doesn't show how many tokens the channel currently holds.

Automatic management follows the channel target

With ChannelLifecycle active, the node opens, funds, tops up, closes and finalizes outgoing channels under its configured rules. Peer connectivity and quality influence those decisions. The strategy can close channels to peers that perform poorly or disappear, helping direct available funding toward useful connections.

The minimum channel count and target channel count have different jobs. The minimum pauses closures that would take the count below its configured floor. The target tells the node how many outgoing channels to try to open. Neither setting guarantees that every channel retains enough tokens for every purpose.

Each additional funded channel draws wxHOPR from the Safe. A larger target can use reserves that existing channels need for later top-ups. Available funds, per-channel capacity and the target therefore interact: enough tokens to open the first channels doesn't necessarily cover all the channels that the configuration seeks to maintain.

Manual channel management remains available through the Admin UI or API. An active lifecycle strategy can also manage channels, so its configuration still matters.

Settlement leaves fewer links to packet traffic

The payment design separates packet forwarding from immediate blockchain settlement, reducing the information that a payment trail reveals about communication. Relaying a packet doesn't automatically create a blockchain reward transaction. Tickets carry the claims between relays, and winning-ticket redemption settles rewards without recording a payment for every packet. Payment channels provide the funds that make those claims payable.

Channel transactions and redemptions still leave on-chain records. Fewer settlement events reduce the payment layer's metadata footprint; they don't make blockchain activity invisible. The mixnet's encrypted routing and mixing address transport metadata, while probabilistic tickets reduce the detail exposed by paying relays.

Redemption and closure move different balances

When its redemption strategy permits, a node can redeem valid winning tickets while the channel remains open. Closing a channel isn't a prerequisite for every reward claim. Closure instead concerns ending that funded payment relationship and releasing its remaining funds after the closure process completes.

For cover-traffic rewards on Piz Palü, redeemed rewards normally go to the Safe. If the relay has an open outgoing channel to the paying cover-traffic node, the reward credits that channel's balance instead. That channel's remaining balance returns to the Safe after closure is finalized. A reward can therefore increase channel funding without immediately increasing the Safe's balance.

Pending closure still has to pass its closure period and reach finalization. A PendingToClose status doesn't establish that channel funds have returned to the Safe.

Hopr payment channels FAQ