DEV Community: Nefi Swap

Your Asset List Needs a Jurisdiction Column: Modeling ESMA's Exit-Only Stablecoin Rules

Nefi Swap — Fri, 09 Oct 2026 01:26:21 +0000

On October 8, 2026, ESMA published an opinion telling MiCA-authorised crypto service providers to stop offering services for non-MiCA-compliant stablecoins to EU clients, and to remediate existing exposure within three months. The outer deadline is January 8, 2027. USDT is the largest affected token.

The interesting part for engineers is the shape of the rule. It isn't "remove the asset." It's:

Block actions that let EU clients acquire or increase holdings
Allow, temporarily, actions that support an orderly exit: sell, exchange, transfer, withdraw
Apply per jurisdiction, with dates set by each platform's regulator, inside an outer limit

If your asset availability is a single enabled: boolean, you can't express that. Here's a model that can.

Availability is per action, per jurisdiction, over time

type Action =
  | "buy"
  | "deposit"
  | "swap_in"     // receive this asset as the output of a swap
  | "swap_out"    // spend this asset as the input of a swap
  | "sell"
  | "withdraw"
  | "custody";

type Mode = "full" | "exit_only" | "unavailable";

interface AvailabilityRule {
  asset: string;          // asset key, e.g. "tron:trc20:<contract>"
  jurisdiction: string;   // e.g. "EU"
  mode: Mode;
  effectiveFrom: string;  // ISO date
}

const EXIT_ONLY_ALLOWED: ReadonlySet<Action> = new Set([
  "sell",
  "swap_out",
  "withdraw",
  "custody",
]);

exit_only is the important state. It lets users reduce exposure and blocks anything that increases it. Note that swap_in and swap_out are separate actions. Converting out of a restricted asset is an exit; converting into one isn't.

Resolve the active rule at request time

Rules change on dates, so resolve them when the request arrives rather than caching a flag:

const MODE_RANK: Record<Mode, number> = {
  full: 0,
  exit_only: 1,
  unavailable: 2,
};

function activeMode(
  rules: AvailabilityRule[],
  asset: string,
  jurisdiction: string,
  now: Date = new Date(),
): Mode {
  const applicable = rules
    .filter(
      (r) =>
        r.asset === asset &&
        r.jurisdiction === jurisdiction &&
        new Date(r.effectiveFrom) <= now,
    )
    .sort((a, b) => b.effectiveFrom.localeCompare(a.effectiveFrom));

  return applicable[0]?.mode ?? "full";
}

export function isAllowed(
  rules: AvailabilityRule[],
  asset: string,
  jurisdiction: string,
  action: Action,
  now?: Date,
): boolean {
  const mode = activeMode(rules, asset, jurisdiction, now);
  if (mode === "full") return true;
  if (mode === "unavailable") return false;
  return EXIT_ONLY_ALLOWED.has(action);
}

With this, the ESMA transition is data, not a deploy:

const rules: AvailabilityRule[] = [
  {
    asset: "tron:trc20:usdt",
    jurisdiction: "EU",
    mode: "exit_only",
    effectiveFrom: "2026-10-20",
  },
  {
    asset: "tron:trc20:usdt",
    jurisdiction: "EU",
    mode: "unavailable",
    effectiveFrom: "2027-01-08",
  },
];

Things that bite in practice

A swap touches two assets. Check swap_out for the input and swap_in for the output. A USDT-to-USDC conversion is an allowed exit; a USDC-to-USDT conversion isn't.

Pending orders cross the boundary. An order created in full mode and settled after the exit_only date needs a defined outcome. Decide whether you honour, refund, or re-quote it, and store the decision with the order.

Mode changes must be visible. Show the restriction and the date in the UI before it takes effect. Silent failures on a regulatory date generate the worst kind of support load.

Never decrease rank silently. If two rules collide on the same date, prefer the more restrictive mode. MODE_RANK exists so you can enforce that in validation when rules are loaded.

Jurisdiction is an input, not a constant. It comes from your compliance layer, and it can change for a user. Pass it explicitly rather than reading a global.

