Request Lifecycle: Sequencing and Execution

A DerivaDEX request unfolds in two phases: first in the queue, then in the market. Keeping those moments distinct makes the system easier to understand. Queue position matters. Execution matters. They answer different questions, and they become true at different times.

​

A request answers two questions over time

Most requests move through the same two-stage sequence: Traditional venues live with the same distinction. An acknowledgment tells you the venue accepted the message. Later messages tell you what happened to the order. DerivaDEX makes that separation visible and gives each stage its own clear meaning.

​

Sequencing settles queue position

The first decisive moment in the lifecycle is sequencing. A trader signs a request, encrypts it to the operator, and submits it to the request API. If the request passes admission and reaches the sequencer, the operator returns a signed receipt containing the request’s identity and sequence slot. That receipt plays the same role an exchange acknowledgment plays in other markets: it tells the trader that the venue has accepted responsibility for where the request sits in line. On DerivaDEX, that point carries real economic weight. Under leverage, the difference between arriving first and arriving second can change whether you post, whether you cross, which liquidity you meet, which price band applies, and whether the rest of the order can continue through the engine. Once a request is sequenced, the exchange has committed to that place in ordered processing. This is where DerivaDEX comes closest to the institutional idea of an exchange acknowledgment. The parallel is useful, as long as it stays precise. A sequencing receipt means the request now has a fixed place in line. It does not yet describe the market outcome. That comes next.

​

Execution settles the market outcome

Execution starts after the request has its place in line. This is the stage where the matching engine and the account logic turn a request into consequences. For an order, execution can mean a new resting order, an immediate fill, a partial fill followed by a remainder on the book, a cancellation, or a rejection that appears only once the engine sees the actual path through the market. For a withdrawal request, it means funds move from available to locked inside exchange state. For trader-level actions, it can mean a profile change, a DDX balance update, or a later rejection tied to trader state rather than order state. That is why the lifecycle does not collapse into one status field. Different events answer different parts of the story. ORDER_UPDATE carries the order-domain story: posting, fills, liquidations, cancellations, and order-level rejections. STRATEGY_UPDATE carries the strategy-domain story: collateral movement, funding, realized PnL, fees, liquidation effects, ADL (auto-deleveraging, forced position reduction against opposing traders), and withdrawal intent or completion. TRADER_UPDATE carries the trader-domain story: DDX balance changes, fee-payment preferences, and trader-level rejections. A successful submission is only the beginning. The outcome the trader cares about arrives in the execution events that follow.

​

Why acceptance and execution are kept apart

The split becomes natural once you look at what each stage has to decide. Some checks belong before the request ever enters the queue. A malformed request, an invalid signature, missing trader state, or a request that already fails a risk check all belong there. Those cases should fail before the venue gives the request a place in line. Other decisions can only be made once the request reaches execution. The engine has to see the current book, the mark price, the applicable price bands, the trader’s live state, and the actual path through available liquidity. That is where you get outcomes such as a partial fill followed by a rejected remainder, or a sequenced cancel request that arrives too late because the target order has already been filled. Seen from that angle, the split is clean. Sequencing answers the queue question. Execution answers the market question.

​

Where checkpoints enter the picture

The lifecycle does not end at execution, because some claims have to leave the exchange and land on Ethereum. Withdrawal is the clearest example. A withdrawal request first becomes a withdrawal intent inside exchange state, which locks the requested collateral. Later, a checkpoint covers that state so the claim can be proved on Ethereum. That later step matters for settlement. It sits downstream of sequencing and execution.

​

The lifecycle in one sentence

Two verbs carry the whole model:

• a request is sequenced when its place in line is fixed
• a request is executed when the engine turns it into market and account outcomes

First the request gets its place in line. Then the market answers it. Checkpoints matter later, when a claim has to stand up on Ethereum.

​

How this connects to the rest of the docs

Once sequencing and execution are distinct in your head, the other trading docs line up naturally.

• Order and Account Event Reference defines the event fields and replay semantics for client state machines.
• Trading Safeties and Guards lists the exact admission and matching rules that govern the lifecycle.
• Order and Account Event Reference defines the event fields and replay semantics for the execution events.
• Why DerivaDEX Is Architected Differently explains the broader architectural argument behind this design.