Go to article content Hopr

Hopr cover traffic rewards eligible Piz Palü nodes for relaying bursts

Updated Monday, October 19, 2026

Hopr cover traffic adds extra packets to the mixnet, helping conceal user activity while rewarding nodes for forwarding those packets. On the Piz Palü network, reachable relay nodes qualify through funded outgoing payment channels. Each relayed packet earns a ticket, and winning tickets provide token rewards. Eligibility doesn't promise a fixed payout: traffic handling, ticket parameters and operating costs shape what running a node earns. HOPRd v5.0.0 brings this burst-based model alongside the network's ordinary user traffic.

Cover packets and user packets share relay work

Cover traffic is additional network traffic that gives user packets other activity to blend into, especially during quieter periods. Its packets carry no meaningful user content, yet nodes forward them through the same mixnet machinery. Operators earn tickets for that forwarding work, just as they do for ordinary user traffic. The extra traffic therefore supports privacy while paying for the resources that relaying consumes.

A user sends traffic to communicate; cover-traffic senders create activity that helps conceal communication patterns and incentivizes relays. Both use actual bandwidth and processing capacity. An idle node doesn't earn cover-traffic rewards simply because it holds tokens. Running one suits an operator who can maintain connectivity and channel funding, then handle the packets that arrive.

Piz Palü links reachability with funded channels

On Piz Palü, a relay must be reachable by a cover-traffic node and maintain enough funded outgoing payment channels. For HOPRd v5.0.0 on Piz Palü, the initial eligibility threshold is at least five open outgoing channels with at least 100 wxHOPR each. The balance belongs in each qualifying channel; combining smaller balances across more channels doesn't meet that threshold.

These settings belong to Piz Palü's initial cover-traffic configuration and may change as the network develops. Stake weighting, Safe balance and location don't determine this eligibility. The Safe still matters operationally because it supplies the wxHOPR that the node places into channels. A public, correctly announced address also matters: a cover-traffic sender must be able to connect when the relay's turn arrives.

Piz Palü also removes the earlier registration requirement, so node operators don't need an allocated network slot.

Channel balances need room for onward payments

A channel funding buffer helps preserve eligibility as forwarding spends wxHOPR on the next hop. Funding exactly 100 wxHOPR leaves little room before that channel falls below the initial threshold. The documented Piz Palü setup targets about 150 wxHOPR per channel, so five channels require about 750 wxHOPR for initial funding. Announcement funding and later top-ups need separate provision. This isn't a new minimum stake or a guaranteed operating budget. Channel funding moves tokens out of the Safe, and additional channels can consume reserves that would otherwise support top-ups.

ChannelLifecycle converts capacity into wxHOPR funding

HOPRd v5's ChannelLifecycle strategy manages outgoing channels, expressing funding as data capacity and converting that capacity into wxHOPR. Ticket price and ticket winning probability drive the conversion, and the node funds whole winning tickets. A capacity setting therefore doesn't represent an immutable token amount. The cover-traffic funding configuration aims to maintain a buffer above the eligibility threshold; generic hosted funding values don't automatically provide that buffer.

The documented cover-traffic configuration uses probabilistic sizing_mode with success_probability: 0.99 . That probability controls the funding safety buffer; it isn't a reward ticket's winning probability. An explicitly configured funding section that omits sizing_mode uses deterministic sizing. With the documented capacities and network ticket parameters, deterministic sizing funds about 90 wxHOPR per channel, below the initial 100 wxHOPR eligibility threshold.

Channel population settings also affect the available reserve. The hosted configuration targets up to 20 open channels. With the documented cover-traffic funding settings, 20 channels require about 3000 wxHOPR before later top-ups. A configuration targeting five channels uses a smaller initial funding pool. The node still needs enough available wxHOPR and allowance to replenish channels as forwarding spends their balances. The conversion changes when network ticket parameters change, so the resulting channel balances remain the relevant amounts.

Short bursts put peak demands on node hardware

Piz Palü's initial schedule distributes bursts through five cover-traffic nodes, with an eligible relay receiving one roughly every 20 minutes on average. Each sender works through a shuffled set of eligible nodes. A burst lasts about 10 seconds, and an unreachable node loses that round's opportunity. These timings describe the initial operating settings; they don't reserve an exact appointment for any particular node.