Why this matters beyond the EU

The same week as ESMA's opinion, FinCEN in the US withdrew its unhosted-wallet and mixing proposals. Rules are diverging across jurisdictions, and they change on dates. Systems that model availability as time-bound, per-action, per-jurisdiction data can follow those changes without emergency code changes.

Disclosure: written by the NefiSwap team. NefiSwap supports conversion across 8,000+ assets via the web, a Telegram Mini App and bot, and an API. nefiswap.com

Stop Using Tickers as Asset IDs. USDT on Bitcoin Just Made It Worse

Nefi Swap — Sun, 04 Oct 2026 17:05:04 +0000

This month, Utexo, a Tether-backed company, plans to launch USDT natively on Bitcoin using the RGB protocol, with Lightning support to follow. Once it does, "USDT on Bitcoin" will refer to at least four different things: Omni (the 2014 original), Liquid, Lightning via Taproot Assets, and RGB.

If your system identifies assets by ticker, or even by ticker + chain, that's a data model problem waiting to happen.

The bug pattern

Most codebases start like this:

type Asset = "BTC" | "ETH" | "USDT" | "USDC";

Then multi-chain support arrives:

type Asset = { symbol: string; chain: string };
// { symbol: "USDT", chain: "bitcoin" }  ← which one?

With four distinct USDT rails tied to Bitcoin, chain: "bitcoin" is ambiguous. Each rail has different address formats, different wallets, different deposit detection, and different settlement semantics.

Model the rail, not the chain

An asset needs enough fields to be unambiguous and to drive behavior:

type Protocol =
  | "native"
  | "erc20"
  | "trc20"
  | "bep20"
  | "spl"
  | "jetton"
  | "omni"
  | "liquid"
  | "taproot-assets"
  | "rgb";

interface AssetId {
  symbol: string;          // display only, never a key
  network: string;         // "bitcoin", "ethereum", "tron", "lightning", ...
  protocol: Protocol;      // how the asset exists on that network
  contract?: string;       // token contract / asset id where applicable
}

const assetKey = (a: AssetId): string =>
  [a.network, a.protocol, a.contract ?? "native"].join(":");

Two rules follow from this:

symbol is a label, not an identifier. Never join, dedupe, or route on it.
The key must include the contract or asset ID wherever one exists. Tickers can be copied by anyone; contract addresses can't.

Capabilities belong on the rail

Different rails need different flows. Encode that as data instead of scattering if (chain === ...) checks:

interface RailCapabilities {
  needsMemo: boolean;               // XRP, XLM, TON deposits
  publicLedger: boolean;            // false for RGB-style client-side validation
  addressFormat: RegExp;
  minConfirmations: number;
  supportedForDeposit: boolean;
  supportedForWithdrawal: boolean;
}

const rails = new Map<string, RailCapabilities>();

publicLedger: false matters for RGB. With client-side validation, transaction data isn't published to a public ledger the way it is on Tron or Ethereum, so deposit detection and status tracking can't rely on the usual "watch the chain" approach.

Gate new rails explicitly

New rails will keep arriving. Treat every new one as unsupported until enabled, and validate before showing a deposit address:

function assertDepositable(asset: AssetId): RailCapabilities {
  const caps = rails.get(assetKey(asset));
  if (!caps || !caps.supportedForDeposit) {
    throw new Error(`Deposits not supported for ${assetKey(asset)}`);
  }
  return caps;
}

Failing closed here prevents the most expensive class of user error: funds sent to a rail you can't detect.

Show the network everywhere

Every UI surface that shows a symbol should also show the network and protocol. "USDT" alone is now as ambiguous to users as it is to your database.

Plan for more fragmentation, not less

USDT on Bitcoin isn't the only change. Open USD launched on September 30 with $1 billion in committed liquidity from Coinbase, Mastercard, Visa, Stripe, and Shopify. More rails for the same stablecoin and more stablecoins for the same dollar are both trends. A schema that assumes either one is stable will need a migration.

