DEV Community: NefiSwap

Counting USDT freezes on Tron with 70 lines of Node.js

NefiSwap — Fri, 13 Nov 2026 00:49:19 +0000

This week Tron, Tether and Chainalysis announced the Digital Crime Task Force, a group that will use Chainalysis data to spot illicit USDT on Tron and help police freeze it before it moves (Decrypt, Cointelegraph). It replaces the T3 Financial Crime Unit that Tron and Tether formed with TRM Labs in 2024, which Bloomberg reported had disbanded in late August.

The news coverage talks about freezes as if they were a legal process. Under the hood the process ends in a contract call, and contract calls leave events. So instead of taking anyone's totals on trust, I wanted to count them.

Where the freeze lives

USDT on Tron is the TRC20 contract TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t. Like the Ethereum version, it carries a blacklist with three events that matter here:

AddedBlackList(address _user) when the issuer freezes an address
RemovedBlackList(address _user) when it lifts one
DestroyedBlackFunds(address _blackListedUser, uint _balance) when it burns the balance of a frozen address

It also exposes a public read, isBlackListed(address), that returns true or false. Reading it costs nothing because it runs as a constant call.

The script

No dependencies, Node 18 or newer. It pages through TronGrid's public event API for the last 30 days, backs off when the free tier answers 429, and optionally checks one address.

// freeze-watch.mjs: how often does Tether freeze USDT on Tron, and is a given address frozen?
// Node 18+, no dependencies, public TronGrid API (no key needed for light use).
//   node freeze-watch.mjs                 -> blacklist activity on the USDT TRC20 contract, last 30 days
//   node freeze-watch.mjs <T... address>  -> also checks that address with isBlackListed(address)
const USDT = 'TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t';
const API = 'https://api.trongrid.io';
const DAYS = 30;
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

async function events(name, since) {
  const out = [];
  let url = `${API}/v1/contracts/${USDT}/events?event_name=${name}&min_block_timestamp=${since}&limit=200&order_by=block_timestamp,desc`;
  while (url) {
    let r;
    for (let tries = 0; ; tries++) {
      r = await fetch(url);
      if (r.status !== 429 || tries === 5) break;
      await sleep(2000 * (tries + 1)); // free tier: back off and retry
    }
    if (!r.ok) throw new Error(`${name}: HTTP ${r.status}`);
    const j = await r.json();
    out.push(...j.data);
    url = j.meta?.links?.next || null;
    await sleep(1200); // stay polite with the free tier
  }
  return out;
}

async function isBlackListed(addr) {
  const r = await fetch(`${API}/wallet/triggerconstantcontract`, {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ owner_address: USDT, contract_address: USDT, function_selector: 'isBlackListed(address)', parameter: toWord(addr), visible: true }),
  });
  const j = await r.json();
  const hex = j.constant_result?.[0];
  if (!hex) throw new Error('no result: ' + JSON.stringify(j.result || j));
  return BigInt('0x' + hex) === 1n;
}

// base58check T-address -> 32-byte ABI word (drop the 0x41 prefix, left-pad the 20 bytes)
function toWord(addr) {
  const A = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz';
  let n = 0n;
  for (const c of addr) {
    const i = A.indexOf(c);
    if (i < 0) throw new Error('not a base58 address');
    n = n * 58n + BigInt(i);
  }
  const hex = n.toString(16).padStart(50, '0'); // 25 bytes: 0x41 + 20 bytes + 4-byte checksum
  if (!hex.startsWith('41')) throw new Error('not a Tron mainnet address');
  return hex.slice(2, 42).padStart(64, '0');
}

const since = Date.now() - DAYS * 864e5;
const added = await events('AddedBlackList', since);
const removed = await events('RemovedBlackList', since);
const destroyed = await events('DestroyedBlackFunds', since);
const day = (e) => new Date(e.block_timestamp).toISOString().slice(0, 10);
const perDay = {};
for (const e of added) perDay[day(e)] = (perDay[day(e)] || 0) + 1;
const burned = destroyed.reduce((s, e) => s + Number(e.result._balance || e.result[1] || 0), 0) / 1e6;

console.log(`USDT on Tron (${USDT}), last ${DAYS} days, as of ${new Date().toISOString().slice(0, 16)} UTC`);
console.log(`  addresses added to the blacklist:   ${added.length}`);
console.log(`  addresses removed from it:          ${removed.length}`);
console.log(`  DestroyedBlackFunds calls:          ${destroyed.length} (${burned.toLocaleString('en-US')} USDT burned)`);
const busiest = Object.entries(perDay).sort((a, b) => b[1] - a[1]).slice(0, 3);
console.log(`  busiest days:                       ${busiest.map(([d, n]) => `${d} (${n})`).join(', ')}`);

const target = process.argv[2];
if (target) console.log(`\n${target} is ${(await isBlackListed(target)) ? 'FROZEN' : 'not frozen'} by the USDT contract`);

A few details that took a second look:

TronGrid paginates with a meta.links.next URL, so the loop just follows it until it's gone.
triggerconstantcontract wants the ABI-encoded argument, not the base58 address. A Tron address is base58check over 0x41 + 20 bytes + a 4-byte checksum, so the script decodes it, drops the 0x41 and pads the 20 bytes to a 32-byte word.
_balance is in USDT's 6 decimals.

What it printed

I ran it on November 13, 2026, with a freshly generated address that has never held anything:

USDT on Tron (TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t), last 30 days, as of 2026-11-13T00:10 UTC
  addresses added to the blacklist:   385
  addresses removed from it:          26
  DestroyedBlackFunds calls:          41 (37,992,921.092 USDT burned)
  busiest days:                       2026-10-14 (65), 2026-10-30 (63), 2026-10-28 (36)

TVZ8ST7Ue57QnTWCNPcBW5VL51jhDu714H is not frozen by the USDT contract

October 30 was the day after the $6.3 billion Binance hack. Cointelegraph, citing Crystal Intelligence, reports that the attackers swapped about $234 million of USDT into TRX before Tether froze what was left in two linked wallets. Tether's CEO now puts total USDT freezes at more than $7 billion.

Where this is useful

If you run anything that pays out USDT on Tron, the isBlackListed check is cheap enough to run before every send. A frozen destination means the funds get stuck at an address that can't move them.

The event counts also make a decent sanity check for news. When a report says the issuer froze funds after an incident, the contract events show the day and the size.

