AI Trading Bot Order Types: Market, Limit, IOC and FOK Explained

DN AI Trading Beginner Series · Reviewed 7 November 2026

A tutorial can show a successful entry without showing the setting that mattered most. One bot might submit an immediate market order. Another might leave a limit order working after the signal has become irrelevant. A third might start with a limit order and later apply its own replacement or fallback policy.

This guide covers single, unlevered spot orders. It separates the initial instruction from a bot’s later actions. Derivatives, margin, stop triggers, brackets, multi-leg orders and on-chain settlement mechanisms require additional rules beyond this article.

Market, limit, IOC and FOK answer different questions

It is useful to separate a price instruction from a time-in-force instruction. A limit order can carry an immediate-or-cancel policy. Calling it “limit” does not tell you whether an unfilled remainder will wait on the book.

Definitions are a teaching summary. Binance Spot, Coinbase Advanced and Kraken document the relevant concepts differently, and each route governs its supported combinations. [3][4][5][6]

Turn the signal into four explicit choices

Before discussing a venue, answer these four questions in ordinary language:

1. Price: must the order carry a specific limit price, or is the intent to submit no limit price?
2. Timing: do you request only an immediate attempt, a policy capable of leaving unmatched quantity working until canceled, or a policy with an expiry?
3. Partial execution: is less than the full quantity acceptable for this order attempt?
4. Liquidity: may the order take available liquidity, or must it be post-only?

“I want a good entry” cannot answer those questions. Nor can a confidence score. A precise instruction gives a reviewer something to compare with the submitted settings.

For example: “Use a specified limit price. Make one immediate attempt. A partial quantity is acceptable. Do not leave a remainder working. Taking liquidity is allowed.” That is a different instruction from “Wait at my limit until I cancel.”

How to read a result: a family can match the selected intent while adding a stricter condition. If partial execution is acceptable, FOK still qualifies conceptually, but it adds an all-or-none requirement that can leave the order unfilled. The explorer makes that difference visible. A match is not proof of API support, suitability or execution.

1. Name the exact product and route

Write down the venue, spot pair, account context and the software path that will create the order. “My bot supports Binance” is less useful than identifying the exact bot mode and the exchange endpoint or ticket it uses.

Even the amount needs a unit. Binance’s plain Spot new-order documentation distinguishes a base quantity from a quote amount for market orders. Those fields express different intentions. Its plain LIMIT request has its own required fields, including a time-in-force choice and price. This article does not extend that simplified field set to pegged or conditional orders. [7]

A fictional instruction to acquire 1 BASE is not identical to an instruction to spend 100 QUOTE. If a workflow silently changes the sizing convention, the words “buy” and “market” may still look correct while the requested amount means something else.

Product versions also matter. The current 3Commas migration guide separates Signal Bot workflows from standalone indicator-driven DCA Bot workflows. A control visible in an older tutorial is not evidence that the current route sends the same request. [8]

Record: venue, product, pair, side, amount unit, bot mode and configuration version. Then use the separate minimum-order-size guide for increments and amount constraints. A logically coherent instruction can still fail those checks.

2. State what the price boundary actually protects

For a buy, a limit is the maximum gross execution price per unit. For a sell, it is the minimum. The price displayed on a chart is neither an execution receipt nor evidence that the entire requested quantity is available there. A limit order can also remain partly or wholly unfilled. [6]

Suppose a fictional buyer’s limit is 100 QUOTE per BASE. A fill at 99.80 is consistent with that boundary. A fill at 100.20 is not. But the boundary alone says nothing about how many units fill, when they fill, or the net cash and asset movements after charges.

A market instruction removes that reader-specified limit price; it does not remove exchange rules. Binance documents a market order that executes partly and expires its remainder when liquidity is insufficient. Kraken separately documents protection rules that can produce a partial market buy with the rest canceled. Neither example supports treating “market” as a promise of complete execution. [9][10]

Record: whether a limit is required, its currency and unit, and whether the intended spending constraint is gross or includes fees. Keep source-data freshness separate using the signal timing guide.

3. Decide whether any remainder may stay working

An order can stop matching now while still being eligible to match later. That possibility matters when a signal has a short useful life, or when a person assumes the bot has finished its attempt.

GTC permits a working remainder. An expiry-based instruction adds a deadline. IOC is the immediate-attempt family that removes the unfilled remainder from further matching. These names describe order policy, not a promise that the application will return a response within a particular number of milliseconds. [5]