Disclosure: written by the NefiSwap team. NefiSwap converts across 8,000+ assets and their networks, with crypto swaps that need no account, a Telegram Mini App and bot, and an API for teams that want conversion built in. nefiswap.com

Your Swap Service Is on the Laundering Path: Engineering Notes From the Bitget and NEAR Intents Incidents

Nefi Swap — Fri, 02 Oct 2026 03:13:52 +0000

Within one week, NEAR Intents, a cross-chain swap protocol that had processed more than $30 billion across 35 chains, was on both sides of a security incident.

After Bitget's September 24 breach, about $50 million of stolen funds tried to route through the protocol and was stopped. On October 1, NEAR Intents was exploited itself for about $3.8 million, through a bug in how its Omni deposit and withdrawal infrastructure interacted with the Intents smart contract. Investigators traced the exploit to irregular outflows from a BNB Chain hot wallet, and the team froze deposits and withdrawals on 11 networks while it patched.

If you build or operate any swap or bridge service, both halves of that week are design inputs. Here's what they suggest.

1. Screen before execution, not after

Stolen funds arrive looking like any other deposit. The only point where you can stop them cheaply is before you execute the swap and send the output on-chain. After that, you're chasing.

Model screening as an explicit state in your order lifecycle:

awaiting_deposit → deposit_detected → screening → (cleared | held) → executing → sent

The important part is held. It needs a defined exit path (refund, manual review, or release) and a user-visible status. An order that silently stalls looks identical to a scam from the user's side.

2. Pause per network, not globally

NEAR Intents froze deposits and withdrawals on 11 specific networks rather than shutting everything down. Their co-founder said the exploit was isolated to USDT on BSC. Network-level granularity let unaffected routes keep running.

If your only kill switch is "stop the service," every incident becomes a full outage.

3. Limit hot-wallet outflow velocity

The NEAR Intents exploit started with irregular outflows from a hot wallet. An outflow guard that tracks volume per network in a rolling window, and trips a pause automatically, bounds how much an exploit can drain before a human looks at it:

export class OutflowGuard {
  constructor({ windowMs, limits }) {
    this.windowMs = windowMs;   // e.g. 10 * 60 * 1000
    this.limits = limits;       // { "BSC": 250000, "TRON": 400000 } in USD
    this.events = new Map();    // network -> [{ ts, usd }]
    this.paused = new Set();
  }

  allow(network, usd, now = Date.now()) {
    if (this.paused.has(network)) return false;

    const limit = this.limits[network];
    if (limit === undefined) return false; // unknown network: fail closed

    const recent = (this.events.get(network) ?? [])
      .filter((e) => now - e.ts < this.windowMs);

    const total = recent.reduce((sum, e) => sum + e.usd, 0);
    if (total + usd > limit) {
      this.paused.add(network);
      return false;
    }

    recent.push({ ts: now, usd });
    this.events.set(network, recent);
    return true;
  }

  resume(network) {
    this.paused.delete(network);
  }
}

Notes for production:

This is in-memory; put state somewhere shared if you run multiple signers
Fail closed on unknown networks, as above
Tripping the guard should page a human and flip the network's public status, not just block quietly
Set limits from historical peak volume per network, not round numbers

4. Separate the deposit path from the contract logic

The NEAR Intents bug sat in the interaction between deposit infrastructure and contract logic, not in either one alone. Integration boundaries deserve their own tests: replayed deposits, duplicated callbacks, amounts that don't match the order, and deposits arriving on a network the order didn't expect.

5. Publish status like an API

During incidents, users need one machine-readable source of truth: which networks accept deposits right now. A simple /status endpoint with per-network flags, consumed by your own UI and bots, prevents users from sending funds into a paused route and gives partners something to integrate against.

6. Plan for the "refund scam" phase

Every public incident is followed by fake compensation messages. Decide in advance where compensation will be announced, state that you will never contact users first about it, and put that statement on the status page before you need it.

Disclosure: written by the NefiSwap team. NefiSwap runs no-account crypto-to-crypto swaps where no-KYC doesn't mean no-AML: transactions can be screened and flagged funds held for review. nefiswap.com