Two caveats. TronGrid's public tier is rate-limited, so for anything regular use an API key or your own node. And each network's USDT is a separate contract with its own list, so a check on Tron says nothing about the same holder on Ethereum.

Sources: Decrypt (Nov 2026); Cointelegraph (Nov 2026); The Block (Nov 12, 2026); TronGrid public API.

Splitting a wallet key 2-of-3 in Node.js, and what Keplr's social login incident shows about it

NefiSwap — Tue, 10 Nov 2026 00:56:34 +0000

On November 6, 2026, Web3Auth paused its wallet service after a flaw in its systems exposed the private keys of some Keplr Wallet users who had signed up with Google or Apple. Keplr co-founder Josh Lee estimated about 20% of those social login accounts were affected and said Keplr's own code wasn't the problem. Over the weekend Web3Auth moved about $5.6 million out of exposed wallets into 12 recovery addresses, which on-chain trackers first read as the attacker's haul (The Block).

Keplr's preliminary review said accounts created with a recovery phrase or a hardware wallet were not affected. Its help center says Google login accounts get a hex private key generated by Web3Auth instead of a 12 or 24 word phrase, and coverage of the incident describes Web3Auth's method as distributed key generation: the key lives as shares in different places and comes together at login.

Web3Auth hasn't published the root cause, so this post doesn't guess at it. What I wanted to understand is the primitive underneath: how a key can be split so that no single share means anything, and where that guarantee stops.

The idea in one line

Shamir's secret sharing hides the secret as the value of a polynomial at x = 0. For a 2-of-3 split you pick a random line f(x) = secret + a1 * x, hand out the points f(1), f(2), f(3), and throw away a1. Two points define a line, so any two shares give back f(0). One point fits infinitely many lines, so a single share tells you nothing.

The arithmetic has to happen in a finite field, otherwise the share values leak size information. For a secp256k1 wallet key the natural choice is the curve's group order N, since valid private keys are already integers mod N.

The code

Plain Node.js 18+, no dependencies. Save it as split-key.mjs.

import { randomBytes } from 'node:crypto';

// secp256k1 group order: valid private keys are integers in [1, N-1]
const N = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141n;
const mod = (a) => ((a % N) + N) % N;
const rand = () => mod(BigInt('0x' + randomBytes(32).toString('hex')));
const inv = (a) => { // Fermat: a^(N-2) mod N, N is prime
  let r = 1n, b = mod(a), e = N - 2n;
  while (e > 0n) { if (e & 1n) r = (r * b) % N; b = (b * b) % N; e >>= 1n; }
  return r;
};
const hex = (x) => x.toString(16).padStart(64, '0');

// Split: f(x) = secret + a1*x, share i is (i, f(i)). Any 2 points fix the line.
function split(secret, n = 3) {
  const a1 = rand();
  return Array.from({ length: n }, (_, k) => { const x = BigInt(k + 1); return { x, y: mod(secret + a1 * x) }; });
}
// Combine: Lagrange interpolation at x = 0
function combine(shares) {
  let s = 0n;
  for (const { x: xi, y: yi } of shares) {
    let num = 1n, den = 1n;
    for (const { x: xj } of shares) if (xj !== xi) { num = mod(num * -xj); den = mod(den * (xi - xj)); }
    s = mod(s + yi * num * inv(den));
  }
  return s;
}

const key = rand();
const shares = split(key);
console.log('private key   ', hex(key));
shares.forEach((s) => console.log(`share ${s.x}       `, hex(s.y)));

for (const pair of [[0, 1], [0, 2], [1, 2]]) {
  const got = combine(pair.map((i) => shares[i]));
  console.log(`shares ${pair[0] + 1}+${pair[1] + 1} ->  `, got === key ? 'same key' : 'MISMATCH');
}

// One share alone says nothing: for ANY candidate key there is a line through it and share 1.
const guess = rand();
const slope = mod((shares[0].y - guess) * inv(shares[0].x));
console.log('share 1 alone fits a random key too:', mod(guess + slope * 1n) === shares[0].y);

// The catch: whoever ends up holding two shares holds the key.
console.log('attacker with shares 1+3 rebuilds it:', combine([shares[0], shares[2]]) === key);

Output

Your hex values will differ on every run; the checks won't.

private key    8f5d2b92921cf8791535495c163aa1025ca3ec575d4b7f5ecd6a7134bb41a8b2
share 1        8cac3d676aeb94d4150b78c133b078c096c5d7c0704f7a77b5e1c92c138e7c83
share 2        89fb4f3c43ba312f14e1a8265126507ed0e7c329835375909e5921236bdb5054
share 3        874a61111c88cd8a14b7d78b6e9c283d0b09ae92965770a986d0791ac4282425
shares 1+2 ->   same key
shares 1+3 ->   same key
shares 2+3 ->   same key
share 1 alone fits a random key too: true
attacker with shares 1+3 rebuilds it: true

What the split protects, and what it doesn't

The math does its job. Steal one share and you have a uniformly random number. That is why a social login design can keep one share with a sign-in network, one on the user's device and one as a backup, and still say no single party holds the key.

The last line of the output is the part that matters for incidents like this one. The scheme is only as strong as the separation between share holders. If one system can reach two shares, or if the full key is ever rebuilt in a place an attacker can read, the threshold stops mattering. Real deployments use threshold signatures or DKG so the full key is never assembled at all, which shrinks that window but doesn't remove the dependency on the provider's infrastructure.

A recovery phrase sits on the other end of the trade. One copy, no math, and only the person holding the paper can rebuild it. Keplr's phrase and hardware accounts were outside this incident because nothing about them touched Web3Auth.

If you're building on embedded wallets

Read your provider's docs for where each share lives and which component rebuilds or uses the key. Find out whether users can export the key and leave, and check that they can do it during an outage, not only when your app is healthy. Keep a status page or a kill switch for deposits ready, because Keplr's first instruction to users was to stop sending funds to affected accounts.

This demo is for learning. Don't hand-roll secret sharing for production keys; use an audited library and a threshold signature scheme.

Sources: The Block (Nov 8, 2026); Keplr Help Center, "Privacy & Security"; CryptoTicker (Nov 7, 2026).

Measuring Zcash's NU7 hard fork from raw block headers

NefiSwap — Fri, 06 Nov 2026 12:51:36 +0000

