Order Types

dreamDEX supports a range of order types to accommodate different trading strategies.

Every order must clear the market's minimum size. Each pair sets a minQuantity (minimum order size) and a lotSize (size increment) in base-token units, plus a tickSize price increment. An order below minQuantity, or whose size/price is not a whole multiple of lotSize/tickSize, is rejected on-chain. minQuantity is the most common cause of a rejected first order. Read the live values per market from GET /v0/markets or on-chain getPoolParams() - see Quantizing price and quantity.

Basic Order Types

Limit Order

Place an order at a specific price. It fills at your price or better. What happens to any part that does not fill immediately is set by the order's time-in-force (below); with the default GTC it rests on the book until filled or cancelled.

  • Use case: When you want to control your entry/exit price
  • Execution: Fills at your specified price or better

Market Order

Execute immediately at the best available price. Market orders are Immediate-or-Cancel (IOC) orders that carry a price limit. In the dreamDEX app that limit is the estimated fill price moved by your slippage tolerance (0.5% by default, adjustable in the Pro order ticket, fixed at 0.5% in Simple mode). Via the SDK or API you set the limit yourself: above the best ask for buys, below the best bid for sells. The order fills whatever is available within that limit and any unfilled remainder is cancelled, never filled beyond it.

  • Use case: When speed of execution is more important than price
  • Execution: Fills against resting liquidity at current market prices

Time-in-Force Options

In the dreamDEX app, the Limit ticket's time-in-force dropdown offers all four policies the pool executes: GTC, IOC, FOK and ALO (post-only). Each one is an OrderType on the contract. A policy the pool cannot honour does not place a reduced order: the transaction reverts with a named error (listed under each policy and in Contract errors) and nothing is spent.

Good-Till-Cancelled (GTC)

Order remains active until filled or manually cancelled. This is the NormalOrder type on the contract. Any part that does not fill immediately rests on the book.

  • Funding: Any source. Under the default wallet auto-pull the pool pulls the input at placement and returns proceeds to your wallet; in manual vault mode it draws from a pre-deposited balance.

Immediate-or-Cancel (IOC)

Order executes immediately for any available quantity; the unfilled portion is cancelled and never rests. This is the ImmediateOrCancel type on the contract. If nothing at all can fill at your price, the transaction reverts with ImmediateOrCancelNoFill().

  • Use case: Large orders where partial fills are acceptable
  • Funding: Any source (wallet auto-pull or vault).

Fill-or-Kill (FOK)

Order must be filled entirely or not at all; it never rests. This is the FillOrKill type on the contract. If the full size cannot fill immediately, the transaction reverts with FillOrKillNotFillable() and nothing is placed.

  • Use case: When you need the full quantity or nothing
  • Funding: Any source (wallet auto-pull or vault).

Post-Only

Shown as ALO (Add Liquidity Only) in the dreamDEX app; this is the PostOnly type on the contract. The order only ever rests as a maker: if any part of it would match immediately (take liquidity), the transaction reverts with PostOnlyWouldCross() and nothing is placed.

  • Use case: Ensure your order always provides liquidity (maker order)
  • Funding: Any source (wallet auto-pull or vault).

What happens when an order is refused

Three of the types above exist precisely to not execute under some condition — IOC with nothing to fill, FOK that cannot fill in full, Post-Only that would cross. When that condition hits, the order is rejected by reverting the transaction, with a named reason:

SituationReason
IOC filled nothing at allImmediateOrCancelNoFill
FOK could not fill in fullFillOrKillNotFillable
ALO / Post-Only would have crossedPostOnlyWouldCross
Would have matched your own resting order (Cancel Taker)SelfMatchCancelTaker
Expiry already in the pastOrderAlreadyExpired

A rejection is a failed transaction, not a successful one that quietly did nothing — inclusion is not effect. A partially-filled IOC is not a rejection: it fills what it can, cancels the remainder, and succeeds normally.

If you place many orders at once, use the batch surface (placeOrders) instead — it flags the individual order that was refused and lets the rest go through, so one bad rung cannot discard your whole ladder. Full details in Errors.

Advanced Order Types

Stop-Loss

Triggers a market or limit order when the mark price drops to a specified level. The mark price is the EMA-smoothed midpoint emitted by the SpotPool.

  • Trigger: LTE — when mark price falls to or below your stop price
  • Use case: Limit downside risk on open positions
  • See Stop Orders for full details

Take-Profit

Triggers an order when the mark price rises to your profit target. The mark price is the EMA-smoothed midpoint emitted by the SpotPool.

  • Trigger: GTE — when mark price rises to or above your target price
  • Use case: Lock in gains automatically
  • See Stop Orders for full details

Order Matching

Orders are matched using Price-Time Priority (PTP):

  1. Best price has priority
  2. Among orders at the same price, earlier orders fill first

All matching occurs on-chain with atomic settlement.

Self-Trade Prevention (STP)

dreamDEX prevents users from trading against themselves. Via the SDK or API you specify one of the following behaviours for when an order would match against your own resting order. The dreamDEX app always sends Cancel Taker and does not expose the choice.

  • Cancel Taker (the SDK's default when omitted): The incoming (taker) order is cancelled. This prevents the trade without affecting your resting orders.
  • Cancel Maker: The resting (maker) order is cancelled, allowing the taker order to continue matching against other orders.

Self-trading is never permitted — one side is always cancelled.