MBMarket BenderSpecification system
08.01 · Challenge and acceptance

House and friend paths converge before readiness

A challenge records creator, network, allowed universe, wager terms, expiry and mode (House or friend invitation). Acceptance is authenticated and idempotent. Funding commitments are verified for both players before readiness; no client may force start or change terms after both accept.

08.02 · Formal state machine

One revision, explicit guards and terminals

Challengecreated · expiring
Acceptedboth principals bound
Readyfunds · signers · feeds
LivestartsAt → lockAt
Lockedcancel/reduce only
Snapshottedfrozen scores
Flatteningverify residuals
Settledreplay ready
StateEntry guardAllowed actionFailure terminals
ChallengeAuthenticated valid termsAccept, cancel, expireExpired, canceled
AcceptedTwo unique eligible playersVerify commitments/readinessRefund pending, abandoned
ReadyFunds/signers/feeds/policy verifiedAtomic startReadiness failed
LivePersisted timestamps and revisionBounded trading/steeringVoid/refund per outage rule
Lockednow ≥ lockAtCancel/reduce onlySnapshot review
SnapshottedImmutable evidence for both playersFlatten and calculateManual review/refund
FlatteningSnapshot immutableCancel/reduce/reconcileFlatten failed/manual review
SettledDecision and payout/refund reconciledReplay/dispute recordNone; corrections are new audited records
08.03 · Clock and locking

Persisted timestamps, not UI countdowns or delayed alarms

The Match Durable Object persists startsAtMs, lockAtMs and snapshotAtMs in the accepted start transition. Every command is checked against authoritative time and state revision. Clients derive countdown display from server timestamps. An alarm wakes reconciliation; its firing time never moves the deadline.

08.04 · Snapshot, flatten and settlement

Score first; risk removal second

At the deadline, new risk is rejected and the service gathers the immutable equity inputs for both players using the approved reference-price hierarchy. The score freezes from that common timestamp. Only then does each account run cancel-all plus fresh-position reduce-only flatten. Sequential flatten prices do not change the winner. Settlement requires the frozen snapshot and verified/explicitly escalated flatten status.

08.05 · Disconnections, outages and disputes

Published rules decide; operators cannot improvise silently

  • Player/opponent disconnect: server continues; reconnect returns current revision unless the published abandonment condition applies.
  • Failed participant before start: expire/refund; never start a one-sided live match.
  • Exchange outage: stop risk, use the predefined void/snapshot fallback based on outage timing and evidence.
  • Partial flatten: preserve frozen score, keep recovery active and mark settlement pending/manual review according to policy.
  • Dispute: retain immutable inputs, formula version, transitions and artifact hashes; administrative resolution creates a separate signed record.
Navigate specification

Search pages and sections