For an expiry, write the actual instant and timezone into the implementation record. Check the route’s accepted representation instead of copying a label from another exchange. Kraken’s Spot WebSocket v2 specification, for example, pairs GTD with a separate expiry-time parameter. [11]

A deadline is also different from a human reminder to cancel. If an external workflow must send the cancellation, its availability and successful completion are separate dependencies. The initial order may otherwise continue under the instruction the venue actually accepted.

Record: whether resting is allowed, what ends that permission and which system enforces the end. Do not treat GTC as a promise that the venue will keep the order forever.

4. Separate “partial is acceptable” from “all or none now”

Consider a fictional request to buy 5 units. Being comfortable with 2 units is a different policy from requiring all 5 in the same immediate attempt.

IOC permits an immediate partial execution. FOK requires the whole requested quantity at execution or no fill for that attempt. Canceling or expiring an unfilled remainder does not reverse quantity that already traded under a policy that permitted partial execution. [3]

The explorer deliberately treats “partial is acceptable” as permission. It does not mean that a partial fill must occur. Both limit IOC and limit FOK can fit an immediate, price-bounded intention that permits partial execution, but FOK adds a restriction: an otherwise possible smaller fill may be refused.

Conversely, “I hope it eventually fills completely” is not an all-or-none rule. A resting order may execute in pieces over time. A strategy that cannot tolerate an intermediate position needs a more precise policy than an expectation about its eventual result.

Record: whether partial execution is permitted within this attempt and what the strategy does after a smaller result. That later handling belongs to a separate workflow; the explorer does not authorize a top-up or retry.

5. Treat post-only as an execution constraint

A limit order can immediately trade against an existing opposing order when its price permits it. That is taking liquidity. A portion left on the book may later provide liquidity instead. Coinbase’s fee documentation distinguishes the two portions and says maker and taker rates can be equal or different. “Limit” therefore does not mean “maker,” and “maker” does not mean “free.” [12]

Post-only adds a requirement about how the order enters the book. Coinbase describes rejection if any part would immediately take on arrival. That is a permitted outcome of the control, not proof that the strategy’s price target was achieved. [4]

Imagine a fictional limit buy at 100 when an opposing sell is already available at 99.80. A normal marketable limit may execute within its price boundary. A reject-on-cross post-only rule can instead decline that placement. The same limit price does not imply the same behavior.

After an order rests, an incoming opposing order may match it quickly. Post-only is not a minimum waiting period. It also does not establish that the eventual trade is profitable after costs.

Record: whether taking is permitted, how a maker-only attempt can end and whether the bot will change the price after a rejected placement. For fill-by-fill fee reconstruction, use the separate limit-order taker-fee audit.

6. Inspect what the bot may do after the first order

The initial exchange instruction and the automation policy are different objects. A bot can cancel, replace or submit a new order after the first attempt. Those actions need their own conditions.

The current 3Commas Best Bid/Ask guide provides a concrete example. It describes replacing an unfilled limit order at updated prices, an attempt limit and a Market fallback setting for exhausted attempts. It separately describes a partial-fill remainder being sent to market after 40 seconds. That guide does not establish that disabling the exhausted-attempt fallback removes that separate partial-fill behavior. [13]

This example concerns that named mode. It is not a claim that all 3Commas limit orders or all trading bots behave that way. It is a reason to inspect the complete policy instead of interpreting one switch as a universal guarantee.

In a fictional workflow, every child order could be a valid limit order while the bot repeatedly raises the buy limit. If the original intent capped price at 100, a later replacement at 100.20 changes the instruction. “Each request was a limit order” does not resolve that mismatch.

Record: repricing, maximum chase, attempt count, partial-fill handling and every path that can change the order type. Mark a field unknown when the current documentation or interface does not establish it.

7. Verify combinations on the actual interface

A family name in documentation is useful evidence, but it is not a compatibility certificate for every account and connector.

Coinbase illustrates why scope matters. Its retail limit-order help lists GTC, GTT and IOC. Its broader Create Order schema includes several configurations, including market and limit FOK variants, and post-only fields on some limit configurations. That schema alone does not establish which branch a particular spot pair, retail ticket or third-party bot accepts. [4][14]

This is also why the explorer does not call every uncovered combination impossible. Post-only with an expiry may be supported on a specific route, even though that combined family is outside its six simplified rows. Ordinary market orders in the model also exclude route-specific market-FOK variants.

