Original topic illustration: ChainView BTC866 original topic diagram · ChainView BTC866 Editorial · CC BY 4.0
Three independent order properties
A limit price, a post-only instruction, and a time-in-force setting answer different questions. The limit sets an acceptable execution boundary. Post-only controls whether an order may immediately remove liquidity. Time in force controls how an unfilled balance is handled. Availability depends on the venue, instrument, interface, and trading phase; a combination offered on a website may not be available through its API. Record the quote currency, quantity unit, tick size, minimum amount, price protections, and supported order combinations before submitting. None of these settings guarantees profit, a particular fee, immediate execution, or execution at all. A label such as advanced order should never replace the actual trading rule, including restrictions during maintenance, opening auctions, or product launches.
Read IOC and FOK operationally
Immediate-or-cancel normally executes whatever quantity is immediately available within the price condition and cancels the rest. Fill-or-kill normally requires complete immediate execution or cancellation, subject to the venue's precise rules. Suppose a fictional order buys ten units with a limit of one hundred, but only six units are available at acceptable prices. IOC may execute six and cancel four, whereas FOK may execute none. This is a rule illustration rather than a live order-book observation. Execution can arrive in several fills, so reconcile their identifiers, amounts, timestamps, and fees. Do not assume that one final status line contains every event or that two repeated notifications describe two different trades.
Post-only creates no fill guarantee
A post-only order that would immediately trade against resting liquidity can be rejected, cancelled, or handled through another explicitly documented policy. It cannot simply demand a maker fee while taking liquidity. If accepted into the book, it may wait behind earlier orders and may never execute. It can also fill when the market moves against the position, making a low maker fee an incomplete measure of cost. Consider inventory exposure, funds reserved, queue position, and the time needed to cancel. Good-till-cancelled is likewise a venue instruction with exceptions: maximum lifetimes, maintenance, delistings, or instrument changes may cancel resting orders. Check those exceptions rather than treating GTC as a permanent contractual promise across every system event.
Cancellation is a sequence of states
A cancel button or acknowledgement proves that a request was received, not that matching has stopped. A fill can race with the cancellation and become valid before the matching engine confirms the cancel. Retain the order ID, client ID, submission time, acknowledgement, each fill ID, cancellation request, and final venue record. After a timeout, query the existing order before sending another order for the same amount; otherwise an uncertain first request can become duplicate exposure. Batch cancellation also needs individual reconciliation. If six units filled before four were cancelled, record both outcomes. An empty interface list is useful context but should not be the sole accounting evidence, especially after reconnecting or changing account filters.
Validate the implementation and maintain it
Use a permitted test environment or a deliberately limited workflow to check rejection codes, partial fills, expiry, and cancellation handling. Test environments can differ from production liquidity and protections, so read both sets of documentation. Confirm API versions, retry rules, and whether a unique client identifier supports safe deduplication. Compare intended order properties with actual maker or taker classification and the charged fee asset. When the venue changes its rules, update automation, local checklists, and published instructions together. A practical trading record states the quantity, price boundary, lifetime, and cancellation condition before submission, then reconciles the actual fills afterwards. That record explains execution far better than a green success message or an attractive fee schedule.
A recovery workflow should distinguish a repeated client request from a genuinely new order. Confirm whether the venue enforces unique client identifiers and for how long. After reconnecting, reconcile outstanding orders before replaying queued requests. A local retry policy that is safe for a read endpoint may be unsafe for order creation and must be tested separately.
