Trading venue order lifecycle
How a signed order moves through intake checks, reservation, the orderbook, matching, and on-chain settlement, how a stop order arms and triggers, how a preopen auction opens the session, and how the venue recovers when a fill fails or a compliance change invalidates resting orders.
An order on the Trading Venue is an EIP-712-signed intent from the trader's own key. The venue checks it at intake, reserves the committed quantity in the trader's wallet, rests it on the orderbook, matches it by price-time priority, and settles matched fills on-chain in failure-isolated batches. A stop order takes a detour: it arms dormant with no reservation and enters this same lifecycle only when a settlement-confirmed print triggers it. On a market with a trading calendar, the session opens through a call auction before continuous matching begins. This page follows one order through that lifecycle and names what happens on every exit path.
System context
Related
- Trading Venue capability for the market model, custody model, and trust boundaries
- Trading venue market structure for reservation, trading authorization, and the price protection band as concepts
- XvP settlement flow for bilateral settlement without an orderbook
Order states
The venue reports one of nine order statuses. Four are open states and five are terminal.
| Status | Meaning | Reserved balance |
|---|---|---|
| Armed | A dormant stop order holding its signed intent. Not matchable, never in depth, waiting for a settlement-confirmed print to reach its trigger. | None; the venue reserves at trigger |
| Pending reservation | The order passed intake and its reserved-balance transaction is awaiting confirmation. The order is not matchable and not visible in depth. | Being established |
| Working | The order rests on the book at its price-time priority. | Held |
| Partially filled | Part of the quantity settled; the remainder still works. | Reduced with each fill |
| Filled | The full quantity settled on-chain. | Released |
| Cancelled | The trader cancelled the order; the cancellation is recorded on-chain so the signed order can never fill. | Released |
| Expired | The signed expiry passed. Expiry is enforced at match time and again on-chain at execution. | Released |
| Rejected | An intake check failed, the reservation did not confirm, or a stop's trigger-time reservation failed. The order never reached the book. | Never held, or compensated |
| Pruned | The venue removed the order: its fill failed at settlement, a compliance or custody change invalidated it, or a fee-schedule raise exceeded its signed fee cap. | Released |
Intake
Intake runs before anything is reserved. The platform rejects the order with a named reason when any check fails:
- The market's session accepts orders: continuous open, preopen, or an auction collection window. A closed session refuses new orders.
- The maker wallet belongs to a participant registered in the deployment's identity registry, and on a private market it is on the approved-participant list.
- The maker's trading authorization to the settlement contract covers the reserved amount plus the maximum applicable fee.
- For an institutional desk, the order stays within the desk's approved limits.
- The signed fee cap covers the market's current fee schedule.
- The order's price, quantity, and notional fit the market's tick size, lot size, and minimum notional, stay inside any active static and dynamic price band, and stay under any maximum-quantity and maximum-notional threshold.
- A good-till-date order carries a real expiry; the expiry is enforced at intake, at match, and on-chain at execution.
- The EIP-712 signature verifies against the maker wallet, smart-account signers included.
- The wallet's spendable balance covers the new reservation on top of every reservation the wallet already holds, across all markets.
A rejected order changes no state. The rejection reason names the failed check so the caller can correct it.
Reservation
An accepted order does not join the book directly. The venue first reserves the committed quantity in the trader's own wallet: the base token for a sell, the quote token plus the maximum applicable fee for a buy. The reservation is a partial freeze on the trader's balance, so the tokens never leave the wallet and the venue holds no pooled funds.
The order stays in the pending-reservation state until the reservation transaction confirms on-chain. Only then does it rest on the book and appear in aggregated depth. If the reservation reverts or times out, the platform rejects the order and compensates any partial state, so a failed reservation never leaves a stranded freeze.
Reservation accounting is cumulative per wallet and token across every market and order. Each partial fill reduces the reservation atomically with its settlement, so the released amount is spendable the moment the fill confirms.
Matching
The matching engine is deterministic and applies price-time priority. Two rules bound what an incoming order can do:
- An incoming order never matches a resting order of the same identity. The engine skips the self-cross and records the skip in the audit trail.
- A market order executes as a marketable limit bounded by the market's price protection band. Quantity that would next fill outside the band is refused, not filled at any price. Already-filled quantity stands.
Before the engine confirms a match, it simulates the settlement call. A simulation failure means no fill prints and the failing resting order is pruned, so eligibility divergence is caught before settlement rather than at it.
Session open by call auction
On a market with a trading calendar, continuous matching starts with an opening auction instead of a first-come race. The same flow runs an auction-only market's scheduled uncrosses; there the remainder carries to the next auction or cancels, per the market's configuration.
During preopen, every accepted order is reserved exactly as in continuous trading; only matching waits. The engine recomputes the indicative equilibrium price and matchable quantity whenever the book changes, over the self-trade-excluded book, and streams it to subscribers. The uncross selects one clearing price: maximum volume, then minimum imbalance, then closest to the reference, bounded by the static band. The settlement contract validates on-chain that the uniform price clears between each fill's own limits, and an uncross that would clear outside the static band is refused and escalated to the operator.
Stop order lifecycle
A stop order enters the lifecycle sideways: accepted at intake but armed instead of reserved. Nothing is frozen while the stop is dormant.
The trigger source is settlement-confirmed prints only, an auction clearing print included, so a print that fails settlement or is later busted can never fire a stop. A sell stop fires on a confirmed print at or below the trigger; a buy stop at or above. Multiple stops fire in trigger-price-then-time order with a bounded cascade per print, and the sequence replays deterministically from the engine's audit trail. Triggers evaluate only while the market is open for continuous trading; a condition met during a halt queues and fires on resume.
The converted order executes as a marketable limit bounded by the trader's signed price and the market's protection band. A dormant stop faces every invalidation an ordinary order faces: the trader's on-chain cancel-all, an address freeze, removal from a private market's participant list, delisting, and its own expiry. Armed stops also count against the trader's open-order cap.
Settlement
Confirmed fills settle on-chain in batches, and each fill in a batch executes independently. The settlement contract verifies both order signatures, releases the reserved amounts, and transfers both legs through each token's own transfer path. Every fill therefore passes the same identity and compliance checks that govern every platform token transfer. Fees come out of the quote leg into the operator fee account, atomically with the fill, and never above the order's signed fee cap.
A fill that fails at settlement does not block the rest of the batch. The failing order is pruned, its reservation is released, the surviving counterpart order re-rests at its original priority, and both parties are notified. Settlement submission is idempotent: on-chain per-order fill accounting is the source of truth, so a crash and replay never double-fills.
After each trade, the venue publishes the market's last-traded price into the platform's price feed infrastructure, marked venue-sourced.
Bulk pruning on compliance change
A custody or compliance change can invalidate resting orders: an address freeze, a forced transfer by a token custodian, or a compliance-module change. The venue detects the chain event and prunes the affected orders in bulk, releasing their reservations, instead of discovering the divergence at fill time. A fee-schedule increase is handled the same way for resting orders whose signed fee cap falls below the new schedule. Dormant stops participate in every mass invalidation, so a frozen or removed wallet keeps no armed stop behind.
Failure modes
| Failure | System behavior |
|---|---|
| An intake check fails | The order is rejected with the failed check named; no state changes |
| The reservation does not confirm | The order is rejected and compensated; it never joins the book |
| A fill reverts at settlement | The fill is isolated; the failing order is pruned; the counterpart re-rests; both parties are notified |
| A cancel lands on-chain before a matched batch executes | The cancelled fill reverts alone and its counterpart re-rests; a cancelled signed order can never fill |
| The market halts mid-flight | Matching and new order acceptance stop; resting orders and reservations stay untouched; already-submitted batches complete |
| A stop's trigger-time reservation fails | The stop is rejected, not retried; the rejection reason is recorded on the order; nothing rests on the book |
| The session closes with a staged batch in flight | The batch still settles; no new orders are accepted after close |
| The auction would clear outside the static band | The uncross is refused and escalated to the operator; no fill prints |
| The engine crashes | The venue reconciles reservations and fills from on-chain events before matching resumes |
Related resources
- Trading Venue capability: contracts, roles, custody model, and trust boundaries.
- Trading venue market structure: reservation, calendars, auctions, bands, stops, private markets, and the busting model as concepts.
- Place and cancel orders: the API integration path for this flow.
- Place stop orders and use time in force: the stop and expiry integration path.
- Trade through sessions and auctions: session state, indicative prices, and auction integration.
- Trading venue operations: the operator surface for listing, calendars, halts, and fees.
PvP and DvP settlement for digital assets
When to use local PvP, local DvP, or hashlock coordinated settlement, and how DALP runs approvals and atomic execution for each pattern.
Token Sale Flow - Primary distribution lifecycle
How the DALP Token Sale flow manages primary distribution of digital assets -- from sale creation and configuration through purchase execution, presale-to-public transition, vesting withdrawal, and soft-cap-failure refunds.