Skip to main content
note

Current public-DAV authority boundary — 2026-07-12. Pre-launch target design; nothing here proves a live system. A public-DAV consequence may occur only when at least two natural-person councilors bind the exact consequence in a complete valid bound PRISM decision receipt. PRISM records and verifies that receipt only; it never serves as council, signatory, authority, or receipt producer. AI and caste seats stage unsigned proposals only; they never authorize or execute a public-DAV consequence. Constitution or membership adoption establishes constitution and membership only; it does not authorize a later consequence. Policy may constrain an unsigned proposal but never authorizes execution or substitutes for the complete consequence-bound receipt. Before receipt validity, consequence fails closed to read-only proposal, simulation, or deterministic sandbox; live evidence remains gated_pending_complete_valid_bound_receipt. Software deterministically carries out only the exact consequence bound to a complete valid bound PRISM decision receipt from at least two natural-person councilors binding that exact consequence.

Proof of Relay — Earning by Routing

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. A node cannot know whether any given packet contains a winning ticket until it has already relayed the packet. In the target design, the only way to earn consistently is to relay consistently.

How It Works

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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: Lottery tickets are encrypted within the onion layer. The node cannot inspect the ticket without decrypting, which requires completing the relay. By the time it knows whether the packet contains a ticket, it has already relayed it.
  • 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

ParameterValue
Ticket insertion rate~1 per 1,000 packets (tunable per epoch)
Expected value per ticketProportional to traffic volume and epoch reward pool
Protocol fee on winnings38.2% (phi-split, immutable)
Epoch length24 hours
Minimum relay uptime for eligibility95% 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

  1. Sybil-resistant: In the target design, creating many node identities would not help — lottery tickets require actual packet relay, which requires actual bandwidth.
  2. Proportional: Nodes that relay more traffic would encounter more lottery tickets. Rewards would scale linearly with contribution.
  3. Self-correcting: Nodes that game the system (self-dealing, selective relay) would degrade their own routing allocation via SmallEBM, reducing future earnings.
  4. 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.


Implementation Notes

  • This page is maintained as part of the Skyzai wiki extraction pass.
  • Claims should remain aligned with canonical source files and evidence tiers.
  • Operational use should distinguish between constitutional invariants and derived heuristics.

Validation Checks

  1. Definitions are internally consistent with adjacent sections.
  2. Any quantitative claim is paired with context and measurement window.
  3. Cross-links to related pages remain valid after edits.
  4. Status-oriented language reflects current verifiable state.

Agent Execution Surface

If you are an AI agent reading this document:

  1. This is a downstream public content page. The canonical source lives in EMERGENTISM_ORG/08_FRAMEWORK_SUPPORT/ or SKYZAI_ORG/. Edit source upstream, not here.
  2. Preserve evidence tiers. Do not promote claims up the [C] < [D] < [S] < [B] < [E] ladder when reproducing them here; [I]/[A] qualifiers never substitute for [B]/[E].
  3. Regenerate from source. If the upstream source changes, regenerate this page rather than editing it independently.
  4. Canonical Path: SKYZAI_ORG/07_PWAs/skyzai_org/wiki/46-proof-of-relay.md

Output: This is content. Route edits to upstream source. Regenerate when source changes.

K3 public-DAV authority history — 2026-07-12

K3 historical reference — not active authority
note

Current public-DAV boundary — 2026-07-10. Pre-launch target design; nothing here is live. The active DAV is public and targets PRISM, with no K2 runtime, launch, genesis/bootstrap, or fallback dependency. Consequential authority requires at least two natural-person councilors; AI/caste seats stage unsigned proposals only. Before quorum, behavior fails closed to read-only/proposal, simulation, or deterministic sandbox, and a live decision receipt remains gated pending quorum.

APU · local guide, not live AI Proof Of Relay

Context: Proof Of Relay. Local guide only. Messages are not sent or saved.

Skyzai

Explore the protocol map Development & availabilityContact Skyzai

Your world. Better connected.
A Skyzai experience, with APU.

Skyzai is coming together.

The shared app at skyzai.com is in development. Explore the website while we build the connected experience.