Crypto good-till-date orders set an expiry time for an unfilled order or its remaining quantity. They do not reverse fills or close the position those fills created. Check the selected venue's timestamp units, precision and cancellation rules, then reconcile the terminal order and cumulative executions. Reaching the requested expiry time alone does not prove that the order has stopped trading.
Give the entry permission an end time
A limit entry can remain sensible at noon and become stale before an afternoon announcement. A good-till-date instruction, usually abbreviated GTD, gives that entry permission an intended end time without requiring the operator to remember to cancel it manually.
The expiry applies to the order's remaining executable quantity. If part has already filled, that exposure needs its own management. An expiry is also different from a request deadline: the latter can reject an instruction that arrives too late to be accepted, rather than schedule cancellation after acceptance.
This article examines those timing boundaries. For the immediate execution choices that precede them, use the post-only and time-in-force comparison. The examples below are constructed accounting exercises, not live exchange tests or a description of a KLINEO GTD feature.
A precise-looking timestamp may lose precision
In the Binance USDⓈ-M Futures new-order documentation reviewed on October 23, 2026, goodTillDate is required for timeInForce=GTD. Its millisecond component is ignored, leaving second-level precision. The timestamp must be more than 600 seconds ahead of the current time. Binance also warns that automatic GTD cancellation can be delayed in extreme market conditions. These rules belong to that futures endpoint. Binance USDⓈ-M Futures: new-order GTD parameters.
Suppose an otherwise valid request is prepared at 12:00 UTC with a desired expiry of 12:15:00.900 UTC. Under that documented precision rule, the effective timestamp is 12:15:00.000 UTC: 900 milliseconds earlier than the time selected. The extra decimal places did not buy extra lifetime.
Record both the operator's requested time and the normalized time sent to the exchange. Displaying the original selection after silently truncating it makes a later audit misleading. Avoid choosing a boundary that only barely satisfies an endpoint's minimum lead time; request preparation and network transit consume time too.
Kraken Spot illustrates why a generic GTD adapter needs product-specific handling. Its REST Add Order endpoint pairs timeinforce=GTD with expiretm, accepts absolute Unix times or relative seconds, and documents a one-month future limit and a five-second minimum for relative expiry. A separate deadline field limits acceptance of a delayed new-order request. Kraken Spot REST: expiry and request deadline fields.
A client cannot copy the Binance lead-time rule into Kraken, or treat Kraken's request deadline as the lifetime of an already resting order. Before submission, resolve timezone, units, rounding, allowed range and which clock defines a relative duration.
One expiry, two fills and three clocks
Assume a hypothetical linear BTCUSDT futures buy for 0.020 BTC at a limit of 50,000 USDT per BTC. The account starts flat, no other orders or trades occur, and every fill is at the limit. The requested GTD time has been normalized to 12:15:00.000 UTC. Fees and funding are excluded. This is quantity and notional accounting, not a margin calculation.
| Time in UTC | Constructed evidence | Consequence |
|---|---|---|
| 12:00:01 | Exchange accepts the GTD order for 0.020 BTC. | Up to 0.020 BTC can fill under this instruction. |
| 12:14:58.000 | First execution buys 0.004 BTC; the client receives it promptly. | Cumulative fill is 0.004 BTC; 0.016 BTC remains. |
| 12:14:59.960 | Second execution buys 0.003 BTC at the exchange. | Actual cumulative fill becomes 0.007 BTC. |
| 12:15:00.000 | The normalized expiry boundary passes. | The client's timer alone does not establish the terminal exchange state. |
| 12:15:00.250 | Client receives the second execution report. | A report received after expiry can describe a fill before expiry. |
| 12:15:00.500 | Terminal order evidence confirms expiry with 0.007 BTC executed and no remaining live quantity. | The unfilled 0.013 BTC is no longer working; the 0.007 BTC position remains. |
Keep three times separate: the intended expiry, the exchange event time and the local receipt time. A late receipt is not proof of a late execution. Here the second execution occurred 40 milliseconds before expiry, even though its report arrived 250 milliseconds afterward.
The gross acquired notional is 0.007 × 50,000 = 350 USDT. The canceled remainder's limit notional is 0.013 × 50,000 = 650 USDT. Together they reconcile to the original 1,000 USDT maximum order notional. None of these amounts establishes required collateral or available balance.
What if the cancellation itself is late?
The table assumes there are no further executions. A separate failure scenario is that an order remains active during delayed cancellation and the official history records another 0.002 BTC fill after the intended boundary. That is a hypothetical outcome to investigate, not a claim about how often it occurs or a universal matching rule.
The new cumulative total would be 0.009 BTC, with 450 USDT gross notional. The eventual canceled remainder would be 0.011 BTC. A local expiry timer must not erase that additional 0.002 BTC from inventory because it arrived outside the strategy's preferred window. Preserve the execution timestamp, reconcile the authoritative record and investigate the boundary violation.
The partial-fill accounting guide covers the inventory consequences. If the final status cannot be retrieved, follow the order-timeout reconciliation process while keeping the original order identity unresolved. Submitting a fresh full-sized order can add exposure on top of the first one.
Use an expiry acceptance worksheet
Fill this worksheet for the exact account, environment, instrument and endpoint before relying on a timed entry. It tests the expiry contract rather than a strategy's profitability.
| Check | Evidence to retain | Boundary case to resolve |
|---|---|---|
| Capability | Supported order type and GTD fields for the selected product | A client offers GTD while the execution endpoint rejects it. |
| Clock conversion | Requested UTC time, encoded value, units and normalized expiry | Fractional seconds disappear or local time is interpreted as UTC. |
| Admission window | Current exchange-time observation and documented minimum lead time | A valid preview becomes too near expiry before submission. |
| Accepted instruction | Order ID, original quantity and accepted expiry where exposed | A wrapper drops the expiry field and sends an ordinary resting order. |
| Expiry recovery | Terminal status, cumulative fills and last observation time | The timer has fired but cancellation or execution history remains unresolved. |
| Exposure handoff | Remaining position and any separate protective orders | An expired entry is mistaken for a closed position. |
Do not release an order reservation solely because its local countdown reaches zero. Confirm the exchange outcome and its scope. The open-order count limit guide explains why a pending cancellation can also matter when another submission competes for an order slot.
For derivatives, hand the confirmed filled position to the account's risk review. Expiring the remainder cannot remove scenario losses on the quantity already acquired; the portfolio-margin scenario guide examines that separate calculation.
Finally, decide what expiry means for the strategy: abandon the entry, request a new decision with fresh data, or escalate unresolved state. Extending the expiry or recreating the order changes the period during which capital can move. Record that as a new authorization decision, with the first order's fills already accounted for.
Editorial method: Prepared with AI assistance from official exchange documentation reviewed on October 23, 2026. The timing scenarios, arithmetic and worksheet are original educational examples. No live exchange behavior or KLINEO GTD capability was tested.