OKX schedules five-token delisting

The trading and transfer schedule

OKX scheduled ICX, STORJ and ELF pairs against EUR or USDC for removal on September 30, 2026, 08:00–10:00 UTC. DORA, ICX, STORJ, ZEUS and ELF pairs against USDT follow on October 3 at the same hours. Buy/Sell and Convert stop September 30 at 08:00 UTC, including USDT. Bots close 07:00–08:00 UTC on each delisting day.

Deposits stopped September 23 at 10:00 UTC; withdrawals stop December 23 at 08:00 UTC. Consolidation temporarily suspends withdrawals and transfers. Uncancelled orders are cancelled automatically, potentially taking one to three working days. Check regional availability in the app.

What “untradable” means in this context

OKX’s help guide distinguishes assets that cannot be traded on the platform from assets still supported for withdrawal. Its untradable category can include delisted assets and unsupported deposits. The label is therefore about available platform functions; it does not itself describe a successful transfer or a completed sale.

The general help page is background, while this dated notice supplies the specific deadlines. A general description of withdrawal support should not override a named suspension date. Likewise, a balance remaining visible in an account does not establish that every service previously available for it is still available.

Start with the exact pair, not only the token

An effective account review begins by writing down both sides of each trading pair. A token name alone may leave the relevant row ambiguous. Then give each service its own line: an order book, a conversion feature, an automated strategy and a transfer are different operations.

Consider a fictional checklist with three entries: a pending order, a bot and a planned withdrawal involving the same asset. A reminder containing only the asset name and one date would not tell you which entry it covers. The mistake is organizational: different tasks were compressed into one label.

A clearer checklist adds the service, the published cutoff, the account’s current status and the next unresolved question. You can then mark the order as cancelled without also marking the withdrawal as completed. This does not require deciding to buy or sell; it simply makes the state of each operation explicit.

Preserve the time zone when making a reminder

The schedule uses UTC. When placing a reminder in a personal calendar, keep the original UTC time in the note even if the calendar displays a local conversion. That makes it possible to check the reminder against the notice later without reconstructing which time zone was assumed.

For a simple invented example, suppose a service closes at 08:00 UTC and a calendar displays that as 10:00 in the user’s chosen zone on that date. A reminder written only as “10:00” loses the original reference. Recording both the date and “08:00 UTC” makes the intended event much clearer if the calendar zone is later changed.

Also distinguish a closure window from a single promised moment. Planning to act at the end of a published window assumes access will persist until then. A window instead identifies a period in which the change is scheduled. Treating its earliest boundary seriously is a more accurate reading of the notice than turning its latest boundary into an access guarantee.

Check completion in the relevant account record

When an action is needed, record what was actually completed rather than what was intended. A cancellation request, a cancelled order and an executed trade are different records. Similarly, a prepared withdrawal is not the same as a transfer recorded at its destination. This separation helps identify unfinished work while there is still time to resolve it.

The dated schedule and selector below are reading aids, not account controls. They cannot cancel an order, stop a bot or move a balance. If the account display conflicts with the notice, use official support to resolve the exact service and asset involved. The purpose of this article is to make the deadlines understandable enough that a reader can ask the right question and avoid applying one service’s deadline to everything else.