Overview
BULK applies a 25 millisecond speed bump to transactions that may take liquidity. Transactions containing only provably maker-only orders can proceed immediately, while taker-capable transactions wait in the delay pool before becoming eligible for execution. The speed bump runs after consensus acceptance and before deterministic shuffle. It changes when a transaction becomes eligible for execution, not how the transaction is submitted.Temporary Maker Protection
The speed bump is a temporary launch mechanism, limited to the first 90–120 days while market makers become comfortable quoting consistently on BULK. It provides a simple, predictable protection window while liquidity and trading behavior mature. After this transition, BULK will introduce a novel protective order type that provides more targeted protection without delaying all taker flow. The design direction is an order that can cancel or constrain its resting exposure when deterministic short-horizon flow signals indicate elevated adverse-selection risk.What Is Held
Classification applies to the complete signed transaction. If any action in the transaction is taker-capable, the entire transaction receives the speed bump.
Only ALO guarantees maker behavior before execution. A GTC order is held even when it would currently rest, because the classification does not depend on mutable order-book state.
Mixed Transactions
A transaction is the scheduling boundary. If an ALO order, transfer, or cancel is packaged with a taker-capable action, every action in that transaction is held together. The speed bump does not split, rewrite, or merge signed transactions. This preserves signature integrity and action ordering, but does not make execution all-or-none. Individual actions may still be rejected, partially filled, or cancelled under their normal execution rules.How the Delay Pool Works
The delay pool holds complete signed transactions until they become eligible. When the 25 ms window has passed, a transaction is released into the first available execution batch together with newly accepted maker-only transactions. The 25 ms value is a minimum eligibility delay rather than an exact execution-time promise. Execution occurs in the first available batch after the delay, so normal consensus, batching, and processing time may make the observed interval slightly longer.Cancels During the Delay
Cancel While an Order Is Still Delayed
If a cancel references an order ID still in the delay pool, the cancel transaction also enters the delay pool. It does not remove or modify the original placement transaction. The placement may therefore be placed, filled, rejected, or partially filled before the cancel becomes eligible. When released, the cancel applies to whatever live order state remains.Cancel at the Release Boundary
A cancel arriving as its placement leaves the delay pool may become eligible in the same execution batch. Normal cancel-first priority still applies. If the placement is not live when the cancel executes, the cancel can be rejected and the placement can proceed afterward.Cancel-All
Cancel-all remains immediate and applies to orders already live in the executor. It does not remove transactions waiting in the delay pool.Deterministic Ordering
Transactions released from the delay pool join the maker-only transactions eligible for that execution batch. The combined batch then passes through BULK’s deterministic shuffle and existing structural priority queues before matching. The speed bump does not create a client-selected fast lane. Every account, API connection, and ingress path receives the same classification and ordering rules.API Compatibility
The speed bump requires no trading API changes:- action payloads and signatures are unchanged;
- nonces, transaction IDs, and order IDs are unchanged; and
- clients do not opt in or select an execution priority.