Koppa economics

Value measured by useful work

SUM Chain aims to denominate value in real productivity, storage held, blocks produced, inference verified. Every fee figure on this page is grounded in code or live mainnet parameters; design directions that are not yet implemented are labeled as such.

800B Ϙ
Canonical supply
after supply migration
9
Decimals
1 Ϙ = 1,000,000,000 base
1000
Min fee (base)
0.000001 Ϙ · live
0
Automatic emissions
no block rewards, no inflation
Live supply · chain_getSupplyInfo

Supply state, read from the chain

Canonical supply, account balances, protocol reserve, burns, and any governance-minted expansion are fetched from the public RPC on load. If a node does not yet serve the supply methods (pre-correction binaries), this section says so instead of showing numbers.

Current supply composition

Koppa & base units

A stable unit of account

Koppa (Ϙ) has nine decimals: one Koppa is 1,000,000,000 base units. There are no automatic emissions, no inflation and no block reward. Initial canonical supply is 800B Koppa after the coordinated supply migration; the 799B correction delta lives in a non-transferable ProtocolReserve, not in accounts. Future supply expansion, if ever needed, requires explicit on-chain consensus governance. Validators are paid from fees, not new issuance.

koppa.units

symbol
Ϙ (Koppa)
decimals
9
base_unit
1 Ϙ = 1,000,000,000
total_supply
800,000,000,000 Ϙ
issuance
none automatic; governance-only expansion
ProtocolReserve

How the supply is distributed

1B Koppa was allocated at genesis to the two bootstrap validators. The 799B correction delta is non-transferable ProtocolReserve supply, released only through service grants earned by network participation or native-Koppa consensus governance. Figures follow the published economic model.

Designed pool split (protocol constants; live remaining balances above):

Governance reserve
40% · 319B Ϙ
Ecosystem / public goods
20% · 160B Ϙ
Archive service
15% · 120B Ϙ
Compute service
15% · 120B Ϙ
Validator bootstrap
10% · 80B Ϙ
Service grants

Grants are earned by network work, not handed out

The reserve's service pools bootstrap operators without a supply shock: every grant is mostly locked, and liquidity comes from verifiable protocol work. Claiming is gate-controlled: the service-grants gate is deployed in runtime genesis and activates at height 9,200,000, after which claims go live automatically.

  • 10% liquid / 90% locked. A claimed grant credits a tenth immediately; the rest is locked service stake.
  • Locked stake unlocks 1:1 against protocol-earned Koppa , proposer fees for validators, PoR payouts for archives, settlement rewards for verifiers.
  • Ordinary transfers do not unlock. Received or self-sent Koppa never counts as earned credit; only the protocol reward paths do.
  • No automatic emissions. Grants move existing reserve supply; they never mint.

grants.rules

split
10% liquid · 90% locked
unlock
1:1 vs protocol-earned Koppa
transfers_as_credit
never
genesis_validators
first two excluded (funded at genesis)
early_archive_nodes
eligible via service evidence
retroactive_grants
none, counting starts at correction
slashing
forfeits locked stake to reserve
claiming
gate-controlled · activates at height 9,200,000

The first two genesis validators are excluded from validator bootstrap grants because they were funded 500M Ϙ each at genesis. Early archive nodes are not excluded, they earn archive grants through the same service evidence (successful PoR proofs, active service) as future nodes, with no automatic lump sums.

Live network feesLive on mainnet

Fees pay the validators who produce blocks

Under Proof-of-Authority, transaction fees go to the block proposer, the validator that produced the block. Fees are not burned and no new tokens are minted. The values below are live mainnet chain parameters.

verified 2026-07-02 · height 8,183,329

fee.params · live

consensus
Proof of Authority
min_fee
1000 base (0.000001 Ϙ)
fee_recipient
block proposer
fee_burn
none
storage_fee_per_byte
100 base units
Storage economicsLive on mainnet

Storage is funded by a per-file fee pool

Registering a file locks a fee deposit into that file’s fee pool. Archive nodes that answer Proof-of-Retrievability challenges with valid Merkle proofs are paid from the pool; nodes that let a challenge expire are slashed. The constants below are defined in the storage protocol code.

fee_poolCHALLENGE_REWARDSLASH_PERCENTAGE

storage.economics · code

registration
fee_deposit → fee_pool
challenge_reward
10 Ϙ (from fee pool)
slash_on_expiry
5% of staked balance
abandonment
10% of pool retained
storage_fee_per_byte
100 base units
AI compute accounting

A productivity anchor for inference

The intended design anchor is that one LLM token of useful inference work maps to one Koppa base unit, value denominated in productivity rather than speculation.

Design direction, not yet implemented in code

The 1 LLM token = 1 base unit mapping is an accounting direction, not a live protocol formula. Today, OmniNode records verifier-signed InferenceAttestation entries on-chain, but the chain does not price, meter, or settle inference payments, there is no on-chain inference fee formula, reward, or slashing. Those are on the roadmap.
Governance economicsCode-backed · dormant

Proposal bond & treasury, when activated

Governance v1 defines an optional proposal bond and a treasury address. These live in the code but apply only if a network activates governance, none is configured on mainnet, so no bond, treasury, or governance fee is in effect today.

governance.params · dormant

proposal_bond
configurable (default 0)
treasury
optional address
bond_settlement
return / burn
mainnet_status
not configured