Stake-Weighted Mix RLN DoS Protection

Timeline

• 2026-09-07 — 074fb79 — Stake-Weighted Mix RLN DoS Protection spec (#327)

Abstract

This document specifies a registration policy extension for the RLN Per-Hop DoS Protection specification, introducing stake-proportional rate limits for mix nodes. Under this extension, each node's rate limit is proportional to its committed stake and enforced via the RLN-Diff circuit defined in RLN-v2. The mapping is Sybil-resistant, requires no circuit changes, and enforces rate differentiation entirely through the membership registry.

1. Introduction

The RLN Per-Hop DoS Protection assigns a flat rate limit to all mix nodes that meet a minimum stake requirement. To accommodate high-capacity relay nodes, this limit must be set high — making the same rate headroom available to any minimally-staked attacker. This structural limitation is referred to as the rate amplification gap, defined in Section 3.1.

This document specifies an extension that replaces this flat limit with a stake-proportional mapping: a node claiming a higher rate must commit proportionally more stake. This raises the economic cost of exploiting the gap but does not eliminate it.

Section 2 defines terms used in this specification. Section 3 provides background on the rate amplification gap and RLN-Diff. Section 4 specifies the stake-to-rate mapping, registration, and verification mechanics. Section 5 covers security and privacy considerations. Section 6 defines scope boundaries. Section 7 identifies limitations and future directions.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The following terms are used throughout this specification. Other terms are as defined in the Mix Protocol, Mix DoS Protection, RLN Per-Hop DoS Protection, RLN-v1, and RLN-v2 specs.

• S_unit: The stake required per message per epoch. A system-wide constant defined at deployment time.

• R_base: The flat per-node rate limit per epoch on outgoing packets, referred to as the messaging rate in RLN Per-Hop DoS Protection.

• T: The stake tier size, a deployment-defined positive integer. Each tier corresponds to a stake increment of T × S_unit and a rate increment of T.

• R_min: The minimum rate limit a node may be registered with. R_min is the smallest multiple of T greater than or equal to R_base. R_min = ⌈R_base / T⌉ × T.

• R_max: The maximum rate limit any node may be assigned, regardless of stake. R_max MUST be a multiple of T and MUST be at least R_min.

• floor-stake: The minimum stake required to register, R_min × S_unit. Nodes with stake below floor-stake are rejected at registration.

• Membership: The result of a single node registration, backed by one stake deposit. Each node holds exactly one membership.

• Sybil-resistant: A property of a stake-based membership mechanism in which registering N nodes requires N times the stake of one, ensuring no rate advantage from splitting stake across multiple nodes.

3. Background

This section provides background on the rate amplification gap in RLN Per-Hop DoS Protection and on RLN-Diff.

3.1 Rate Amplification Gap

RLN Per-Hop DoS Protection enforces a flat rate limit R_base per node per epoch on outgoing packets. Two properties combine to make this exploitable:

• R_base must be set high enough to accommodate the forwarding load of high-capacity relay nodes. As a result, all nodes receive the same high R_base regardless of stake.
• The Mix Protocol's unlinkability guarantees make forwarded and originated packets cryptographically indistinguishable by design, so any node can use its R_base allowance entirely for origination.

Together, these give a minimally-staked attacker the same effective origination budget as the forwarding budget intended for a high-capacity honest relay.

Raising R_base to accommodate higher-capacity relays widens this budget proportionally. This structural limitation is referred to as the rate amplification gap.

3.2 RLN-Diff

Rate Limiting Nullifiers (RLN) is a zero-knowledge construct that allows message rate limits to be set and cryptographically enforced for members of a group, without revealing their identity. This specification uses the RLN-Diff variant, which supports per-member rate limits set individually at registration. The full mechanics are defined in RLN-v2; only the parts required to follow Section 4.2 and Section 5 are summarised below.

Registration: A member generates an identity_secret and derives id_commitment = Poseidon(identity_secret). It submits id_commitment and a user_message_limit to the membership registry.

The registry writes a Merkle leaf encoding both as a rate_commitment:

rate_commitment = Poseidon(id_commitment, user_message_limit)

user_message_limit is observable to any party that can read the registry.

Rate limit: Each member's rate is bounded by the user_message_limit set at registration. For each outgoing packet, a member selects an unused message_id in [1, user_message_limit] for the current epoch and generates an RLN-Diff proof. The proof binds the packet to that message_id and epoch, attests that the member holds a rate_commitment in the Merkle tree, and enforces message_id ≤ user_message_limit via a range constraint.

user_message_limit is not revealed by the proof.

Double-signalling and slashing: Reusing the same message_id with different signals in an epoch allows any verifier to reconstruct the member's identity_secret and slash its stake.

4. Approach

This specification raises the economic cost of exploiting the rate amplification gap defined in Section 3.1, by tying rate limits to committed stake.

The approach mirrors bandwidth-weighted relay selection in Tor, where relays are assigned traffic proportional to their capacity. The analogue here is economic: stake functions as a commitment to capacity, and rate limits scale accordingly.

The following sections specify the mapping, registration, and verification mechanics.

4.1 Mapping Function

A node's rate limit user_message_limit is computed from its registered stake S as follows:

user_message_limit = min( ⌊ S / (T × S_unit) ⌋ × T, R_max )

Setting T = 1 reduces the mapping to fully linear ⌊ S / S_unit ⌋.

The integer t = ⌊ S / (T × S_unit) ⌋ is the stake tier index. All stake amounts that map to the same t have user_message_limit = t × T.

This mapping MUST be computed and enforced by the membership registry at the time of registration. It MUST NOT be modifiable after registration without re-registration.

Rationale for linear mapping: Any linear mapping g of stakes is additive: g(S₁) + g(S₂) = g(S₁ + S₂), meaning an attacker gains no aggregate rate by splitting stake across multiple registrations. This makes linear mapping Sybil-resistant. The quantized form used in this spec retains additivity at tier boundaries: stakes that are exact multiples of T × S_unit are additive; stakes between tier boundaries round down without any rate advantage.

4.2 Registration

The node generates an identity_secret and derives id_commitment, as described in Section 3.2. It submits id_commitment and stake S to the registry.

The membership registry MUST enforce the following at the time of registration:

1. Verify that S ≥ R_min × S_unit. Reject registrations below floor-stake.
2. Compute user_message_limit from S according to Section 4.1.
3. Complete registration as described in Section 3.2 using the computed user_message_limit.
4. Lock the stake for the duration of membership. Stake MUST NOT be withdrawable while membership is active.

Stake top-ups MUST NOT be accepted while a membership is active. Any change in stake requires deregistration followed by re-registration.

4.3 Packet Sending and Verification

Packet sending follows the rate limit and double-signalling mechanics described in Section 3.2. The node selects a message_id in [1, user_message_limit] that has not been used in the current epoch and generates an RLN-Diff proof.

user_message_limit is not revealed by proofs; verifiers only learn that the sender has not exceeded their registered limit.

All per-hop verification and slashing logic are as defined in RLN Per-Hop DoS Protection.

4.4 System Parameters

S_unit SHOULD be set such that a floor-stake node generating only mandatory cover traffic at the rate specified in Mix Cover Traffic can sustain operation at R_min.

R_max MUST be set such that a single node operating at R_max cannot individually saturate the network's forwarding capacity. A value near 10 × R_base, rounded to a multiple of T, is a reasonable starting point: it allows a high-stake operator to handle 10× the base forwarding load without dominating the network. Values above 50 × R_base SHOULD be avoided without careful analysis of the deployment's expected node count and forwarding load distribution.

T = 1 provides full rate granularity. Deployments concerned with registered-stake privacy SHOULD use T ≥ 10; see Section 5.3.

S_unit, R_base, T, R_min, and R_max MUST be published in a deployment configuration accessible to all participants before the network accepts registrations. The membership registry MUST reject registrations inconsistent with the published parameters. Verifiers trust the membership registry to enforce the correct value of these parameters at registration time.

5. Security and Privacy Considerations

5.1 Sybil-Resistance

The stake-to-rate mapping is Sybil-resistant: each rate increment of T costs T × S_unit of stake, regardless of how that stake is distributed across registrations.

For any partition of stake S across N nodes with individual stakes S_1, ..., S_N (∑ S_i = S), the aggregate user_message_limit satisfies:

∑ ⌊ S_i / (T × S_unit) ⌋ × T  ≤  ⌊ S / (T × S_unit) ⌋ × T

Splitting stake across nodes cannot produce more aggregate user_message_limit than a single registration with equal total stake. Equality holds when each S_i is an exact multiple of T × S_unit.

The above holds for stake up to R_max × S_unit per node. Above this ceiling, the per-node R_max cap creates a residual incentive to register across additional nodes — each further R_max × S_unit of stake can claim an additional R_max of rate by registering a new node. Each additional registration also incurs transaction fees and coordination overhead, providing an economic deterrent beyond the protocol guarantee.

5.2 Residual Rate Amplification Gap

The stake-to-rate mapping raises the economic cost of exploiting the rate amplification gap defined in Section 3.1, but does not eliminate the gap. A malicious node that wants a high message rate must commit proportionally more stake, which is subject to slashing on detection.

The gap is structural: the Mix Protocol unlinkability guarantees make forwarding and origination indistinguishable, so any forwarding rate allowance is simultaneously an origination budget. This is an explicitly acknowledged limitation of per-hop RLN regardless of the rate mapping function.

5.3 Registered-Stake Privacy

Proof layer: user_message_limit is a private witness in the RLN-Diff circuit. All proofs are structurally identical regardless of the sender's registered rate, and an observer cannot link a proof to a specific registered stake.

Registry layer: Registration is publicly observable. It reveals a node's stake amount, the resulting user_message_limit (see Section 4.1), and any associated identifying metadata (e.g., wallet address) depending on the registration mechanism.

A node's rate is also observable at the network layer from its traffic. When this rate matches only one registration's user_message_limit, an observer can link the node's network identity to that registration's identifying metadata.

The stake tier size T mitigates this by clustering registered rates at multiples of T. With T ≥ 10, the rate space is coarser, increasing the likelihood of multiple stakers sharing the same user_message_limit, thereby forming anonymity sets at the registry layer. Actual anonymity set size depends on how stakers are distributed across tiers.

A complete fix at the registry layer requires a shielded membership registry that hides the stake-to-identity link via ZK (see Section 7).

6. Out of Scope

The following are explicitly out of scope for this specification:

• Dynamic rate adjustment without re-registration
• Stake token selection and blockchain infrastructure
• Detailed migration procedures and tooling for networks upgrading from flat-rate RLN
• Voluntary deregistration mechanisms (a RLN Per-Hop DoS Protection responsibility)
• Membership registry implementation (smart contract, coordination layer, or other)

7. Future Work

• Shielded Membership Registry: The registration publicly reveals the node's effective rate. A shielded membership registry — where the stake-to-identity link is concealed via ZK — would close this gap. One approach is multi-identity registration: a node registers multiple unit-rate identities, hiding its total rate from registry observers. However, slashing requires linking all identities to the committed stake: double-signalling on any identity must make the entire stake slashable. Achieving such an unlinkable registration with linked slashing requires circuit-level changes not available in current RLN-v2.

• Dynamic stake top-up: A mechanism for incrementally increasing stake without full deregistration would improve operational ergonomics.

• Reputation-based rate differentiation: Stake need not be the only path to a higher rate limit. Nodes with a sustained record of good service could earn a higher limit than their stake alone would buy, complementing the stake-based mapping defined here. This requires a verifiable reputation signal, and a way to adjust a node's rate limit without re-registration.

• Rate-weighted path selection: The Mix Protocol currently specifies uniform random path selection, which distributes forwarding load equally regardless of node capacity. Under stake-weighted rate limits, weighted path selection proportional to registered rates — similar to Tor — is an alternative, with an open trade-off between the two. Path-selection rules only constrain honest senders, so attackers can target low-stake nodes under either strategy. Weighted selection biases honest paths toward high-rate nodes, reducing honest-path impact when low-stake nodes are flooded. However, well-funded adversaries can stake more to gain disproportionate path inclusion, enabling traffic surveillance. Uniform random selection avoids this surveillance vector, but every honest path that includes at least one low-stake node is affected by such flooding attacks.

• Cover traffic under stake-weighted rates: The Mix Cover Traffic specification derives per-node cover emission bounds assuming uniform rate limits. Under stake-weighted rates, every node's user_message_limit satisfies user_message_limit ≥ R_min ≥ R_base by construction, so R_base can serve as a common budget parameter across all nodes. Whether stake-weighted capacity in the range (R_base, R_max] can be used for emission without breaking uniformity remains open. Resolving this requires either accepting unused capacity above R_base or accommodating per-node budgets up to R_max without breaking emission uniformity.

Copyright

Copyright and related rights waived via CC0.

References

• Mix DoS Protection
• RLN Per-Hop DoS Protection for Mixnet
• Mix Cover Traffic
• libp2p Mix Protocol
• Rate Limiting Nullifiers v1
• Rate Limiting Nullifiers v2