Index methodIndexIndex methodmethod

Tips: read by the program#

For each cohort validator, in cohort order, the program loads its Jito tip distribution account for the epoch and requires all of the following, or the post fails:

• The owner is the Jito tip distribution program, 4R3gSG8BpU4t19KYj8CfnbtRpnT8gtk4dvTHxVRwc2r7, and the account isn't executable.
• The address is the program-derived address ["TIP_DISTRIBUTION_ACCOUNT", vote account, epoch as u64 little-endian] under that program.
• The data is 168 bytes, starts with the TipDistributionAccount discriminator and has zero padding after byte 156.
• The recorded validator is the cohort's vote account, the upload authority is the cohort's authority, the account was created for this epoch and doesn't expire before the epoch's delay limit (Jito lets anyone close an expired distribution), and the commission is at most 10,000 basis points.
• A merkle root is present and non-zero, at least one claim has been made from it, claims don't exceed its node count, and claimed funds don't exceed max_total_claim.
• The account holds enough to pay what it declares: max_total_claim ≤ balance + total claimed − rent.

The epoch's tips are the sum of every cohort validator's max_total_claim.

The source hash#

While reading, the program builds the source hash:

Finalizing reads the same accounts again and requires the same total and the same hash. Anyone can recompute both from chain data and compare them with the checkpoint.

Stake: recorded and attested#

Solana's RPC can't return a validator's stake for a past epoch, so the stake is recorded near the start of each epoch. The collector reads the cluster's genesis hash and the epoch, reads every vote account's active stake, then reads the epoch again; both reads must land in the same epoch and inside a short boundary window, and every cohort validator must appear with stake above zero. The record keeps the raw responses and is signed.

When the checkpoint is posted, the oracle and the reviewer sign the per-validator stake. The program checks that it has one positive value per cohort validator and that the observed slot falls inside the epoch. It can't check the values themselves; challenges can.

The rate#

Settlement uses min(rate_ppb, market cap). The checkpoint always keeps the uncapped rate, so a spike above the cap stays visible.

What would make an epoch wait#

• A cohort validator's distribution has no root, or no claim yet. Jito lets the uploader replace a root until it is first claimed from, so the program waits rather than read a value that could change.
• An account's layout or owner doesn't match. Collection halts rather than guess.
• A posted checkpoint is challenged and the ruling is still open.

None of these is ever filled in as zero. If an epoch can't become final within the delay limit, positions waiting on it can be ended.