Whitepaper / ADMISSION, SIGNATURES, AND ORDER COMMITMENTS
Dexter whitepaper

ADMISSION, SIGNATURES, AND ORDER COMMITMENTS

Page last sync: March 21, 2026
Sections 3 Read 1 min Whitepaper chapter
Requirement Why it exists
Agent authorization Binds the signer to an approved account policy
EIP-712 order signature Proves explicit user intent for the submitted order
Monotonic seq Preserves replay protection and deterministic ordering
createdAtTs guard Rejects stale or backdated signed orders
Order commitment guard Anchors order-arrival evidence when commit mode is active
IOC-only policy Keeps the live execution path narrow in production when GATEWAY_REQUIRE_IOC is enforced

#Authorized signed flow

A client does not simply sign an order and hope the venue accepts it.

In the production path, the account first establishes a self-policy through POST /agent/authorize. That step tells the gateway and engine which signer is allowed to act for the account.

Once that policy exists, each order arrives as EIP-712 signed data rather than as an unsigned instruction.

The engine can therefore reject unauthorised signers before it ever considers pricing or risk.

The signed payload also carries timing and ordering context. In production, createdAtTs is checked so stale, future-skewed, or backdated orders do not drift into the matching path, and non-IOC flow is rejected when GATEWAY_REQUIRE_IOC is enabled as the default live execution posture.

#Sequencing and on-chain commit evidence

Dexter also uses monotonic sequencing so the runtime can preserve a deterministic event order.

When commit guard is active, the gateway must record an order commitment before placement. The relevant order hash is written into the on-chain OrderCommitRegistry through commitOrder or commitOrders.

That does two things at once.

It narrows the admission path operationally, and it gives later fraud-proof review a public timestamped record that the order existed before the engine claimed to match it.

TEXT
 POST /agent/authorize
   -> self-policy becomes active
   -> client signs IOC order payload with nonce, createdAtTs, goodTilTs, and seq
   -> gateway enforces IOC policy and records commitOrder(...) when policy requires it
   -> runtime checks signer, timestamp, seq, and commit evidence
   -> only then can pricing and fill logic run

#Reviewing the admission boundary

The goal is not to add ceremony for its own sake.

It is to make the live execution path narrow enough that a technical reviewer can answer simple questions: who was allowed to sign, in what order the request arrived, and whether the runtime matched something that had already been externally anchored.