Order Types on BULK

Every order type available on BULK Exchange, what it's for, and when to use it. For the formal specification, see docs.bulk.trade/bulk-exchange/Order-Types.

Base order types

Market order

Executes immediately against whatever liquidity is currently available, walking the book until fully filled (or until it hits a risk limit). Use it when speed of execution matters more than price precision — you're guaranteed to get filled, not guaranteed a specific price.

Limit order

Rests on the order book at a price you set and only fills at that price or better — a buy limit fills at your price or lower, a sell limit fills at your price or higher. Use it when price matters more than immediacy.

Time-in-force (how long an order stays live)

Code	Name	Behavior
GTC	Good-Til-Cancelled	The default for limit orders. Rests on the book until it fills or you cancel it manually.
IOC	Immediate-Or-Cancel	Fills whatever portion is immediately available, then cancels the rest instantly — never rests on the book.
ALO	Add-Liquidity-Only (post-only)	Must rest as a maker order. If it would cross the spread and take liquidity instead, it's rejected outright (as `rejectedCrossing`) rather than partially filling.

A wire-format quirk worth knowing if you're building on the API: the internal order type is called `ALO`, but BULK's WebSocket account stream reports it as `"postOnly"` on the wire. The HTTP API accepts either name. If you're parsing order confirmations programmatically and only check for `ALO`, you'll miss post-only fills reported over the WebSocket feed.

Since maker fees are currently waived (see Fees on BULK) while taker fees are not, ALO is the mechanical guarantee that you'll pay the maker rate — or not execute at all, rather than accidentally taking liquidity and paying the taker fee.

Order modifiers

Reduce-Only

Clamps an order so it can only shrink or close an existing position — never open a new one or flip it to the opposite side. If a reduce-only order's size would flip your position, BULK clamps the size down to exactly close it instead. This flag is available on any order type, and it's also what BULK's own liquidation engine uses internally when forcibly reducing an under-margined position (see How Liquidations Work) — so the same safety mechanism you can opt into manually is the one protecting the exchange itself.

Modify Order

Changes the size of a resting limit order without cancelling and resubmitting it — but the two directions behave asymmetrically, and this trips people up:

• Reducing size keeps your existing place in the price-time queue. If you reduce below what's already been filled, the order is effectively cancelled.
• Increasing size sends the order to the back of the queue at that price level — you lose your queue priority.

Modify can't change price at all. To move an order to a different price, cancel it and submit a new one.

Conditional orders

Conditional orders don't sit on the visible book directly — they wait on a separate trigger book and activate an underlying order once the mark price crosses a level you set. See Conditional Orders Playbook for the full walkthrough of Stop, Take-Profit, Range, Trigger, Trailing Stop, and On-Fill orders.

Self-trade prevention

BULK's matching engine won't let your own orders fill against each other. If an incoming order would match a resting order from the same account, the engine skips that resting order (without cancelling it) and keeps looking for other liquidity — so you might see a partial fill or a `cancelledSelfCrossing` result instead of trading against yourself. Sub-accounts are treated independently for this check.

Execution priority: what actually happens inside one consensus batch

This is the part that surprises people who assume "first submitted, first executed." Within a single batch, BULK first applies a deterministic shuffle (part of fair ordering — nobody, including validators, controls it), and then sorts the shuffled transactions into three priority tiers that execute in order regardless of shuffle position:

1. Cancels execute first.
2. Post-only (ALO) orders execute second.
3. Regular orders (market, and GTC/IOC limit orders) execute third.

Worked example: Say a market order, a cancel for an unrelated stale order, and a new ALO limit order all land in the same batch. Even if the shuffle happens to place the market order first and the cancel last, execution still processes the cancel first, then the ALO order, then the market order — the structural priority overrides shuffle position entirely. Practically, this means a cancel you submit is never at risk of "losing a race" to a fill within the same batch, and post-only orders get a genuine structural edge over aggressive orders, not just a fee incentive.

Picking the right order type

• Need certainty of execution over price control → market order
• Want to guarantee you're adding liquidity (and get maker economics) → ALO limit order
• Want to react to a price level without babysitting the screen → a conditional order (see Conditional Orders Playbook)
• Managing risk on an existing position → reduce-only so you can't accidentally flip or over-close it
• Need to shrink a resting order without losing queue position → modify (but only if you're decreasing size — increasing sends you to the back)

Ready to try these live? Sign up on BULK Exchange with referral code YETI — see Getting Started for the full walkthrough.