Docs
Architecture

Blocks and the Sequencer

Where orders go, and how they become blocks.

The sequencer

The sequencer is the exchange's engine. It accepts transactions signed by trading keys — orders, cancellations, deposits, withdrawals, key updates — runs the order book (a central limit order book with price–time priority) and the risk engine (margin checks, funding, liquidations), and applies the oracle's prices.

It answers in milliseconds, which is what makes the exchange feel like a traditional one. What it cannot do is lie about what it did: every transaction it applies becomes part of a block whose correctness is later proven.

Blocks

Every few seconds the sequencer closes a block: the ordered list of transactions it applied, together with the data needed to reconstruct the resulting state. The block is committed to STRATO. This is the exchange's public record — anyone can read the chain and rebuild the exchange's state from the blocks alone, without asking the sequencer anything.

Forced inclusion

If the sequencer ever refused to include your transaction, you could submit it directly to the settlement contract's forced-inclusion queue. Every block must consume the queue in order; a block that skips a queued transaction cannot be settled. The sequencer can be slow, but it cannot censor.

Transaction types

The exchange has a small, fixed set of transaction types. Each has a precise definition of how it changes the state, and it is that definition the block proof checks — there is no transaction the exchange can apply that the proof does not account for.

They fall into two classes, which matters because the proof is shaped around it:

  • Light — cheap to prove: InsertOrder, CancelOrder, ForcedCancel, Deposit, Withdraw, Transfer, KeyUpdate, OracleUpdate, FundingUpdate, PremiumSample, FeeSweep, and Noop (padding, so every block has the same fixed shape for the proof).
  • Heavy — the ones that touch two accounts, the book, and the risk engine at once: Match, LiquidationOrder, AssignToInsurance, and Deleverage.

Some of these you sign (an order, a cancel, a withdrawal, a key rotation); others the exchange itself emits as part of running the market (a match, an oracle update, a funding round, a liquidation step, the periodic fee sweep). Both kinds are transactions in the block, and both are proven the same way.

Block layout

A block is a header plus a compact, ordered record for every transaction it applied — a few bytes for a match, a few tens for a signed order and its signature. The whole payload is committed to STRATO under a single hash. This is the exchange's data-availability guarantee: the records are public and complete, so any follower — a prover, an auditor, anyone rebuilding the state from scratch — can replay the block and arrive at exactly the state the sequencer did, without asking it anything.

On this page