Disputes and recovery
The exact five-minute response paths for signed turn games.
An agreed checkpoint
A checkpoint is a valid ongoing state authenticated by both registered session signers. The initial state has a special contract-defined form and does not require two checkpoint signatures. For later checkpoints, preserve the state and both signatures so you can prove agreement.
Do not sign two different states with the same sequence and parent hash. The contract can use those signatures as proof of equivocation even if no ordinary move transaction was sent.
Unilateral terminal proposal
proposeTerminalSettlement validates an agreed checkpoint and one valid terminal move signed by the correct mover. It records the proposed outcome and starts a five-minute response deadline. A challenger can submit a jointly signed terminal state at the same or a later sequence before that deadline.
If the window expires, anyone can finalizeSettlement. A terminal proposal need not be submitted by the winner: the evidence, not the caller, determines the payout.
Onchain play
Only playerA or playerB can openDispute from an agreed ongoing checkpoint while the game is Active. The contract records that checkpoint as its canonical dispute state and gives the next player five minutes to respond. submitDisputeMove accepts a valid transition and mover signature from any relayer.
An ongoing move resets the next response deadline to five minutes. A terminal move settles immediately. At or after a missed response deadline, anyone can claimTimeout and the player who was supposed to move loses.
Equivocation
proveEquivocation checks two distinct valid states with the same sequence and parent and authentic signatures from the accused registered signer. It can be submitted during Active, Dispute, or SettlementProposed status. The game enters EquivocationProposed, and after five minutes finalizeEquivocation awards the other player the decisive outcome.
The current contract provides no separate challengeEquivocation method. The proof is checked when submitted. The response delay is a finalization delay, not a generic arbitration process.
Resignation and key loss
A main wallet can resign its active game, or a relayer can submit an authorized session-key resignation signature. Resignation produces a decisive result for the opponent and the usual fees. The main wallet retains claim rights; the session key does not control token withdrawals.
If you lose a session key, the contract does not rotate it or restore it. You may be unable to answer signed moves and can lose by onchain timeout. Local transcript availability matters independently of relay availability.
Status-specific actions
| Status | Available path |
|---|---|
| Open | Join before the deadline; cancel after it. |
| AwaitingStart | Participant starts before deadline; anyone cancels after. |
| Active | Cooperate, propose terminal state, open dispute, prove equivocation, or resign. |
| Dispute | Submit a signed move before deadline, claim timeout afterward, or prove equivocation. |
| SettlementProposed | Challenge with eligible joint terminal evidence before deadline; finalize afterward; equivocation proof is also possible. |
| EquivocationProposed | Finalize after response deadline. |
| Settled / Cancelled | Eligible main wallets claim payout or refund once. |
Source reference
Checked against the source shipped with this documentation. Contract calls and units are detailed in the contract reference.
Imported source files 27
Supporting contracts, interfaces, and libraries imported by the sources above, including their dependencies.