Two exchange wind-downs in September 2026 are being used by one developer team to argue that most trading-bot codebases do not model what happens when a venue stops operating. In a dev.to post, the NefiSwap team states that BitMEX halted trading on September 23, 2026, and that CoinEx announced on September 15 that it would close on December 22. The post is a community contribution and its account of both timelines is the author's claim, not an independently verified record.
According to the same post, both closures are orderly rather than insolvency events: reserves are reported as fully backed and withdrawals remain open. The author's argument is that orderly or not, a wind-down is still a sequence of breaking changes for anything integrated against an exchange API, and that most codebases do not represent that sequence at all.
The post frames a wind-down as a state machine with predictable phases, and asks developers to treat each phase as a distinct failure mode rather than collapsing everything into "the API returned an error." That framing is the author's editorial position; the evidence supplied does not include the exchange announcements themselves, only the post's summary of them.
Deposit automation is what the author names as the first failure mode. During a wind-down, their account holds that the costliest bug is not a withdrawal that fails, but rather a top-up running automatically that continues pushing funds toward a deposit address which no longer credits them. As a mitigation, they suggest a kill switch verified ahead of each transfer, built as an environment variable containing a comma-separated blocklist of exchange identifiers, so that flipping one variable halts every process that pushes funds.
Retry behaviour comes second. The post says that after a venue switches to reduce-only mode, error codes a bot has likely never seen are returned by order placement, and hammering the endpoint is what a naive retry loop will do, running into rate limits and possibly getting the API key restricted precisely when withdrawals require it. Halting strategy logic and alerting a human, instead of retrying, is the author's recommendation whenever rejection codes are unknown.
The third is treasury architecture. The post argues the real fix is to keep only working capital on any venue and sweep the remainder to self-custody continuously, so that a closure announcement becomes an inconvenience rather than an emergency. It includes a minimal ccxt sweep script driven by a per-asset rules table mapping each asset to a network, an environment variable holding an allowlisted destination address, and an amount to keep on the venue.
The post lists caveats before that script is used anywhere real. Destination addresses should be allowlisted on the exchange side and the API key restricted by IP, because a sweep key with withdrawal permissions is a high-value target. Venues differ in how they deduct withdrawal fees, with some taking the fee from the amount and others requiring amount plus fee to fit within the free balance, so the retained amount needs adjusting. Network identifiers are not fully standardized across exchanges even through ccxt and must be verified per venue, and networks requiring a memo or tag need that argument passed to the withdrawal call.
The fourth point concerns API access as an exit route. The post states that BitMEX disabled API withdrawals on September 28, after which withdrawals became manual through the website only. For teams whose treasury operations assume API access, the author recommends a documented manual procedure covering who holds the login, where two-factor authentication lives, and which addresses are pre-approved.
The fifth is monitoring. The author notes that health checks typically ping endpoints, while wind-downs are announced on blogs and status pages weeks before endpoint behaviour changes. The proposed cheap monitor diffs each venue's announcement page and alerts on keywords such as "wind-down," "reduce-only" or "cessation," which the author says buys weeks of lead time.
The long-tail exit is the sixth. Following a trading halt, the post says, the form in which assets are held is the only form in which they can be withdrawn. September 29 is when CoinEx spot trading ends, it states, and after that a long-tail token remains a long-tail token, so integrations holding obscure assets ought to plan either to convert ahead of the halt or to withdraw as-is and convert somewhere else.
For freelancers and developers who maintain exchange integrations for clients, the practical reading is that closure handling is a design requirement rather than an incident-response task. The post's own suggestions are cheap to implement in isolation, but they assume the developer controls environment configuration, key permissions and withdrawal allowlists, which is often not true when the integration was handed over or when the client holds the exchange account.
There are also tradeoffs the post does not resolve. Continuous sweeping reduces exposure to a venue but increases withdrawal fees, on-chain exposure and operational surface area, and the author explicitly warns that a withdrawal-capable key is a high-value target. A kill switch on deposits is only as good as the process that flips it, and announcement-page diffing depends on venues publishing clear language in a predictable place.
What remains unknown from the supplied evidence is substantial. The post does not link to the BitMEX or CoinEx announcements, so the dates, the reserve claims and the API-withdrawal change are reported as the author's statements rather than confirmed facts. The sweep script is presented as illustrative and the author does not claim to have tested it in production, nor does the post give any measurement of how many integrations actually failed during either wind-down.
The post carries a disclosure that it was written by the NefiSwap team, which builds an instant exchange service with no accounts and no stored balances, and that it supports over 8,000 coins for converting long-tail assets after withdrawal. That commercial interest does not invalidate the technical points, but it does mean the piece is partly promotional and should be read as a vendor's account rather than neutral reporting.
The useful conclusion for this audience is narrower than the headline suggests. The post does not prove that any particular bot broke, and it does not establish that these two closures are representative of how exchanges generally fail. What it does offer is a checklist of integration assumptions worth auditing before the next announcement: whether deposits can be stopped centrally, whether unknown order rejections halt rather than retry, whether balances above working capital sit on the venue at all, and whether there is a documented manual path out if API withdrawals are switched off.