DEV Community: Swapcore.Exchange

Checking whether a 2010 bitcoin output has moved, in about 30 lines of JavaScript

Swapcore.Exchange — Sat, 14 Nov 2026 01:28:31 +0000

17.8 years

That's how long the 50 BTC reward from Bitcoin's block 1 has been sitting unspent, according to the script below.

It's a timely question. On November 13, 2026, two mining rewards from September 2010, 50 BTC each, moved for the first time in more than 16 years (Decrypt and The Block covered it; Whale Alert flagged the first move at 04:08 UTC). Each spend paid 1,110 satoshis in fees, and a later transaction combined coins from both wallets.

If you try to check a wallet like that with an address search, you can get a confusing answer. Many 2009 and 2010 coinbase outputs paid a raw public key (P2PK), not an address. Explorers can derive an address from the key, but the cleanest question to ask is about the output itself: was txid:vout spent, and when?

The script

It uses the public Esplora API (Blockstream's by default, mempool.space works too) and Node 18+'s built-in fetch. No key, no dependencies.

// outspend.mjs: was one output spent, and how long did it sit first?
// usage: node outspend.mjs <txid> <vout>
const API = process.env.ESPLORA || 'https://blockstream.info/api';
const [txid, vout = '0'] = process.argv.slice(2);
const get = async (p) => {
  const r = await fetch(API + p);
  if (!r.ok) throw new Error(`${p}: HTTP ${r.status}`);
  return r.json();
};
const day = (t) => new Date(t * 1000).toISOString().replace('T', ' ').slice(0, 16) + ' UTC';

const tx = await get(`/tx/${txid}`);
const out = tx.vout[Number(vout)];
console.log(`${out.value / 1e8} BTC · ${out.scriptpubkey_type} · created ${day(tx.status.block_time)} (block ${tx.status.block_height})`);

const sp = await get(`/tx/${txid}/outspend/${vout}`);
if (!sp.spent) {
  const yrs = (Date.now() / 1000 - tx.status.block_time) / (365.25 * 86400);
  console.log(`unspent, still there after ${yrs.toFixed(1)} years`);
} else {
  const s = await get(`/tx/${sp.txid}`);
  const yrs = (s.status.block_time - tx.status.block_time) / (365.25 * 86400);
  console.log(`spent ${day(s.status.block_time)} after ${yrs.toFixed(1)} years, fee ${s.fee} sat`);
  for (const o of s.vout) console.log(`  -> ${(o.value / 1e8).toFixed(8)} BTC ${o.scriptpubkey_type}`);
}

Two runs

Block 1's coinbase:

$ node outspend.mjs 0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098 0
50 BTC · p2pk · created 2009-01-09 02:54 UTC (block 1)
unspent, still there after 17.8 years

And output 0 of the transaction in block 170, the 10 BTC Satoshi Nakamoto sent Hal Finney in the first person-to-person bitcoin transaction:

$ node outspend.mjs f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 0
10 BTC · p2pk · created 2009-01-12 03:30 UTC (block 170)
spent 2010-11-16 20:39 UTC after 1.8 years, fee 0 sat
  -> 10.00000000 BTC p2pkh

Note the output types. Both started as p2pk: a payment to a public key, with no address in the script. When the block 170 coins moved, they went to a p2pkh output, the address format most wallets show.

What to do with it

Watch a list of old outputs: loop over txid:vout pairs and alert when spent flips to true. That is roughly what whale-tracking bots do.
Read the spend, not just the flag. Friday's two spends split 50 BTC into about 49.99 + 0.01 and 49 + 1. The split, the fee and any later consolidation are the only facts the chain gives you. Ownership and intent are not on it.
Don't hammer a public API. Add a delay between requests, or run your own Esplora or Electrum server.

Sources

Decrypt, "Dormant Bitcoin Wallets Wake Up After 16 Years, Moving $6.9 Million" (Nov 13, 2026)
The Block, "From $6 to $6.9 million: Two dormant Bitcoin addresses wake up to move 100 BTC after more than 16 years" (Nov 13, 2026)
Esplora HTTP API docs: https://github.com/Blockstream/esplora/blob/master/API.md

worse_query and wallet apps on iOS: what the sandbox escape reads, and what to check in your own app

Swapcore.Exchange — Wed, 11 Nov 2026 01:12:15 +0000

The report

On November 10, 2026, Binance posted a warning about worse_query, an iOS flaw that lets a malicious app read local files belonging to other apps. Binance lists iOS 26.7.1, 27.0.1 and 27.2 as affected and calls it "an iOS-level issue, not unique to Binance."

The technique is public. A researcher who goes by forcequitOS published a proof of concept on GitHub; Decrypt reports the repository describes it as a sandbox escape for iOS 26.0 through 26.7.2 and iOS 27.2, and as the successor to an earlier exploit, bad_query. BleepingComputer covers a tool built on it, WQ Files, that can browse, export, edit and delete other apps' data without a jailbreak. The attacker's app has to be installed on the device, so sideloaded apps are the realistic delivery route.

Apple shipped iOS 27.2.1 and 26.7.3 on November 9 with nine security fixes, including one for an App Intents issue that could expose sensitive user data. Apple's notes don't name worse_query, and none of the coverage confirms the two are the same bug. No crypto theft has been confirmed.

What the coverage says is exposed

The reports describe reading files in other apps' storage. None of them says anything about Keychain items, so I'm not going to claim the Keychain is safe or unsafe here. What is clear is that anything your app writes to a file is in scope.

A checklist for your own app

If your app holds a mnemonic, a private key, an API secret or a long-lived session token:

Search the container for secrets on disk. Look at Documents/, Library/Application Support/, Library/Caches/, tmp/, any App Group container, UserDefaults plists, Core Data or SQLite stores, and crash or debug logs. A seed phrase in a JSON backup file or a logged request body counts.
Keep secrets in the Keychain with the narrowest accessibility class the feature allows, and avoid classes that sync or survive a device migration unless you need that.
If you must keep something in a file, encrypt it with a key that lives in the Keychain (or the Secure Enclave), so a copied file is useless on its own.
Treat App Group containers as shared space. Anything you put there for an extension or widget should be data you'd accept being read.
Make server sessions revocable, and give users a "sign out everywhere" action. That is the recovery step Binance tells people to take.
For wallets: make "create a new wallet and move funds" a short, well-tested path. If a user's seed may have leaked, a new seed and an on-chain transfer is the only real fix, and that transfer is irreversible, so show the destination address and network clearly before signing.

Telling your users

Binance's user advice is a good template: update iOS and all apps, delete apps from untrusted sources (sideloaded or manually signed), and if compromise is suspected, move funds to a new wallet created on a clean device and reset all sessions.

Sources: Binance on X, BleepingComputer and Decrypt (November 10, 2026); 24/7 Wall St. (November 10, 2026).

Flagging "pool hops" like the ones in the Binance-hack laundering, in 60 lines of JavaScript

Swapcore.Exchange — Tue, 10 Nov 2026 01:38:14 +0000

The pattern

On November 9, Elliptic described how the launderers behind the Binance hack moved stolen NEAR through home-made meme coins. Between November 5 and 7 they created at least six tokens on NEAR, each costing about 25 NEAR to make, and paired each with NEAR in its own liquidity pool. One set of wallets bought the token with stolen NEAR. Another set sold it back to the pool. About 117,000 NEAR (roughly $430,000) went through before the tokens were abandoned; none has traded since November 8.

No wallet pays another wallet directly, so a naive "who sent money to whom" graph has a gap where the pool is. The trail is still all on-chain. You just have to look at the trades instead of the transfers.

From Elliptic's description, a pool hop has five signs:

The token is brand new when the swaps start.
Almost nobody else trades it.
The wallets that buy are never the wallets that sell.
What comes out is close to what went in.
The buyers were funded from a wallet you already flag.

None of these alone means much. New tokens with few traders appear by the thousand every day. All five together is a different story.

The script

It takes a JSON file of swaps and token creation times, groups swaps by token and scores each one from 0 to 5.

// pool-hop.mjs
import { readFileSync } from 'node:fs';

const file = process.argv[2] ?? new URL('./sample-swaps.json', import.meta.url);
const { tokens, swaps, flagged } = JSON.parse(readFileSync(file, 'utf8'));

const HOURS = 3600e3;
const MAX_TOKEN_AGE_H = 48;
const MAX_TRADERS = 6;
const MATCH_TOLERANCE = 0.05;

const byToken = new Map();
for (const s of swaps) {
  if (!byToken.has(s.token)) byToken.set(s.token, []);
  byToken.get(s.token).push(s);
}

const report = [];
for (const [token, list] of byToken) {
  const meta = tokens.find(t => t.token === token);
  if (!meta) continue;
  const first = Math.min(...list.map(s => Date.parse(s.ts)));
  const ageH = (first - Date.parse(meta.createdAt)) / HOURS;
  const buyers = new Set(list.filter(s => s.side === 'buy').map(s => s.wallet));
  const sellers = new Set(list.filter(s => s.side === 'sell').map(s => s.wallet));
  const traders = new Set([...buyers, ...sellers]);
  const overlap = [...buyers].filter(w => sellers.has(w)).length;
  const inAmt = list.filter(s => s.side === 'buy').reduce((a, s) => a + s.amount, 0);
  const outAmt = list.filter(s => s.side === 'sell').reduce((a, s) => a + s.amount, 0);
  const taintedBuyers = [...buyers].filter(w => list.some(s => s.wallet === w && flagged.includes(s.funder)));

  const reasons = [];
  if (ageH <= MAX_TOKEN_AGE_H) reasons.push(`token ${ageH.toFixed(1)} h old at first swap`);
  if (traders.size <= MAX_TRADERS) reasons.push(`${traders.size} wallets ever traded it`);
  if (overlap === 0 && buyers.size && sellers.size) reasons.push('buyers and sellers never overlap');
  if (inAmt && Math.abs(outAmt - inAmt) / inAmt <= MATCH_TOLERANCE) reasons.push(`out ${outAmt} vs in ${inAmt} (within 5%)`);
  if (taintedBuyers.length) reasons.push(`${taintedBuyers.length} buyer(s) funded by a flagged wallet`);

  report.push({ token, score: reasons.length, reasons, sellers: [...sellers] });
}

report.sort((a, b) => b.score - a.score);
for (const r of report) {
  console.log(`${r.token.padEnd(8)} score ${r.score}/5`);
  for (const why of r.reasons) console.log(`   - ${why}`);
  if (r.score >= 4) console.log(`   => treat sells to ${r.sellers.join(', ')} as coming from the flagged source`);
}

Running it

The sample file is made up, shaped like the pattern in the report: one throwaway token (DUCK) bought by two wallets funded from a flagged address and sold by two fresh ones, and one older token (REALDOG) traded by seven ordinary wallets. Wallet names are placeholders.

node pool-hop.mjs sample-swaps.json

DUCK     score 5/5
   - token 0.3 h old at first swap
   - 4 wallets ever traded it
   - buyers and sellers never overlap
   - out 19700 vs in 20000 (within 5%)
   - 2 buyer(s) funded by a flagged wallet
   => treat sells to collector-1, collector-2 as coming from the flagged source
REALDOG  score 0/5

What it won't catch

The thresholds are guesses you should tune on real data. A launderer who adds a few decoy traders, lets the token age for a week or splits the exit across many tokens will slip under a fixed cutoff. Elliptic's own description of the operation is many cheap layers stacked together, so treat a score like this as a first filter that tells you which wallets to look at by hand.

The point that holds up is Elliptic's advice to compliance teams: funds that arrive from a liquidity pool shouldn't be assumed clean, especially when a fresh token and a few wallets are involved. Follow the funding of the buyers and the gap closes.

To use this on a real chain, you'd build the swaps list from the pool contract's swap events and the funder field from each buying wallet's incoming transfers. On NEAR that means reading receipts from an indexer; on EVM chains, Swap logs plus the transfers before them.

Sources: Elliptic, "North Korea is minting meme coins to launder the Binance hack" (Nov 9, 2026); Decrypt and Cointelegraph coverage (Nov 9, 2026).

Samsung Wallet sends USDC on Solana. Here's a 40-line script that tells which chain an address is for

Swapcore.Exchange — Fri, 06 Nov 2026 14:06:44 +0000

The news, briefly

On November 5, 2026, Samsung Wallet launched stablecoin accounts for eligible U.S. Galaxy users. The account holds USDC on Solana. Users can send it to other Samsung Wallet users or to "compatible external crypto wallets", and Bastion and Coinbase handle custody (The Block, Decrypt).

"Compatible" is doing a lot of work there. USDC is issued on many chains, and each issuance is a separate token. Send Solana USDC to an Ethereum address and, at best, the wallet blocks you. Sending on the wrong chain from a multi-network exchange is a common way to lose funds.

So I wrote a small script that answers one question: what chain family is this address from, judging by its format alone?

The script

No dependencies, Node 18+. It decodes base58 by hand and uses node:crypto for the TRON checksum.

// which-network.mjs
import { createHash } from 'node:crypto';

const ALPHABET = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz';

function base58Decode(str) {
  let n = 0n;
  for (const ch of str) {
    const i = ALPHABET.indexOf(ch);
    if (i < 0) return null;
    n = n * 58n + BigInt(i);
  }
  const bytes = [];
  while (n > 0n) { bytes.unshift(Number(n % 256n)); n /= 256n; }
  for (const ch of str) { if (ch !== '1') break; bytes.unshift(0); }
  return Uint8Array.from(bytes);
}

const sha256 = (b) => createHash('sha256').update(b).digest();

function classify(addr) {
  if (/^0x[0-9a-fA-F]{40}$/.test(addr)) {
    return 'EVM (20 bytes). Same format on Ethereum, Arbitrum, Base, BNB Chain, Avalanche C-Chain... the address alone cannot tell you which one.';
  }
  if (/^0x[0-9a-fA-F]{64}$/.test(addr)) {
    return '32-byte hex. Matches Sui or Aptos style, not EVM. An EVM wallet cannot receive here.';
  }
  const raw = base58Decode(addr);
  if (raw && raw.length === 25 && raw[0] === 0x41) {
    const ok = sha256(sha256(raw.subarray(0, 21))).subarray(0, 4).equals(Buffer.from(raw.subarray(21)));
    return ok ? 'TRON (base58check, 0x41 prefix, checksum OK).' : 'Looks like TRON but the checksum FAILS. Typo?';
  }
  if (raw && raw.length === 32 && addr.length >= 32 && addr.length <= 44) {
    return 'Solana (base58, 32 bytes). No checksum in this format, so a typo can still decode to a valid-looking key.';
  }
  return 'Unknown format. Do not send until you know the network.';
}

for (const a of process.argv.slice(2)) console.log(`${a}\n  -> ${classify(a)}\n`);

Running it

node which-network.mjs \
  EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v \
  0xA6ca3bF1a63bCab37725bF4B1FA3F74fBbc9596a \
  TCz734oe5wBtXLWYrJAcC5RrRECarmEEsJ \
  TCz734oe5wBtXLWYrJAcC5RrRECarmEEsK

Output:

EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
  -> Solana (base58, 32 bytes). No checksum in this format, so a typo can still decode to a valid-looking key.

0xA6ca3bF1a63bCab37725bF4B1FA3F74fBbc9596a
  -> EVM (20 bytes). Same format on Ethereum, Arbitrum, Base, BNB Chain, Avalanche C-Chain... the address alone cannot tell you which one.

TCz734oe5wBtXLWYrJAcC5RrRECarmEEsJ
  -> TRON (base58check, 0x41 prefix, checksum OK).

TCz734oe5wBtXLWYrJAcC5RrRECarmEEsK
  -> Looks like TRON but the checksum FAILS. Typo?

The first input is the USDC mint on Solana. The last one is the TRON address from line three with its final character changed, and the checksum catches it.

What the output teaches

TRON catches typos, Solana doesn't. A TRON address is base58check: 21 bytes of payload plus 4 bytes of double-SHA256. Change one character and the checksum almost certainly fails. A Solana address is a raw 32-byte public key in base58, so a mistyped address usually still decodes to 32 bytes and passes every format check. If your UI accepts pasted Solana addresses, the format check is nowhere near enough. Show the address back to the user in chunks, or require a small test send.

EVM addresses are ambiguous by design. 0x plus 40 hex chars is valid on every EVM chain. The address is the same on all of them, but the USDC contract and the balance are different. Format checks can't tell you whether the user meant Ethereum or Arbitrum, so the network has to be an explicit choice in your UI and never inferred. (EIP-55 mixed-case checksums help with typos, not with the chain question.)

32-byte hex is not EVM. Sui and Aptos use 32-byte hex addresses with the same 0x prefix. A regex that only checks ^0x[0-9a-f]+$ will happily accept them for an EVM transfer.

Where this fits

Samsung hides most of this behind a custodial account, which is a reasonable product choice. But the moment users send funds out, someone's code has to answer "is this address for the right chain?" A format check like this one is cheap first-line validation. It doesn't replace an explicit network selector, and it doesn't replace a test transaction.

The full script and its output are about 40 lines. Feel free to lift it.

Sources: The Block, "Samsung Wallet launches USDC accounts on Solana for US Galaxy users" (Nov 5, 2026); Decrypt, "Stablecoins Go Mainstream as Samsung Wallet Adds USDC on Solana" (Nov 5, 2026).

"USDT" Is at Least Three Different Tokens. Your Token Registry Should Know That.

Swapcore.Exchange — Thu, 22 Oct 2026 20:47:40 +0000

If your product handles USDT across networks, there's a good chance your token model treats it as one asset with several "networks." That model is wrong in ways that matter for accounting, risk and support.

In practice, what wallets display as "USDT" includes at least three structurally different things:

Kind	Example chains	Issued by	How it moves cross-chain
Native USDT	Ethereum, Tron, Solana, TON, Avalanche	Tether	It doesn't. Each chain has its own supply
Exchange-pegged USDT	BNB Chain (Binance-Peg BSC-USD)	Binance, backed by USDT	Via the issuer
Omnichain USDT0	Arbitrum, Optimism, Polygon, newer EVM chains	Everdawn Labs, backed by USDT locked on Ethereum	LayerZero burn-and-mint

They're all worth about a dollar. They don't share an issuer, a redemption path or a risk profile.

1. Model issuer and kind, not just chain

A registry keyed only by (chain, contract) is necessary but not sufficient. Add the fields that describe what the token actually is:

{
  "symbol": "USDT",
  "chain": "arbitrum",
  "contract": "0x…",
  "decimals": 6,
  "kind": "omnichain",
  "issuer": "everdawn-labs",
  "backing": "native-usdt-locked-ethereum",
  "redeemable_with_tether": false
}

Why it matters:

Accounting. Treating Binance-Peg USDT and USDT0 as interchangeable with native USDT in your books means your stablecoin exposure has counterparties you aren't tracking.
Risk limits. A depeg, an exploit in a bridge's lockbox or an issuer problem hits one kind without touching the others. Exposure limits should be per kind.
Support. "I sent USDT and received USDT0" is a real ticket. If your system can't tell them apart, neither can your agents.

2. Never resolve tokens by symbol

On most EVM chains, anyone can deploy a contract named "USDT." Explorers on BNB Chain list many of them. Combined with the legitimate variety above, symbol-based resolution is guaranteed to misfire eventually.

Keep an explicit allowlist of (chain, contract) pairs and reject everything else, including in admin tools and indexers.

3. Tron needs its own transfer logic

TRC20 isn't an EVM chain with a different address prefix. Its fee model is different:

Bandwidth covers transaction size. Each account gets a small free daily allowance.
Energy covers smart contract execution. A TRC20 transfer is a contract call, so it needs energy.

If the sending account hasn't staked TRX for energy, the network burns TRX to pay for it. If there isn't enough TRX, the transaction fails, and the TRX it consumed is still gone.

Practical consequences for payouts:

// Before a TRC20 payout, check the sender can actually pay for it.
const resources = await tronWeb.trx.getAccountResources(hotWallet);
const energyAvailable = (resources.EnergyLimit || 0) - (resources.EnergyUsed || 0);

if (energyAvailable < estimatedEnergy) {
  const trxNeeded = estimateTrxBurn(estimatedEnergy - energyAvailable);
  assertBalanceAtLeast(hotWallet, trxNeeded);
}

Also budget for first-transfer cost. Sending USDT to a Tron address that has never held it costs roughly double, because the transfer has to create the token balance. If you sweep deposits to many fresh addresses, this shows up in your costs.

Set feeLimit on TRC20 transactions deliberately. Too low and they fail mid-execution; too high and a bug can burn more than you meant.

4. Cross-network conversion is a trade, not a transfer

If your product lets users "move USDT from Tron to Ethereum," it's executing a swap between two different tokens, whatever the UI says. That means:

Quote it like a swap. Show the amount received net of the destination network fee and any spread. It won't be exactly 1:1.
Track it like a swap. Two legs, two chains, two transaction IDs, and a failure state for each.
Label the output precisely. If the destination is USDT0, say USDT0. Don't let a user find out from their wallet.

5. Gas tokens on both sides

A user receiving USDT on a chain where they hold no native token can't move it. On Ethereum, that's ETH; on Tron, TRX; on BNB Chain, BNB.

If your product delivers USDT to a user's wallet on a network that's new for them, say so before they confirm. Better still, point them to how to get the gas token.

Checklist

Registry fields for kind, issuer, backing and redeemability
Allowlist by (chain, contract); never resolve by symbol
Exposure limits per token kind, not per symbol
Tron payouts check energy and TRX before sending; feeLimit set deliberately
First-transfer costs to fresh Tron addresses budgeted
Cross-network moves modeled as two-leg swaps, labeled with the actual output token
Users warned when they'll receive on a chain without gas

Disclosure: I work on SwapCore (swapcore.exchange), a non-custodial instant exchange. Cross-network USDT conversions are one of the most common things people use us for, and most of the edge cases above come from them.

Your Ethereum Gas Assumptions Are Probably From 2021

Swapcore.Exchange — Wed, 14 Oct 2026 01:09:15 +0000

A lot of Ethereum deposit and payout code still carries assumptions from when gas was the dominant cost: hardcoded fee constants, minimums sized for twenty-dollar transfers, defaults that steer users away from mainnet. Through 2026, standard gas has mostly sat well under one gwei. An ERC-20 transfer costs cents.

That doesn't just make old code expensive. It makes some of it wrong. Here's what to revisit if you accept ETH or ERC-20 deposits.

1. Stop hardcoding gas prices and minimums

If a constant like this is still in your codebase, it's overcharging by two orders of magnitude:

# Written for a different fee era
PAYOUT_GAS_PRICE_GWEI = 40
MIN_DEPOSIT_USDT = 50

Since the London upgrade, fees are EIP-1559: a protocol-set base fee plus a priority tip. Estimate both from live data at the moment of payout:

def estimate_fees(w3, priority_percentile=50):
    hist = w3.eth.fee_history(10, "latest", [priority_percentile])
    base_fee = hist["baseFeePerGas"][-1]   # next block's base fee
    tips = [r[0] for r in hist["reward"]]
    tip = sorted(tips)[len(tips) // 2]
    # Allow the base fee to rise for a few blocks before the tx lands
    max_fee = base_fee * 2 + tip
    return {"maxFeePerGas": max_fee, "maxPriorityFeePerGas": tip}

Then derive minimums from the live estimate instead of a fixed value. A minimum sized for 40 gwei turns away users your economics could serve profitably today, and a minimum sized for 0.2 gwei will be wrong the next time the network gets busy. Recompute per quote.

2. Detect internal transactions, not just top-level transfers

The simplest deposit watcher checks each block for transactions whose to is a deposit address and whose value is non-zero. That misses ETH sent from smart contract wallets.

A Safe multisig, for example, executes a transfer through a contract call. On-chain, the ETH movement is an internal call, not a top-level transaction to your address. A naive watcher never sees it.

You have two reliable options:

Trace calls. Use debug_traceTransaction or trace_block (provider-dependent) and look for value transfers to your addresses at any call depth.
Watch balances. Poll eth_getBalance for deposit addresses at each block, and reconcile any increase against known transactions. Cruder, but it catches everything.

EIP-7702, introduced in the Pectra upgrade, lets ordinary accounts delegate to contract code. As adoption grows, the share of ETH deposits arriving through contract execution rather than plain transfers will grow with it. Plan for internal transfers to be normal.

ERC-20 deposits don't have this problem in the same way, because they emit a Transfer event regardless of who calls the token contract. Watch logs for those.

3. Use finality, not just confirmations

Ethereum produces a block every 12 seconds. Proof-of-stake adds a second signal: finality. A block becomes finalized after two epochs, roughly 13 minutes, at which point reverting it would require a large share of staked ETH to be destroyed.

Many services still use a confirmation count carried over from proof-of-work habits. You can do better with the block tags the JSON-RPC API exposes:

latest    = w3.eth.get_block("latest")
safe      = w3.eth.get_block("safe")       # justified, very unlikely to reorg
finalized = w3.eth.get_block("finalized")  # economically final

def is_credited(deposit_block, amount_usd):
    threshold = safe if amount_usd < 10_000 else finalized
    return deposit_block <= threshold["number"]

safe usually trails the head by a few minutes; finalized by around 13. Tiering by amount gives most users a fast credit and keeps large deposits on economic finality.

4. Treat L2 ETH as a different asset

ETH on mainnet, Arbitrum, Base and Optimism all use identical 0x addresses. A deposit address you generated for mainnet is, byte for byte, a valid address on every one of them.

Users will send L2 ETH to a mainnet deposit address. Your mainnet watcher won't see it. Two things help:

Model assets as (chain_id, asset) pairs everywhere, so "ETH on Base" is never conflated with "ETH on mainnet" in quotes, orders or UI.
Optionally watch your deposit addresses on the major L2s too. You won't credit those deposits automatically, but you can flag them for support instead of having a user report "lost" funds days later.

5. Warn about the empty-gas-tank problem

A user swapping their entire ETH balance into USDT on Ethereum ends up with tokens they can't move, because they have no ETH for gas.

If your interface offers a "max" button for ETH, consider a soft default that leaves a small reserve, with an explicit override:

const RESERVE_WEI = estimateReserve(liveFees, 5); // ~5 future transfers
const maxSendable = balance - gasForThisTx - RESERVE_WEI;

At current fee levels the reserve is tiny. The point is that it isn't zero.

6. Never ask for approvals on a deposit flow

A deposit-address model is a plain transfer. It needs no approve, no permit, no signed message.

If your product uses deposit addresses, make that explicit in your UI copy. Users have learned that legitimate swaps sometimes ask for approvals (router-based DEX swaps do). A clear statement that yours never will gives them a way to spot clones impersonating you.

Checklist

Fees estimated live with EIP-1559 fields; no hardcoded gwei
Minimums derived per quote from live fees
Deposit detection covers internal transactions
Crediting uses safe / finalized tags, tiered by amount
Assets keyed by chain ID; L2 deposits to mainnet addresses flagged
"Max" leaves a gas reserve by default
Deposit flow never requests approvals or signatures

Disclosure: I work on SwapCore (swapcore.exchange), a non-custodial instant exchange. Several of these came from revisiting our own assumptions after Ethereum fees fell.

Accepting Bitcoin Deposits Correctly: Confirmations, Replacement and Address Types

Swapcore.Exchange — Tue, 06 Oct 2026 20:02:41 +0000

If your product accepts BTC deposits, for a swap, a checkout or a top-up, the patterns that work on account-based chains will get you into trouble. Bitcoin's UTXO model, probabilistic finality and fee market each need specific handling.

Here's what to get right.

1. Never credit on zero confirmations

An unconfirmed Bitcoin transaction is a proposal, not a payment. Until it's in a block, the sender can replace it with a conflicting transaction that pays the same coins elsewhere.

Most nodes on the network now accept fee-bumping replacements, so treating unconfirmed transactions as safe is not a viable risk model.

Make the confirmation threshold a config value, and consider scaling it with amount:

def required_confirmations(amount_btc: float) -> int:
    # Illustrative policy. Tune to your own risk tolerance.
    if amount_btc < 0.01:
        return 1
    if amount_btc < 1:
        return 2
    return 3

Expose the threshold and the current count to the user. "2 of 3 confirmations" ends a support ticket before it starts.

2. Track deposits by outpoint, not by txid alone

A replaced transaction gets a new txid. If your deposit detection keys on the original txid, a fee bump turns into a "missing" deposit from your system's point of view.

Watch the address, not the transaction. When a new transaction pays the same deposit address, check whether it conflicts with one you've already seen (spends the same inputs). If it does, treat it as a replacement: update the record and keep the order alive.

def on_transaction_seen(tx, deposit_address):
    outputs = [o for o in tx.outputs if o.address == deposit_address]
    if not outputs:
        return
    existing = find_pending_by_inputs(tx.inputs)
    if existing:
        existing.replace_with(tx)  # RBF: same inputs, new txid
    else:
        create_pending_deposit(tx, outputs)

The same logic handles the reverse case: a deposit that disappears from the mempool because it was replaced by a transaction paying somewhere else. Mark it failed explicitly instead of leaving it pending forever.

3. Your quote window and Bitcoin block time don't agree

Average block time is ten minutes, but it follows an exponential distribution. Waits of thirty minutes or more between blocks happen regularly.

If you offer locked-rate quotes, a ten-minute window on a BTC deposit will expire often. Options:

Measure the window from first sighting in the mempool, not from confirmation. The user did their part when they broadcast. This is the fairest approach, but you carry price risk until confirmation.
Extend windows for BTC specifically, and price the extra risk into the spread.
Default BTC deposits to floating rates, and make locked rates opt-in with a clear warning.

Whichever you choose, model quote_expired as a normal state with a one-click re-quote.

4. Validate address types, all four of them

Bitcoin has four mainnet address formats:

Prefix	Type	Encoding
`1…`	P2PKH (legacy)	Base58Check
`3…`	P2SH (often nested SegWit)	Base58Check
`bc1q…`	P2WPKH / P2WSH (native SegWit v0)	Bech32
`bc1p…`	P2TR (Taproot, SegWit v1)	Bech32m

The common bug is a validator written before Taproot that accepts Bech32 but rejects Bech32m, so valid bc1p addresses get refused. The less common but worse bug is a validator that accepts Bech32m checksums for v0 addresses, or the reverse. BIP-350 defines which checksum applies to which witness version. Use a maintained library instead of a regex.

Also reject testnet prefixes (tb1, m, n, 2) in production, and the reverse in staging.

5. Handle amounts in satoshis, and expect wallets to disagree about fees

Store amounts as integers in satoshis. Floating-point BTC values cause rounding errors at the eighth decimal place.

Expect underpayments. Some wallets subtract the network fee from the amount the user typed; others add it on top. A user who "sent 0.05 BTC" may have delivered 0.04998. Decide upfront how you treat a shortfall: tolerance band, execute on received amount, or refund. Surface the rule before the user sends.

6. Refunds need a refund address

Refunding to the sender address is wrong for Bitcoin in two ways. A UTXO transaction can have many inputs from many addresses, so "the sender" may not be one address. And if the deposit came from an exchange withdrawal, every input belongs to the exchange's shared wallet.

Collect a refund address at order creation. Validate it with the same rules as above.

7. Estimate payout fees from live data

If you send BTC back out, for refunds or payouts, fee estimation can't be a constant. Pull from your node's estimatesmartfee or a mempool API, choose a confirmation target, and recompute minimums from the result. A fixed fee will overpay in quiet periods and get stuck in busy ones.

Summary

Credit on confirmations, never zero-conf
Track deposits by address and inputs so RBF doesn't lose them
Align quote windows with Bitcoin's real block time distribution
Validate all four address types with a library that implements BIP-350
Store satoshis as integers; define underpayment handling upfront
Collect a refund address
Estimate payout fees live

Disclosure: I work on SwapCore (swapcore.exchange), a non-custodial instant exchange. BTC deposits are where most of the edge cases above come from, for us and for anyone else handling them.

Integrating a Swap Provider? Here's the Threat Model You Inherit

Swapcore.Exchange — Tue, 29 Sep 2026 09:21:08 +0000

"Non-custodial" in a swap provider's docs usually gets read as "not my security problem." That's half right. Integrating a non-custodial instant exchange removes the biggest risk class, which is holding user balances. But it hands your users a different, smaller one, and parts of that risk run straight through your frontend.

Here's the threat model, split by who owns each piece.

First, get the custody model right

A non-custodial instant exchange isn't zero-custody. The flow looks like this:

user wallet ──deposit──▶ provider deposit address ──swap──▶ user wallet
   (user keys)            (PROVIDER KEYS: transit)           (user keys)

From deposit confirmation until payout, the provider controls the funds. The window is short, usually minutes, bounded by confirmation time on the input chain. But it exists, and any honest threat model starts from it.

What your app never holds: keys, balances, deposits. That's the real win. You're not a custodian, you don't carry a hot wallet, and your breach doesn't drain anyone.

Threats the provider owns

Transit-window compromise. If the provider's operational wallets are breached, in-flight funds are exposed. This has happened in this category: FixedFloat lost around $26M from its own wallets in February 2024. You can't mitigate it in code. You mitigate it in vendor selection (incident history, how they handled it, whether in-flight users were made whole) and by keeping per-swap exposure small.

AML holds. Deposits get screened, and flagged ones pause. That's the provider's process, but surfacing it is your job. Give it a distinct held_for_review state and don't fold it into pending.

Availability. Rate feeds stall, pairs get disabled, minimums spike with congestion. Treat every quote as perishable and every pair as possibly unavailable.

Threats you own

This is the part integrators underestimate. Your frontend is the only place several of these can be caught.

Address substitution. Clipboard malware swaps a copied address for the attacker's. Your UI can't detect malware, but it can make substitution visible:

// Render the destination with its first and last 6 chars emphasized,
// and restate it on the confirmation step. Visual diffing catches
// most substitutions, which change the whole string.
function renderAddress(addr) {
  return {
    head: addr.slice(0, 6),
    middle: addr.slice(6, -6),
    tail: addr.slice(-6),
  };
}

Chain ambiguity. EVM addresses carry no chain identity. Never infer the chain from an address. Make it a required selection with no default, and restate it in words at confirmation.

Conditional memos. For XRP, XLM, ATOM, HBAR, EOS and TON, a memo is required when the destination is a shared (exchange) address and meaningless when it's self-custody. Ask which one it is, and make the field blocking only when it applies.

Refund routing. Refunds go to the sender address by default. If the user funded from an exchange withdrawal, that's a pooled hot wallet and the refund is effectively lost. Collect a refund address at order creation:

const order = await provider.createOrder({
  pair,
  amount,
  destination,
  refundAddress: connectedWallet ?? userInput.refundAddress, // never null silently
});

Clone-site exposure. If you embed a widget, load it from the provider's canonical origin and pin it in your CSP. A compromised or typo-squatted widget source is a deposit-address swap at scale.

Content-Security-Policy: frame-src https://widget.<provider-domain>;

Quote integrity. If quotes pass through your backend, sign or verify them end-to-end. A deposit address that can be altered anywhere between provider and user is the single highest-value target in your stack.

Threats nobody in the stack owns

Worth stating in your docs so users aren't surprised:

Key loss: self-custody moves it entirely to the user
Malicious token approvals signed elsewhere, which live in the user's wallet
Issuer freezes: Tether can freeze USDT at the contract level on any chain

Shrinking the transit window by design

The one risk the model adds is time in transit. Design to minimise it:

Prefer fast input chains in your defaults when the user holds the asset on several
Don't create the order until the user is ready to send. Generate the deposit address at the last step, not the first, so abandoned sessions don't leave stale addresses around.
Offer split execution above a threshold. Several moderate swaps cap peak exposure below one large one.

Summary table

Threat	Owner	Mitigation lives in
Transit-window breach	Provider	Vendor selection, size limits
AML hold	Provider	Your state machine
Address substitution	You	Confirmation UI
Wrong chain	You	Required selection, restatement
Missing memo	You	Conditional blocking field
Lost refunds	You	Refund address at creation
Widget/clone tampering	You	Canonical origin, CSP
Key loss, bad approvals, issuer freeze	User	Documentation

Non-custodial removes the catastrophic risk: holding everyone's money. What's left is smaller, but most of it gets caught or missed in your frontend.

Disclosure: I work on SwapCore (swapcore.exchange), a non-custodial instant exchange. We have a transit window like every provider in this category, and the mitigations above are the ones I'd expect any integrator to ask us about.

Show Users the Real Cost: Building Honest Pricing Into a Crypto Swap UI

Swapcore.Exchange — Sun, 27 Sep 2026 23:17:17 +0000

If your product quotes crypto conversions, your UI is making a claim about cost whether you intended to or not. Most make it badly — and the fix is a handful of fields you probably already have access to.

Here's what an honest quote object looks like and how to compute it.

Why `fee: 0.005` is not a price

A swap has four cost components. Most quote objects surface one.

1. input network fee    — paid by the user to their own chain (never yours)
2. output network fee   — deducted from the payout
3. service fee          — your explicit charge
4. spread               — quoted rate vs. market rate

Display only component 3 and your interface is technically accurate and practically misleading. Users discover the difference by comparing the balance change in their wallet against what your UI promised, and they discover it after the transaction is irreversible.

The number a user cares about is a single figure: what fraction of market value did this operation consume. Everything else is internal accounting.

Computing the effective rate

def effective_cost_bps(amount_in, amount_out_received, mid_market_rate):
    """
    Total cost in basis points, relative to mid-market.
    Captures spread + service fee + output network fee together.
    """
    expected = amount_in * mid_market_rate
    if expected <= 0:
        raise ValueError("mid_market_rate and amount_in must be positive")
    return (expected - amount_out_received) / expected * 10_000

Two implementation notes that matter more than the formula.

Your reference rate needs a timestamp and a source. A cost figure computed against a rate from thirty seconds ago is noise on a volatile pair. Pin the rate you quoted against, store it with the quote, and surface both. cost_bps: 180 with no reference rate is an unfalsifiable claim.

Decide gross or net and label it. If your amount_out is before the output network fee is deducted, say so in the field name — amount_out_gross — because a user comparing your quote against their wallet balance is comparing net. This single ambiguity generates more "you charged me more than you said" tickets than actual overcharging does.

A quote object that doesn't lie

{
  "pair": "ETH_USDT",
  "amount_in": "1.0",
  "rate_type": "floating",

  "reference_rate": "3000.00",
  "reference_source": "coingecko",
  "reference_at": "2026-09-28T01:40:12Z",

  "amount_out_gross": "2955.00",
  "output_network_fee": "15.00",
  "amount_out_net": "2940.00",

  "service_fee_bps": 50,
  "spread_bps": 100,
  "total_cost_bps": 200,

  "quote_expires_at": "2026-09-28T01:50:12Z",
  "minimum_in": "0.012"
}

Points worth arguing about:

spread_bps should be derived, not asserted. Compute it as total_cost_bps − service_fee_bps − (output_network_fee / expected × 10000). If you assert it independently, the three numbers will drift out of agreement and someone will notice.

total_cost_bps is the headline field. It's the only one that maps to what the user experiences. If your UI shows a percentage anywhere, it should be this one.

quote_expires_at, not valid_for_seconds. A duration requires the client to know when the quote was issued, and clock skew makes that unreliable. An absolute timestamp doesn't.

Minimums are dynamic and most codebases hardcode them

minimum_in exists because of component 2: if the output network fee exceeds the output value, the operation is uneconomic. Network fees move with congestion, so the minimum moves with them.

def minimum_input(output_network_fee, rate, max_fee_fraction=0.05):
    """
    Smallest input where the output fee stays under max_fee_fraction
    of the payout. Recompute per quote — never cache across sessions.
    """
    min_output = output_network_fee / max_fee_fraction
    return min_output / rate

A hardcoded minimum fails in both directions — rejecting valid amounts when fees fall, accepting uneconomic ones when they spike — and it fails silently. Take it from the live quote every time.

Fixed vs floating: same schema, different honesty requirement

A fixed rate legitimately costs more, because the platform absorbs price movement for the quote window. Your UI should say that in one line rather than presenting the two as if one is simply worse value.

Floating — 1.2% est. cost. Final amount set when your deposit confirms.
Fixed    — 2.1% cost. Exact amount locked for 9:47.

Two things this framing gets right that a bare toggle doesn't: the cost difference is visible, and the reason for it is attributed to something the user chose.

One rule worth encoding: do not offer a fixed rate as the default when the source chain is slow. A locked window funded by a Bitcoin transaction will expire. Either shorten the choice to floating, or extend the window and price it.

Comparing against other providers

If you aggregate or display competing quotes, three requirements to be honest about it:

Same timestamp. Quotes fetched more than a few seconds apart on a volatile pair aren't comparable. Fetch in parallel, record the fetch time, and show it.
Same net basis. If one provider quotes gross and another net, normalise before comparing or the comparison is meaningless.
Same rate type. Ranking a fixed quote against floating quotes makes the fixed provider look expensive for offering more.

Skip any of these and you have a marketing table, not a price comparison.

The test worth writing

def test_cost_fields_reconcile(quote):
    expected = quote.amount_in * quote.reference_rate
    fee_bps = quote.output_network_fee / expected * 10_000
    derived = quote.service_fee_bps + quote.spread_bps + fee_bps

    assert abs(derived - quote.total_cost_bps) < 1  # bps tolerance
    assert quote.amount_out_net == (
        quote.amount_out_gross - quote.output_network_fee
    )

If that test can't pass, your pricing fields don't describe the same transaction, and the discrepancy will surface as a support ticket rather than a failing build.

Disclosure: I work on SwapCore (swapcore.exchange), a non-custodial instant exchange. The schema above is what we'd defend; the reconciliation test is the part I'd argue every provider in this category should be able to pass.

Adding Crypto Swaps to Your App Without Taking Custody

Swapcore.Exchange — Sat, 12 Sep 2026 21:36:07 +0000

If your product touches crypto — a wallet, a portfolio tracker, a game with an in-app token — you will eventually get asked for swaps. Users hold asset A and want asset B, and every time you send them to an external site to do it, you lose them for the rest of the session.

The obvious implementation is the one you should not build: take deposits, hold balances, execute conversions internally. That turns your app into a custodian, which brings licensing exposure, an attack surface holding other people's money, and an operational burden that has nothing to do with your product.

The alternative is integrating a non-custodial instant exchange. Funds never touch your infrastructure. Here's how that model actually works and what you need to handle in your code.

The execution model

An instant exchange is not an order book. There's no matching, no bids and asks, no depth. The flow is:

Request a quote for a pair and amount
Create an order, submitting the user's destination address
Receive a one-time deposit address for that specific order
The user sends funds to that address from their own wallet
On deposit confirmation, the swap executes and output goes directly to the destination address

Your application is a coordinator. It never holds a key, never holds a balance, and never becomes a party to custody. The user's wallet sends, the exchange routes, the user's wallet receives.

The design decisions that matter
Rate type is a risk-allocation choice, not a UX preference

Most exchange APIs expose fixed and floating rates. This is not a cosmetic toggle and you should not pick a default without understanding it.

Floating calculates the rate at deposit confirmation. The market moves between order creation and confirmation, so the output amount is an estimate. Spread is thinner because the exchange carries no price risk.

Fixed locks the output at order creation for a bounded window. Your user sees a guaranteed amount. The exchange absorbs the price movement and charges for it via a wider spread.

If you're building a checkout flow where a precise amount must arrive, you need fixed — a floating rate that lands two percent short breaks your business logic downstream. If you're building a general-purpose swap UI, expose both and explain the difference in one line. Silently defaulting to floating and showing an estimate as though it's a promise is how you generate support tickets.

Order state is asynchronous and long-lived

A swap is not a request/response operation. It spans a user action in another application and one or more blockchain confirmations. Elapsed time is dominated by network confirmation, which varies by chain and congestion — a Bitcoin deposit and a Tron deposit are not comparable operations.

Design for this:

Persist the order ID on creation, before the user leaves to send funds. If you lose it, you cannot reconcile.
Prefer webhooks over polling for status transitions, with polling as a fallback. Confirmation timing is unpredictable enough that a fixed polling interval is either wasteful or slow.
Handle the terminal states explicitly: completed, expired (fixed-rate window elapsed before deposit), underpaid/overpaid, and held-for-review. That last one is real — deposits are screened against blockchain analytics and flagged ones pause pending manual review. If your UI only knows "pending" and "done", a held order looks like a hang.
Treat expiry as a normal path. Users open a swap, get distracted, and come back after the rate window closed. Build the retry.
Address validation belongs in your UI

The most common failure in this entire flow is a user-supplied destination address that's wrong for the target network — a BEP20 address for an ERC20 payout, or a missing memo/tag on a chain that requires one.

This is unrecoverable by design. No custodial party is holding the funds, so no custodial party can reverse it. Validate format and network client-side before you let the order be created, and surface the memo requirement as a blocking field rather than a hint, on the chains where it applies.

Minimums are per-asset, and they move

Minimum swap amounts are driven by network fees, so they shift with congestion. Don't hardcode them. Fetch the current minimum with the quote and validate against the live value, or you will ship a form that rejects valid amounts and accepts invalid ones.

Two integration surfaces

Most providers offer both:

An embeddable widget. An iframe with your styling. Fast — a day of work — but you don't control the UX and you get limited state visibility.

A REST API. You build the interface, you own the flow, you handle the state machine described above. More work, but it's the only option if swaps are part of a larger transaction in your product rather than a standalone feature.

Start with the widget to validate that users actually want this. Move to the API once you know they do.

DEV Community: Swapcore.Exchange

Checking whether a 2010 bitcoin output has moved, in about 30 lines of JavaScript

17.8 years

The script

Two runs

What to do with it

Sources

worse_query and wallet apps on iOS: what the sandbox escape reads, and what to check in your own app

The report

What the coverage says is exposed

A checklist for your own app

Telling your users

Flagging "pool hops" like the ones in the Binance-hack laundering, in 60 lines of JavaScript

The pattern

The script

Running it

What it won't catch

Samsung Wallet sends USDC on Solana. Here's a 40-line script that tells which chain an address is for

The news, briefly

The script

Running it

What the output teaches

Where this fits

"USDT" Is at Least Three Different Tokens. Your Token Registry Should Know That.

1. Model issuer and kind, not just chain

2. Never resolve tokens by symbol

3. Tron needs its own transfer logic

4. Cross-network conversion is a trade, not a transfer

5. Gas tokens on both sides

Checklist

Your Ethereum Gas Assumptions Are Probably From 2021

1. Stop hardcoding gas prices and minimums

2. Detect internal transactions, not just top-level transfers

3. Use finality, not just confirmations

4. Treat L2 ETH as a different asset

5. Warn about the empty-gas-tank problem

6. Never ask for approvals on a deposit flow

Checklist

Accepting Bitcoin Deposits Correctly: Confirmations, Replacement and Address Types

1. Never credit on zero confirmations

2. Track deposits by outpoint, not by txid alone

3. Your quote window and Bitcoin block time don't agree

4. Validate address types, all four of them

5. Handle amounts in satoshis, and expect wallets to disagree about fees

6. Refunds need a refund address

7. Estimate payout fees from live data

Summary

Integrating a Swap Provider? Here's the Threat Model You Inherit

First, get the custody model right

Threats the provider owns

Threats you own

Threats nobody in the stack owns

Shrinking the transit window by design

Summary table

Show Users the Real Cost: Building Honest Pricing Into a Crypto Swap UI

Why fee: 0.005 is not a price

Computing the effective rate

A quote object that doesn't lie

Minimums are dynamic and most codebases hardcode them

Fixed vs floating: same schema, different honesty requirement

Comparing against other providers

The test worth writing

Adding Crypto Swaps to Your App Without Taking Custody

Why `fee: 0.005` is not a price