Before implementation, compare the intended four choices with the route’s supported parameters, its response and the order record. Keep the exact configuration and its review date. A missing setting should stay unresolved until the interface or documentation answers it.

Record: the official evidence for the exact combination and any connector transformation. If a submission times out, the question becomes whether an order already exists; use the order-timeout reconciliation guide before treating the intent as a fresh request.

8. Rehearse the unwanted outcomes

A useful practice session includes more than a successful fill. Write down what the workflow should do if an immediate attempt finds no eligible quantity, a permitted partial fills, a post-only attempt cannot be placed, or an expiry arrives with quantity still unmatched.

TradingView currently offers Paper Trading and documents market, limit and stop tickets. That can help someone learn the interface. Its main-functionality page does not verify every IOC/FOK/post-only combination or demonstrate that simulated queue position and execution match a live venue. [15]

Keep two records: the intended behavior and the observed behavior. If a rehearsal cannot express the required instruction, record that coverage gap. Do not count an untested control as a successful test.

For a single order attempt, useful questions include: Was taking permitted? Could the order rest? Was a smaller quantity acceptable? Did a wrapper submit another order? Did the observed status come with executed quantity? The canceled-order and partial-fill guide handles the later exposure question in detail.

Record: scenario, expected instruction, actual result, remaining uncertainty and the date reviewed. A clean rehearsal of the settings is evidence about that rehearsal, not a profitability claim.

One fictional intention, several distinct instructions

Take a fictional single-order plan: buy 1 BASE with a maximum gross unit price of 100 QUOTE. No book depth, current quote, account balance or real order is supplied. We can compare policies without inventing a fill.

At the stated limit, 1 × 100 gives a gross notional of 100 QUOTE if the whole unit trades at that price. This is arithmetic on invented inputs, not an estimate of total account debit, fees or actual fills.

The important output is a clear instruction to verify. It is not a winning order type. Choosing between permitted families still requires the strategy’s goals and the exact route’s behavior.

What the current venue documentation establishes

This is a documentation comparison, not a ranking of execution quality. No order was submitted to measure fills, speed, fees or availability in a particular account.

Methodology: what the DN explorer checks

The DN Order Instruction Explorer is an original educational rules engine. It compares four declared choices against six explicitly defined families: ordinary immediate market, limit GTC, limit GTD, limit IOC, limit FOK and a generic post-only resting limit.

It checks each choice independently. Unknown selections remain unresolved. A family that survives incomplete inputs is provisional. A family that matches complete inputs can still impose extra restrictions, which the output identifies. A contradictory input or unsupported value does not receive a silent default.

For this model, “no specified limit” means no submitted limit price; it does not mean “either price instruction is fine.” “Partial forbidden” means that this attempt must not execute less than the full quantity. The resting choice requests a policy capable of keeping unmatched quantity working, without guaranteeing that the venue will do so. Timing selects a requested lifecycle; partial acceptance and permission to take liquidity can still accommodate stricter variants.

Six fictional scenarios illustrate the covered families and their interactions. The JSON and CSV exports preserve the entered choices, rule results, scope notes and source references. They contain an educational decision record, not an exchange request.

Outside coverage: post-only plus an expiry and route-specific market-FOK are not represented as separate families. Neither omission means the combination is impossible. The model also does not check prices, sizes, balances, permissions, live liquidity, actual support, queues, account fees, clocks, retries, profitability or investment suitability.

Official documentation establishes the cited concepts and product-specific examples. DN supplies the comparison logic and fictional scenarios. The research date applies to the documentation review; the sources are not measurements of provider performance. All explorer operations run locally in the page, without connecting a trading account.

Frequently asked questions

Primary sources

Official documentation reviewed on 7 November 2026 (SAST). Interface, product and route scope matter. These are not live execution measurements.

1. SPOT API Glossary — Binance
2. ENUM Definitions — Binance Spot
3. How to Place a Time In Force Order? — Binance Academy
4. Understanding the order types — Coinbase Advanced Trade
5. Other order options — Kraken
6. Market and limit orders — Kraken support
7. New order — Binance Spot REST Trade reference
8. Moving from 3Commas v1 to 3Commas v2: Feature & Bot Migration Guide
9. MARKET orders — Binance Spot
10. Market Price Protection — Kraken
11. Add Order — Kraken Spot WebSocket v2
12. Coinbase Advanced fees
13. How Best Bid/Ask limit orders work — 3Commas
14. Create Order — Coinbase Advanced Trade API
15. Paper trading — main functionality — TradingView
16. 3Commas official public product page