Designing a Telegram Swap Bot That's Hard to Impersonate

Nefi Swap — Sun, 27 Sep 2026 22:27:41 +0000

Telegram mini apps have passed 100 million monthly active users, according to the TON Foundation. For anyone building crypto services there, that distribution comes with a problem: your bot is trivially easy to imitate.

Scam Sniffer documented a campaign using a fake verification bot named OfficiaISafeguardBot, with a capital I in place of a lowercase l. Nothing in the Telegram UI stops that. You can't prevent lookalikes. What you can do is design your service so that impersonating it is harder, and so that users have a reliable way to tell the difference.

These notes assume a deposit-address swap flow: the user sends a specific amount to an address generated for their order and receives the output at an address they specify.

1. Minimize what the user hands over

The single biggest security decision is the custody model:

Model	User hands over	Worst case if impersonated or compromised
Bot-held wallet	Private key	Entire wallet
Connect + sign	Approvals / signatures	Whatever was approved
Deposit address	One transaction's amount	That transaction

A deposit-address flow means your bot never needs a seed phrase, a private key, or a token approval. Say that explicitly in the bot's description and first message. It turns "the bot asked for my seed phrase" into an instant, unambiguous red flag for your users.

2. Make the website the root of trust

Users can't verify a bot by how it looks. They can verify where the link came from.

Publish your exact bot username on your website
Put "Open in Telegram" deep links only on your own domain
Repeat the canonical website in the bot's description and about text, so users see it from both directions

Telegram deep links let you pass a start parameter of up to 64 characters from A-Z, a-z, 0-9, _ and -. You can use that to connect orders created on the website to the bot, and sign the payload so the bot only accepts links your backend issued:

import crypto from "node:crypto";

const SECRET = process.env.START_LINK_SECRET;

function sign(orderId) {
  return crypto
    .createHmac("sha256", SECRET)
    .update(orderId)
    .digest("base64url")
    .slice(0, 22);
}

// orderId: alphanumeric only, max ~40 chars, so the payload stays under 64
export function buildStartLink(botUsername, orderId) {
  return `https://t.me/${botUsername}?start=${orderId}_${sign(orderId)}`;
}

export function parseStartPayload(payload) {
  const i = payload.lastIndexOf("_");
  if (i <= 0) return null;

  const orderId = payload.slice(0, i);
  const received = Buffer.from(payload.slice(i + 1));
  const expected = Buffer.from(sign(orderId));

  if (received.length !== expected.length) return null;
  return crypto.timingSafeEqual(received, expected) ? orderId : null;
}

This doesn't stop a copycat bot from existing. It means the official bot shows the same order ID and the same deposit address the user just saw on the website, which gives them something concrete to cross-check.

3. Let users verify the deposit address outside Telegram

The core attack against a deposit-address flow is a fake bot showing an attacker's address. The defense is a second channel:

Every order gets an ID shown in both the bot and the Mini App
The website has an order lookup page that displays the deposit address for that ID
The bot's instructions tell users to confirm the address matches before sending

It adds one step for cautious users and costs you almost nothing.

4. Use the fact that bots can't message first

A Telegram bot can't start a conversation with a user who hasn't started it. That's a useful property to teach:

State in your onboarding that official support never messages first
Never have human support initiate DMs from personal accounts either, or you train users to accept exactly the pattern scammers rely on

5. Never build a "verification" step that runs anything

The fake Safeguard campaign worked because users were conditioned to expect verification gates in crypto groups. If your community uses a verification bot, make sure it never asks users to paste commands, install anything, or visit an external page to "prove they're human."

6. Reduce the value of a stale screenshot

Scammers reuse screenshots of real interfaces. Include dynamic details in order confirmations: order ID, creation time, and quote expiry. A static fake is easier to spot when the real thing is visibly specific.

Disclosure: written by the NefiSwap team. NefiSwap's Telegram Mini App and bot use a deposit-address flow that never requests keys or approvals, and the official way to open them is from nefiswap.com.

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.