crestDocs

Concepts

The crest index

What the index counts, how one epoch's number is computed, and what it leaves out.

Two parts of staking yield#

A staker's reward for an epoch has two sources. Inflation is minted on a published schedule and shared by stake: that is the base. On top of it, validators running the Jito client collect tips from traders and searchers who want their transactions placed first. After the epoch, each validator's tips are distributed to its stakers through Jito's tip distribution program: that is the crest.

The base is close to known in advance. The crest follows demand for blockspace, so it is high when trading is busy and low when it isn't. Crest's index turns it into one number per epoch that a swap can settle against.

The number#

For a finished epoch, the index adds up the Jito tips of a named cohort of validators and divides by the cohort's stake.

tips = Σ max_total_claim of each cohort validator's tip distribution
stake = Σ active stake of each cohort validator at the start of the epoch
rate = floor(tips × 1,000,000,000 ÷ stake) ppb per epoch
  • Tips come straight from Jito's tip distribution accounts. When a checkpoint is posted, the Crest program reads each cohort validator's account for that epoch itself. It checks the account's owner, address, validator, epoch and upload authority, and reads max_total_claim, the total the account will pay out. It reads every account again before the checkpoint becomes final and refuses if anything changed.
  • Stake for a past epoch can't be read on chain, so it is recorded at the start of the epoch and attested by two keys, the oracle and the reviewer, when the checkpoint is posted. This is the one input the program takes on trust, which is why every checkpoint carries a bond and can be challenged. See Checkpoints and disputes.
  • The rate is in parts per billion per epoch. The app shows it as a percentage per epoch: 58,000 ppb is 0.0058%.

Why per epoch#

Payments happen once per epoch, so the index is per epoch, and so is every rate in Crest. The app never converts it to a yearly figure. Epochs vary in length with slot times, and a yearly number would need a guess about how many epochs fit in a year.

What it leaves out#

  • Inflation. That is the base, and it isn't part of the index.
  • Priority fees. They go to each block's producer directly, and no per-epoch account records them where a program could read it.
  • Validators outside the cohort. The cohort is a named sample of up to eight validators, not the whole network.
  • Fees inside the distribution. max_total_claim is gross: it includes the validator's commission and any distribution fees. The index measures what the cohort's tip accounts pay out in total, not what one staker nets.

The cohort#

The cohort is fixed when Crest is configured: every validator's vote account and the one authority allowed to upload its tip distribution root. It can't be changed afterwards, and every market settles against it. The Index view lists the cohort with each validator's attested stake for any epoch.

When an epoch's number can exist#

A checkpoint can be posted only after the epoch has ended and every cohort validator's tip distribution has a final root. Jito lets the uploader replace a root until the first claim is made from it, so the program waits for at least one claim on each. A missing root is never counted as zero: the epoch simply waits, and so does settlement.

The cap#

Each market sets a cap on the crest it settles at. A checkpoint always records the raw rate; settlement uses the raw rate or the cap, whichever is lower. The cap bounds what the short side can lose in a single epoch, which is what lets its deposit be finite.