# 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.

{% hint style="info" %}
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.
{% endhint %}

#### Post + Cancel Prioritisation

<table><thead><tr><th width="243.171875">Order type</th><th>Behavior</th></tr></thead><tbody><tr><td><strong>Post (maker) orders</strong></td><td>Bypass the block for immediate inclusion</td></tr><tr><td><strong>Cancel of a resting order</strong></td><td>Bypass the block for immediate inclusion</td></tr><tr><td><strong>Cancel of an in-flight order</strong></td><td>Joins the same block as the order being canceled</td></tr><tr><td><strong>Taker orders</strong></td><td>Held in the block until the end of the block </td></tr></tbody></table>

### 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. &#x20;
* **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.

{% hint style="info" %}
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.
{% endhint %}

### Pre-block Execution vs. Post-block Execution

{% hint style="warning" %}
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.
{% endhint %}

#### 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`.&#x20;

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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.ethereal.trade/trading/perpetual-futures/block-execution.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.