Token

The protocol token is the unit of account inside the network. It is the medium of validator rewards, the bond against fraud, the right to vote, and the asset whose trading sustains the treasury. This chapter sketches its role; the precise economic parameters are intentionally not specified here.

What the token is for

The token serves four distinct functions:

1. Settlement of compute. Validators are paid in tokens for serving inference, running training jobs, hosting data, and auditing peers.
2. Stake. Validator participation requires posting tokens as a bond; misbehavior is punished by slashing.
3. Governance weight. Voting on parameter changes, treasury disbursements, and acceptance-set changes is weighted by token holdings and tenure.
4. Sink and source. Trading the token on open markets generates the fee revenue that funds the treasury, which funds the network.

A reader is asked to keep all four functions in mind simultaneously; the token cannot be reduced to any one of them without losing the structure that makes the system coherent.

Demand side

Demand for the token arises from the four functions above:

• Validator demand. New validators acquire tokens to stake. As the network grows, stake requirements scale with the size of the jobs validators are eligible for.
• Governance demand. Participants who wish to influence the network's direction acquire tokens.
• Speculative demand. Participants who anticipate that the network's value will grow over time acquire tokens.

The third source is the largest in absolute terms but the least durable. The first two are smaller in flow but provide the structural floor.

Supply side

The supply is fixed at network genesis. There is no inflation, no emission schedule, no future mint. Operational funding is paid from treasury revenue, which derives from trading activity, not from issuance.

The fixed-supply choice is constitutional and not a parameter. Changing it requires the full migration described in Governance.

Deployment

The token is issued as a standard SPL token on Solana. The mint authority is revoked at genesis and the freeze authority is left unset. The deployment uses the original SPL token program, not the Token-2022 extension set; transfer-side mechanics are out of the token contract itself and live in the liquidity layer.

Liquidity and the sink

Liquidity is concentrated on Raydium CPMM. The treasury seeds and continues to hold a concentrated-liquidity position whose price range is set by governance. Swap fees accrued by that position flow to the treasury on a continuous basis.

The mechanism is straightforward: the more the token is traded against its quote asset, the more swap-fee revenue accumulates in the treasury position. The treasury, in turn, pays validators. The cycle is the network's metabolism: every swap funds a small slice of the network's continued operation, and the protocol's own liquidity is the sink.

This design avoids embedding a transfer tax in the token contract. The token itself is fungible and unencumbered; only the protocol-owned liquidity position participates in the revenue cycle. Third-party holders are not taxed on transfer.

Allocation and distribution

The initial allocation is published at deployment. The codex deliberately does not include allocation tables; those are operational artifacts of a specific deployment, and including them in the codex would imply a permanence that the codex does not warrant. The deployment-specific token document is the authoritative source.

The codex states only that any allocation must satisfy the constitutional constraints:

• No allocation may grant unilateral control over governance.
• All allocations are public, vested where appropriate, and verifiable on chain.

What this chapter does not state

The codex does not specify the price range of the protocol-owned liquidity position. It does not specify the validator reward rate. It does not specify the distribution between classes of work (inference vs training vs storage vs audit). It does not specify the slashing magnitudes beyond their constitutional caps.

These are operational parameters. They are set by governance, published in machine-readable form, and revised over time. A reader interested in the current values should consult the live registry, not this document.

What this chapter does state

The token has exactly the four functions listed above. Any proposal that adds a fifth, or removes one, is a constitutional change and is governed accordingly. The protocol's economic claims rest on this functional decomposition; the specific magnitudes are tuning, not architecture.