Zcash activated its NU7 network upgrade on November 6, 2026, at block 3,543,405. Two changes got most of the attention. The target time between blocks dropped from 75 seconds to 25, and ZIP 2003 made nodes reject version 4 transactions. Version 4 is the only format that can spend from Sprout, Zcash's first shielded pool, so the roughly 12,224 ZEC still sitting there (per ZecStats, as reported by Cointelegraph and Decrypt) can no longer be moved.

I wanted to check the block-time claim on the chain itself, without running a node and without trusting an explorer's summary. This post shows how to pull a raw block, find the timestamp in the header bytes, and compare the average interval before and after activation.

What ZIP 2003 actually changes

The consensus change is one line in the protocol spec. Before NU7:

The transaction version number MUST be 4 or 5 or 6.

From NU7 on:

The transaction version number MUST be 5 or 6.

Neither the v5 format (ZIP 225) nor v6 (ZIP 229) has fields for Sprout JoinSplits, so dropping v4 also drops the only way to spend Sprout notes. The ZIP says the funds are not burned and stay counted in issued supply, and that the ability to spend them "may never be re-enabled".

Any software that still produced v4 transactions for other reasons breaks as well, which is worth checking if you maintain a Zcash integration.

Where the timestamp lives

A Zcash block header is a fixed-size prefix followed by the Equihash solution:

Field	Bytes	Offset
`nVersion`	4	0
`hashPrevBlock`	32	4
`hashMerkleRoot`	32	36
`hashBlockCommitments`	32	68
`nTime`	4	100
`nBits`	4	104
`nNonce`	32	108

nTime is a little-endian Unix timestamp at byte 100. Blockchair's public API returns the raw block as hex at /zcash/raw/block/<height>, so we take the first 108 bytes, read four bytes at offset 100, and we have the block's time.

The script

// Measure Zcash block times before and after NU7 from raw block headers.
// Usage: node block-times.mjs [activationHeight=3543405] [window=1000]
// Data: Blockchair's public raw-block endpoint (no key needed for a few calls).

const ACT = Number(process.argv[2] ?? 3543405);
const WIN = Number(process.argv[3] ?? 1000);
const API = 'https://api.blockchair.com/zcash';

async function json(url) {
  const r = await fetch(url);
  if (!r.ok) throw new Error(`${r.status} for ${url}`);
  return r.json();
}

// Zcash header layout: version(4) | prevHash(32) | merkleRoot(32) |
// blockCommitments(32) | nTime(4, little-endian) | nBits(4) | nonce(32) | solution...
// so nTime sits at byte offset 100.
async function blockTime(height) {
  const j = await json(`${API}/raw/block/${height}`);
  const hex = j.data[height].raw_block;
  const buf = Buffer.from(hex.slice(0, 216), 'hex');
  return buf.readUInt32LE(100);
}

const tip = (await json(`${API}/stats`)).data.best_block_height;
const before = ACT - WIN;
const heights = [before, ACT, tip];
const t = {};
for (const h of heights) {
  t[h] = await blockTime(h);
  await new Promise((r) => setTimeout(r, 1200)); // be gentle with the free API
}

const avg = (a, b) => (t[b] - t[a]) / (b - a);
const iso = (s) => new Date(s * 1000).toISOString().replace('.000Z', 'Z');

console.log(`activation block ${ACT} at ${iso(t[ACT])}`);
console.log(`before: ${WIN} blocks (${before}..${ACT}) averaged ${avg(before, ACT).toFixed(1)} s`);
console.log(`after:  ${tip - ACT} blocks (${ACT}..${tip}) averaged ${avg(ACT, tip).toFixed(1)} s`);
console.log(`target after NU7: 25 s (was 75 s)`);

It needs Node 18 or newer for the built-in fetch, and nothing else.

What it printed

I ran it at about 12:15 UTC on November 6:

activation block 3543405 at 2026-11-06T02:34:02Z
before: 1000 blocks (3542405..3543405) averaged 75.4 s
after:  1238 blocks (3543405..3544643) averaged 28.1 s
target after NU7: 25 s (was 75 s)

The activation time matches the 02:34 UTC that ZecStats reported. Before the fork, blocks landed almost exactly on the old 75-second target. After it, the average is already 28.1 seconds. It sits a little above 25 because difficulty adjusts over a window of past blocks, so the first few hours run slow. Run the script again in a day or two and the number should get closer to 25.

Caveats

Block timestamps are set by miners and can be off by a bit. Averaging over hundreds of blocks smooths that out, but don't read much into any single interval.
Taking the average from two endpoints is cheap and ignores what happens in between. If you want the distribution, fetch every block in the range, but mind the API's rate limits or point the same parser at your own zebrad node.
Blockchair is a third party. You can check its bytes, though: hash the full header with double SHA-256, reverse the bytes, and compare the result with the block hash a second source gives you.

Read the take-home test before you run it

NefiSwap — Thu, 05 Nov 2026 03:12:16 +0000

On November 3, Binance published its first incident report on the October 29 breach, in which more than $6.3 billion was stolen from its wallets. According to The Block's summary, one step in the chain will be familiar to anyone who has looked for a job in tech. In September, attackers posing as company executives ran a fake recruitment process and sent an employee a coding assignment. He downloaded it, and it infected his work computer. Weeks later that computer was the starting point for the wallet attack.

A take-home test asks you to clone a stranger's repository, install its dependencies and run it, which is also what an attacker needs you to do. This post looks at where a repo can run code on your machine before you have read it, and walks through a small Node.js script that checks for those spots without executing anything.

Where a repo can run code on your machine

In a project folder, npm install runs the project's preinstall, install, postinstall and prepare scripts by itself, and dependencies can run their own install scripts too (npm docs).
A VS Code task with "runOptions": { "runOn": "folderOpen" } starts when the folder is opened, once automatic tasks are allowed (VS Code tasks). Workspace Trust keeps tasks from running in Restricted Mode (Workspace Trust).
A github: URL or a user/repo shorthand in package.json pulls a dependency straight from a Git repository, outside the npm registry.
Then there's the code you're asked to run. Tests, npm start and helper scripts run with your permissions like anything else.

The script

audit-take-home.mjs reads files and nothing else. It looks for install hooks, editor tasks that run on open, non-registry dependencies, native binaries, and a few source patterns that deserve a closer look: code built from strings, child processes, base64 decoding, raw IP addresses, paths to SSH keys or wallet files, and very long lines that often mean minified or obfuscated code.

