Time-in-Force (TIF)

What Is Time-in-Force?

Time-in-force (TIF) is an order parameter that tells a trading venue how long a submitted order should remain active. When a trader places a limit order or a conditional order, the TIF instruction specifies the conditions under which the venue should automatically cancel it if it has not been filled. Without a TIF designation, most venues default to treating the order as a Day order, meaning it expires at the end of the current trading session.

The concept originates from traditional equities and futures markets, where it was standardized in the FIX protocol as tag 59 (TimeInForce). The FIX specification defines values including 0 (Day), 1 (GTC), 3 (IOC), 4 (FOK), and 6 (GTD), though not every exchange supports every value. As cryptocurrency trading matured, centralized exchanges adopted these same TIF types. Now, on-chain order book DEXs are implementing them as well, with adaptations to account for blockchain mechanics.

How It Works

When a trader submits an order with a TIF instruction, the trading engine evaluates it in two phases: first, it attempts to match the order against existing resting orders on the book; second, it applies the TIF rule to determine what happens to any unfilled portion.

1. The trader specifies the order type (limit, stop, etc.), price, quantity, and a TIF parameter
2. The matching engine checks for available counterparty orders at the specified price
3. If the order fills completely, the TIF parameter is irrelevant: the trade is done
4. If the order fills partially or not at all, the TIF instruction determines whether the remainder rests on the book, is canceled immediately, or expires at a future time

Standard TIF Types

The following types are widely supported across both centralized and decentralized venues:

Additional TIF Variants

Some venues support extended TIF options that serve specialized purposes:

• Post-Only (also called Maker-or-Cancel): the order is rejected if it would match immediately, ensuring it only adds liquidity to the book. Traders use this to guarantee they pay maker fees rather than taker fees.
• At the Open / At the Close: available on traditional exchanges, these participate only in the opening or closing auction. They do not apply to 24/7 crypto markets.
• GTT (Good Till Time): a variant of GTD that uses a precise timestamp rather than a calendar date. Supported on venues like dYdX and RISEx.

FIX Protocol Encoding

In the FIX messaging standard used by institutional trading systems, TIF is encoded as tag 59 on order messages. A simplified example of a new order single message:

# FIX NewOrderSingle (tag 35=D)
# Key fields:
Tag 11  = ClOrdID        (client order ID)
Tag 54  = Side           (1=Buy, 2=Sell)
Tag 38  = OrderQty       (quantity)
Tag 44  = Price          (limit price)
Tag 40  = OrdType        (2=Limit)
Tag 59  = TimeInForce    (0=Day, 1=GTC, 3=IOC, 4=FOK, 6=GTD)

# Example: GTC limit buy for 0.5 BTC at $95,000
35=D | 54=1 | 38=0.5 | 44=95000 | 40=2 | 59=1

TIF on Centralized Crypto Exchanges

Centralized exchanges like Coinbase, Binance, and Kraken support TIF parameters on their trading APIs. The most commonly available types are GTC, IOC, and FOK. Day orders are less common in crypto because markets trade continuously without session boundaries, so GTC serves as the practical default.

For algorithmic trading systems, TIF selection is a critical parameter. A market-making bot placing orders on both sides of the bid-ask spread typically uses GTC with frequent cancellations and replacements. An arbitrage bot executing a cross-venue trade uses IOC or FOK to avoid leaving stale orders that could be adversely filled.

API Example

Most exchange APIs accept TIF as a string parameter on order creation:

// Place a GTC limit order via REST API
POST /api/v1/orders
{
  "symbol": "BTC-USD",
  "side": "buy",
  "type": "limit",
  "price": "95000.00",
  "quantity": "0.5",
  "timeInForce": "GTC"
}

// Place an IOC order: fill what's available, cancel the rest
POST /api/v1/orders
{
  "symbol": "BTC-USD",
  "side": "buy",
  "type": "limit",
  "price": "95500.00",
  "quantity": "1.0",
  "timeInForce": "IOC"
}

TIF on Decentralized Exchanges

On-chain order book DEXs implement TIF differently from centralized venues due to blockchain constraints. There are two fundamental challenges: block time granularity and the cost of state changes.

Block Time Granularity

On a blockchain, time is measured in blocks rather than milliseconds. Ethereum produces blocks roughly every 12 seconds; Solana roughly every 400 milliseconds. This means GTD-style expiry cannot be set to an arbitrary timestamp: it must align with block boundaries. Some protocols, like Perpl, express order expiry as a block number rather than a wall-clock time. When the chain reaches that block, anyone can clear the expired order (sometimes earning a small incentive fee for doing so).

On-Chain Order Costs

