# Block Execution

## Overview

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

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

### Post + Cancel Prioritisation

| Order Type                       | Behavior                                          |
| -------------------------------- | ------------------------------------------------- |
| **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.

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

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

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

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

<div className="faq-list">
  <section className="faq-item">
    <h3>Can I see if my order is in a block?</h3>

    <p>
      No. There is no pending status on the websocket feed. Your order will appear as filled or acknowledged after the
      block is processed.
    </p>
  </section>

  <section className="faq-item">
    <h3>What about OCO (one-cancels-the-other) orders?</h3>

    <p>
      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.
    </p>
  </section>

  <section className="faq-item">
    <h3>Do blocks have a fixed duration?</h3>

    <p>
      Not exactly. A small random jitter is added to each block to prevent participants from timing the block boundary.
    </p>
  </section>

  <section className="faq-item">
    <h3>Can I cancel an in-flight order?</h3>

    <p>
      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.
    </p>
  </section>

  <section className="faq-item">
    <h3>How are stop orders handled during block execution?</h3>

    <p>
      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.
    </p>
  </section>
</div>
