Supplier Rewards & Economics

Shannon replaced the old inflationary reward model with a usage-based burn-and-mint system. Suppliers earn POKT directly from work they prove they did — not from protocol inflation.

The Core Idea: You Earn What You Prove

Applications burn POKT to pay for data. Suppliers get paid in newly minted POKT equal to what was burned (minus the PIP-41 deflation factor). You earn your share by proving you served valid relays. No relay work, no reward. No valid proof, no payment.

Compute Units — The Pricing Primitive

Compute Units (CUs) are the internal currency for measuring work. Every relay consumes CUs determined by the service being queried. CUs are then converted to POKT at a governance-controlled exchange rate.

The pricing chain: Relays → Compute Units → uPOKT → POKT

Reward Allocation

When minted POKT is distributed, it splits according to the mint_equals_burn_claim_distribution parameter:

Session Mechanics

Pocket Network organizes relay work into sessions — time-bounded periods where specific Suppliers are assigned to serve a specific Application+Service pair.

• Sessions are deterministic: the protocol calculates assignments from (Application, Service, block height)
• You don’t apply for sessions — the protocol assigns them
• Selection among eligible Suppliers is uniform and pseudorandom — stake size does not improve your odds
• Each session lasts 20 blocks, about 20 minutes on MainNet

What Actually Affects How Much You Serve

Shannon has no stake weighting for Suppliers. To be considered for a session you must be staked for that service with an active service configuration at the session’s block height — that is an eligibility gate, not a weighting. Among eligible Suppliers the protocol ranks candidates by a deterministic hash of the session ID and operator address, then takes the top 50.

Two consequences worth internalising:

• If a service has fewer eligible Suppliers than 50, every one of them is included in every session. On thinner services, participation is effectively guaranteed — staking more changes nothing.
• Registering additional services widens your eligibility, not your odds within a service. Each service is its own candidate pool, so more registered services means more pools you can be drawn from.

Quality of service does not influence protocol-level session assignment. It matters after selection: Gateways route relays among the Suppliers in a session based on observed latency and reliability, so QoS determines how much of a session’s traffic you actually receive — and therefore how much you earn from it.

Settlement Timing

After a session ends, rewards don’t arrive instantly:

1. Session ends → RelayMiner submits a Claim (on-chain transaction)
2. Claim window → Protocol verifies, then opens Proof submission window
3. Proof submitted → Protocol validates → POKT minted and distributed

What Affects Your Earnings

• Relay volume: More relays = more CUs burned and minted
• CUTTM rate: The governance-controlled POKT/CU exchange rate
• Competition: More Suppliers = smaller share per node
• Chain mix: Different services have different CU rates and volumes
• POKT price: Affects USD value of rewards (CUTTM adjusts to stabilize)

There is no fixed APR. Reward rates depend on total network relay volume, the number of competing nodes, and the POKT/USD price. Published APR estimates from third parties are indicative only — verify against current Pocket Analytics data.

Monitoring Your Earnings

Use Owner Staking to track:

• Rewards over time: POKT earned, per address or aggregated
• Settlement events: Each reward issuance with block height, service, relay count, and settled vs. minted amounts
• Rewards by service: Which chains generate the most revenue for your nodes
• Key signal: A service that stops producing settlements is losing rewards — an expired proof yields no settlement at all, so investigate RelayMiner logs when settlements go quiet.

Governance Parameters That Affect Rewards

Subscribe to governance notifications on forum.pokt.network to track proposed parameter changes.