Every order placed on a fully on-chain book requires a transaction, which means paying gas fees. Canceling an unfilled GTC order also costs a transaction. This makes rapid order placement and cancellation (a common pattern in high-frequency trading) prohibitively expensive on most chains. Hybrid architectures address this by keeping the order book off-chain and settling matches on-chain, which restores the speed of centralized TIF processing while preserving settlement guarantees.

dYdX Implementation

dYdX, one of the largest decentralized perpetual futures exchanges, runs its own app-chain with a built-in order book. Its TIF options include a default mode (match then rest), IOC (match only, no resting), Post-Only (reject if it would cross), and Fill or Kill. The app-chain architecture avoids the gas cost problem by making order operations part of the consensus layer rather than smart contract calls.

AMMs and TIF

Automated market makers do not use a traditional order book, so TIF concepts do not apply directly. A swap on an AMM is a single atomic transaction: it either executes at the current pool price (subject to slippage tolerance) or reverts. This behavior is closest to FOK: the entire swap must succeed or nothing happens.

However, limit-order layers built on top of AMMs (such as range orders in concentrated liquidity pools or third-party conditional order services) do introduce TIF-like parameters. These layers typically monitor pool state and submit the swap transaction when price conditions are met, using an off-chain keeper or relayer to manage expiry logic.

Use Cases

Execution Strategy

Professional traders select TIF based on their execution goals:

• GTC for passive limit orders when willing to wait for a target price
• IOC for sweeping available liquidity without leaving residual orders that could be adversely filled
• FOK for large block trades where partial execution would leave unwanted exposure or disrupt hedging calculations
• GTD for event-driven strategies: set a limit order that expires after an earnings announcement, token unlock, or protocol upgrade

Market Making

Market makers quoting on both sides of the book typically use GTC orders with frequent amendments. When conditions change (a price move in a correlated asset, a shift in volatility), they cancel and replace their quotes. The TIF ensures that stale quotes do not linger if the cancellation message is delayed.

TWAP and Algorithmic Execution

TWAP algorithms slice a large order into smaller child orders spread over a time window. Each child order typically uses IOC: it captures whatever liquidity is available at the current price without resting on the book and signaling the parent order's intent to other participants.

Cross-Venue Arbitrage

Arbitrage strategies require simultaneous execution across multiple venues. IOC or FOK ensures that if one leg fails to fill, the order does not rest and accumulate risk. This is especially important across centralized and decentralized venues, where latency differences can cause one leg to fill before the other is even submitted.

TIF and Settlement Finality

In traditional markets, TIF governs order lifespan, while settlement happens separately (typically T+1 for equities). In crypto, the relationship between TIF and finality is more nuanced. On a centralized exchange, order matching is instant but withdrawal may depend on blockchain confirmation depth. On an on-chain order book, the fill and settlement happen in the same transaction: once the block is finalized, so is the trade.

This has implications for GTD orders on-chain. A GTD order expiring at block 10,000 is guaranteed to be enforced by the protocol itself, unlike a traditional GTD that relies on the exchange's software to honor the expiry. The blockchain's deterministic execution removes counterparty risk from the TIF enforcement mechanism. For a deeper comparison of how settlement finality varies across systems, see Payment Finality Comparison Across Blockchains.

Risks and Considerations

Missed Fills with Aggressive TIF

IOC and FOK prioritize execution certainty over fill probability. In a fast-moving market, an IOC order at a limit price may find no available liquidity and return zero fills. A FOK order for a large quantity may be rejected entirely when the same quantity could have been filled in smaller pieces over time. Choosing an overly aggressive TIF can lead to systematically missing trading opportunities.

Stale GTC Orders

GTC orders that are forgotten can fill at prices that no longer reflect the trader's intent. If a trader places a GTC buy order at $50,000 and the market drops to that level weeks later under fundamentally different conditions, the fill may be unwanted. Good practice is to review and prune GTC orders regularly, or use GTD with a reasonable expiry.

Front-Running on On-Chain Books

On fully on-chain order books, resting GTC orders are visible in contract storage. This transparency exposes them to front-running and sandwich attacks. A searcher can observe a large resting order and trade ahead of it, or manipulate the price to trigger it at an unfavorable level. Hybrid off-chain/on-chain architectures mitigate this by keeping the book opaque until settlement.

Gas Costs for Cancellation

On-chain GTC orders that go unfilled still require a cancellation transaction to free up locked collateral. During periods of high network congestion, the cost of canceling an order may exceed the economic value of the position. Traders on on-chain venues should factor cancellation costs into their TIF selection, favoring IOC for speculative orders where the cancellation-to-fill ratio is high.

Partial Fill Risk with IOC

Because IOC allows partial fills, a trader intending to buy 10 BTC may receive only 0.3 BTC if that is all the available liquidity. The remaining 9.7 BTC position must be sourced separately, potentially at worse prices. For strategies requiring full position entry, FOK is the safer choice despite its lower fill probability.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.