Coin: Heads or Tails

User chooses

Heads or Tails, reward asset, and 1–200 USDG all-in.

Outcome

Exactly two outcomes: Heads or Tails. A verified uniform VRF word is domain-separated and reduced to one bit, so each side is 50% and neither side has a protocol advantage.

Win

A complete 2x principal USDG liability is created, then used for JIT reward delivery or cash fallback.

Loss

Principal becomes settled Reserve funding; the fee moves into settled Fee Escrow and becomes Treasury revenue only after flushFee.

Before gas and swap costs, a 50/50 Manual game returns 2B on a win and 0 on a loss while the user pays B + F; the expected payout is B, so the explicit economic cost is the 3.5% fee F subject to integer rounding.

Mystery does not let calldata choose the side or reward. Acceptance freezes the ordered Catalog version/hash and reserves the full prize notional against every member, but the concrete reward remains unassigned. onRandomnessReady derives side, outcome, and reward from independent domains of the verified VRF word, moves capacity from all-member unassigned exposure to the selected asset, freezes that reward, and only then enters RandomReady. Reward selection uses unbiased range mapping and cannot be changed during settlement.

All-in

1–10 USDG.

Win chance

50/50: independently domain-separated side and outcome bits match in exactly half of uniform cases.

Payout

2.5x principal; the extra 0.5x compensates the user for surrendering the reward/selection choice and is a separately locked Mystery bonus—not discretionary backend prize selection.

Access

A real seven-day holding report, an unused rolling allowance, and no existing Mystery pending Ticket.

Budget

Only qualified canonical Hook surplus. Game fees and losing principal cannot fund the bonus.

Accepted → AwaitingRandomness
AwaitingRandomness → RandomReady → Settled(Win | Loss)
AwaitingRandomness → Refunded (after the frozen timeout boundary)
Win → PurchasePending → StockDelivered
Win → PurchasePending → CashClaimable → CashClaimed

A late callback cannot revive a refunded Bet. Repeated callbacks and settlement attempts cannot duplicate funds. Pausing new Bets does not block existing settlement, refund, JIT retry, or cash claim paths.

After either frozen Coin timeout boundary is reached, anyone may call refundExpired. The Game returns B + F, releases Reserve/JIT capacity, and the Provider Bond pays exactly additionalReserveRaw = prizeNotionalRaw - B as a separate compensation transfer.

The Coordinator verifies a proof against the registered proving key and request block hash. The Game accepts only its configured path, so an operator cannot substitute an arbitrary word. A single self-hosted node can still withhold a proof; FLIP addresses liveness with frozen refund boundaries and provider-funded Bond compensation, not by calling the node trustless.

Functional Provider

Provider 4

Router path

Game → 4 via Randomness Router → Provider Adapter → Coordinator → Oracle Transmitter → callback

BHS contracts

blockhashStore + batchBlockhashStore

BHS Keeper

0xd9a1AB7fCB296bAA258ecD2cb8BAe0d0EA362DE2Copy

Functional result

9/9 fulfilled · 0 pending

• Provider IDs are never reused. A new Provider serves only new Bets; an existing Bet keeps its frozen legacy Adapter callback path.
• The same Bet is never re-requested during migration. Its original request either fulfills or reaches the frozen timeout/refund path.
• Do not remove a Provider, Adapter, Coordinator, BHS, or callback route until every request assigned to it has drained to zero pending.