Block Execution
Overview
Ethereal uses block execution with post + cancel prioritization to promote fair and efficient markets.
How It Works
When the sequencer receives an order, it is either 1) held in queue until the end of the block (taker orders), or 2) immediately included (post or cancel orders).
At the end of the block, the block is processed and all held orders are matched against the order book.
Orders within a block are currently processed in the order they were received (FIFO). In the future, in-block ordering may be randomized to further reduce any advantage from submission timing within a block.
Post + Cancel Prioritisation
Post (maker) orders
Bypass the block for immediate inclusion
Cancel of a resting order
Bypass the block for immediate inclusion
Cancel of an in-flight order
Joins the same block as the order being canceled
Taker orders
Held in the block until the end of the block
Why Block Execution?
Block execution reduces adverse selection risk and encourages tighter spreads and deeper liquidity:
Tighter spreads and deeper liquidity: makers quote tighter and larger under less threat of adverse selection or latency arbitrage.
Fair access: takers submitting within the same block are treated equally regardless of connection speed.
Lower barriers: longer tail makers can participate without investing in ultra-low-latency infrastructure.
Block execution is applied uniformly across all perpetual futures markets. There is no per-market configuration - all markets share a single block cadence, which ensures consistent behavior and allows features like OCO orders to work atomically across markets.
Pre-block Execution vs. Post-block Execution
The following are user-facing behavioral changes introduced by block execution that differ from the previous (non-block) flow. Integrators should update their clients accordingly.
Cancel Status For in-block Orders
When a cancel targets an order that entered the current block (i.e. a taker order that has not yet been flushed), the cancel is placed into the same block rather than executing immediately. Because the cancel is accepted into the block, the HTTP response returns an OK status. However, the cancel may ultimately be rejected when the block is flushed, for example, if the target taker order was fully filled during block processing, there is nothing left to cancel and the engine will reject the cancellation.
Cancels targeting resting orders on the book continue to bypass the block and resolve synchronously as before. This change only affects cancels against orders that are still pending inside a block. The OK status in that case only confirms that the cancel was accepted into the block, not that it will succeed. Integrators should treat the cancel response as optimistic and listen to WebSocket order acknowledgements to confirm whether the order was actually canceled or whether the cancel was rejected post-flush.
Filled Quantity is Always Zero on Submit Response
Previously, submitting a taker order could return a non-zero filled value in the HTTP response, reflecting the quantity matched at submission time. With block execution enabled, all taker orders are held in the block and matching occurs only when the block is flushed. As a result, the filled field in the immediate submit response will always be 0.
To obtain the actual fill quantity, integrators must listen to the WebSocket order fill feed. Fill information will arrive as order update messages once the block has been processed and matching is complete.
FAQ
Can I see if my order is in a block?
No. There is no pending status on the websocket feed. Your order will appear as filled or acknowledged after the block is processed.
What about OCO (one-cancels-the-other) orders?
OCO groups work correctly because all markets share the same block schedule. Both legs of an OCO will always be in the same block, so atomic cancellation is guaranteed.
Do blocks have a fixed duration?
Not exactly. A small random jitter is added to each block to prevent participants from timing the block boundary
Can I cancel an in-flight order?
Yes, but the cancel will join the same block rather than executing immediately. Cancels only bypass the block when targeting a resting order on the book.
How are stop orders handled during block execution?
Stop orders are risk-management orders, so once registered they can trigger immediately on later mark updates to help reduce losses and avoid liquidation. However, a stop submitted during the current block cannot be triggered by a mark update in that same block; it remains dormant until the block completes. This prevents traders from using fresh mark-price information to submit stops that effectively bypass block execution.
Last updated