Tokenomics Deep Dive

This page covers the internal economics of Shannon at the protocol level — Token Logic Modules, settlement math, relay mining difficulty, and mint allocation. If you’re looking for a token holder overview of POKT economics, see Tokenomics instead.

Token Logic Modules (TLMs)

Shannon implements modular tokenomics through Token Logic Modules (TLMs). Each TLM represents a distinct economic model that can be applied per-service or globally. This modular design lets the protocol evolve its economics without breaking changes.

Relay Mining Burn (RMB)

The base deflationary model. Applications burn POKT for compute units consumed, and the protocol mints up to (but never more than) the burned amount to reward actors.

burn_amount = compute_units × compute_units_to_tokens_multiplier
mint_amount = burn_amount × (1 - deflation_rate)

The key property: burn ≥ mint. Since the passage of PIP-41 (January 2026, implemented in v0.1.31), the global mint ratio is below 1 — currently 0.975, meaning only 97.5% of burned POKT is minted back. The remaining 2.5% is never created, producing permanent on-chain deflation that scales with network usage.

Source Boost TLM

Bootstraps rewards for new service owners. Provides additional minting to Source Owners beyond their standard RMB allocation. The boost progressively reduces as relay volume for the service increases — high relay volume means more RMB rewards naturally, so the boost becomes unnecessary. This is designed to attract new services to the network during the growth phase.

Supplier Boost TLM

Maintains competitive staking APR during low-volume periods. Provides additional minting to Suppliers beyond their RMB allocation, preventing stake exodus during network bootstrapping. The boost distributes evenly across session suppliers and penalizes those serving minimal relays. Like Source Boost, it scales down as the network matures.

Mint Allocation

Two separate governance parameters split minted tokens. They are easy to confuse:

• mint_equals_burn_claim_distribution splits the Mint=Burn settlement, which is how relays are paid.
• mint_allocation_percentages splits only the Global Mint amount (global_inflation_per_claim).

Both are stored in the tokenomics module params and are modifiable through governance. Values are live from MainNet.

message MintAllocationPercentages {
  double dao = 1;
  double proposer = 2;
  double supplier = 3;
  double source_owner = 4;
  double application = 5;  // Usually 0
}

Settlement Flow

Settlement occurs automatically after the proof window closes for a session. The tokenomics module’s EndBlocker processes all validated proofs.

Step 1: Proof Validation

The x/tokenomics EndBlocker retrieves all proofs ready for settlement — those where the proof window has closed and the proof passed cryptographic validation in x/proof.

Step 2: Compute Units Extraction

Compute units come from the claim’s SMST root. The root hash encodes both the Merkle commitment (proving relay data exists) and the sum (total compute units claimed).

claimed_compute_units = claim.root_hash.sum

Step 3: Token Conversion

Compute units are converted to token amounts using the compute_units_to_tokens_multiplier (CUTTM) and compute_unit_cost_granularity parameters from x/shared. On MainNet one compute unit currently costs 0.116016 uPOKT. Governance adjusts the multiplier so that compute units keep a fixed dollar value as the POKT price moves.

upokt_amount = claimed_compute_units × CUTTM ÷ compute_unit_cost_granularity

TLM modifiers are then applied based on the service and current network state.

Step 4: Burn from Application

POKT is burned from the Application’s staked balance. If the Application’s remaining stake falls below the minimum, it enters unbonding.

Step 5: Mint to Recipients

The final mint amount is split according to mint_equals_burn_claim_distribution and distributed:

• Supplier operator address receives the supplier share
• Source Owner of the service receives the source owner share
• DAO reward address receives the DAO share
• Block proposer receives the proposer share

Settlement Events

The tokenomics module emits events that operators and indexers can monitor:

• EventTypeClaimSettled — a claim was successfully settled with session ID, compute units, and token amounts
• EventTypeProofValidated — a proof passed validation
• EventTypeTokensMinted — POKT was minted to recipients
• EventTypeTokensBurned — POKT was burned from an Application
• EventTypeRelayMiningDifficultyAdjusted — per-service difficulty changed

Relay Mining Difficulty

Relay mining difficulty controls how many relays become “volume applicable” and thus count toward claims. This keeps on-chain data bounded regardless of total relay throughput.

