Concepts

Checkpoints and disputes

How one epoch's number is posted, challenged, ruled on and made final.

  1. PostedTips read on chain, stake attested, proposal bond paid
  2. Challenge windowAnyone can challenge with a bond
  3. FinalSettlement can use it; it never changes again

Challenged · settlement on this epoch waits for the dispute authority

  • Value upheld. The value is final at once, and both bonds go to the proposer.
  • Value rejected. Both bonds go to the challenger. A corrected checkpoint can be posted for the epoch.

No final value by the delay limit. Posting and finalizing close for that epoch, bonds go back to whoever paid them, and positions waiting on it can be ended.

Posting#

After an epoch ends, its checkpoint is posted with three signatures: the proposer, who pays the proposal bond and locks the CREST proposal stake, and two distinct keys that attest the stake, the oracle and the reviewer. The program reads every cohort validator's tip distribution account for the epoch itself, adds up the tips, divides by the attested stake and records the rate. The challenge window opens at that slot, and it has to close before the delay limit runs out, so a post that comes too late for its window is refused.

Challenging#

Until the window closes, any wallet other than the proposer, the oracle, the reviewer and the dispute authority can challenge the checkpoint by paying the challenge bond and committing to a hash of its evidence. A challenge freezes the checkpoint: nothing can settle against it until the dispute authority rules.

Ruling#

The dispute authority rules on each challenge:

  • Value upheld. The checkpoint is final at once. The program reads the cohort's tip accounts again, as finalizing does, then the proposal bond, the challenge bond and the CREST stake all go to the proposer.
  • Value rejected. Both bonds and the proposer's CREST stake go to the challenger, and the checkpoint is marked rejected. A corrected checkpoint can then be posted for the same epoch, with a new bond and a new window.

Finalizing#

Once the window has passed with no open challenge, anyone can finalize the checkpoint. The program reads the cohort's tip accounts once more and refuses if the total or the source hash has changed since the post. Otherwise the proposal bond and the CREST stake go back to the proposer, and the checkpoint is final. A final checkpoint never changes, and every position on that epoch can settle against it.

The delay limit#

All of this must happen by the epoch plus the delay limit, which is at most ten epochs. After that, the epoch's checkpoint can't be posted, ruled on or finalized. Any bonds and CREST stake still held go back to whoever paid them, and positions waiting on the epoch can be ended. A final checkpoint stays valid after the limit, so positions that fell behind can still settle against it.

Reading checkpoints in the app#

The chart and the Index view draw each epoch by its checkpoint's status:

StatusDrawn asMeaning
In challenge windowA dashed barPosted, not final yet.
DisputedA hatched barChallenged. Settlement waits for the ruling.
RejectedA crossRejected or expired. A new checkpoint may follow.
FinalA solid barSettlement can use it.

The bond sizes, the CREST stake, the window length and the delay limit are set when a configuration is created. Their live values are on Parameters.