ADMISSION, SIGNATURES, AND ORDER COMMITMENTS

Six requirements gate every order. They run in fixed order and any failure aborts the request before the pricing layer sees it. The first three are signer-and-payload checks; the last three are timing, commitment, and execution-shape policy.

#Authorized signed flow

A client cannot sign an order and hope the venue accepts it. The account first registers a self-policy through POST /agent/authorize, which records the specific signer key allowed to act on its behalf. That separation matters in practice: the account's withdrawal key, KYC binding, and referral cash never need to touch a trading session — a hardware wallet, a session key, or an API client takes over the signing surface without the rest of the wallet ever being exposed.

Once authorization exists, every order arrives as an EIP-712 typed payload rather than an unsigned instruction. The signed structure carries the market, side, size, limit price, validity window (createdAtTs, goodTilTs), and the account's monotonic seq. The engine rejects unauthorized signers, missing seq, expired or future-skewed timestamps, and non-IOC payloads at the gate — none of those failures reach the pricing or risk layer. In production this is enforced by GATEWAY_REQUIRE_IOC at the gateway and by the runtime's payload validator, so the same rule is checked twice on independent code paths.

#Sequencing and on-chain commit evidence

Monotonic sequencing gives the runtime a deterministic event order. Each account's seq advances strictly upward, so two independent observers replaying the same chain see the same order of fills. The runtime rejects any payload whose seq is not greater than the previously accepted seq for that account — a replay, a network re-order, or a duplicate retry all collapse into a single accepted event.

When commit guard is active in production, the gateway anchors the order hash on the OrderCommitRegistry contract on Base through commitOrder (single) or commitOrders (batch) before the runtime is allowed to match. That achieves two distinct things in one step. It narrows admission: the runtime will not price an order whose commit is missing. And it produces a public, timestamped, on-chain record that the order existed in the form the signer attested to, before any fill could have been generated — which is what later dispute review checks against.

 POST /agent/authorize
   -> signer policy becomes active for the account
   -> client signs EIP-712 IOC payload (market, side, size, price, createdAtTs, goodTilTs, seq)
   -> gateway enforces GATEWAY_REQUIRE_IOC and validates payload shape
   -> commitOrder(orderHash) lands on OrderCommitRegistry on Base
   -> runtime re-checks signer, seq monotonicity, timestamps, and commit presence
   -> only then does vAMM pricing and fill logic run

#Reviewing the admission boundary

The admission stack is not ceremony. It exists so a technical reviewer can answer three questions from public state alone: which signer was allowed to act for this account at the time of the order, in what order the requests arrived relative to one another, and whether the runtime matched a payload that had already been anchored on-chain. If any of those answers is "we cannot tell," the venue is operating outside its own admission contract. With agent authorization, monotonic seq, and the OrderCommitRegistry anchor, all three answers come from data a reviewer can fetch without trusting the venue's word.

#Why this matters for the leaderboard and payouts

• Trade history is anchored on Base. Every order's hash hits the OrderCommitRegistry through commitOrder before the runtime matches it. A podium finish or a 90 / 10 funded payout can be reproduced from the chain — the venue cannot rewrite the history that a payout was calculated against, because the timestamp of each commit is older than the fill it justified.
• Monotonic seq prevents double-counting. A network retry, a relayer race, or a client bug that re-sends a payload all collapse into one accepted event because the seq has already advanced. The leaderboard cannot double-count a fill, and a profit-share withdrawal cannot be disputed by a duplicate fill claim arriving later.
• Agent authorization isolates the trading surface. The wallet that holds challenge entries, funded payouts, and DXTR stake does not need to sign trades. POST /agent/authorize binds a separate signer — hardware wallet, session key, API client — to the account policy. If the trading key leaks, withdrawals, KYC binding, and referral cash remain on the original wallet and outside the attacker's reach.
• createdAtTs / goodTilTs block replay windows. A signature is only valid inside its declared validity window. A signed payload captured 10 minutes ago cannot be replayed today, even if the signer key is later compromised — the runtime rejects it on the timestamp guard before any further check.
• Same gate for everyone. A copy-trading client, an institutional API integration, and a retail wallet all authorize, sign, commit, and submit through the same boundary. There is no privileged lane that lets the venue admit one class of order under a different rule.