CoinEx announced an orderly shutdown on September 14, 2026, with different services ending on different dates and withdrawals remaining available until December 22. For anyone who automates exchange activity, that sequence matters more than the word “shutdown.” A crypto exchange shutdown checklist should freeze new decisions, inventory every strategy, order, and position, complete asset actions at the venue, and retire API access only after final states are confirmed. One deadline is not enough when trading, order cancellation, asset conversion, and withdrawals stop at different times.
This article uses CoinEx as a current example of a staged venue exit. It does not imply that CoinEx is supported by or integrated with Gimmer. Always use the venue’s official notice and account interface for its exact instructions.
CoinEx turned one shutdown into several operating deadlines
CoinEx’s official cessation announcement sets out a sequence rather than a single cut-off. New registrations stopped on September 15. Futures and several other services are scheduled to cease on September 22. Spot trading is scheduled to stop on September 29, when the platform says it will cancel unexecuted spot orders. At 02:00 UTC that day, CoinEx says it will begin processing non-USDT assets; anyone who wants to withdraw those assets in their original form must act before that cut-off. General withdrawal service is scheduled to end at 02:00 UTC on December 22.
CoinDesk independently reported the planned closure on September 15 and the December 22 withdrawal deadline. CoinEx’s notice remains the primary source for the detailed timetable, asset-treatment rules, and later updates.
Those dates describe different state transitions:
- New activity closes: an operator should stop creating exposure before a venue starts forcing the decision.
- Trading services end: pending orders or open positions may be cancelled, closed, or settled under venue rules.
- Asset treatment changes: remaining assets may be converted, delisted, or handled differently after a stated deadline.
- Withdrawals end: moving assets away from the venue has its own final cut-off.
The practical risk is mixed state: a bot can be stopped while an order remains open at the exchange, an order can disappear while a balance remains, or an API key can be revoked before the operator has finished reconciling the account.
A crypto exchange shutdown checklist for automation
Use one row per exchange account and market. A five-state record makes the sequence visible without pretending that every venue follows the same rules.
| State | Question to answer | Evidence to keep |
|---|---|---|
| 1. Notice | Which product, account, asset, and time zone does the official notice cover? | Official URL, publication date, relevant deadlines, and time zone. |
| 2. Freeze | What can still create a new order or increase exposure? | Strategies paused, manual entry stopped, and automation owner recorded. |
| 3. Inventory | What orders, positions, balances, and running strategies still exist? | Timestamped app view plus the corresponding venue account state. |
| 4. Finality | Which orders are filled, cancelled, failed, or still pending, and which positions remain? | Terminal order states and a fresh venue-side reconciliation. |
| 5. Exit | Have required asset actions finished before access is retired? | Venue withdrawal or transfer records, final balances, and API-key revocation time. |
Do not compress those states into one checkbox called “bot stopped.” Gimmer’s Simulation and Live guide makes the same operational boundary explicit: stopping a bot does not necessarily close positions or cancel orders. The app action and the exchange outcome are separate evidence.
Use Gimmer as the app-side wind-down record
For a signed-in Gimmer account with a configured connection to a supported spot venue, current builds group Gimmer-recorded manual positions, orders, and statistics by Simulation or Live mode, selected venue, and quote currency. Use the Trade workspace as one app-side record during offboarding, not as a credential-specific or complete exchange-account ledger, venue balance or withdrawal record, or universal mirror of every strategy or external order. Review each strategy runtime separately, pause any strategy that could submit another order, and compare the app record with the venue’s current account interface before concluding that activity is resolved.
Freeze decisions before editing the connection
Pause or stop any strategy that can submit another order. Record the account and market attached to each strategy. If the venue notice affects only one product or market, do not assume that every connection shares the same deadline. The recent exact-market delisting checklist shows how to scope a narrower notice; a full venue exit adds account-wide reconciliation and access retirement.
Reconcile orders and positions in two places
Use the Trade workspace to review its recorded manual positions and orders for the selected mode, venue, and quote currency. Review each strategy runtime separately, then compare both app records with the venue’s current account record. Do not assume that activity created directly at the venue, by another process, or under another connection appears in Gimmer. Where the supported workflow permits a cancellation request, treat the accepted request as pending. Confirm the later app state and the venue state: cancelled records cancellation in Gimmer, while filled or failed still requires venue-side reconciliation rather than assumption. A control click or an app state by itself is not proof of venue finality.
If the two views disagree, stop and investigate the difference before moving to the next step. Network delays, venue rules, partial fills, and orders created outside Gimmer can all leave an app view and an exchange account temporarily or permanently different.
Complete custody actions at the venue
Gimmer is not a withdrawal tool for the CoinEx shutdown. Follow the venue’s official process for conversion, withdrawal, destination-address checks, network selection, and confirmations. A zero open-order count does not prove that a withdrawal is complete or that a destination wallet received the asset.
Retire the API connection after reconciliation
The Gimmer exchange-connection guide recommends trading-only API credentials with withdrawals disabled. During a planned exit, when there is no suspected credential compromise and the venue has not directed immediate revocation, revoke the exchange key after the strategy, order, position, balance, and required venue-side asset actions have been reconciled. If the credential may be exposed or compromised, revoke it immediately and continue reconciliation through the venue account. Leaving an unused credential active adds avoidable exposure.
A short example: one account, three clocks
Consider a synthetic example on a venue that Gimmer supports. The notice says new orders stop on Friday, existing orders are cancelled on Monday, and withdrawals close two weeks later.
- On Thursday, the operator records the notice in UTC, stops one live strategy, and confirms no other process can submit to that account.
- The operator reviews two manual limit orders recorded in the Trade workspace, checks the stopped strategy runtime separately, and reconciles both with the venue. One cancellation becomes final; the other partially fills before reaching its final venue state.
- The partial fill leaves a position and changes the available balance. The operator resolves that state under the venue’s rules, not by assuming the original order size still applies.
- After the venue shows no unresolved orders or positions, the operator completes the required asset transfer through the venue and verifies the destination.
- Only then does the operator revoke the trading key and remove the retired connection from the operating record.
The example is not a recommendation to trade, transfer, or hold a particular asset. It shows why a shutdown plan needs separate clocks for order entry, final account state, and withdrawal access.
What this workflow cannot do
- It cannot make a venue extend a deadline, restore a service, or process a withdrawal.
- It cannot guarantee that an order cancellation, conversion, transfer, or withdrawal will succeed.
- It does not prove an exchange’s solvency, security, liquidity, or regulatory status.
- It does not make an app record authoritative when the venue reports a different final state.
- It does not establish CoinEx support in Gimmer.
Deadlines and product availability can change. Re-open the official notice before each irreversible step, use the venue’s stated time zone, and keep enough time for manual review rather than planning around the final minute.
Frequently asked questions
Does stopping a Gimmer bot cancel its exchange orders?
No. Stopping a bot does not necessarily cancel orders or close positions. Review the app and venue states separately and wait for terminal order evidence.
Should I revoke an exchange API key as soon as a shutdown is announced?
During a planned exit with no suspected compromise, first freeze new automated activity and reconcile the remaining strategy, order, position, balance, and required venue-side actions. Revoke the key after that work is complete unless the venue directs immediate revocation. If the credential may be exposed or compromised, revoke it immediately and continue reconciliation through the venue account.
Can Gimmer complete a CoinEx withdrawal?
This article makes no such claim. Use CoinEx’s official account workflow and cessation notice for CoinEx withdrawals. The Gimmer workflow described here is limited to one scoped app-side record of manual activity for a supported, configured connection; strategy runtime and venue state must be reviewed separately.
Leave the connection only after the account
A venue shutdown is not one date. It is a controlled reduction of authority: stop new decisions, reconcile what already exists, complete asset actions at the venue, and retire credentials after final evidence is in hand. If you use Gimmer with a supported venue, open the Simulation and Live guide and write the five-state record for every affected connection before changing access.