09 · Settlement & Fairness

09.01 · What is settled

Committed wager principal, not the trading account itself

Each player commits the agreed wager amount to the approved custody/accounting path before Ready. The winner receives the distributable pool after any explicitly approved fee; a tie/void follows the refund rule. Trading P&L determines the winner but is not itself transferred by the settlement service.

Production gate: the exact escrow/account segregation, regulated operator, jurisdictions, sanctions/KYC, dispute authority and withdrawal operations need specialist approval. The architecture decision is preserved; real-money release is blocked until the implementation proves it.

09.02 · Authorization state

Settlement starts only from one immutable match revision

The Match DO authorizes settlement only after both wager commitments are verified, the match reached its stored snapshot deadline, the EquitySnapshot is complete and hashed, and flattening is verified or the published exceptional-state rule authorizes a decision. The authorization stores match revision, snapshot ID and formula version.

09.03 · Exact baseline formula

Normalize performance; keep decimal precision explicit

markValue(position) = signedSize × referencePrice
playerEquity = collateralBalance
             + Σ unrealizedPnl(position, referencePrice)
             + realizedPnlSinceStart
             - feesSinceStart
             + fundingPaymentsSinceStart

score = round((playerEquity - startingEquity) / startingEquity, SCORE_SCALE)

winner = higher score
tie    = abs(scoreA - scoreB) ≤ TIE_EPSILON

startingEquity is the verified match-start equity after wager commitment and before live trading, normalized to equal competition capital by the approved funding rule. Decimal arithmetic and explicit rounding mode/scale are mandatory. SCORE_SCALE and TIE_EPSILON are versioned policy values, not model choices.

09.04 · Reference price and timestamp

One deadline, a predeclared source hierarchy

snapshotAtMs is the persisted match deadline. Reference prices come from a preapproved hierarchy such as a Hyperliquid authoritative mark/oracle snapshot or bounded time-window reference that cannot be selected after seeing outcomes. A player's own last trade is never the sole mark. Missing/stale sources produce the predefined fallback, manual review or refund—never an invented price.

09.05 · Fees, funding and flattening

Count economic effects once

Exchange fees and rebates occurring between match start and snapshot are included once.
Funding payments with exchange timestamps inside the interval are included with their sign.
Post-snapshot flatten fills/fees remove risk but do not alter the frozen score.
Wager-service fees, if legally and product-approved, are separate from trading equity and disclosed before acceptance.

09.06 · Ties, retries and records

Pure decision, idempotent effect

The calculator is a pure versioned function. A tie refunds both committed principals under the published fee rule. The immutable decision is stored before a payout/refund effect. decisionId is the idempotency key for Workflows/Queues and the custody ledger; retries reconcile the same effect and cannot create another payout. Records include commitments, authorization revision, snapshot and source hashes, formula values, rounding, outcome, effect attempts, final ledger entries, replay manifest and administrative actions.

09.07 · Anti-manipulation and administration

Precommit rules and narrow operator power

Equal start-capital verification and identical market/risk policy version.
Deadline/lock state enforced server-side; late/duplicate actions rejected.
Reference source and fallback committed before the match.
Exchange reconciliation and source hashes retained for both players.
Administrative override requires strong authentication, reason code, two-person approval where applicable, append-only record and user-visible dispute outcome.
Future trust minimization may add segregated/on-chain proofs, but does not silently replace the approved baseline.