Delisting do perpétuo ICXUSDT na OKX: cronograma e checklist

Verified source facts

1. OKX's September 10 notice names September 17, 2026 at 08:00 UTC as the ICXUSDT perpetual delisting time. 2. The notice says open orders will be canceled and remaining positions settled from the arithmetic average of the OKX index during the hour before delisting. 3. OKX says bots will gradually close within the final hour and warns that users concerned about fees or slippage may stop them manually. 4. The notice states a temporary 30-minute transfer restriction after delisting for positions with notional value above 10,000 USDT.

Comparison at a glance

1. Deadline control: Timeline

Delisting work is a clock-management problem. Here, timeline concerns the official UTC deadline and local conversion. Translate the official UTC time once, write it beside the original, and then record the deadline with a timezone label. Do not schedule the last safe action for the final minute: login friction, confirmation delays, volatility, and maintenance can consume the remaining buffer.

Separate voluntary action from exchange automation. Canceling an order, closing a bot, or reducing a position deliberately gives the user a known timestamp and clearer records. Waiting for the platform process delegates execution price and timing to rules described in the notice. That does not make automatic handling improper, but it is a different decision with different evidence. The unknown is whether OKX later amends the notice.

After the event, reconcile account history against the notice: orders canceled, funding applied, positions settled, transfers restricted, and records retained. Preserve exports before the interface changes. This section does not forecast ICX or judge the listing decision; it isolates the operational consequence the user can still control.

2. Deadline control: Open orders

Here, open orders concerns automatic cancellation at delisting. Translate the official UTC time once, write it beside the original, and then export and cancel intentionally if records matter.

The unknown is fill behavior immediately before suspension.

3. Deadline control: Position settlement

Here, position settlement concerns one-hour arithmetic-average index methodology. Translate the official UTC time once, write it beside the original, and then understand that settlement is not the last trade.

The unknown is the final observed index path.

4. Deadline control: Leverage

Here, leverage concerns sensitivity of equity before forced settlement. Translate the official UTC time once, write it beside the original, and then reduce risk before the final hour if appropriate.

The unknown is future volatility.

5. Deadline control: Funding

Here, funding concerns funding charged or paid at delisting. Translate the official UTC time once, write it beside the original, and then check the contract and account statement.

The unknown is the final funding result.

6. Deadline control: Trading bots

Here, trading bots concerns gradual closing in the last hour. Translate the official UTC time once, write it beside the original, and then inspect and stop bots manually when control matters.

The unknown is the exact automated close execution.

7. Deadline control: Transfer timing

Here, transfer timing concerns temporary restriction for larger notional positions. Translate the official UTC time once, write it beside the original, and then plan transfers outside the restricted window.

The unknown is account-specific operational delays.

8. Deadline control: Records

Here, records concerns history remains available but exports reduce dependency. Translate the official UTC time once, write it beside the original, and then download orders and bills before interface changes.

The unknown is future retention policy.

9. Deadline control: Regional scope

Here, regional scope concerns notice applicability may vary by customer. Translate the official UTC time once, write it beside the original, and then check the signed-in entity and product availability.

The unknown is eligibility for a specific account.

10. Deadline control: Decision boundary

Here, decision boundary concerns operational risk rather than price prediction. Translate the official UTC time once, write it beside the original, and then separate deadline management from market views.

The unknown is future ICX price or other-venue listings.

Decision scenarios

Scenario 1: when timeline becomes decisive

Consider a reader whose main constraint is the official UTC deadline and local conversion. The correct response is not to infer a universal platform or product winner. It is to record the deadline with a timezone label, retain the evidence, and define a stop condition before funds or permissions are committed. If the evidence changes, the decision must be reopened. This produces a repeatable operating rule rather than a one-time opinion.

Scenario 2: when open orders becomes decisive

Consider a reader whose main constraint is automatic cancellation at delisting. It is to export and cancel intentionally if records matter, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 3: when position settlement becomes decisive

Consider a reader whose main constraint is one-hour arithmetic-average index methodology. It is to understand that settlement is not the last trade, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 4: when leverage becomes decisive

Consider a reader whose main constraint is sensitivity of equity before forced settlement. It is to reduce risk before the final hour if appropriate, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 5: when funding becomes decisive

Consider a reader whose main constraint is funding charged or paid at delisting. It is to check the contract and account statement, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 6: when trading bots becomes decisive

Consider a reader whose main constraint is gradual closing in the last hour. It is to inspect and stop bots manually when control matters, retain the evidence, and define a stop condition before funds or permissions are committed.