Status: pre-launch. This page describes target design; this document does not establish a deployed service.
Proof of Relay — Earning by Routing
Current reading — 2026-09-27
The relay-ticket proposal retains its selective-relay open problem. This page does not establish incentive compatibility, Sybil resistance, bounded adversarial cost or live rewards. Fee, split and instrument terms need separate owner decisions. [I]
This is an editorial boundary, not a new runtime contract, upstream repeal or proof of adoption. See current status and the product roles. Original revision dates remain as recorded below.
Historical research draft — retained on 2026-09-27; not current terms or implementation instructions
This page describes the target relay-incentive design for SPECTRE. Read the mechanism below as protocol architecture unless a narrower runtime proof has explicitly closed the loop.
The Problem
Every decentralized network faces the same bootstrapping question: how do you prove that a node is contributing real work, not gaming metrics to extract rewards? Proof of Work burns electricity. Proof of Stake locks capital. Both are proxies for contribution, not measurements of it.
The SPECTRE design calls for a proof mechanism tied to the actual value the network is meant to produce: routing real traffic between real endpoints.
The Mechanism
Proof of Relay would embed cryptographic lottery tickets inside onion-routed packets. Open problem: in onion routing a node decrypts its own layer before forwarding, so as described it could check for a winning ticket and then drop the packet. The design needs an added mechanism, for example a ticket redeemable only with a receipt from the next hop, before selective relay can be ruled out. In the target design, the only way to earn consistently would be to relay consistently.
How It Works
-
Packet construction: The sender wraps the payload in onion layers (one per relay hop). Each layer is encrypted to the corresponding relay node's public key.
-
Lottery embedding: The sender inserts a cryptographic lottery ticket into one or more layers. The ticket is indistinguishable from normal routing metadata until the relay node decrypts its layer.
-
Relay execution: Each relay node peels its onion layer, forwards the payload to the next hop, and checks whether its layer contained a winning ticket. The ticket is a hash preimage that, when combined with the node's public key and the current epoch nonce, satisfies a difficulty target.
-
Claim: In the target design, a winning node would submit the preimage to the Merkle bridge (see 47-merkle-bridge) for inclusion in the next epoch settlement. The claim would be verified by checking the preimage against the packet's routing receipt.
-
Payout: In the target design, winning claims would be settled in the epoch's Merkle root transaction. ZAI rewards would flow to the node's wallet.
Why Self-Dealing Is Net-Negative
A node that routes packets to itself (self-dealing) incurs costs without generating external value:
- 38.2% protocol fee: In the target design, every ZAI reward would be subject to the phi-split. The operational share (38.2%) would go to the protocol. Self-dealing nodes would pay this fee on rewards they "earned" from traffic they generated.
- Bandwidth cost: Generating and routing fake traffic consumes real bandwidth. The node pays infrastructure costs for packets that serve no external user.
- Opportunity cost: Bandwidth consumed by self-dealt traffic cannot serve real traffic. Real traffic is the only source of sustainable demand (and therefore sustainable lottery ticket supply).
- Detection risk: In the target design, the immune system (see 43-immune-system) would monitor cross-report variance. A node whose inbound and outbound traffic profiles are suspiciously symmetric would trigger anomaly detection. Flagged nodes would receive elevated energy scores in SmallEBM, reducing their routing allocation.
The math: if a self-dealing node generates 100 ZAI of fake traffic rewards, it keeps 61.8 ZAI (LP share) but pays infrastructure costs of X, plus the opportunity cost of real traffic it displaced. For any realistic bandwidth cost, self-dealing is net-negative.
Why Selective Relay Fails
A node that only relays packets it suspects contain lottery tickets (and drops the rest) also fails:
- Indistinguishability (open problem): see above; as described, a node can see its own layer before it forwards.
- Reputation degradation: Dropped packets cause delivery failures. In the target design, the SmallEBM telemetry system would record reliability scores. A node with high drop rates would receive a high energy score and be deprioritized for future routing. Reduced routing allocation would mean fewer lottery tickets.
Ticket Economics
| Parameter | Value |
|---|---|
| Ticket insertion rate | ~1 per 1,000 packets (tunable per epoch) |
| Expected value per ticket | Proportional to traffic volume and epoch reward pool |
| Protocol fee on winnings | 38.2% (phi-split, immutable) |
| Epoch length | 24 hours |
| Minimum relay uptime for eligibility | 95% per epoch |
In the target design, the ticket insertion rate would be a protocol parameter adjusted per epoch based on total network traffic volume. Higher traffic = lower insertion rate per packet (constant total reward). Lower traffic = higher insertion rate (incentivize early participation).
Properties
- Sybil-resistant: In the target design, creating many node identities would not help — lottery tickets require actual packet relay, which requires actual bandwidth.
- Proportional: Nodes that relay more traffic would encounter more lottery tickets. Rewards would scale linearly with contribution.
- Self-correcting: Nodes that game the system (self-dealing, selective relay) would degrade their own routing allocation via SmallEBM, reducing future earnings.
- Composable: Proof of Relay is designed to work at every SPECTRE tier — VPN, CDN, and Inference. Higher tiers would relay more valuable traffic with proportionally larger reward pools.
What Proof of Relay Is Not
- It is not Proof of Work. No computation is wasted. The "work" is useful packet relay.
- It is not Proof of Stake. No capital is locked. Relay capability is the stake.
- It is not Proof of Bandwidth. Bandwidth alone does not earn rewards — successful, verified relay of real traffic does.
Proof of Relay is designed to align incentives structurally: the only way to maximize revenue would be to maximize the quality and volume of real traffic you route. The network's economic incentive and its operational purpose are intended to be identical.