#!/usr/bin/env node
// Static red-flag scan for a take-home coding test, before you install or run anything.
// It only reads files. It never runs npm, node, python or any script from the repo.
// usage: node audit-take-home.mjs <path-to-repo>
import { readdirSync, readFileSync, statSync } from 'node:fs';
import { basename, extname, join, relative, sep } from 'node:path';

const root = process.argv[2];
if (!root) {
  console.error('usage: node audit-take-home.mjs <path-to-repo>');
  process.exit(2);
}

const SKIP_DIRS = new Set(['.git', 'node_modules']);
const CODE_EXT = new Set(['.js', '.cjs', '.mjs', '.ts', '.jsx', '.tsx', '.py', '.sh', '.ps1', '.bat', '.cmd']);
// scripts npm runs by itself during `npm install` in a project folder
const INSTALL_HOOKS = ['preinstall', 'install', 'postinstall', 'prepublish', 'preprepare', 'prepare', 'postprepare'];
const CODE_PATTERNS = [
  ['builds code from strings', /\beval\s*\(|new\s+Function\s*\(/],
  ['starts other processes', /child_process|\bexecSync\s*\(|\bspawn\s*\(|subprocess\.|os\.system\s*\(/],
  ['decodes base64', /\batob\s*\(|Buffer\.from\([^)]*['"]base64['"]|b64decode\s*\(/],
  ['talks to a raw IP address', /https?:\/\/\d{1,3}(?:\.\d{1,3}){3}/],
  ['touches keys, wallets or browser data', /\.ssh[\/]|id_rsa|id_ed25519|Login Data|Local State|wallet\.dat|keychain|\.npmrc|Exodus|MetaMask/i],
];
const outsideRegistry = (v) =>
  /^(git\+|git:|github:|gitlab:|bitbucket:|https?:|file:)/.test(v) || /^[\w.-]+\/[\w.-]+(#.*)?$/.test(v);

const findings = [];
const flag = (file, what, detail) => findings.push({ file: (relative(root, file) || basename(file)).split(sep).join('/'), what, detail });

function checkPackageJson(file) {
  let pkg;
  try {
    pkg = JSON.parse(readFileSync(file, 'utf8'));
  } catch {
    return flag(file, 'package.json does not parse', '');
  }
  for (const hook of INSTALL_HOOKS) if (pkg.scripts?.[hook]) flag(file, `npm install runs "${hook}"`, pkg.scripts[hook]);
  const deps = { ...pkg.dependencies, ...pkg.devDependencies, ...pkg.optionalDependencies };
  for (const [name, spec] of Object.entries(deps)) if (outsideRegistry(String(spec))) flag(file, 'dependency from outside the npm registry', `${name}: ${spec}`);
}

function checkVsCodeTasks(file) {
  if (/"runOn"\s*:\s*"folderOpen"/.test(readFileSync(file, 'utf8'))) flag(file, 'VS Code task runs when the folder is opened', 'runOptions.runOn: "folderOpen"');
}

function checkSource(file) {
  const src = readFileSync(file, 'utf8');
  for (const [what, re] of CODE_PATTERNS) {
    const m = src.match(re);
    if (m) flag(file, what, m[0].slice(0, 60));
  }
  const longest = src.split('\n').reduce((n, line) => Math.max(n, line.length), 0);
  if (longest > 2000) flag(file, 'very long line, often minified or obfuscated', `${longest} characters`);
}

function walk(dir) {
  for (const name of readdirSync(dir)) {
    if (SKIP_DIRS.has(name)) continue;
    const path = join(dir, name);
    const st = statSync(path);
    if (st.isDirectory()) {
      walk(path);
      continue;
    }
    if (name === 'package.json') checkPackageJson(path);
    if (name === 'tasks.json' && basename(dir) === '.vscode') checkVsCodeTasks(path);
    if (/\.(node|exe|dll|so|dylib)$/i.test(name)) flag(path, 'ships a native binary', `${st.size} bytes`);
    if (CODE_EXT.has(extname(name).toLowerCase()) && st.size < 2_000_000) checkSource(path);
  }
}

walk(root);
if (!findings.length) {
  console.log('No red flags found. That is not proof the code is safe: still run it in a throwaway machine.');
  process.exit(0);
}
const byFile = Map.groupBy ? Map.groupBy(findings, (f) => f.file) : findings.reduce((m, f) => m.set(f.file, [...(m.get(f.file) ?? []), f]), new Map());
console.log(`${findings.length} red flag(s) in ${byFile.size} file(s):\n`);
for (const [file, list] of byFile) {
  console.log(file);
  for (const f of list) console.log(`  - ${f.what}${f.detail ? `: ${f.detail}` : ''}`);
}
console.log('\nDo not run npm install, the tests or the editor tasks on a machine that holds credentials.');
process.exit(1);

A few notes on the choices:

It skips node_modules and .git. A take-home repo shouldn't ship either, and if it does, that is worth a look on its own.
The patterns are deliberately loose. A real project may use child_process for good reasons, so each hit is a pointer to a file to read, and a hit doesn't mean the file is malicious.
It exits with code 1 when it finds anything, so you can put it in a script or a pre-commit hook for reviewers.

Running it on a sample

The sample repo next to the script has a postinstall hook, a dependency pulled from GitHub, a VS Code task set to run on folder open, and an install script that decodes a base64 string and passes it to a shell command. The script itself is harmless and only prints "hello", but it has the same shape as the real thing.

node audit-take-home.mjs sample-take-home

5 red flag(s) in 3 file(s):

.vscode/tasks.json
  - VS Code task runs when the folder is opened: runOptions.runOn: "folderOpen"
package.json
  - npm install runs "postinstall": node scripts/setup.js
  - dependency from outside the npm registry: helpers: github:example/helpers
scripts/setup.js
  - starts other processes: child_process
  - decodes base64: Buffer.from('aGVsbG8=', 'base64'

Do not run npm install, the tests or the editor tasks on a machine that holds credentials.

Pointed at the src folder alone, which only holds the exercise code, it prints No red flags found. and exits with 0.

What it doesn't catch

Static checks are a first look. Obfuscated code can avoid every pattern here, a dependency's own install script only exists after you download it, and a malicious test file looks like any other test file. A clean result means nothing obvious turned up. Run the code somewhere disposable anyway:

a virtual machine, a container or a cloud development environment with no SSH keys, cloud credentials, browser sessions or wallets;
npm install --ignore-scripts when you need dependencies without running their hooks;
VS Code in Restricted Mode until you've read the repository.

In the Binance case the infected machine was a work computer, and that gave the attackers a path to colleagues and, eventually, to a container deployment permission. A throwaway environment would have stopped them at the first step.

Sources

How many guesses is a seed phrase? BIP39 entropy and PBKDF2 cost, measured in Node.js

NefiSwap — Mon, 02 Nov 2026 19:41:20 +0000

In July 2026, attackers rebuilt Bitcoin wallets created on Coldcard hardware wallets without touching the devices. A firmware configuration mistake dating back to 2021 meant the devices skipped their hardware random number generator when creating seeds, and Coinkite, the maker, estimates the affected seeds carried about 40 bits of entropy on the Mk2 and Mk3 and about 72 bits on the Mk4, Mk5 and Q. A BIP39 seed is designed for 128. Galaxy Research counted 1,778 BTC stolen by August 14.

On November 1, Trezor raised its maximum wallet passphrase length from 50 to 128 characters and cited those attacks. This post works through the numbers behind both events with one Node script that has no dependencies: what a seed is made of, what one guess costs, how big 40, 72 and 128 bits are at that cost, and what a passphrase adds. Everything here ran on Node 24 on a laptop.

What a BIP39 seed is made of

A 12-word mnemonic encodes 128 bits of entropy plus a 4-bit checksum, split into twelve 11-bit indexes into a 2,048-word list. A 24-word mnemonic encodes 256 bits. The words are only an encoding. Their strength is exactly the strength of the random number behind them, which is why a broken generator produces normal-looking words.

The wallet never uses the words directly. BIP39 turns them into a 64-byte seed with PBKDF2:

import { pbkdf2Sync } from 'node:crypto';

// salt = "mnemonic" + passphrase, 2048 rounds of HMAC-SHA512, 64 bytes out
const seedFrom = (mnemonic, passphrase = '') =>
  pbkdf2Sync(mnemonic.normalize('NFKD'), ('mnemonic' + passphrase).normalize('NFKD'), 2048, 64, 'sha512');

Two details matter for the rest of the post. The 2,048 rounds make every guess deliberately slow. And the passphrase is part of the salt, so a different passphrase gives a completely different seed, and every passphrase an attacker tries costs a full derivation of its own.

Check it against the test vector first

Timing a function that computes the wrong thing tells you nothing, so the script starts with the first official test vector, the all-zero entropy mnemonic with the passphrase TREZOR:

const VECTOR = {
  mnemonic: 'abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about',
  passphrase: 'TREZOR',
  seed: 'c55257c360c07c72029aebc1b53c05ed0362ada38ead3e3e9efa3708e53495531f09a6987599d18264c1e1c92f2cf141630c7a3c4ab7c81b2f001698e7463b04',
};
const ok = seedFrom(VECTOR.mnemonic, VECTOR.passphrase).toString('hex') === VECTOR.seed;
console.log(`BIP39 test vector: ${ok ? 'match' : 'MISMATCH'}`);
if (!ok) process.exit(1);

BIP39 test vector: match

Timing one guess

Any attack on a weak seed has to run this derivation once per candidate. The script warms up, then takes the median of three runs of 300 derivations on a single thread:

const rate = (n) => {
  const start = process.hrtime.bigint();
  for (let i = 0; i < n; i++) seedFrom(VECTOR.mnemonic, String(i));
  return n / (Number(process.hrtime.bigint() - start) / 1e9);
};
rate(100);
const perSecond = [rate(300), rate(300), rate(300)].sort((a, b) => a - b)[1];

PBKDF2 seeds per second, one core of Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz: 375

About 2.7 ms per guess. Your machine will give a different number, and a GPU will give a much bigger one. A real attack also has to derive keys from each seed and check the resulting addresses against the chain, which adds work per guess. So read the next table for its orders of magnitude, not its exact values.

What 40, 72 and 128 bits mean at that rate

Full search at the measured rate (one core, then 10,000 cores like it):
    40.0 bits  Coldcard Mk2/Mk3 seed, Coinkite estimate                       92.9 years         3.39 days
    72.0 bits  Coldcard Mk4/Mk5/Q seed, Coinkite estimate                 3.99e+11 years     3.99e+7 years
   128.0 bits  12-word BIP39 seed, as designed                            2.88e+28 years    2.88e+24 years
    65.8 bits  40-bit seed + two random words from a 7,776-word list       5.62e+9 years     5.62e+5 years
   117.5 bits  40-bit seed + six random words from a 7,776-word list      2.05e+25 years    2.05e+21 years
   129.2 bits  50 private die rolls on their own                          6.83e+28 years    6.83e+24 years

The 40-bit row is the one that matters. About a trillion candidates is a long job for one laptop core and a short one for a rented cluster, and the July thefts show someone ran it. On average an attacker finds a given seed halfway through the space, and an attacker scanning for any weak wallet with funds collects every hit along the way.

The 72-bit row looks safe in this table, and Coinkite still tells owners of affected Mk4, Mk5 and Q seeds to migrate. Casa's write-up mentions an independent analysis that puts the worst case for a targeted attacker much lower. An entropy estimate for a broken generator depends on what the attacker knows about the device's state, and "about 72 bits" is a best case.

What a passphrase adds

Because the passphrase is in the salt, a passphrase with p bits of entropy multiplies the search by 2^p. The script's rows for a 40-bit seed show the effect. Two words drawn at random from the EFF large wordlist (7,776 words, about 12.9 bits each) take the search to about 66 bits. Six random words take it to about 118.

The key word is random. Coinkite's security page says a passphrase "does not repair a seed generated on affected firmware", while it "can add a barrier", and Casa mentions a reported loss from a Mk3 with a two-word passphrase. Two words a person picks have far less entropy than two words from dice, because attackers try common words and phrases first. The table's numbers assume words drawn uniformly at random.

The passphrase length limit decides how much of that randomness fits:

const PRINTABLE = 94; // ASCII 33-126
const AVG_WORD = 6.99 + 1; // EFF large wordlist: 6.99 letters on average, plus a space
for (const limit of [50, 128]) {
  const words = Math.floor((limit + 1) / AVG_WORD);
  console.log(`${limit}-character limit: ${(limit * Math.log2(PRINTABLE)).toFixed(0)} bits of random printable characters, or about ${words} random words (${(words * Math.log2(7776)).toFixed(0)} bits)`);
}

50-character limit: 328 bits of random printable characters, or about 6 random words (78 bits)
128-character limit: 839 bits of random printable characters, or about 16 random words (207 bits)

Fifty characters were always enough for random characters. They were tight for word-based passphrases, which are the kind people can actually remember and type on a small screen. That is the case Trezor's new 128-character limit helps.

Dice rolls

Coinkite's exception for affected seeds is a seed created with at least 50 fair, private dice rolls that were never recorded. A six-sided die gives log2(6), about 2.585 bits per roll, so 50 rolls give about 129.2 bits, the last row of the table, and 99 rolls give about 256. User-supplied entropy works because it doesn't depend on the device's generator being right. Coinkite's newer firmware now requires it for every new seed: at least 65 key presses, 50 die rolls or 128 coin flips, mixed with the device's own sources.

Limits of this estimate

One CPU core is a floor for attacker speed, not a forecast. GPUs and many machines change the per-second numbers by orders of magnitude, in the attacker's favor.
Key derivation and address lookups add per-guess cost that this script leaves out.
The bit counts for the Coldcard seeds are Coinkite's estimates, not measurements.
A passphrase's entropy is a property of how it was chosen. No script can measure that from the passphrase itself.

The full script

// How expensive is one guess at a BIP39 wallet, and how many guesses do weak and strong setups allow?
// Node 18+, no dependencies: node seed-math.mjs
import { pbkdf2Sync } from 'node:crypto';
import { cpus } from 'node:os';

// BIP39: the seed is PBKDF2-HMAC-SHA512 over the mnemonic, salted with "mnemonic" + passphrase, 2048 rounds.
const seedFrom = (mnemonic, passphrase = '') =>
  pbkdf2Sync(mnemonic.normalize('NFKD'), ('mnemonic' + passphrase).normalize('NFKD'), 2048, 64, 'sha512');

// 1. Check the function against the first official BIP39 test vector before trusting any timing.
const VECTOR = {
  mnemonic: 'abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about',
  passphrase: 'TREZOR',
  seed: 'c55257c360c07c72029aebc1b53c05ed0362ada38ead3e3e9efa3708e53495531f09a6987599d18264c1e1c92f2cf141630c7a3c4ab7c81b2f001698e7463b04',
};
const ok = seedFrom(VECTOR.mnemonic, VECTOR.passphrase).toString('hex') === VECTOR.seed;
console.log(`BIP39 test vector: ${ok ? 'match' : 'MISMATCH'}`);
if (!ok) process.exit(1);

// 2. Time one guess on this machine, single thread: warm up, then take the median of three runs.
//    A real attack also derives keys and checks addresses, which adds work per guess, and usually runs
//    on GPUs, which does far more guesses per second. Read the results as orders of magnitude.
const rate = (n) => {
  const start = process.hrtime.bigint();
  for (let i = 0; i < n; i++) seedFrom(VECTOR.mnemonic, String(i));
  return n / (Number(process.hrtime.bigint() - start) / 1e9);
};
rate(100);
const perSecond = [rate(300), rate(300), rate(300)].sort((a, b) => a - b)[1];
console.log(`PBKDF2 seeds per second, one core of ${cpus()[0].model.trim()}: ${perSecond.toFixed(0)}`);

// 3. Search spaces in bits, and how long a full search takes.
const human = (s) => {
  const units = [['years', 31557600], ['days', 86400], ['hours', 3600], ['minutes', 60], ['seconds', 1]];
  for (const [name, size] of units) if (s >= size) return `${(s / size).toPrecision(3)} ${name}`;
  return `${s.toPrecision(3)} seconds`;
};
const bits = (n) => Math.log2(n);
const SPACES = [
  ['Coldcard Mk2/Mk3 seed, Coinkite estimate', 40],
  ['Coldcard Mk4/Mk5/Q seed, Coinkite estimate', 72],
  ['12-word BIP39 seed, as designed', 128],
  ['40-bit seed + two random words from a 7,776-word list', 40 + 2 * bits(7776)],
  ['40-bit seed + six random words from a 7,776-word list', 40 + 6 * bits(7776)],
  ['50 private die rolls on their own', 50 * bits(6)],
];
const CORES = 10000;
console.log(`\nFull search at the measured rate (one core, then ${CORES.toLocaleString('en-US')} cores like it):`);
for (const [name, b] of SPACES) {
  const total = 2 ** b / perSecond;
  console.log(`  ${b.toFixed(1).padStart(6)} bits  ${name.padEnd(56)} ${human(total).padStart(16)}  ${human(total / CORES).padStart(16)}`);
}

// 4. What fits under a passphrase length limit: random characters versus words.
const PRINTABLE = 94; // ASCII 33-126
const AVG_WORD = 6.99 + 1; // EFF large wordlist (7,776 words): 6.99 letters on average, plus a space
for (const limit of [50, 128]) {
  const words = Math.floor((limit + 1) / AVG_WORD);
  console.log(`\n${limit}-character limit: ${(limit * bits(PRINTABLE)).toFixed(0)} bits of random printable characters, or about ${words} random words (${(words * bits(7776)).toFixed(0)} bits)`);
}

References

Reading the Binance EIP-7702 attack from raw chain data

NefiSwap — Sat, 31 Oct 2026 15:27:09 +0000

Decoding the 50 signed authorizations that turned a Binance hot wallet into a proxy for the attacker, with Node scripts you can run yourself.
On October 29, 2026, about $6.3 billion left Binance hot wallets across several chains. The Ethereum portion is unusually easy to study, because the attacker used EIP-7702 and the whole takeover sits in public state. This post walks through it with plain JSON-RPC calls. Everything below ran against mainnet, and you can reproduce it with Node 18+ and an archive-capable RPC endpoint.

The scripts can't tell you how the attacker got the signatures. Binance has not explained that, and it says it found no evidence of leaked private keys.

EIP-7702 in short

A type 0x04 transaction carries an authorization_list of tuples:

[chain_id, address, nonce, y_parity, r, s]

Each tuple is signed by the account being delegated, called the authority, over this message:

keccak(0x05 || rlp([chain_id, address, nonce]))

For each tuple, the client recovers the authority, checks that the tuple's nonce equals the authority's current nonce, sets the authority's code to 0xef0100 || address, and increments its nonce. If a check fails, that tuple is skipped and the next one runs. Anyone can submit the transaction. The signed message has no recipient, no amount and no expiry. The spec has the full list of steps.

A small RPC helper

All the scripts share this file. Historical state needs an archive-capable endpoint, so set RPC_URL if the default stops working for you.

// rpc.mjs
const RPC = process.env.RPC_URL ?? 'https://eth.drpc.org';

export const rpc = async (method, params = []) => {
  const res = await fetch(RPC, {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params }),
  });
  const { result, error } = await res.json();
  if (error) throw new Error(error.message);
  return result;
};

export const toHex = (n) => '0x' + Number(n).toString(16);

Watching the code change

A delegated account's code is exactly 23 bytes: the 0xef0100 prefix plus the delegate's address. That makes the check trivial.

// check-delegation.mjs
import { rpc, toHex } from './rpc.mjs';

const [address, block] = process.argv.slice(2);
const code = await rpc('eth_getCode', [address, block ? toHex(block) : 'latest']);

if (code === '0x') console.log('no code: plain EOA');
else if (code.startsWith('0xef0100')) console.log('delegated to 0x' + code.slice(8));
else console.log(`contract, ${(code.length - 2) / 2} bytes`);

Run it on Binance 14 around the attack:

$ node check-delegation.mjs 0x28C6c06298d514Db089934071355E5743bf21d60 26300752
no code: plain EOA

$ node check-delegation.mjs 0x28C6c06298d514Db089934071355E5743bf21d60 26300753
delegated to 0x63e842b054bd624a465454d533c33f573e9c6fae

$ node check-delegation.mjs 0x28C6c06298d514Db089934071355E5743bf21d60 26301895
delegated to 0x63e842b054bd624a465454d533c33f573e9c6fae

$ node check-delegation.mjs 0x28C6c06298d514Db089934071355E5743bf21d60 26301896
no code: plain EOA

The delegation lived for 1,143 blocks, from 20:20:59 UTC to 00:10:35 UTC, about 3 hours and 49 minutes.

Why there are 50 authorizations

The transaction has no value and no calldata. It exists only to carry the authorization list.

The tuple nonce has to match the authority's nonce at execution time, and a hot wallet's nonce moves constantly. So the attacker signed a range and let the protocol throw away the misses. This script finds the one that hit:

// match-nonce.mjs
import { rpc, toHex } from './rpc.mjs';

const TX = '0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b';
const WALLET = '0x28c6c06298d514db089934071355e5743bf21d60';

const tx = await rpc('eth_getTransactionByHash', [TX]);
const nonces = tx.authorizationList.map((a) => parseInt(a.nonce, 16));
const height = parseInt(tx.blockNumber, 16);
const index = parseInt(tx.transactionIndex, 16);

// wallet nonce at the end of the previous block
const start = parseInt(await rpc('eth_getTransactionCount', [WALLET, toHex(height - 1)]), 16);

// plus anything the wallet sent earlier in this block
const block = await rpc('eth_getBlockByNumber', [tx.blockNumber, true]);
const earlier = block.transactions.filter(
  (t) => t.from === WALLET && parseInt(t.transactionIndex, 16) < index,
);
const live = start + earlier.length;

console.log(`authorizations: ${nonces.length}, nonces ${Math.min(...nonces)} to ${Math.max(...nonces)}`);
console.log(`wallet nonce after block ${height - 1}: ${start}`);
console.log(`wallet txs earlier in block ${height}: ${earlier.length} (index ${earlier.map((t) => parseInt(t.transactionIndex, 16))})`);
console.log(`wallet nonce at index ${index}: ${live}`);
console.log(`matching authorizations: ${nonces.filter((n) => n === live).length}`);

authorizations: 50, nonces 18914775 to 18914824
wallet nonce after block 26300752: 18914808
wallet txs earlier in block 26300753: 1 (index 133)
wallet nonce at index 138: 18914809
matching authorizations: 1

The wallet's own withdrawal at index 133 moved the nonce to 18914809, and the attacker's transaction at index 138 landed on it. The sender was a different account, so the wallet's nonce wasn't bumped first, which is why the tuple's nonce equals the live value. A self-sponsored delegation would need nonce + 1.

Who signed them

Recovering the signer needs a little RLP and a secp256k1 library:

npm install @noble/curves @noble/hashes

// recover-signers.mjs
import { secp256k1 } from '@noble/curves/secp256k1.js';
import { keccak_256 } from '@noble/hashes/sha3.js';
import { rpc } from './rpc.mjs';

const TX = '0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b';

const bytes = (hex) => {
  const h = hex.slice(2);
  return Uint8Array.from((h.length % 2 ? '0' + h : h).match(/../g) ?? [], (b) => parseInt(b, 16));
};
const toHexStr = (b) => [...b].map((x) => x.toString(16).padStart(2, '0')).join('');
const trim = (b) => b.slice(b.findIndex((x) => x !== 0));

// minimal RLP for short strings and one short list, enough for this tuple
const rlpString = (b) => (b.length === 1 && b[0] < 0x80 ? b : Uint8Array.from([0x80 + b.length, ...b]));
const rlpList = (items) => {
  const body = items.flatMap((i) => [...rlpString(i)]);
  return Uint8Array.from([0xc0 + body.length, ...body]);
};

const { authorizationList } = await rpc('eth_getTransactionByHash', [TX]);
const signers = {};

for (const a of authorizationList) {
  const payload = rlpList([trim(bytes(a.chainId)), bytes(a.address), trim(bytes(a.nonce))]);
  const digest = keccak_256(Uint8Array.from([0x05, ...payload]));
  const sig = new secp256k1.Signature(BigInt(a.r), BigInt(a.s)).addRecoveryBit(Number(a.yParity));
  const pub = sig.recoverPublicKey(digest).toBytes(false);
  const signer = '0x' + toHexStr(keccak_256(pub.slice(1)).slice(-20));
  signers[signer] = (signers[signer] ?? 0) + 1;
}

console.log(signers);

{ '0x28c6c06298d514db089934071355e5743bf21d60': 50 }

All 50 recover to Binance 14. That shows something able to use that key signed them. It doesn't say whether that was a stolen key, a tricked signing service or something else.

What the delegation exposed

Once an EOA is delegated, a call to it runs the delegate's code. Nothing in the tuple limits that to the balance at signing time.

CoinDesk's reconstruction has the first sweep at 20:24:23 UTC, moving about 167,464 ETH and 63 tokens. Customer deposits kept landing in the wallet and were swept again at 21:04 and 21:44 UTC. TRM Labs reported that the delegated code was also used to direct a separate smart-contract wallet, Hot Wallet 34, which lost 823 million USDC.

The same night, about 18,270 BTC left in 11 validly signed bitcoin transactions. Bitcoin has no EIP-7702, so as far as the chain data shows, this feature behaved as specified and the failure sits upstream, wherever those signatures came from.

Detecting it

A plain EOA hot wallet should always return 0x from eth_getCode. That gives you a one-line invariant to monitor:

// watch-code.mjs
import { rpc, toHex } from './rpc.mjs';

// Replays a block range. In production, run the same check on every new head.
const WALLETS = ['0x28c6c06298d514db089934071355e5743bf21d60'];
const [from, to] = process.argv.slice(2).map(Number);

const seen = new Map();

for (let n = from; n <= to; n++) {
  for (const wallet of WALLETS) {
    const code = await rpc('eth_getCode', [wallet, toHex(n)]);
    if (seen.has(wallet) && seen.get(wallet) !== code) {
      const { timestamp } = await rpc('eth_getBlockByNumber', [toHex(n), false]);
      const when = new Date(parseInt(timestamp, 16) * 1000).toISOString();
      console.log(`ALERT block ${n} (${when}): ${wallet} code ${seen.get(wallet)} -> ${code}`);
    }
    seen.set(wallet, code);
  }
}

$ node watch-code.mjs 26300750 26300756
ALERT block 26300753 (2026-10-29T20:20:59.000Z): 0x28c6c06298d514db089934071355e5743bf21d60 code 0x -> 0xef010063e842b054bd624a465454d533c33f573e9c6fae

That alert fires 3 minutes and 24 seconds before the first sweep. It's a short window, but it's long enough for automation to pause a signer.

Prevention at the signer

If your hot wallets don't use delegation, the signing service should refuse EIP-7702 authorizations outright. The preimage always starts with the byte 0x05, so a service that sees structured payloads can block it. A service that signs opaque 32-byte digests can't tell the difference, which is a good reason to stop exposing raw digest signing to anything on the network.

If you do use delegation, pin an allowlist of delegate addresses and treat anything else as an incident.

Freezes are visible too

USDT and USDC both expose their blacklists as view functions, isBlackListed(address) and isBlacklisted(address).

// check-freeze.mjs
import { rpc } from './rpc.mjs';

const USDT = '0xdAC17F958D2ee523a2206206994597C13D831ec7';
const USDC = '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48';

const [address] = process.argv.slice(2);
const arg = address.slice(2).toLowerCase().padStart(64, '0');

const check = async (token, selector) => BigInt(await rpc('eth_call', [{ to: token, data: selector + arg }, 'latest'])) === 1n;

console.log('USDT isBlackListed:', await check(USDT, '0xe47d6060'));
console.log('USDC isBlacklisted:', await check(USDC, '0xfe575a87'));

$ node check-freeze.mjs 0x28C6c06298d514Db089934071355E5743bf21d60
USDT isBlackListed: true
USDC isBlacklisted: true

The AddedBlackList and Blacklisted event logs give the timeline. The first USDT freeze came in block 26,300,954 at 21:01:35 UTC, about 37 minutes after the first sweep. The first USDC freeze came in block 26,300,971 at 21:04:59 UTC. Both named 0x5227f603c1ee34ce3c06efe6477003bdfccb2f8c, which held 971,149,299 USDT and 823,000,000 USDC at those blocks. Tether blacklisted Binance 14 itself in block 26,301,278 at 22:06:23 UTC, and Circle followed in block 26,301,812 at 23:53:35 UTC.

What is still unknown

The chain shows what the 50 signatures did and doesn't show how they were produced. Binance first pointed to a compromised engineer's laptop and later reported more breach points, with cloud systems, key management and transaction signing all under review. Its full report should fill in that part.

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

NefiSwap — 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

NefiSwap — 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

NefiSwap — 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

NefiSwap — 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

NefiSwap — 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

NefiSwap — 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.

DEV Community: NefiSwap

Counting USDT freezes on Tron with 70 lines of Node.js

Where the freeze lives

The script

What it printed

Where this is useful

Splitting a wallet key 2-of-3 in Node.js, and what Keplr's social login incident shows about it

The idea in one line

The code

Output

What the split protects, and what it doesn't

If you're building on embedded wallets

Measuring Zcash's NU7 hard fork from raw block headers

What ZIP 2003 actually changes

Where the timestamp lives

The script

What it printed

Caveats

Further reading

Read the take-home test before you run it

Where a repo can run code on your machine

The script

Running it on a sample

What it doesn't catch

Sources

How many guesses is a seed phrase? BIP39 entropy and PBKDF2 cost, measured in Node.js

What a BIP39 seed is made of

Check it against the test vector first

Timing one guess

What 40, 72 and 128 bits mean at that rate

What a passphrase adds

Dice rolls

Limits of this estimate

The full script

References

Reading the Binance EIP-7702 attack from raw chain data

EIP-7702 in short

A small RPC helper

Watching the code change

Why there are 50 authorizations

Who signed them

What the delegation exposed

Detecting it

Prevention at the signer

Freezes are visible too

What is still unknown

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

Availability is per action, per jurisdiction, over time

Resolve the active rule at request time

Things that bite in practice

Why this matters beyond the EU

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

The bug pattern

Model the rail, not the chain

Capabilities belong on the rail

Gate new rails explicitly

Show the network everywhere

Plan for more fragmentation, not less

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

1. Screen before execution, not after

2. Pause per network, not globally

3. Limit hot-wallet outflow velocity

4. Separate the deposit path from the contract logic

5. Publish status like an API

6. Plan for the "refund scam" phase

Designing a Telegram Swap Bot That's Hard to Impersonate

1. Minimize what the user hands over

2. Make the website the root of trust

3. Let users verify the deposit address outside Telegram

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

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

6. Reduce the value of a stale screenshot

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

A wind-down is a state machine

1. Stop deposit automation first

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

3. Sweep by policy, not by panic

4. Never make the API your only exit

5. Watch announcements, not just uptime

6. Handle the long-tail exit

1. Never trust `initData` on the client