Market, limit and stop orders: what execution is actually promised

An order form contains several different promises. A limit specifies an acceptable execution price. A stop specifies an activation condition. A market order asks the matching system to execute against available orders. Confusing those instructions can turn a displayed price into an expectation the exchange never made.

The useful question is not simply whether an order is “safer.” It is which uncertainty the instruction controls: price, timing, quantity or activation. These examples concern documented Coinbase Advanced and Kraken order types checked on 23 September 2026. Availability and detailed rules depend on the product and market.

A market order asks for execution at available prices

Coinbase explains that a market order can fill in pieces at different prices, and that the price shown before submission is not guaranteed. Its Advanced documentation also describes market protection mechanisms that can stop execution and leave a partial fill. Immediate execution therefore should not be read as an unconditional promise that the entire requested amount will trade. See its order-type guide.

The distinction matters when reading a confirmation. “Submitted” describes an instruction; “filled” describes an executed quantity. If only part traded, the average fill price applies to that part, not automatically to the original order size. A final status and remaining quantity answer different questions from the price field.

Our guide to visible order-book depth explains the available-liquidity side. Here the additional issue is the rule the customer gave the matching engine.

A limit controls the execution boundary

A buy limit sets the maximum execution price; a sell limit sets the minimum. Kraken's limit-price explanation makes that direction explicit. Neither instruction guarantees that a willing counterparty will appear for the whole quantity.

A limit order can execute immediately if acceptable opposing orders already exist. It does not necessarily wait on the book or receive maker treatment. Coinbase's trading rules, sections 1.3–1.5 distinguish ordinary limits, post-only instructions and time-in-force settings. Post-only restricts immediate matching; immediate-or-cancel cancels any quantity that cannot fill immediately. A displayed limit price alone does not identify these settings.

Consider a hypothetical buy for ten units with a limit of $100. If only three units are available at acceptable prices, three may trade while seven remain unfilled. Whether those seven stay open depends on the time-in-force instruction. The $100 boundary has worked even though the requested purchase is incomplete. Fees remain a separate part of the total cash cost.

A stop activates another instruction

Coinbase's cited rules describe spot stop orders as stop-limit orders: a qualifying last-trade price activates a limit order. The rules explicitly do not guarantee a fill. A trigger is therefore a transition in the order's state, not proof of a completed sale.

Kraken separately documents a stop-loss order that creates a market order. Its trigger can reference last traded price or, for certain pairs, an index. The resulting execution can occur beyond the stop price. Its stop-loss-limit order instead creates a limit order and can remain unfilled if the market moves past the acceptable price too quickly. Those are materially different instructions despite their similar names.

Suppose a fictional asset has a sell stop at $100 and a sell limit at $98. After activation, assume all available bids are below $98. The limit prevents a sale below $98; it does not prevent the asset's market value from falling further. A stop-market variant would seek available bids, with a potentially worse price and any venue execution constraints still applying. Neither example establishes a guaranteed maximum loss.

Read the complete instruction and the result

Use this worksheet when interpreting an order record:

Keep the order identifier with these fields. A chart reaching a familiar price cannot show which instruction was accepted, how much executed or whether a remainder was cancelled. Execution records can. This also prevents an unsuitable comparison with DEX minimum-received settings, whose transaction mechanics differ from exchange order instructions.

A cancelled remainder and an untouched stop are both unfilled, but their next possible events differ. A cancelled order requires a new instruction; an active stop is still waiting for its condition. Recording that state prevents a blank execution field from being mistaken for a pending order that can still trade.