DEV Community: Nefi Swap

Your Trading Bot Assumes the Exchange Will Exist Tomorrow. BitMEX and CoinEx Just Proved Otherwise

Nefi Swap — Fri, 25 Sep 2026 20:48:20 +0000

In September 2026, two exchanges entered wind-down within days of each other. BitMEX stopped trading on September 23. CoinEx announced on September 15 that it will close on December 22.

Both closures are orderly: reserves reported as fully backed, withdrawals open. But if you run bots, treasury scripts, or any integration against an exchange API, an orderly closure is still a sequence of breaking changes, and most codebases don't model it.

A wind-down is a state machine

Looking at both timelines, closures move through predictable phases:

Phase	What breaks	BitMEX	CoinEx
Reduce-only	New orders rejected; only closes allowed	From Aug 26	Futures from Sep 15
Product halts	Margin, loans, staking, Earn stop	—	Sep 22
Trading halt	All order placement fails; open positions force-closed	Sep 23	Spot ends Sep 29
Deposits disabled	Funds sent in are not credited	After closure	Before final close
API withdrawals off	Scripted exits stop working	Sep 28	—
Final close	Remaining balances charged fees / moved to custody	1%/yr or $50/mo	5%/mo on unclaimed USDT

Each phase is a failure mode your code should recognize, not just "the API returned an error."

1. Stop deposit automation first

The most expensive bug in a wind-down isn't a failed withdrawal. It's an automated top-up that keeps sending funds to a deposit address that no longer credits them.

Any process that pushes funds to an exchange should check a kill switch before every transfer:

import os

def deposits_allowed(exchange_id: str) -> bool:
    blocked = os.environ.get("DEPOSIT_BLOCKLIST", "").split(",")
    return exchange_id not in blocked

Flipping one environment variable is faster than finding every cron job that sends funds.

2. Don't retry-loop on reduce-only rejections

Once an exchange is in reduce-only mode, order placement returns errors your bot has probably never seen. A naive retry loop will hammer the endpoint, hit rate limits, and potentially get the key restricted, right when you need it for withdrawals.

Treat unknown rejection codes as a signal to halt strategy logic and alert a human, not to retry.

3. Sweep by policy, not by panic

The real fix is architectural: keep only working capital on any venue, and sweep the rest to self-custody continuously. Then a closure announcement is an inconvenience instead of an emergency.

A minimal sweep with ccxt:

import os
import ccxt

exchange_class = getattr(ccxt, os.environ["EXCHANGE_ID"])
exchange = exchange_class({
    "apiKey": os.environ["API_KEY"],
    "secret": os.environ["API_SECRET"],
    "enableRateLimit": True,
})

# asset -> (network, env var holding the allowlisted address, amount to keep on the venue)
SWEEP_RULES = {
    "USDT": ("TRC20", "COLD_USDT_TRC20", 500),
    "BTC": ("BTC", "COLD_BTC", 0.01),
}

def sweep():
    exchange.load_markets()
    balances = exchange.fetch_balance()

    for asset, (network, address_env, keep) in SWEEP_RULES.items():
        free = (balances.get(asset) or {}).get("free") or 0
        amount = free - keep
        if amount <= 0:
            continue

        amount = float(exchange.currency_to_precision(asset, amount))
        tx = exchange.withdraw(
            asset,
            amount,
            os.environ[address_env],
            params={"network": network},
        )
        print(f"Swept {amount} {asset} via {network}: {tx.get('id')}")

if __name__ == "__main__":
    sweep()

Notes before running this anywhere real:

Allowlist destination addresses on the exchange side and restrict the API key by IP. A sweep key with withdrawal permissions is a high-value target.
Check how the venue deducts withdrawal fees. Some take the fee from the amount, others require amount + fee <= free. Adjust keep accordingly.
Network names aren't fully standardized across exchanges, even through ccxt. Verify the exact network identifier per venue.
For networks that need a memo/tag, pass the tag argument to withdraw().

4. Never make the API your only exit

BitMEX disabled API withdrawals on September 28, after which withdrawals are manual through the website only. If your treasury operations assume API access, have a documented manual procedure: who has the login, where 2FA lives, and which addresses are pre-approved.

5. Watch announcements, not just uptime

Your health checks probably ping endpoints. Wind-downs are announced on blogs and status pages weeks before endpoints change behavior. A cheap monitor that diffs each venue's announcement page and alerts on keywords like "wind-down," "reduce-only," or "cessation" buys you weeks of lead time.

6. Handle the long-tail exit

