A GTD order has two clocks

You set an expiration and expect the order to live right up to that second. A GTD order is more precise than that: the requested timestamp and the effective safety threshold are not identical.

Polymarket's order guidance says a GTD order expires one minute before its stated expiration, and an expiration that is too close is rejected.

Store both deadlines

Keep the timestamp sent to the API and the effective lifetime the strategy intended. For a lifetime of N seconds, the documented calculation adds a 60-second buffer to the current time before setting the expiration.

This makes a review readable. A later cancellation can be compared with the deadline the strategy actually designed, not only with a raw Unix timestamp.

Put the deadline before the catalyst

GTD is useful when a quote should stop before a known event or information window. The order type can enforce the time boundary even if the process is busy with other work.

The boundary is a risk control, not a promise that the order will fill before it. Check the order status and any trade identifiers separately.

Validate the minimum lifetime

The expiration must be at least three minutes in the future, which leaves an effective lifetime of about two minutes after the safety threshold. Orders that expire sooner are rejected.

Treat that validation as part of order construction. Do not wait for a rejection to discover that the strategy's time window was shorter than the venue allows.

Reconcile after the clock runs out

When the deadline passes, fetch open orders and recent trades before releasing the reserved risk in your local model. The clock says when an order should stop; the account read tells you what state it reached.

The useful question is not whether the timestamp looked right. It is whether the order's effective lifetime, final status, and remaining exposure agree with the plan.

Further reading: Place orders · Order lifecycle · Manage orders.

Explore the markets: Open Polymarket (referral link).