How It Works

1. Each completed relay is hashed.
2. If relay_hash < target_difficulty, the relay is volume applicable and gets added to the Supplier’s SMST.
3. Only volume-applicable relays count toward claims and settlement.
4. Difficulty adjusts per-service to maintain a target number of claims per session.

Difficulty Adjustment

The algorithm uses an exponential moving average (EMA) of observed relay volume per service, similar conceptually to Bitcoin’s difficulty retargeting:

estimated_relays = EMA(recent_relay_counts_for_service)
adjustment_ratio = target_claims_per_session / estimated_relays
new_difficulty = current_difficulty × adjustment_ratio

When relay volume increases, difficulty rises (fewer relays pass the threshold), keeping on-chain claim data constant. When volume decreases, difficulty drops to maintain minimum proof density.

Deflation Mechanics (PIP-41)

Since v0.1.31 (February 2026), Shannon is actively deflationary. PIP-41 introduced the mint ratio, currently 0.975: for every 100 POKT burned by applications, only 97.5 POKT is minted to network participants. The remaining 2.5% is never created.

The amount removed scales with relay volume: the more the network is used, the more deflationary it becomes. For live burn and mint figures, see pokt.money or Pocket Analytics.

The mint ratio is governance-controlled. The DAO can vote to adjust it, and the Foundation has modeled dynamics down to a ratio of 0.5. The first value was chosen to minimize the impact on active suppliers while establishing the deflationary mechanism.

For each relay settlement cycle:
  burn_amount   = compute_units × CUTTM ÷ granularity   (all of it burned)
  mint_amount   = burn_amount × mint_ratio              (minted back)
  deflation     = burn_amount × (1 − mint_ratio)        (permanently removed)

Key Parameters Reference

Current MainNet values, read from chain when this page was built. Beta TestNet and local networks use different values.

Shared Parameters

params:
  num_blocks_per_session: "20"
  grace_period_end_offset_blocks: "10"
  claim_window_open_offset_blocks: "11"
  claim_window_close_offset_blocks: "10"
  proof_window_open_offset_blocks: "1"
  proof_window_close_offset_blocks: "10"
  supplier_unbonding_period_sessions: "1429"
  application_unbonding_period_sessions: "3"
  compute_units_to_tokens_multiplier: "116016"
  gateway_unbonding_period_sessions: "3"
  compute_unit_cost_granularity: "1000000"
  session_grid_anchor_height: "831001"
  session_number_at_anchor: "13851"

Tokenomics Parameters

params:
  dao_reward_address: "pokt1dr5jtqaaz4wk8wevl33e7vkxsjlphljnjhyq2l"
  mint_allocation_percentages:
    dao: 0.1
    proposer: 0
    supplier: 0.8
    source_owner: 0.1
    application: 0
  global_inflation_per_claim: 0.000001
  mint_equals_burn_claim_distribution:
    dao: 0.045
    proposer: 0.14
    supplier: 0.79
    source_owner: 0.025
    application: 0
  mint_ratio: 0.975
  overservicing_bonus_multiplier: "2"

Service Parameters

service:
  compute_units_per_relay: 1        # Base CU — configurable per service
  relay_mining_difficulty:
    target_hash: "..."              # Per-service difficulty target

Debugging Tokenomics

Settlement Not Occurring

# Check if proof window has closed
pocketd query shared params

# Look for settlement events at recent heights
pocketd query txs --events 'message.action=/poktroll.tokenomics.MsgSettlement'

Wrong Mint Amount

# Check compute units on the claim
pocketd query proof show-claim <session_id> <supplier_address>

# Check the token multiplier
pocketd query shared params | grep compute_units_to_tokens

# Check mint allocation percentages
pocketd query tokenomics params

Application Burn Not Happening

# Verify the Application has sufficient stake
pocketd query application show-application <app_address>

# Look for burn events
pocketd query txs --events 'coin_spent.spender=<app_address>'

Code Locations

Related Pages

• Tokenomics — token holder overview with Overview/Advanced tabs
• Shannon Architecture — module map and actor model
• Sessions, Claims & Proofs — claim/proof lifecycle detail
• Governance Parameters — how parameters are changed