After a trading halt, you can only withdraw assets in the form they're held. CoinEx spot trading ends September 29, and from then on, a long-tail token stays a long-tail token. If your integration holds obscure assets, plan to either convert before the halt or withdraw as-is and convert elsewhere.

Disclosure: written by the NefiSwap team. We build an instant exchanger with no accounts and no stored balances, so the question of "where does the money sit, and for how long" is one we think about a lot. NefiSwap supports 8,000+ coins if you need to convert long-tail assets after withdrawing them: nefiswap.com

Telegram Mini App vs Bot for Crypto Swaps: Architecture Notes

Nefi Swap — Thu, 24 Sep 2026 16:29:40 +0000

If you're building a crypto swap flow inside Telegram, you have two interfaces to choose from: a bot (chat commands and inline buttons) or a Mini App (a web app rendered inside Telegram). Most production exchangers end up shipping both. Here's how they split the work, and the pitfalls that actually break swaps.

When to use which

	Bot	Mini App
Best for	Status updates, quick repeat swaps, notifications	First-time swaps, pair search, address input
UI	Messages + inline keyboards	Full HTML/JS UI
Searching 1,000s of assets	Painful	Natural (search + filter)
Push notifications	Native	Needs the bot anyway

A practical split: the Mini App handles the swap creation, and the bot handles everything after: deposit confirmation, status changes, completion.

1. Never trust `initData` on the client

The Mini App receives window.Telegram.WebApp.initData, a query string with user info and a hash. Your backend must validate it before creating any swap tied to a user.

The algorithm (from Telegram's docs):

Remove hash from the params
Sort the remaining key=value pairs alphabetically and join them with \n
secret_key = HMAC_SHA256(key="WebAppData", msg=bot_token)
Compare hex(HMAC_SHA256(key=secret_key, msg=data_check_string)) with hash

import crypto from "node:crypto";

export function validateInitData(initData, botToken, maxAgeSec = 3600) {
  const params = new URLSearchParams(initData);
  const hash = params.get("hash");
  params.delete("hash");

  const dataCheckString = [...params.entries()]
    .sort(([a], [b]) => a.localeCompare(b))
    .map(([k, v]) => `${k}=${v}`)
    .join("\n");

  const secretKey = crypto
    .createHmac("sha256", "WebAppData")
    .update(botToken)
    .digest();

  const computed = crypto
    .createHmac("sha256", secretKey)
    .update(dataCheckString)
    .digest("hex");

  if (computed.length !== hash?.length ||
      !crypto.timingSafeEqual(Buffer.from(computed), Buffer.from(hash))) {
    return null;
  }

  const authDate = Number(params.get("auth_date"));
  if (Date.now() / 1000 - authDate > maxAgeSec) return null;

  return JSON.parse(params.get("user") ?? "null");
}

Also check auth_date. A valid-but-old initData string is still replayable.

2. Quotes expire, so design for it

A swap quote is only valid for a short window. If a user opens the Mini App, gets distracted, and comes back ten minutes later, the rate on screen is stale.

Store quote_expires_at server-side, and don't trust the client's timer
Re-quote on "Confirm" if expired, and show the diff
Decide upfront how you handle a deposit that arrives after expiry (re-quote, refund, or floating rate)

3. Memo/tag networks cause most "missing deposit" tickets

Assets on networks like XRP, XLM, EOS, and TON (for exchange deposit addresses) often require a memo/destination tag in addition to the address. If the user omits it, funds land in the shared deposit address with no way to match them automatically.

Make the memo field required in the UI for those networks, not optional
Show it with the same visual weight as the address, plus a copy button
In the bot, send address and memo as separate messages so each can be copied on mobile

4. Network ambiguity is the second biggest issue

"USDT" isn't one asset. It's USDT-TRC20, USDT-ERC20, USDT-BEP20, and so on. EVM chains share the same 0x address format, so an address check alone won't catch a wrong-network send.

Make network selection explicit, never implicit
Display the network name next to every address you show

5. Deep links connect the two interfaces

Use startapp parameters to hand off from bot to Mini App with context:

https://t.me/YourBot/app?startapp=swap_BTC_USDTTRC20

The parameter shows up as start_param in initData, so a bot message like "Swap again?" can open the Mini App pre-filled.

6. Push status through the bot, don't poll in the UI

Mini Apps close. Users leave. Swap status (awaiting deposit → confirming → exchanging → sent) should be pushed as bot messages, triggered by your backend's state machine and not by a polling loop in a web view nobody is looking at.

For a live example of this split, NefiSwap runs swap creation in a Telegram Mini App and uses a bot for quick swaps and status updates across 8,000+ assets: nefiswap.com. Disclosure: written by the NefiSwap team.