Escalation Game
The Escalation Game gives a finished Statoblast market a local, REP-backed resolution path before a universe-wide fork is necessary.
For a binary launch question, suppose Yes has 8 REP, No has 5 REP, and Invalid has 2 REP. The median balance is 5 REP, so 5 REP is the game's binding capital and determines its scheduled deadline. A deposit that raises only the leading Yes balance does not move that deadline; a deposit that raises Invalid above 5 REP raises the median and moves it later.
After the deadline, Yes wins only if it remains the unique strict leader. If two outcomes each reach the non-decision threshold before local finalization, the game records non-decision and the SecurityPool follows the Zoltar fork path. A tie is never treated as a local winner.
Deposits must also pass the pool's vault-backing and lifecycle checks and normally meet the configured start bond. A smaller deposit is accepted only when it exactly fills an outcome to the non-decision threshold.
Lifecycle: tentative claim → conflicting deposit → accepted amount and new deadline → local settlement or non-decision → child continuation after a fork → proof-backed claims.
Escalation
A vault owner with enough backing can add REP to an outcome with a valid deposit that meets the configured start bond. The deposit adds to that outcome's cumulative balance; it does not have to exceed the leader. The deadline moves only when the deposit raises the median outcome balance. Separately, the required support rises over time. This is the cumulative REP an outcome must hold for the game to still be worth contesting: until binding capital reaches it, the game stays open and the deadline keeps moving, so a side that stops adding REP eventually loses the ability to keep the dispute alive.
Required support. Nothing is required for the first three days. From day 3 the requirement climbs from the start bond to the non-decision threshold, reaching it on day 52. The EscalationGame reference gives the exact curve.
Try a simplified escalation round
This simulator uses the contract model: a three-day activation delay, a 49-day escalation interval, and the fixed-point required-support curve. Change the configuration, then choose an outcome and requested deposit to see clipping, tie adjustment, acceptance, or rejection.
Game settings
Player positions
Player move
Timeline
How the game ends
Once the relevant deadline or threshold is reached, the game follows one of two mutually exclusive paths:
- Strict local winner. After the scheduled deadline, exactly one outcome has the greatest balance. Statoblast finalizes on that outcome.
- Local non-decision. Two outcomes reach the non-decision threshold. Statoblast uses its fork path instead of choosing one locally.
Settlement rewards the side that held its ground. Winning deposits get their principal back plus a bonus. The runner-up's stake, the binding capital, pays for it: three fifths becomes the bonus pool and two fifths is burned. REP staked on a third outcome is forfeited: a local game sweeps it to the SecurityPool, while a game carried across a fork burns it. The bonus is only available on the portion of winning deposits up to the reward-eligible cap, one and a half times binding capital; deposits beyond that cap simply get their principal back. If Zoltar's fork threshold at settlement is lower than the game's non-decision threshold, every withdrawal is scaled down by that ratio, which can push the final transfer below principal. The EscalationGame reference works one payout through with exact numbers.
Escalation game continuation
Escalation game continuation uses Merkle Mountain Range carry proofs and nullifier roots to migrate user game deposits, without requiring expensive data copying efforts onchain.