Rewards

​

Overview

Validators earn 12.5% of all trading fees. Each settled fee credits that share to the validator reward pool, and the pool is distributed every consensus epoch - roughly 5 seconds of consensus rounds. Each validator’s share is set by a consensus-agreed weight with three components:

​

The Weight Vector

Each epoch assigns every validator $v_j$ in the epoch’s active set of $n$ validators a reward weight $w_j \in [0, 1]$. The weight is a direct share of the pool: $$\text{reward}_j = \text{pool} \times w_j$$ The weight vector has two properties:

• Deterministic. Weights are computed from committed ledger data only, using integer fixed-point arithmetic in parts-per-million (ppm). Every validator derives byte-identical weights, so any mismatch is immediately detectable, like any other execution divergence.
• Conservative. Weights sum to at most 1. Credit that cannot be attributed cleanly - unknown source, self-reports, validators outside the active set - is burned, never redistributed to other validators. The undistributed remainder of the pool stays in the pool account and carries into later epochs.

​

Origination

Origination rewards the validator that sourced fee-generating order flow. When a transaction first arrives at the network - via a validator’s HTTP or WebSocket ingress - downstream validators remember which peer first delivered it to them. If that transaction later produces a fill that adds value to the validator reward pool, the exact positive pool contribution is attributed to that peer. Origination credit is earned only for the exact positive atoms the fill added to the validator reward pool. A fill that adds zero atoms - because it paid no fee, its fee funded a maker rebate, or it otherwise did not fund the pool - earns no origination credit. Attribution is peer-witnessed. Each validator $v_i$ reports, once per epoch in a signed record, how many positive reward-pool atoms came from fills whose transactions it first heard from each peer: $$f_i[j] = \frac{A_i[j]}{T_i}$$ where $A_i[j]$ is the exact number of positive reward-pool atoms validator $i$ attributes to transactions first heard from validator $j$, and $T_i$ is the total positive reward-pool contribution validator $i$ observed that epoch, including unattributed atoms. The origination weight averages these rows across all $n$ validators: $$w_j^{\text{orig}} = \frac{1}{n} \sum_{i \neq j} f_i[j]$$ Self-reports are burned: a validator’s claims about its own volume never count - only what its peers witnessed. A dishonest reporter cannot raise its own weight, and can shift any peer’s weight by at most $1/n$. A validator that reports nothing contributes an all-zero row while the divisor stays $n$, so a missing report shrinks total credit rather than shifting it. Positive pool atoms with no attributable source remain in $T_i$ but are assigned to nobody, preventing unknown flow from being redistributed to named peers.

​

Participation

Participation rewards consensus liveness. For each committed round, validator $i$ credits every peer whose commit vote matched a digest $i$ itself committed. Per epoch: $$w_j^{\text{part}} = \frac{1}{n(n-1)} \sum_{i \neq j} \frac{P_i[j]}{Q_i}$$ where $P_i[j]$ counts the rounds in which validator $i$ observed $j$ voting with the committed quorum, out of the $Q_i$ rounds $i$ committed that epoch. A fully live validator set splits the participation share equally; a validator that is slow, frequently in the minority, or offline loses exactly the fraction of rounds it missed.

​

Stake

The stake component is a linear share of Solana stake: $$w_j^{\text{stake}} = \frac{s_j}{\sum_{k} s_k}$$ where $s_j$ is validator $j$‘s Solana stake, read at finalized commitment from the co-located Agave validator (see Stake Inheritance), and the sum runs over the epoch’s pinned active set. Stake is pinned once per epoch, so mid-epoch stake changes take effect at the next epoch boundary.

​

Blending

The final weight sums the three components in their protocol-fixed proportions: $$w_j = 0.50 \cdot w_j^{\text{orig}} + 0.40 \cdot w_j^{\text{part}} + 0.10 \cdot w_j^{\text{stake}}$$ The blend constants are protocol parameters, identical on every validator.

​

Epochs and Settlement

• Epoch length: ~5 seconds of consensus rounds.
• Reporting: each validator’s origination and participation rows are included in its signed epoch beacon transaction - the same per-epoch transaction that carries the validator’s clock beacon - so the raw inputs are themselves committed, tamper-evident ledger data.
• Settlement lag: epoch $N$ settles two epochs later (~10 seconds), giving every beacon time to commit and propagate. Settlement uses the validator set and stake pinned at epoch $N$, not the live set.
• Payout: a system settlement transaction anchors the payout point in committed order. On applying it, every validator derives the same weights from the same committed rows and credits the same amounts from the pool into each validator’s exchange account.

There is no claim transaction. Rewards land automatically in the validator’s exchange account at settlement, in USDC - a regular balance, transferable via native transfer or withdrawable to Solana. Each epoch settles independently: rewards are earned for what a validator did that epoch, not accrued against a running total.

​

Auditability

The entire reward computation is reproducible from the committed ledger alone: attribution rows are committed in beacon transactions, the validator set and stake are committed state, and the weight computation is a pure function of that data. An external observer can re-derive every credit. Validators can inspect reward state live via the /status endpoint: Comparing settled_weights across validators is the standing health check for reward accounting.