The documented burst rate is about 30 Mbit/s, and independently scheduled bursts can overlap. HOPRd's minimum requirements are four CPU cores, 4 GB of RAM, 5 GB of disk and 10 Mbit/s in both directions. Peak processing demand explains the recommendation for headroom above those minimums. Local hardware needs reliable power and connectivity; a VPS adds recurring rental costs. Weak throughput also affects peer quality scores, which can lead other nodes to close channels. Performance-weighted routing also affects ordinary traffic opportunities, so a poorly performing relay can lose user traffic as well as cover-traffic tickets.

How do ticket probabilities affect cover-traffic earnings?

Probabilistic tickets make cover-traffic payments variable, because relaying earns chances of redemption and only winning tickets provide a payout. A ticket's expected gross reward equals its winning probability multiplied by its redeemable reward. That relationship explains why a smaller winning probability can preserve the expected value when the payout rises correspondingly. It doesn't predict how many winners one burst will contain.

Ticket price and winning probability remain tunable parameters in the Piz Palü model. A count of relayed packets alone can't establish a fixed token return without those inputs. The proof-of-relay mechanism ties payment claims to forwarding, while probabilistic payments reduce the number of reward transactions that reach the blockchain. This lowers payment overhead and reduces the metadata that frequent individual settlements would reveal.

The Safe, node balance and allowance have separate jobs

The Safe holds wxHOPR for outgoing channels, while the node address needs xDai for on-chain transaction fees on Gnosis Chain. HOPRd v5.0.0's setup requires at least 1 wxHOPR in the Safe for the node announcement and at least 0.01 xDai on the node address. Neither balance replaces the outgoing-channel balances that Piz Palü's initial cover-traffic eligibility requires.

An approved Safe allowance separately limits how much wxHOPR the channels contract may take for opening and topping up channels. Funding can stop when that allowance runs out, even while the Safe still holds tokens. The balance and allowance therefore need to cover the intended channel funding. An approval also grants spending authority, so its amount and spender determine the scope of that permission.

View full-size image

The v5 network's probing traffic also spends tokens between bursts, while other nodes' probes can provide incoming relay tickets.

Extra traffic makes communication patterns harder to isolate

Mixing, packet sizing and cover traffic work together to make communication patterns harder to isolate from the surrounding network activity. The mixnet's Sphinx packets have a uniform size, and mixing delays disrupt simple timing correlations. Additional cover packets enlarge the traffic that genuine communications can blend into during quieter periods. This protection concerns communication routed through the mixnet. It doesn't establish that unrelated application connections use the same path, and extra traffic alone isn't proof of complete anonymity. Bandwidth and processing costs rise with this extra activity, making traffic availability and sustainable incentives part of the same design.

Dufour's stake-based allocation belongs to the earlier network

Dufour's earlier allocation used the stake in a node's Safe to determine how much cover traffic it received. Piz Palü pays for burst packets that an eligible node actually forwards. Applying a legacy stake percentage to the newer network would therefore produce the wrong earnings model. The change removes stake weighting while preserving the practical need to fund channels and maintain a working relay.

The October 8, 2026 cover-traffic announcement scheduled Dufour cover-traffic rewards to taper to zero over the following weeks. Piz Palü's channel thresholds belong to its new network, so an older Dufour node needs the network migration before those rules apply. The shared wxHOPR token doesn't make the network environments interchangeable. The v5 release announcement sets October 27, 2026 as the migration deadline for existing node runners.

Net earnings depend on relayed traffic and operating costs

Net cover-traffic earnings depend on actual packet forwarding, ticket outcomes and costs that continue while the node stays online. Hardware or VPS charges sit alongside connectivity, on-chain fees and the funds needed for channel operation. There is no fixed APR for Piz Palü's burst system. Channel balances remain working funds; unused wxHOPR returns to the Safe after channel closure. Ordinary user traffic can add relay tickets alongside cover traffic, without fixing their future quantity or value. A setup that handles current bursts may need more headroom if burst intensity or eligibility parameters change.

Good to know