DEV Community: Azalea

Your App Will Meet a Freeze. Design for It

Azalea — Thu, 05 Nov 2026 15:40:20 +0000

Last week Binance lost about $6.3 billion in roughly 20 minutes. Within hours, stablecoin issuers froze around $3 billion of it, Binance paused withdrawals for everyone, and analytics firms labeled the attacker's Bitcoin wallets in public.

Most of us will never run an exchange that size. But almost every crypto app touches at least one of the mechanisms that showed up that week: a hot wallet, a stablecoin with a blacklist, a deposit from a flagged address, a "withdrawals paused" banner. Each of them is a state your product needs to handle on purpose.

Here's what I'd take from it as a builder.

1. Watch your hot wallets for EIP-7702 delegations

Binance co-CEO Richard Teng said the attacker used an EIP-7702 delegation to gain execution authority over a hot wallet and bypass normal approvals, Cointelegraph reported. Binance says no private keys leaked.

EIP-7702 lets an externally owned account point to contract code. Once that happens, the address behaves partly like a smart contract. The spec marks a delegated account by setting its code to a fixed prefix, 0xef0100, followed by the 20-byte address of the delegate.

That makes it cheap to monitor. If an address you control suddenly has code, something changed:

import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";

const client = createPublicClient({ chain: mainnet, transport: http() });

export async function checkDelegation(address: `0x${string}`) {
  const code = await client.getCode({ address });
  if (!code || code === "0x") return { delegated: false };
  if (code.startsWith("0xef0100")) {
    return { delegated: true, delegate: `0x${code.slice(8, 48)}` };
  }
  return { delegated: true, delegate: "unknown contract code" };
}

Run that on every hot wallet on a schedule, and alert on any change. It won't stop an attack, but it can shorten the gap between "something happened" and "someone noticed".

2. Check the issuer's blacklist before you pay out

Tether froze more than $1.5 billion in USDT during the hack and Circle more than $800 million in USDC. Both tokens have blacklist logic in their contracts. If your app sends stablecoins, an address can become unpayable at any moment. A blacklisted USDC address can't send or receive, so a transfer to it reverts.

Check before you build the transaction, not after it fails. Both contracts expose a read method, but the names differ by one letter: USDC uses isBlacklisted, USDT uses isBlackListed. Easy to get wrong, so keep the name per token:

const BLACKLIST_FN: Record<string, "isBlacklisted" | "isBlackListed"> = {
  USDC: "isBlacklisted",
  USDT: "isBlackListed",
};

export async function canReceive(
  symbol: "USDC" | "USDT",
  token: `0x${string}`,
  to: `0x${string}`,
) {
  const fn = BLACKLIST_FN[symbol];
  const abi = [{
    name: fn, type: "function", stateMutability: "view",
    inputs: [{ name: "account", type: "address" }],
    outputs: [{ type: "bool" }],
  }] as const;

  try {
    const blocked = await client.readContract({
      address: token, abi, functionName: fn, args: [to],
    });
    return !blocked;
  } catch {
    return null; // can't read it: fall back to simulating the transfer
  }
}

The null branch still matters. Other stablecoins use other names or none at all, so when the check isn't available, simulate the transfer with eth_call and treat a revert as "not payable right now".

And tell the user plainly. "This address can't receive USDT" is better than a generic failure, and much better than a stuck payout.

3. Treat tainted deposits as a normal state

Bitcoin can't be frozen, so the 18,270 BTC from the hack can move whenever the attacker wants. What stops them is everyone else. Exchanges and swap services screen deposits and can refuse coins linked to flagged addresses.

If you accept deposits, some will eventually come from addresses that become flagged after the fact. Model that up front:

type DepositStatus =
  | { state: "confirming"; confirmations: number; required: number }
  | { state: "credited" }
  | { state: "under_review"; reason: "risk_screening"; since: string }
  | { state: "returned"; txHash: string };

under_review needs its own screen with a clear explanation and an expected timeline. Users who see "pending" for two days with no reason assume the worst, and they're usually right to.

4. Withdrawals reopen per asset, not all at once

Binance paused withdrawals on October 29 and reopened them on November 1 in phases, starting with about 15 major assets and networks, CoinDesk reported. Hundreds of smaller tokens stayed locked.

That's the realistic recovery pattern after any incident: some chains come back first, others later. A single global "withdrawals enabled" flag can't express that. Store status per asset and per network, and show it next to each balance:

type WithdrawalStatus = Record<
  `${string}:${string}`, // e.g. "USDT:tron"
  { enabled: boolean; reason?: string; updatedAt: string }
>;

In the first nine and a half hours after the reopening, users pulled about $4.65 billion out of Binance, according to Bitcoin.com News. Plan your queue and rate limits for the day the gate opens, not for a normal Tuesday.

5. Know where privacy coins still fit

During the hack week, Monero rose about 5.7%, and a reply that kept showing up under news posts was "XMR has no freeze switch". That's true, and it's also why regulated services keep dropping it. Kraken ended Monero trading for EEA clients in 2024. From July 10, 2027, Article 79 of the EU's Anti-Money Laundering Regulation bars regulated crypto providers from keeping accounts that allow anonymous transactions, including through coins like Monero.

If your product touches XMR, check where your users are before you ship a feature around it. This overview of whether it's safe and legal to exchange Monero for Ethereum has a country-by-country summary that's a reasonable starting point for that conversation with your legal team. It also flags the UX trap: after a swap to ETH, the user is on a public chain, and any address linked to their name is visible.

A short checklist

Monitor hot wallets for unexpected code, including EIP-7702 delegations.
Check stablecoin blacklists before building a payout, and simulate when you can't.
Give flagged deposits their own state and their own screen.
Keep withdrawal status per asset and per network.
Size your withdrawal queue for the reopening, not the average day.
Map which assets you can legally support in each market before you add them.

Freezes, pauses and flags aren't edge cases anymore. Last week all of them happened at once, to the biggest exchange in the world. Your app should already know what to show when one of them happens to a user.

Sources: Cointelegraph live coverage, CoinDesk, Bitcoin.com News, EIP-7702, EUR-Lex: Regulation (EU) 2024/1624.

The Chain You Pay Out On Changed This Month

Azalea — Fri, 30 Oct 2026 15:01:09 +0000

If your app sends stablecoins, you probably made a network decision once and stopped thinking about it. Most teams did. TRON for USDT, maybe Solana or Base for USDC, and a dropdown so users can pick.

October 2026 is a good month to reopen that decision. Four things changed at once, and each one affects a different part of a payout flow: finality, gas assumptions, which tokens you can offer in Europe, and how those tokens are supervised.

I wrote before about why stablecoin payments are becoming a developer problem. This is the practical follow-up.

Start with the boring numbers

A recent comparison of the best blockchains for everyday crypto payments is a useful baseline, because it looks at the costs a regular user pays, not the costs an exchange with staked TRX pays. A few of its findings matter for anyone building payouts:

TRON holds the most USDT, but a single send costs roughly $2 to $4.50 for a wallet with no staked or rented Energy.
An ERC-20 USDT transfer on Ethereum mainnet was about $0.22 in early October. Cheaper than TRON for that same wallet.
Solana charges a fraction of a cent, but the first transfer to a new address needs a token account, about 0.002 SOL in rent.
TON got sub-second finality in April and renamed its token to Gram in June, which scammers are already using.

The first point surprises people. If your users self-custody and don't hold TRX, "send it on TRON, it's cheap" is no longer good default advice. I went into the TRON side of this in an earlier post.

1. Solana's finality just changed, and your timeouts may be wrong

On October 21, Solana activated Alpenglow, replacing the consensus system it had run since 2020. The target is finality in about 150 milliseconds instead of roughly 12.8 seconds. On launch day the Foundation's dashboard showed about 6.6 seconds, so treat 150 ms as a goal for now.

Two things to check in your code:

If you poll for confirmed and wait a fixed number of seconds before crediting, revisit that. The Foundation says confirmed and finalized become the same state under Alpenglow, and confirmed will be removed in a later release. Move new code to finalized, but only now that Alpenglow is live. Before activation, finalized meant a 12.8-second wait.
If your dashboards count transactions, expect a sharp drop. Validator votes no longer appear as transactions. That's an accounting change, not a fall in usage.

2. Ethereum's gas assumptions are on hold

Glamsterdam went live on the Sepolia testnet on October 6. Its Hoodi testnet activation, planned for October 26, was postponed while developers check how EIP-8037 interacts with existing contracts. EIP-8037 raises and separately meters the gas cost of creating new state: new accounts, new storage slots, new contract code.

For payouts, that means the cost of sending to a brand-new address could change once the upgrade ships. If you estimate gas with hardcoded values, stop. Use eth_estimateGas per transaction and keep a margin. The fee itself is still gas used times base fee plus priority fee, and the base fee can move up to 12.5% per block (ethereum.org).

3. Your EU users may lose USDT

Tether never applied for authorization under MiCA, so licensed platforms in the EU are phasing out USDT. ESMA told them to finish by January 8, 2027. Coinbase moved faster: today, October 30, is its deadline for customers in the European Economic Area to withdraw USDT, DAI and several others before leftovers are converted into USDC.

If you serve EU users through a licensed partner, your available token list may shrink without a code change on your side. Model support as a state, not a boolean:

type TokenSupport =
  | { status: "active" }
  | { status: "deprecating"; region: "EEA"; until: string; convertsTo?: string }
  | { status: "unavailable"; region: "EEA" };

Then let the UI warn users before the partner emails them.

4. USDC gets a supervisor with a date

On October 14, the European Banking Authority classified USDC as the EU's first "significant" e-money token. From November 12, the EBA directly supervises its reserves and liquidity. Nothing changes in the contract or the peg, but it's another reason USDC is becoming the default for EU-facing flows.

Putting it together

Here's roughly how I'd describe networks in a payout service now. The point is to keep the facts that change in data, not in branching logic.

type PayoutNetwork = {
  id: "tron" | "ethereum" | "base" | "arbitrum" | "solana" | "stellar";
  tokens: Record<string, TokenSupport>;
  gasToken: string;
  needsGasForRecipient: boolean;   // e.g. TRX Energy, SOL token account rent
  finality: "probabilistic" | "economic" | "fast";
  estimateFee: (to: string, amount: bigint) => Promise<bigint>;
};

And a few rules I'd put in front of any default:

Recommend the network the recipient already uses, not the cheapest one in theory.
Show the full cost, including first-transfer extras like Solana token accounts.
Never hardcode gas or finality timings. Both changed this month.
Keep per-region token support in config, so a regulator's deadline is a data update, not a deploy.

The cheapest chain on paper changes every few months. The habit of checking is what actually saves users money.

Your "Licensed" Badge Is Doing More Work Than It Should

Azalea — Wed, 28 Oct 2026 16:03:27 +0000

A lot of crypto apps in Europe now show some version of the same line near the buy button: "Licensed under MiCA." It's true, it's reassuring, and a surprising number of users read it as "this is safe to buy."

That's not what it means. And if you build these products, the gap between those two readings is partly a design problem.

I wrote earlier about what MiCA changed after July 2026. This post is narrower. It's about how a compliance fact turns into a trust signal on screen, and how to keep it honest.

What the badge actually certifies

MiCA regulates the operator, not the asset. A crypto-asset service provider gets authorized after meeting rules on capital, governance, custody of client assets, complaints handling and disclosure. Since July 1, 2026, no transition period is left anywhere in the EU, so a company without that authorization shouldn't be serving EU customers at all.

So the badge says: this company is supervised and accountable.

It doesn't say:

the asset is protected (there's no deposit guarantee for crypto);
the user was checked for whether they understand the product;
the user controls the coins.

Users don't read regulation text. They read your UI. If the license badge sits right next to the "Buy BTC" button with nothing else around it, you've made a claim you didn't intend.

Users are being told to check things your product should make easy

Consumer guides have started telling people exactly what to verify before using a platform. A Spanish explainer on what MiCA means for people who use crypto in 2026 is a good example. Its advice comes down to a short list: confirm the platform is authorized, understand which stablecoin you hold, check the destination address and network before sending, keep records for taxes, and remember that the regulation doesn't make crypto a safe investment.

Read that list as a product spec. Every item is something your app can support or quietly make harder.

1. Make the license verifiable, not decorative

A badge that just says "Licensed" is an image. A useful one names the regulator and the license number, and links to the public record.

type LicenseInfo = {
  regime: "MiCA";
  authority: string;      // e.g. "AMF (France)"
  licenseId: string;
  registerUrl: string;    // national register or ESMA's list
  homeState: string;      // where the passport comes from
};

The homeState field matters more than it looks. A MiCA license works across the EU, so a user in Spain may be using an app supervised in Malta or France. Say so. ESMA keeps a central MiCA register you can point to.

2. Keep the badge and the risk warning apart

Put the license and the price-risk warning in separate places, with separate visual weight. When they share a card, users tend to read the badge as cancelling the warning.

A plain line works better than legal copy: "Our license covers how we hold and handle your assets. It doesn't protect you from price drops."

3. Say who holds the keys, in the product, not the terms

"Custodied by us" and "in your wallet" are different products. Some licensed services in Europe don't give users keys and only allow withdrawals to addresses at approved providers. That's a legitimate setup, but users should learn it before buying, not when they try to leave.

Show withdrawal rules on the asset page:

{
  "custody": "platform",
  "withdrawals": {
    "selfCustody": false,
    "allowedDestinations": "approved_providers_only",
    "networks": ["bitcoin", "ethereum"]
  }
}

I covered the pre-send side of this in What a Crypto App Should Do Before You Press "Send". The same idea applies one step earlier, at purchase.

4. Treat stablecoin support as something that can change

Tether never applied for MiCA authorization, so licensed platforms have been phasing out USDT for EU users. ESMA told them to finish by January 8, 2027, and some exchanges moved faster, converting leftover balances into USDC after a deadline.

Most users found out from an email. A better pattern is a status field per asset that the UI can surface early:

type AssetSupport =
  | { status: "supported" }
  | { status: "deprecating"; until: string; convertsTo?: string }
  | { status: "withdraw_only"; until: string };

Meanwhile USDC moves the other way. The European Banking Authority classified it as the EU's first "significant" e-money token, with direct EBA supervision of its reserves from November 12, 2026. That's worth reflecting in your asset info too.

5. Build tax records in, because the tax office already has them

Under DAC8, platforms collect users' tax residence and report their transactions from January 1, 2026, with the first reports sent in 2027. Your users' tax authorities will see their trades. Many users still won't have their own records.

A one-click export (date, pair, amount, price, fee, network, tx hash) costs little to build and saves people a lot of pain in spring. It's also one of the items on every consumer checklist, so it reads as care rather than a feature.

The short version

A license tells users the company is accountable. Your interface decides whether they think it means more than that. Name the regulator, separate the badge from the risk, show custody and withdrawal rules up front, warn before an asset loses support, and give people their records.

None of this is required by MiCA in exactly this form. It's just what users are now being told to look for.

What Wrapped Bitcoin Actually Asks You to Trust

Azalea — Thu, 22 Oct 2026 18:28:36 +0000

Bitcoin can't run on Ethereum. So when a lending market or a DEX pool on Ethereum says it accepts "BTC", it means something else: a token that promises a real bitcoin is sitting somewhere, waiting to be redeemed.

That promise has a structure. Someone holds the BTC, someone decides who can mint and burn, and someone charges for each step. In my last post on proof of reserves I looked at what an exchange's reserve report can and can't tell you. Wrapped bitcoin raises the same question, just with a token contract in the middle.

The token is a claim on a vault

WBTC, the oldest and best-known wrapper, works through two kinds of participants: merchants and a custodian.

Mint:  User → Merchant → Custodian receives BTC → WBTC minted on Ethereum
Burn:  User → Merchant → WBTC burned → Custodian releases BTC

The user never talks to the custodian directly. A merchant handles the request, usually after KYC, and the custodian mints or releases. Official minting waits for 6 Bitcoin confirmations, and burning waits for 25 Ethereum blocks.

Once WBTC exists, moving it between users costs only network fees. The trust question sits entirely at the edges: when the token is created and when it's turned back into bitcoin.

Three wrappers, three different promises

WBTC isn't the only way to hold BTC on Ethereum anymore. In a wallet, these tokens look almost identical. Underneath, they ask you to trust different parties:

WBTC:
  backing: BTC held by a custodian
  mint_and_redeem: through approved merchants, usually with KYC
  fees: custodian fee + merchant fee, rates not published

tBTC:
  backing: BTC deposits secured by Threshold network operators
  mint_and_redeem: 0.2% each way, minimum deposit 0.01 BTC

cbBTC:
  backing: BTC held by Coinbase
  mint_and_redeem: through a Coinbase account, no wrap or unwrap fee

They aren't interchangeable. A pool that accepts only WBTC won't take tBTC, so a cheaper mint on one wrapper can mean an extra swap, and another fee, later.

Custody can change while the token stays the same

This is the part that's easy to miss if you only look at the contract address.

In 2024, BitGo announced it would move WBTC custody into a new structure with a partner, BiT Global. The token kept its name, its contract and its 1:1 claim. What changed was who stood behind it. Coinbase later delisted WBTC, saying it no longer met its listing standards, and promoted its own cbBTC instead.

Nothing broke on-chain. Holders could still transfer and use their tokens. But the trust model they had originally accepted was different from the one they ended up with, and the change happened off-chain, in agreements most users never read.

For anyone building on top of wrapped BTC, that's the real risk surface. Your code checks a contract. The guarantee lives somewhere else.

The fee nobody publishes

Cost is where wrapping gets murky. A recent comparison of the cheapest ways to convert BTC to WBTC lines up four routes: official merchants, centralized exchanges, instant swap services and the tBTC bridge. One finding stood out to me. The custodian's fee for official WBTC minting isn't public. It's set in an off-chain agreement between merchant and custodian, and the third-party estimates the authors found disagreed with each other by a wide margin.

So the most "official" route is also the one you can't price in advance.

The routes with published numbers behave very differently depending on size. A percentage fee scales with the amount. The Bitcoin network fee doesn't. With a simple SegWit payment of about 140 vbytes:

function wrapCostShare(amountSats, percentFee, satPerVb, vbytes = 140) {
  const serviceFee = amountSats * percentFee;
  const networkFee = vbytes * satPerVb;
  return (serviceFee + networkFee) / amountSats;
}

wrapCostShare(1_000_000, 0.002, 20);   // 0.01 BTC → 0.0048   (~0.48%)
wrapCostShare(100_000_000, 0.002, 20); // 1 BTC    → 0.002028 (~0.20%)

At 0.01 BTC on a busy day, the Bitcoin fee (about 2,800 sats) is bigger than a 0.2% bridge fee (2,000 sats). At 1 BTC it barely registers. Ethereum gas, meanwhile, was the smallest line of all in mid-October 2026: about $0.04 for a swap, according to Etherscan's gas tracker.

The cheapest route for a $200 conversion and the cheapest route for a $200,000 one are often different routes.

What this means if you're building

If your app accepts BTC on Ethereum, the wrapper choice is a risk decision, and it deserves the same treatment as any other dependency:

Treat each wrapped asset as a separate asset with its own backing, custodian and redemption path. A shared ticker prefix doesn't make them equivalent.
Keep an explicit allowlist and review it. Custody arrangements can change without a contract upgrade.
Show users which wrapper they hold or receive. "BTC" in the UI hides the one detail that matters most.
Don't promise instant redemption. Burning WBTC goes through a merchant, and that's an off-chain process with its own timing.
When you quote a conversion, quote the amount that arrives after every fee. A good-looking rate with a separate fee can lose to a plain one.

Wrapped bitcoin made BTC usable across Ethereum, and that's been genuinely useful for years. The token, though, is only as reliable as the arrangement behind it. Read that arrangement before you build on it.

Drafted with AI assistance. Facts were checked against the linked sources, and the text was edited by me.

Private In, Public Out: What an XMR to ETH Swap Looks Like From the Inside

Azalea — Tue, 20 Oct 2026 22:46:07 +0000

Last week a privacy coin had a bad few days. On October 14, Pirate Chain found an exploit that let an attacker mint about 39.8 million ARRR out of thin air, roughly a fifth of the supply. The new coins went straight into the shielded pool, where the chain's mandatory privacy makes them impossible to fully trace. The team dropped its rollback plan and asked exchanges and pools to pause.

That's the dramatic version of a trade-off every privacy chain lives with. Privacy hides the user, and it can also hide the problem.

Most people will never touch an exploit like that. What they do touch is a much more boring moment: moving value out of a private chain and into a public one. Swapping Monero for Ether is the most common example. If you build wallets, payment flows or anything with a "Send" button, that boundary has its own timing, its own costs and a couple of states that most interfaces never show.

Here's what happens inside it.

Two ledgers with opposite defaults

Monero hides the sender, the receiver and the amount by default. Ethereum shows all three to anyone with a block explorer.

So an XMR to ETH swap is a one-way door. Whatever happens on the Monero side stays fairly private. Whatever happens after the ETH lands is public forever: the receiving address, every transfer it makes afterward, and every contract it touches.

I wrote earlier about what a public crypto wallet can reveal. The short version applies here too. If the ETH address is already linked to your name through an exchange account or an ENS name, the swapped ETH is linked to you as well. Privacy on the way in doesn't carry over.

Where the time goes

People expect the swap itself to be the slow part. It isn't. Most of the waiting happens on the Monero side, before any exchange runs.

Three things set the clock:

Your own balance. Monero locks newly received coins for 10 blocks before they can be spent. If you got the XMR twenty minutes ago, you may not be able to send it yet.
Block pace. Monero produces a block about every 2 minutes.
The service's threshold. Each swap service decides how many confirmations it waits for before accepting a deposit. Five confirmations is about ten minutes. Twenty is forty minutes or more. Large or unusual orders often get a higher threshold.

The Ethereum side rarely slows anything down. Ethereum runs on 12-second slots, so once the payout is sent, it shows up quickly.

For builders, this has a simple consequence: a spinner is the wrong UI here. Users wait more calmly when they see "3 of 5 confirmations" than when they stare at a loading animation for twelve minutes with no idea whether anything is happening.

Where the money goes

There's no single fee in an XMR to ETH swap. There are four:

the Monero network fee on your deposit, which you pay from your own wallet;
the provider's trading costs with its liquidity partners;
the spread, the gap between the market price and the rate you're offered;
the Ethereum network fee on the payout.

On most instant swap services, only the first one is visible to you as a separate charge. The rest is folded into the quote. This breakdown of XMR to ETH exchange fees puts it well: the number worth comparing is the ETH you actually receive, not the headline rate.

A few details from the protocol docs are worth knowing.

Monero wallets offer four fee priority levels. The fee depends on congestion and transaction size, not on how much XMR you send.

On Ethereum, the fee is gas used times the base fee plus a priority fee. A plain ETH transfer uses 21,000 gas, and the base fee can move by up to 12.5% per block as demand changes (ethereum.org). That's why the same swap can cost more to pay out on a busy afternoon.

Then there's the minimum amount. Network costs are roughly fixed per transaction, so on a tiny swap they eat a large share. Near the minimum, the ETH you receive can look noticeably worse than the market rate.

The choice between fixed and floating rates is a trade-off too. A fixed rate locks the amount for a short window, and the provider usually builds a small buffer into it for price swings. A floating rate follows the market until execution and can land a bit above or below the estimate. On a volatile day, the certainty may be worth the buffer. On a calm day, often it isn't.

For builders: show the final received amount as the main number. Show the rate second. If your quote is an estimate, say so in plain words, right next to the figure.

The state nobody designs for

Every swap flow has the happy path: waiting for deposit, confirming, exchanging, sending, done. Most also have a state that rarely shows up in mockups: on hold for a compliance review.

"No account" and "no checks" are not the same thing. Account-free services still run risk-based reviews. Reports of stolen funds, unusual transactions or local law can trigger identity verification, and in some countries verification is required before any order at all.

The wider rules are getting tighter, and they differ a lot by country. Dubai banned privacy coin activity in February 2023. Kraken ended Monero trading and deposits for clients in the European Economic Area in October 2024. And from July 10, 2027, Article 79 of the EU's Anti-Money Laundering Regulation bars regulated crypto service providers from keeping accounts that allow anonymised transactions, including through anonymity-enhancing coins.

Read that last one carefully. It applies to providers. It doesn't stop individuals from holding XMR in their own wallets. If you want the country-by-country picture, this overview of whether it's safe and legal to exchange Monero for Ethereum collects the main rules in one table.

For builders, the lesson is to treat "verification requested" as a first-class state. Say what triggered it, what the user needs to do, and how long the request stays open. A held order with a clear explanation is annoying. A held order with no explanation feels like a scam, and users will treat it like one.

A short checklist if you're building this flow

Show confirmation progress as a count, not a spinner.
Lead with the amount the user will receive. Put the rate second.
Label estimates as estimates, and say what's already included.
Warn when the amount is close to the minimum, where fees weigh most.
Make the payout network impossible to miss. Mainnet, Base and Arbitrum addresses look identical.
Design the compliance-hold screen before you need it.
Give the user an order ID they can save, and a status page that works with nothing else.

And if you're on the user side: send already-unlocked XMR, compare the full ETH address character by character, and assume the receiving address will be public for good. Because it will be.

Why Sending USDT Still Requires a Second Coin

Azalea — Fri, 16 Oct 2026 21:33:40 +0000

If you've worked on a stablecoin wallet, you've probably seen this support ticket. A user has 500 USDT on TRON, presses Send, and gets an error. The balance is right there on the screen. What's missing is TRX, a coin they never bought and didn't know they needed.

Every chain that carries stablecoins charges its fees in its own native token. So "send 50 USDT" is quietly a two-asset operation, and the second asset is the one users forget. My last post looked at why a swap screen shows the wrong number. This one is about the coin that never shows up on the send screen at all, until it blocks the transfer.

Key takeaways

On TRON, Solana, Stellar, TON and Ethereum, a USDT or USDC transfer costs something in the chain's native token, and each chain charges it differently.
The cost often depends on the recipient. Sending USDT on TRON to an address that has never held USDT needs about twice the Energy. On Solana, a missing token account adds rent.
Fee sponsorship exists on every one of these chains: TRON Energy delegation, Solana fee payers, Stellar fee-bump transactions, TON gasless transfers, Ethereum paymasters.
Gasless doesn't mean free. Someone still pays the network, and the cost usually comes out of the stablecoin.
A wallet should check the native balance before the user types an amount, not after they press Send.

Five chains, five billing models

A comparison of the best blockchains for crypto payments published this week scores TRON, Solana, TON, Stellar and Ethereum on cost per transfer, finality, stablecoin liquidity, real payment use and access. Its definition of access includes how hard it is to get the gas token. I think that criterion deserves more attention than it usually gets, because it's where first-time users get stuck.

Here is what each chain actually charges for a stablecoin transfer, checked against the networks' own documentation:

Chain	Native token	What a stablecoin transfer costs	What depends on the recipient
TRON	TRX	About 65,000 Energy, or 6.5 TRX if burned at 100 sun per Energy	About 131,000 Energy if the recipient has never held USDT
Solana	SOL	5,000 lamports per signature, plus an optional priority fee	About 0.00204 SOL rent if the recipient has no token account
Stellar	XLM	100 stroops per operation (0.00001 XLM)	The recipient needs a trustline, which locks 0.5 XLM of their reserve
TON	Gram (formerly Toncoin)	A small fee in Gram, or in USDT through gasless transfers	Depends on the wallet, see below
Ethereum and L2s	ETH	Gas units times gas price, paid in ETH on mainnet, Base and Arbitrum alike	More gas if the recipient holds none of the token yet, since a new storage slot is written

The rows don't line up, so a wallet that supports all five needs five different answers to "can this user send right now?"

TRON: Energy, Bandwidth and the first-time recipient

TRON doesn't charge a gas price in the usual sense. A USDT transfer consumes two resources. Energy pays for running the token contract, and Bandwidth pays for the bytes of the transaction (GetBlock docs).

A transfer to an address that already holds USDT takes about 65,000 Energy, because it updates an existing storage slot. A transfer to an address that has never held USDT takes about 131,000, because the contract has to create one. If the sender has no Energy, the network burns TRX instead, at 100 sun per Energy. That works out to about 6.5 TRX for the first case and 13.1 TRX for the second.

Bandwidth is easier on the user. Every account gets 600 free Bandwidth points a day, and a USDT transfer uses about 345, so one transfer a day is covered.

There are cheaper routes, but none of them helps a user who has zero TRX:

Staking TRX gives Energy in proportion to the stake. Unstaking takes 14 days.
Energy rental markets delegate Energy from large stakers, typically at 30 to 50 sun per unit.
In February 2025 Justin Sun announced a gas-free option for sending USDT on TRON without holding TRX. Whether you can use it depends on the wallet.

The doubled cost for new recipients catches people out. The amount the wallet quoted yesterday for sending to a friend can be half of what it charges today for paying someone new.

Solana: cheap fees, plus rent

Solana's base fee is 5,000 lamports per signature, or 0.000005 SOL. A priority fee on top is optional (Solana docs).

The surprise is rent. USDC and USDT on Solana live in token accounts, one per owner per token. If the recipient doesn't have one yet, the sender's transaction usually creates it, and every account must hold a minimum balance proportional to its size. The formula in Solana's docs is (account_size + 128) * 3,480 lamports * 2 years. A token account is 165 bytes, so that comes to 2,039,280 lamports, about 0.00204 SOL (Solana docs). The balance is returned when the account is closed.

That is a small number, but it is about 400 times the base fee. A wallet that shows "fee: 0.000005 SOL" and then takes 0.002 more has a trust problem, even if the amount is tiny.

Solana also lets a different account pay the fee for a transaction, which is how many apps sponsor their users' transfers.

Stellar: reserves and trustlines

Stellar's fees are close to nothing: the network minimum is 100 stroops per operation, which is 0.00001 XLM, and it only rises when the network is congested (Stellar docs).

The catch is the minimum balance. Every account must keep two base reserves, currently 1 XLM, plus 0.5 XLM for each subentry (Stellar docs). To hold USDC, an account needs a trustline to the issuer, and that trustline is a subentry. So a wallet holding only USDC still has to keep 1.5 XLM locked.

The recipient side matters even more. An account without a USDC trustline can't receive USDC at all. On TRON or Ethereum a payment to a fresh address just works. On Stellar it fails until the recipient opts in.

Stellar has two built-in ways around this. Fee-bump transactions let another account pay the fee, and sponsored reserves let an app cover a user's reserves.

TON: gasless, with a fee in USDT

On TON, fees are paid in the native token, which was renamed from Toncoin to Gram in June 2026. Tonkeeper's gasless mode lets a W5 wallet send USDT with no Gram in it. The user signs a message, a relayer wraps it in a transaction and pays the network, and the fee is taken from the USDT being sent (Tonkeeper).

Tonkeeper's own explainer is honest about this: gas doesn't disappear, it just gets paid in a different token. Its example, at a price of $7 per token, puts a gasless USDT transfer at about $0.14, against about $0.10 through its prepaid Battery. Users get convenience and pay a small premium for it.

Ethereum and L2s: paymasters

On Ethereum mainnet, Base and Arbitrum, gas is paid in ETH. L2s made transfers cheap, but they didn't remove the need to hold ETH on that specific network. Someone with USDC on Base and ETH only on mainnet still can't send.

Two standards changed this. ERC-4337 introduced paymasters, contracts that pay gas on a user's behalf. EIP-7702, activated with the Pectra upgrade in May 2025, lets regular wallets delegate to smart contract code, so they can use paymasters too. Circle's Paymaster, for example, checks that the sender has enough USDC and pays the gas, charging the user in USDC instead of ETH (Circle).

A different approach is a chain built around one stablecoin. Plasma launched in September 2025 with zero-fee USDT transfers during its initial rollout. That removes the problem for USDT on that chain, but users still have to get there.

Check before the user types an amount

Every chain above has a fix, but the user only benefits if the wallet checks first. Here is a preflight check that returns how much of the native token a stablecoin transfer needs. It ignores some edge cases on purpose, such as TRON Bandwidth beyond the free daily allowance:

type SendCheck =
  | { chain: 'tron'; recipientHasUsdt: boolean; availableEnergy: bigint }
  | { chain: 'solana'; recipientHasTokenAccount: boolean; priorityFeeLamports: bigint }
  | { chain: 'stellar'; recipientHasTrustline: boolean; senderSubentries: number }
  | { chain: 'evm'; gasLimit: bigint; maxFeePerGasWei: bigint }

const SUN_PER_ENERGY = 100n
const TOKEN_ACCOUNT_RENT_LAMPORTS = 2_039_280n // 165-byte token account
const BASE_RESERVE_STROOPS = 5_000_000n // 0.5 XLM

// Native amount the sender must hold, in the chain's smallest unit
export function nativeNeeded(c: SendCheck): bigint {
  switch (c.chain) {
    case 'tron': {
      const energy = c.recipientHasUsdt ? 65_000n : 131_000n
      const missing = energy > c.availableEnergy ? energy - c.availableEnergy : 0n
      return missing * SUN_PER_ENERGY
    }
    case 'solana': {
      const rent = c.recipientHasTokenAccount ? 0n : TOKEN_ACCOUNT_RENT_LAMPORTS
      return 5_000n + c.priorityFeeLamports + rent
    }
    case 'stellar': {
      if (!c.recipientHasTrustline) {
        throw new Error('Recipient has no trustline for this asset')
      }
      const minBalance = BigInt(2 + c.senderSubentries) * BASE_RESERVE_STROOPS
      return minBalance + 100n
    }
    case 'evm':
      return c.gasLimit * c.maxFeePerGasWei
  }
}

A few outputs to sanity-check against the table: a TRON transfer to a new recipient with no Energy returns 13,100,000 sun, or 13.1 TRX. A Solana transfer that creates a token account returns 2,044,280 lamports. A Stellar sender with one USDC trustline needs 15,000,100 stroops, about 1.5 XLM, most of which stays locked as reserve.

The real work is in the inputs. recipientHasUsdt and recipientHasTokenAccount need a lookup on the recipient before the quote, which is easy to skip and expensive to get wrong.

A checklist for the send screen

[ ] Show the native balance next to the stablecoin balance, with the network name.
[ ] Run the preflight check as soon as the recipient is known, before the amount.
[ ] Look up the recipient: USDT history on TRON, a token account on Solana, a trustline on Stellar.
[ ] Show the total fee, including rent or reserves, in both the native token and dollars.
[ ] If the user has no native token, offer the fix in place: sponsored fee, gasless mode or a small top-up.
[ ] When the fee is paid in the stablecoin, say so before signing and show the amount the recipient will get.

FAQ

Why can't I send USDT if I have enough USDT?

Because the network fee is charged in the chain's native token, not in USDT. On TRON you need TRX or Energy, on Solana SOL, on Ethereum and its L2s ETH, on Stellar XLM and on TON Gram. Your USDT balance can cover the amount but not the fee. Some wallets now offer gasless sending, where a relayer or paymaster pays the network and takes the fee from your USDT, so check whether yours supports it. Otherwise, buying a small amount of the native token on the same network solves the problem for many future transfers.

Why did my USDT transfer on TRON cost twice as much this time?

Most likely the recipient had never held USDT before. Sending to such an address takes about 131,000 Energy instead of about 65,000, because the token contract has to create a new storage entry for the recipient. If you have no staked or rented Energy, the network burns TRX to cover it, so the cost roughly doubles. Later transfers to the same address go back to the normal amount. Staking TRX or renting Energy lowers the cost for both cases.

Is a gasless transfer free?

No. The network still charges a fee, and someone pays it. In gasless setups a relayer or paymaster pays the network in the native token and recovers the cost from you, usually in the stablecoin you're sending, sometimes with a small markup. Some apps cover the fee themselves as a feature and make the money back elsewhere. Gasless removes the need to hold a second coin. It doesn't remove the cost, so check the final amount the recipient gets before signing.

Closing thoughts

Sending a stablecoin still means managing two balances, and most of the confusion comes from wallets that show only one of them. All the tools for hiding the second coin already exist on these five chains. What's left is wiring the check into the moment the user picks a recipient.

If you've shipped gasless sending or fee sponsorship, which part took the most work: the relayer, the pricing, or explaining it to users? I'd like to compare notes in the comments.

Your Swap Screen Is Showing the Wrong Number

Azalea — Wed, 14 Oct 2026 23:10:30 +0000

A month ago I wrote about what a crypto app should do before you press "Send". There's one more thing that happens before that button, and most swap interfaces still get it wrong: the number they put in the biggest font.

Usually it's the exchange rate. 1 XMR = 0.12 ETH. Clean, comparable, easy to sort.

It's also the least useful figure on the screen.

What lands in the user's wallet is an amount. Between the rate and that amount sit several costs the rate doesn't show.

One quote, four costs

Cross-chain swaps make this easy to see, because each leg has its own costs. Take Monero to Ethereum. CoinMarketCal recently published a breakdown of XMR to ETH exchange fees and counted four separate costs behind a single quote:

XMR network fee   → paid by the user, from their own wallet
Provider fees     → trading fees charged by liquidity sources
Spread            → gap between the market price and the offered rate
ETH payout fee    → gas to send ETH to the user's address

Only the first one is under the user's control. The Monero fee depends on network load and transaction size, not on the amount sent, and wallets let you choose from four priority levels. Everything else is decided by the provider.

The Ethereum side has its own formula. According to ethereum.org, a transaction costs gas units multiplied by the base fee plus a priority fee. A plain ETH transfer uses 21,000 gas. The base fee can move by up to 12.5% per block with demand, so the same payout can cost noticeably more at a busy moment.

None of this shows up in "1 XMR = 0.12 ETH".

Better rate, worse result

Here's a simple case. Two quotes for a 2 XMR swap (the numbers are illustrative):

Quote A shows a rate of 0.12000 ETH, charges a 0.1% trading fee, and takes a 0.002 ETH withdrawal fee afterwards.
Quote B shows 0.11925 ETH, with every cost after the deposit already included.

Sort by rate and A wins. Now compute what actually arrives:

function rankByReceived(quotes) {
  return quotes
    .map((q) => ({
      name: q.name,
      received: Number(
        (q.amountIn * q.rate * (1 - q.tradingFee) - q.fixedFees).toFixed(6)
      ),
    }))
    .sort((a, b) => b.received - a.received);
}

rankByReceived([
  { name: "A", amountIn: 2, rate: 0.12, tradingFee: 0.001, fixedFees: 0.002 },
  { name: "B", amountIn: 2, rate: 0.11925, tradingFee: 0, fixedFees: 0 },
]);
// [ { name: "B", received: 0.2385 }, { name: "A", received: 0.23776 } ]

B pays out more. The gap is small here, but a UI that ranks by rate picks the wrong option every time this pattern appears. And it appears a lot, because "no fees" usually means the fees moved into the spread or into a step that comes later.

The rate wasn't lying. It answered a question the user didn't ask.

Small swaps hurt the most

Network fees are roughly fixed per transaction. They don't scale with the amount, so their share grows as the swap gets smaller.

const feeShare = (receivedEth, fixedFeesEth) => fixedFeesEth / receivedEth;

feeShare(0.24, 0.002); // ≈ 0.0083 → 0.8%
feeShare(0.03, 0.002); // ≈ 0.0667 → 6.7%

Same fees, eight times the impact. This is also why providers set minimum amounts: below a certain point, fees eat most of the order. A screen that shows only the rate hides this completely. A screen that shows the received amount makes it visible the moment someone types a small number.

What the quote object should carry

If I were designing the API behind a swap screen, the response would put the received amount first and say what's inside it:

{
  "amountIn": { "value": "2.0", "asset": "XMR" },
  "amountOut": { "value": "0.2385", "asset": "ETH" },
  "rateMode": "floating",
  "includedInQuote": ["spread", "provider fees", "ETH payout fee"],
  "paidSeparately": ["XMR network fee"],
  "expiresAt": "2026-10-15T12:00:00Z"
}

amountOut is the headline. Anyone who wants the rate can derive it.

includedInQuote and paidSeparately matter more than they look. Two quotes are only comparable if they cover the same costs. Without these fields, the frontend has no way to tell whether it's comparing like with like.

rateMode tells the user what kind of promise they're getting. A floating quote follows the market until execution and can land slightly above or below the estimate. A fixed quote locks the amount for a limited window, usually with a small buffer priced in for volatility. Both are fine. Hiding which one it is isn't.

expiresAt is there for fixed quotes. A locked amount with no visible deadline is a support ticket waiting to happen.

Thin liquidity widens the gap

For pairs with deep markets, the difference between the rate and the received amount stays small. For thinner pairs it grows, and Monero is a good example. Kraken stopped XMR trading and deposits for clients in the European Economic Area from October 31, 2024. Fewer venues usually means wider spreads, and the spread is exactly the cost a rate-first screen never shows.

So the less liquid the asset, the more misleading the headline rate gets. That's the opposite of what users need.

A short checklist for swap screens

Lead with the amount the user will receive.
Say whether that number is an estimate or a guaranteed amount, and for how long.
List what's already included and what the user still pays.
Flag amounts close to the minimum, where fixed fees dominate.
Compare quotes by received amount, never by rate.

None of this needs new infrastructure. The provider already calculates every one of these numbers to build the quote. The only question is whether the interface passes them on.

People spend what arrives in their wallet. The screen should start there.

What an Exchange’s Proof of Reserves Actually Proves

Azalea — Fri, 09 Oct 2026 15:55:49 +0000

On September 24, 2026, attackers drained about $387.5 million from Bitget. Five days later, the snapshot for its 47th proof of reserves report put the overall reserve ratio at 131%. Withdrawals were still coming back one asset at a time.

I found that pair of numbers more instructive than any explainer. The exchange had lost a large sum and was still holding more than it owed, at least at 09:00 UTC on one Tuesday. What the ratio couldn't say was how the attackers got in, or what the balance sheet would look like the following week.

My last two posts dealt with a single transfer, before and after you press Send. This one is about the platform that holds the balance in the first place. If you build on exchange APIs, or simply keep coins on an exchange, you should know what a proof of reserves report covers and where it stops.

Key takeaways

Proof of reserves has two halves: proof of assets (the exchange controls these wallets) and proof of liabilities (this is what it owes customers). A ratio needs both.
A Merkle sum tree lets each user check that their own balance was counted, without the exchange publishing everyone's balances.
The classic weak spot is a fake negative balance hidden in the tree. Zero-knowledge proofs close it, which is why OKX moved to zk-STARK proofs.
A report is a snapshot. It doesn't cover borrowed assets moved in for the day, fiat, off-chain liabilities or operational security.
Bitget's 131% after a $387.5 million theft is a good case for seeing what a ratio shows and what it leaves out.

Two halves of one number

A reserve ratio is assets divided by liabilities, calculated per asset, and each side has to be proven separately.

Proof of assets shows that the exchange controls specific on-chain addresses. Usually it publishes the addresses and signs a message with each key. OKX, for example, provides open-source tools to verify signed "I am an OKX address" messages and to compare balances against a block-height snapshot (OKX).

Proof of liabilities shows what the exchange owes its users, and it's the harder half. Publishing every customer balance would wreck privacy, so the usual approach is a Merkle sum tree, which Vitalik Buterin walked through in his 2022 post on proof of solvency.

OKX's 47th report lists 109% for BTC, 101% for ETH, 105% for USDT and 100% for USDC. You can only read those figures as reserve ratios because assets and liabilities were proven for the same snapshot.

How a Merkle sum tree proof works

Each user becomes a leaf: a hash of a salted user identifier plus that user's balance. Every parent node stores a hash of its children and the sum of their balances, so the root ends up committing to total liabilities.

The exchange publishes only the root. You get a proof made of the sibling nodes along the path from your leaf to the root. A verification tool recomputes that path, and if it lands on the published root, your balance was counted.

Here is the check in TypeScript. Real exchanges use their own leaf formats, so read this as the shape of the verification rather than a drop-in tool:

import { createHash } from 'node:crypto'

type Node = { hash: string; sum: bigint }
type Step = { sibling: Node; siblingOnLeft: boolean }

const sha256 = (s: string) => createHash('sha256').update(s).digest('hex')

export const leaf = (userIdHash: string, balance: bigint): Node => ({
  hash: sha256(`leaf|${userIdHash}|${balance}`),
  sum: balance,
})

export function parent(left: Node, right: Node): Node {
  if (left.sum < 0n || right.sum < 0n) throw new Error('Negative sum in tree')
  return {
    hash: sha256(`node|${left.hash}|${left.sum}|${right.hash}|${right.sum}`),
    sum: left.sum + right.sum,
  }
}

export function verifyInclusion(start: Node, path: Step[], root: Node): boolean {
  let node = start
  for (const { sibling, siblingOnLeft } of path) {
    node = siblingOnLeft ? parent(sibling, node) : parent(node, sibling)
  }
  return node.hash === root.hash && node.sum === root.sum
}

Balances are bigint in the smallest unit of the asset, since floating point has no business near money. The sum also goes into every hash, so changing a subtotal anywhere breaks every path that runs through it.

The negative balance trick

Suppose an exchange holds 890 ETH but owes customers 1,390 ETH. It can add a fake account with a balance of -500 ETH, and the root will show liabilities of 890 ETH, matched exactly by reserves.

In a plain Merkle sum tree, the defense is the check you see in parent: a negative sum throws. A user whose path passes near the fake account sees the negative value and rejects the proof. But that only helps if someone in that branch actually runs the check, and an exchange can bet that nobody will. Buterin points out that quietly leaving those users out of the tree would work just as well for a dishonest exchange.

Zero-knowledge proofs take that bet off the table. A zk proof can show that every balance in the tree is non-negative and that they add up to the claimed total, without revealing any individual balance. OKX moved its liabilities proof to zk-STARKs. For reports since September 2024, users download an inclusion proof file and run it through an open-source validator, and a separate file proves the total and the non-negative constraint (OKX).

What a reserve ratio can't tell you

Proof of reserves became the standard reassurance after FTX collapsed in November 2022. A month later the accounting firm Mazars paused this work for all its crypto clients, citing concerns about "the way these reports are understood by the public." Its reports followed agreed-upon procedures, were not audits, and described a single past point in time (CNBC).

Four years on, the gaps are the same:

Any day other than the snapshot. Assets can be borrowed for the snapshot and returned afterwards. Buterin's suggested fix is frequent or coordinated proofs, so two exchanges can't count the same funds.
Fiat. Bank balances can't be proven cryptographically. At best they rest on bank confirmations and an auditor's attestation.
Liabilities outside the tree. Loans, obligations to affiliates or market makers, and anything else that isn't a customer balance won't show up in a customer liabilities tree.
Key security. A wallet can be fully reserved and badly protected. Bybit lost about $1.5 billion in ETH in February 2025, in an attack the FBI attributed to North Korea.
Your own inclusion. If you never check that your balance is in the tree, the proof did nothing for you.

Bitget as a worked example

After the September 24 theft, Bitget covered the losses from its protection fund, which had held 5,500 BTC beforehand. On September 30 it said the fund was back at $309 million. Withdrawals resumed for BTC on September 28, ETH on September 29 and USDT on September 30, with other tokens, fiat and P2P following on October 2 (The Crypto Times).

The 47th report, snapshot at 09:00 UTC on September 29, gave an overall ratio of 131% across 19 assets, down from 135% in the previous report. BTC stood at 142%, ETH at 110%, USDT at 107% and USDC at 154%. In the 24 hours before the snapshot, net outflows came to about $463 million.

So Bitget stayed solvent through a theft of that size and a run of withdrawals, and the report shows it. For how the attackers got in, how fast the fund gets rebuilt, or what the ratio looked like on September 23, you need other sources.

Reserves are one column in the table

A recent comparison of top crypto exchanges for users in Asia scores six platforms on five public checks: trading volume share, regulatory access in Asian markets, proof of reserves and protection funds, base spot fees, and incident record since 2025. I like that reserves and incidents sit side by side there. Bitget's 131% reads differently once you know the exchange had just paid out $387.5 million from its own fund.

If you build for Asia, the regulatory column deserves the same attention, because access changes from one country to the next. The comparison tracks platforms that are licensed in one market, blocked in another and winding down in a third.

I also noticed how the table handles a non-custodial swap service: its reserves column is marked not applicable. That's the right call. A service that doesn't hold user balances has no liabilities tree to publish, and the risk sits in the transfer itself, which is where my last two posts went.

A checklist before you trust a ratio

If you keep a balance on an exchange

[ ] Find the latest report and note the snapshot time as well as the publication date.
[ ] Check your own inclusion with the exchange's proof file or validator.
[ ] Look at the ratio for each asset you actually hold, not only the headline figure.
[ ] Compare the last few reports. A falling trend tells you more than a single number.
[ ] Read the incident history and the size of any protection fund next to the ratio.

If you build on exchange APIs

[ ] Show users when reserves were last proven, with the snapshot date.
[ ] Treat withdrawal pauses as a normal state in your app, with clear messaging.
[ ] Track where each venue is licensed or restricted, per user region.
[ ] Don't present a reserve ratio as a safety rating. It is one input.

FAQ

Does a proof of reserves report mean the exchange was audited?

No. Most reports are attestations or self-published proofs, not financial audits. An audit looks at the whole company: all liabilities, internal controls, related parties and accounting policies. A proof of reserves covers a defined set of customer balances and wallets at one moment. When Mazars paused this work in December 2022, it stressed that its reports followed agreed-upon procedures and did not give an audit opinion. A report backs one specific claim: at the snapshot time, customer balances in scope were matched by on-chain assets.

Why would a reserve ratio be above 100% after a hack?

The ratio compares what the exchange holds with what it owes customers, and both sides move after an incident. If the exchange covers stolen funds from its own capital or a protection fund, customer balances stay whole while the company's own money shrinks. Many users also withdraw after a hack, which lowers liabilities and assets together. Bitget's 131% on September 29 reflected all of that. The incident still cost the company hundreds of millions; the ratio just shows customers were covered at the snapshot.

How can I verify my own balance was included?

Log in to the exchange and open its proof of reserves page, which usually links a per-user proof file for each report. Download the file for the latest report and run it through the verification tool the exchange provides, ideally an open-source one you can inspect. For Merkle tree reports, the tool rebuilds the path from your leaf to the published root. For zk-based reports, it checks the proof against the published commitment. If your balance isn't there, contact support and keep a screenshot of the report date.

Closing thoughts

Most of what an exchange tells you about itself has to be taken on trust. A reserve report is one of the rare exceptions, because you can run the check yourself. I'd still read it next to the snapshot date, your own inclusion proof and the incident history, since the ratio alone covers one moment and one kind of risk.

Do you check your inclusion proof when a new report comes out, or has anyone built that check into an app? I'd like to hear how others handle it.

What Happens After You Press Send on a Bitcoin-to-Monero Swap

Azalea — Tue, 06 Oct 2026 13:40:50 +0000

My last post covered what a transfer flow should do before the user signs. A reader replied with the obvious follow-up: make the settlement state visible before the user thinks the transfer is done. Fair point. Most crypto apps put real effort into the confirmation screen and then hand the user a spinner labeled "Pending".

To show what belongs in place of that spinner, I picked the least convenient everyday case I could find: swapping Bitcoin for Monero. It has two chains with different block times, one leg anyone can inspect and one nobody can, a waiting period after the funds arrive, and a protocol upgrade that is in public testing this week. A status model that copes with this pair has an easy time with a stablecoin transfer.

Key takeaways

"Seen", "confirmed", "spendable" and "final" are separate states. On a BTC to XMR swap the gap between two of them can run from minutes to hours.
A Bitcoin deposit sitting in the mempool is replaceable by default since Bitcoin Core 28.0, so treat it as information and wait for a block.
A Monero payout can't be verified in a block explorer. You need the recipient's wallet, or the transaction ID together with the transaction key and the address.
Ten Monero confirmations make funds spendable, which is a weaker promise than final. In September 2025 an 18-block reorg invalidated 115 transactions.
FCMP++ is still not on Monero mainnet as of October 6, 2026.

Why this pair is a good stress test

You can't send BTC to a Monero address. Bitcoin keys live on the secp256k1 curve and Monero keys on ed25519, the address formats have nothing in common, and neither chain knows the other exists. A standard Monero address packs two public keys and a checksum into 95 characters. Moving value between the two networks always means two separate transactions with something in between, usually a swap service.

TechBullion recently published a step-by-step guide on how to transfer Bitcoin to Monero that describes the flow from the user's chair: create a fresh Monero subaddress, open an order, send BTC to the deposit address, save the order ID, wait. I read it as a list of promises made to the user. The guide quotes 15 to 60 minutes for the swap on the service it uses as an example and about 20 more minutes before the XMR can be spent. It also names four usual reasons for a slow transfer: a low Bitcoin fee, a congested network, a deposit that doesn't match the order amount, or a compliance hold.

Every one of those sentences is a state the backend has to track and the interface has to show. The two legs behave very differently:

	Bitcoin leg (deposit)	Monero leg (payout)
Average block interval	About 10 minutes	About 2 minutes
What an outsider can read	Sender, recipient, amount	That the transaction exists and how many confirmations it has
How a payment is verified	Transaction ID in any explorer or node	Recipient's wallet, or transaction ID + transaction key + address
Before the first confirmation	Replaceable by default (full RBF)	In the pool; the wallet reports a `double_spend_seen` flag
When received funds can be spent	No protocol waiting period	Once the output is 10 blocks old

Model the swap as a state machine

A single "pending" status sends every user to support with the same question. An explicit state machine answers it on the order page and gives your own team a shared vocabulary for incidents.

type SwapState =
  | 'awaiting_deposit'
  | 'deposit_seen'        // BTC tx in the mempool, still replaceable
  | 'deposit_confirming'  // in a block, below your confirmation threshold
  | 'exchanging'
  | 'payout_sent'         // XMR tx broadcast, txid known
  | 'payout_confirming'   // in a block, outputs still locked
  | 'spendable'           // the 10-block lock has passed
  | 'on_hold'             // compliance review, user action required
  | 'refunding'
  | 'refunded'
  | 'expired'

const transitions: Record<SwapState, SwapState[]> = {
  awaiting_deposit:   ['deposit_seen', 'deposit_confirming', 'expired'],
  deposit_seen:       ['deposit_confirming', 'awaiting_deposit'], // replaced or dropped
  deposit_confirming: ['exchanging', 'on_hold', 'refunding', 'deposit_seen'],
  exchanging:         ['payout_sent', 'on_hold', 'refunding'],
  payout_sent:        ['payout_confirming', 'exchanging'],        // never mined, send again
  payout_confirming:  ['spendable', 'payout_sent'],               // reorg
  spendable:          ['payout_confirming'],                      // deep reorg
  on_hold:            ['exchanging', 'refunding'],
  refunding:          ['refunded'],
  refunded:           [],
  expired:            [],
}

export function canMove(from: SwapState, to: SwapState): boolean {
  return transitions[from].includes(to)
}

Look at the arrows that point backwards. Each one stands for a real event: a replaced deposit, a payout that never got mined, a chain reorganization. If your model has no backward transitions, it will report "completed" for money that has just disappeared from the recipient's wallet.

On the Bitcoin leg, seen is not confirmed

The deposit is the public half, so tracking it is mostly a matter of discipline about wording.

A transaction in the mempool tells you the user did something, and nothing is settled yet. Since version 28.0, released in October 2024, Bitcoin Core ships with mempoolfullrbf=1 as the default (release notes). Any unconfirmed transaction can be replaced by one that pays a higher fee, whether or not it signaled replaceability. Show "deposit seen" to calm the user down, and start the swap only after the confirmations you require.

With an Esplora-compatible API the check takes two requests. GET /tx/:txid returns the transaction with a status object, and GET /blocks/tip/height returns the current height (Esplora API).

const ESPLORA = 'https://blockstream.info/api'

type BtcDeposit =
  | { state: 'not_found' }   // never broadcast, dropped or replaced
  | { state: 'mempool' }
  | { state: 'confirmed'; confirmations: number }

export async function btcDepositStatus(txid: string): Promise<BtcDeposit> {
  const res = await fetch(`${ESPLORA}/tx/${txid}`)
  if (res.status === 404) return { state: 'not_found' }
  if (!res.ok) throw new Error(`Esplora responded with ${res.status}`)

  // Also check here that a vout pays your deposit address the expected value
  const { status } = (await res.json()) as {
    status: { confirmed: boolean; block_height: number | null }
  }
  if (!status.confirmed || status.block_height === null) return { state: 'mempool' }

  const tipRes = await fetch(`${ESPLORA}/blocks/tip/height`)
  const tip = Number(await tipRes.text())
  return { state: 'confirmed', confirmations: tip - status.block_height + 1 }
}

Two details matter in the interface. Show progress as "1 of 2 confirmations" so the user can see the order moving. When a transaction you had already seen comes back as not_found, say that the deposit was replaced or dropped and tell the user what to do next. The Bitcoin side tends to be the slowest part of a BTC to XMR order, and a low fee can leave the deposit waiting for several blocks. The deposit screen is the right place to say so, before anything is sent.

On the Monero leg, someone has to tell you

On the payout side the public data runs out. A Monero explorer can confirm that a transaction exists and count its confirmations. The amount and the recipient are hidden by design, so "paste the hash into an explorer" is not an answer you can give a user.

There are two ways to verify a payout.

From the recipient's wallet. The wallet scans the chain with its own keys and lists what arrived. In monero-wallet-rpc, get_transfers with in and pool set to true returns each incoming transfer with confirmations, locked, double_spend_seen and suggested_confirmations_threshold. Amounts come in atomic units, and 1 XMR equals 1e12 of them (wallet RPC docs).

From a payment proof. The sender shares three things: the transaction ID, the destination address and the one-time transaction key. Anyone with a synced wallet can then check how much that transaction paid to that address (Monero user guide). Over RPC the method is check_tx_key:

async function walletRpc<T>(method: string, params: object): Promise<T> {
  // Add digest auth if monero-wallet-rpc runs with --rpc-login
  const res = await fetch('http://127.0.0.1:18088/json_rpc', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: '0', method, params }),
  })
  const body = (await res.json()) as { result?: T; error?: { message: string } }
  if (body.error || body.result === undefined) {
    throw new Error(body.error?.message ?? 'Empty RPC response')
  }
  return body.result
}

const XMR_LOCK_BLOCKS = 10

export async function checkXmrPayout(txid: string, txKey: string, address: string) {
  const r = await walletRpc<{ received: number; in_pool: boolean; confirmations: number }>(
    'check_tx_key',
    { txid, tx_key: txKey, address }
  )

  return {
    // Atomic units. Parse as BigInt in production: values above 2^53 lose precision
    receivedXmr: r.received / 1e12,
    inPool: r.in_pool,
    confirmations: r.confirmations,
    pastDefaultLock: !r.in_pool && r.confirmations >= XMR_LOCK_BLOCKS,
  }
}

If you run the sending side, three habits save a lot of support time:

Request the key when you send (get_tx_key: true in transfer) and store it with the order. The docs warn that rescan_blockchain throws away anything that can't be rebuilt from the chain, and transaction keys are on that list.
Show the XMR transaction ID on the order page and hand out the key on request, so the user can run the check in their own wallet.
Ask users for a fresh subaddress per order and create one per deposit on your own side (create_address). Reconciliation then becomes a lookup by subaddr_index.

One caveat from the same documentation: a valid proof shows that funds were sent to an address. It does not guarantee that they are spendable. The recipient's wallet has the last word, and get_balance reports blocks_to_unlock and time_to_unlock for exactly that purpose.

Seen, confirmed, spendable, final

Status pages tend to use these four words as synonyms. On Monero the last two are the ones that get mixed up.

Spendable is a consensus rule. A Monero transaction can only spend an output that was included at least 10 blocks earlier, which works out to about 20 minutes at one block every two minutes. An honest order page says "Arrived, spendable in about 14 minutes" and counts down.

Final is a judgment call. On September 14, 2025, the Qubic mining pool pushed an 18-block reorganization onto Monero's main chain. Researcher Rucknium's analysis counts 115 invalidated transactions, while 456 others from the orphaned blocks were mined again on the new chain (Rucknium). The coins in the invalidated transactions went back to the senders' wallets. The 10-block lock only protects against reorgs up to 9 blocks deep, so in that hour "10 confirmations" stopped meaning "done". A month earlier Kraken had already reopened XMR deposits with a requirement of 720 confirmations, roughly a day of blocks (FXStreet).

For a developer this leads to three decisions:

Keep the confirmation threshold in configuration, per asset and per amount. The wallet RPC even suggests a number through suggested_confirmations_threshold, which scales with the amount received.
Keep polling after spendable. If a payout disappears, first look for the same transaction ID on the new chain, because most transactions survive a reorg. Create a new payout only once you know the original is gone, otherwise you pay twice.
Check locked and unlock_time on incoming transfers. According to the Monero blog, merchant software has lost money by assuming that received XMR was spendable when a custom unlock time said otherwise.

Check where FCMP++ stands before you plan around it

Several explainers currently online state that Monero's FCMP++ upgrade went live in January 2026. The project's own channels say otherwise.

Here is the status as of October 6, 2026. A beta stressnet release tagged v0.19.0.0-beta.3.0 came out on September 25, with that test network scheduled to fork from testnet on October 5 at block 3,102,800. It is separate from mainnet (TokenPost). The newest mainnet software is 0.18.5.3, published on October 6 as a bug-fix release in the current series (getmonero.org). The last official word on timing, from May 10, was that no FCMP++ fork date had been set (same Monero blog post as above).

FCMP++ replaces ring signatures, where the real input hides among 16 outputs, with a membership proof over the whole set of more than 150 million outputs. CARROT, the addressing upgrade shipping with it, is designed to stay compatible with existing addresses. For anyone maintaining swap or payment code, the practical points are these:

Custom transaction unlock times are being removed at consensus with the fork. A relay rule already rejects new transactions that set one.
The 10-block lock keeps its role. Rucknium's analysis describes a trade-off: the privacy leak that follows a reorg today goes away, but every transaction caught in a reorg deeper than the lock would be invalidated, where at present only some are.
The current stressnet build ships without transaction proofs, multisig and hardware wallet support. If your order page relies on check_tx_key, put that flow on the retest list for the day a mainnet release candidate appears.

Holds and availability are states too

The TechBullion guide makes a point that product teams often leave out of their diagrams: a swap without an account can still involve identity checks. Verification on such services is risk-based. A flagged transfer is put on hold, and the user may be asked for documents before the order continues.

From the user's side an unexplained hold looks exactly like a lost payment. That is why on_hold is a separate state in the model above, with a reason, a next action and a deadline attached. It should never be rendered as a longer "exchanging".

Availability deserves the same treatment. From July 10, 2027, Article 79 of the EU Anti-Money Laundering Regulation prohibits crypto-asset service providers from keeping accounts that allow the anonymisation of transactions, including through anonymity-enhancing coins (EUR-Lex). The text names no specific coins and addresses providers, not people holding XMR in their own wallets. In code, pair availability becomes configuration by jurisdiction with an effective date, and the "not available in your region" answer has to come before a deposit address is shown.

A note on atomic swaps

Swap services are one way to connect the two chains. Atomic swaps are another. Monero has no scripting, so the hashed timelock contracts used elsewhere don't apply. Joël Gugger's 2020 protocol and the COMIT team's follow-up work solve this with adaptor signatures on the Bitcoin side (ePrint 2020/1126, arXiv 2101.12332). The state machine gets longer, with lock, redeem, cancel and refund steps on the Bitcoin side. The observability rules from this post stay the same: the Bitcoin half is public, and the Monero half has to be checked from a wallet.

A checklist for a swap status page

[ ] Every order has an explicit state, and "pending" is not one of them.
[ ] Backward transitions exist for a replaced deposit, an unmined payout and a reorg.
[ ] A mempool sighting is shown as "seen" and never triggers the payout.
[ ] Bitcoin progress is displayed as "n of N confirmations".
[ ] The XMR transaction ID is shown, and the transaction key is stored and available on request.
[ ] "Arrived" and "spendable" are separate, with a countdown for the 10-block lock.
[ ] Confirmation thresholds live in configuration and depend on the amount.
[ ] Polling continues after "spendable", and a vanished payout is looked up again before it is re-sent.
[ ] A hold has its own state with a reason and a next step.
[ ] Pair availability is checked per jurisdiction before the deposit address appears.

FAQ

Why can't I look up my XMR payout in a block explorer?

Monero hides the sender, the recipient and the amount of every transaction. An explorer can tell you that a transaction ID exists and how many confirmations it has, and nothing more. To confirm that a payout reached you, open your own synced wallet, which recognizes incoming outputs with your keys. If nothing shows up, ask the sender for the transaction ID and the transaction key. With those two values and your address, the Prove/Check tool in the Monero GUI, or check_tx_key over RPC, shows how much that transaction paid to you.

Are 10 confirmations final on Monero?

Ten blocks is the point where received outputs become spendable under the consensus rules. Finality is a separate question that each service answers for itself. The 18-block reorganization of September 14, 2025 went deeper than the lock and invalidated 115 transactions that already looked settled. Services reacted by raising their own thresholds, in Kraken's case to 720 confirmations for deposits. If you accept XMR, pick a threshold that fits the amount at risk, keep it configurable and be ready to move an order back a state.

Is FCMP++ live on Monero mainnet?

No. As of October 6, 2026, FCMP++ and CARROT run only on a beta stressnet, whose fork from testnet was scheduled for October 5. Mainnet runs the 0.18 series, and the latest release, 0.18.5.3, is a bug-fix update. The Monero blog stated in May 2026 that no fork date had been set, and I found no later announcement of one. Before changing wallet or payment code for the upgrade, check the blog on getmonero.org and the release notes.

Closing thoughts

A Bitcoin to Monero swap takes away the shortcut of pointing people to an explorer, so the order page has to say what the service knows at each step. I think that discipline is worth keeping for transfers where an explorer link does exist, because most users never open it.

Which states does your product show between "sent" and "done"? I'd like to compare notes in the comments.

Irreversible by Design: Building Safer Crypto Transfer Flows

Azalea — Thu, 01 Oct 2026 16:33:31 +0000

On December 20, 2025, a trader withdrew USDT from Binance and did everything the security guides recommend. They sent a 50 USDT test transfer to their own wallet first. About 26 minutes later they sent the remaining 49,999,950 USDT, and it landed in a scammer's wallet.

The test transfer was the trigger. An automated script spotted it, generated an address with the same first five and last four characters, and pushed a tiny transaction into the victim's history. When the trader came back to send the full amount, they copied the address from that history. The two addresses differed only in the middle characters, the part most wallet UIs hide behind an ellipsis. Within 30 minutes the funds were swapped to DAI, then ETH, then sent through Tornado Cash (The Block).

No bank would let a $50M transfer go through on a lookalike account number without a second check. On a blockchain there is no chargeback and no operator who can roll a confirmed transaction back. The only place to catch the mistake is the interface where the user pastes an address and taps Send, and that interface is something we, as developers, build.

Users notice the difference. A recent overview of where digital money habits are heading in 2026 points out that people now choose a crypto exchange or swap service the way they choose a banking app: they compare fees, KYC requirements and supported assets. The same piece makes a point that matters for anyone shipping a send screen. People look for the platform where a wrong-network or wrong-address transfer is harder to make, and the lowest fee is only part of the decision.

This post walks through four layers of protection you can build into a crypto transfer flow, with code you can adapt:

Validate addresses properly.
Bind every address to a network, memo and tag included.
Defend against address poisoning and clipboard swaps.
Simulate and preview the transaction before the user signs.

Key takeaways

A checksum catches typos, but a poisoned lookalike address passes every checksum.
Most recoverable mistakes are the ones where the user or an exchange still holds the destination key; transfers to a stranger's address are almost always lost.
Wallets like MetaMask and explorers like Etherscan already ship lookalike-address warnings and hide zero-value transfers, so users will expect the same from your app.
eth_simulateV1 lets you show what a transaction will do before it is signed, on Ethereum and a growing list of other chains.

A taxonomy of transfer mistakes

Whether a mistaken transfer can be recovered depends on one question: who controls the private key of the destination address? If it is the user or an exchange, there is often a path back. If it is a stranger, the funds are almost always gone. The table below maps the common mistakes to that question and to the place in your code where each one can be stopped.

Mistake	What actually happens	Recovery odds	Where you stop it
Typo in the address	Funds go to an address nobody controls, or to a stranger	Close to zero	Checksum validation
Address poisoning	User copies a lookalike address from their own history	Close to zero	Full address display, lookalike detection, hiding dust
Clipboard hijacking	Malware swaps the copied address for the attacker's	Close to zero	Showing the pasted address in full, hardware wallet confirmation
Wrong network, own address (EVM to EVM)	Funds sit on the same 0x address on another chain	Usually high, the user adds the network to their wallet	Explicit network selection
Wrong network, exchange address	The exchange received the funds but did not credit them	Depends on the exchange, often a fee and days or weeks of waiting	Deposit addresses bound to asset plus network
Missing memo or destination tag	Funds land in the exchange's shared omnibus account with no owner attached	Usually possible through support	Mandatory memo field, protocol-level flags
Tokens sent to a token contract	Tokens get stuck in a contract that cannot send them out	Close to zero	`eth_getCode` check and a warning

The memo row shows how expensive a single missing input can be. When a deposit arrives without the required memo, Blockchain.com may ask the user to make another minimum deposit of 1 XLM or XRP from the same address, this time with the correct memo, to prove ownership before any funds are returned (Blockchain.com Support). A required field on the send screen would have avoided the whole support ticket.

Layer 1. Validate addresses properly

Format validation is the minimum, and it only protects against typos. A checksum tells you the string was not mistyped. It says nothing about whether the address belongs to the person the user meant to pay, because a poisoned lookalike address is a perfectly valid address with a perfectly valid checksum.

Each chain family handles this differently:

Chain / format	How the checksum works	What it guarantees
Ethereum and EVM chains (EIP-55)	Mixed-case hex: a letter is uppercase if the matching bit of the keccak256 hash is 1	About 15 check bits; a random typo slips through 0.0247% of the time
Bitcoin legacy and P2SH (Base58Check)	Base58 plus 4 bytes of double SHA-256	Typos are almost always caught
Bitcoin SegWit (Bech32) and Taproot (Bech32m)	Lowercase only, no lookalike characters like 1, b, i, o	Detects any error affecting up to 4 characters
Tron	Base58Check with a 0x41 version byte, addresses start with T	Checksum included
Solana	Base58-encoded 32-byte ed25519 public key	No checksum at all

The EIP-55 figures come from the ERC-55 specification. The Solana row deserves a warning in your UI: a typo there can produce another valid address, so format validation tells the user nothing about correctness.

A few rules that save real money:

A regex like ^0x[a-fA-F0-9]{40}$ is not validation. It accepts addresses with a broken checksum.
A mixed-case address with an invalid checksum is an error. Do not silently lowercase it and continue.
Validate the address against the selected network. A Bitcoin address in a BSC field should fail even though the string is valid somewhere.
Check whether the recipient is a contract (eth_getCode returns something other than 0x) and warn before sending tokens to a token contract.

With viem, the EVM part takes a few lines:

import { isAddress, getAddress, createPublicClient, http } from 'viem'
import { mainnet } from 'viem/chains'

const client = createPublicClient({ chain: mainnet, transport: http() })

export async function validateEvmRecipient(input: string) {
  const value = input.trim()

  if (!isAddress(value, { strict: true })) {
    return { ok: false, reason: 'Invalid address or checksum' }
  }

  const address = getAddress(value) // checksummed form to show back to the user
  const code = await client.getCode({ address })
  const isContract = !!code && code !== '0x'

  return { ok: true, address, isContract }
}

For other chains, use the chain's own library: bitcoinjs-lib (address.toOutputScript(addr, network)), TronWeb (isAddress), @solana/web3.js (new PublicKey()) and ripple-address-codec for XRP. Generic multi-coin validators are handy for a first pass, but they check format only and know nothing about the network the user picked.

Layer 2. Bind every address to a network

Hundreds of L2s use the same address format as Ethereum mainnet, so a 0x address on its own no longer tells you which chain it belongs to. Your send flow has to make the network an explicit, visible part of the destination, and for some assets the memo or tag too.

In the interface

Treat the network as a required choice. For large amounts, avoid a preselected default.
Show the network name and icon on the confirmation screen right next to the address, not tucked away in a header.
Ask for the receiving side's network first. The recipient knows which network their platform supports; the sender usually picks whatever is cheapest.
On exchanges and swap services, bind each deposit address to an asset plus network pair.
Use the address format to narrow the choice. T… means Tron, bc1… means Bitcoin, 0x… means some EVM chain, and in that last case you still ask which one.

Memo and destination tags

XRP, XLM, TON, ATOM and EOS deposits to exchanges usually need a memo or tag, because the exchange routes everyone's deposits through one shared address. Make the field mandatory when the recipient is an exchange, and require an explicit "this recipient does not need a memo" confirmation to skip it. Validate the format as well: an XRP destination tag is an unsigned 32-bit integer (0 to 4,294,967,295), and a Stellar text memo is limited to 28 bytes.

Both ledgers also give you protocol-level help:

XRP Ledger. An account can set the RequireDest flag, and the network then rejects payments without a destination tag. Query account_info before sending and enforce the tag in your UI when the flag is set.
Stellar SEP-29. An account can publish a config.memo_required data entry, and wallets are expected to check it before submitting a payment.
XRP X-addresses. They pack the classic address and the tag into one string, so the user cannot forget the tag.

Where the standards are heading

Two Ethereum proposals tackle the network problem at the address level. ERC-7930 defines a binary format that carries the chain type, chain reference and address together, and it covers non-EVM chains too. ERC-7828 adds a human-readable form, <address>@<chain>#<checksum>, so something like alice.eth@base names both the account and the chain. Its optional checksum is meant to help against homoglyph and spoofing attacks. Both are still drafts, so treat them as a direction to watch and keep your own network checks in place.

Layer 3. Defend against address poisoning and clipboard swaps

Address poisoning exploits truncated addresses: users compare the first and last few characters, and the attacker matches exactly those. Nobody can stop a stranger from sending dust to a public address, so the defense lives entirely in the wallet and app UI.

The scale is real. Researchers counted 270 million poisoning attempts and 50 million lookalike addresses on Ethereum and BNB Smart Chain, with about $83.8M in confirmed losses across more than 6,600 cases (arXiv 2501.16681). On Bitcoin, Casa's Jameson Lopp identified 48,000 suspected attacks since 2023 (The Block).

Attackers use three techniques (arXiv 2607.24172):

Zero-value transfers. A transferFrom call for 0 tokens emits a real-looking Transfer event without moving anything.
Dust transfers. A negligible amount of ETH or tokens makes the entry look more legitimate.
Fake-token transfers. An attacker-deployed ERC-20 mimics the amount of the victim's real transaction.

Large players already ship countermeasures, which sets user expectations for everyone else. MetaMask shows a blocking warning when the destination closely resembles an address from the user's history, for example when the first four and last four characters match and the middle differs, plus a separate warning for first-time recipients (MetaMask Support). In September 2026 it expanded those warnings to mobile and the extension and added a feature that reverts transactions that do not match their preview (Decrypt). Etherscan hides zero-value transfers and low-reputation tokens by default, highlights similar addresses and shows more characters of each address (Etherscan).

What to build into your own flow:

Never truncate the address on the confirmation screen. In lists, show at least six characters on each side.
Hide or flag zero-value transfers, dust and transfers of unknown tokens in the transaction history.
Do not offer a one-tap "copy address" on incoming transactions from unknown senders. Point users to the address book instead.
Compare the recipient against history and contacts, and block the send when the edges match but the full address does not.
Warn on the first transfer to any new address, and more loudly for large amounts.
Against clipboard malware, show the pasted address in full and ask the user to check it against the source. For large amounts, confirm on a hardware wallet screen.
After a test transfer, take the address for the main transfer from the address book, never from history. The $50M case shows why.

A minimal lookalike check:

// Flags a recipient that shares its first and last characters
// with a known address but is not the same address
export function findLookalike(
  recipient: string,
  known: string[],
  edge = 4
): string | undefined {
  const norm = (a: string) => a.toLowerCase().replace(/^0x/, '')
  const r = norm(recipient)

  return known.find((k) => {
    const n = norm(k)
    return (
      n !== r &&
      n.slice(0, edge) === r.slice(0, edge) &&
      n.slice(-edge) === r.slice(-edge)
    )
  })
}

// Usage: block the send and show both addresses side by side
const match = findLookalike(input, [...addressBook, ...recentRecipients])
if (match) {
  showBlockingWarning({ entered: input, similarTo: match })
}

In production you would also compare a few more characters (attackers generate vanity addresses with longer matching edges as they get cheaper to compute) and highlight the differing middle part in the warning.

Layer 4. Simulate and preview before signing

The confirmation screen is the last moment a mistake can be caught, so it should describe what will happen on-chain rather than echo what the user typed. Transaction simulation gives you that description.

Two RPC methods do most of the work:

eth_call answers "will this succeed?". If the call reverts, the real transaction would revert with the same reason.
eth_simulateV1 runs one transaction or a chain of them (approve plus swap, for example) on top of a block's state, supports state overrides and transfer tracing, and returns logs you can decode into a human-readable diff of balance changes (Chainstack Docs).

Support goes beyond Ethereum mainnet. RPC providers expose eth_simulateV1 on chains like Arbitrum and Monad, and java-tron has a pull request implementing a base version specifically so wallets can show users token movements before they sign (GitHub).

import { JsonRpcProvider, Interface, parseUnits } from 'ethers'

const provider = new JsonRpcProvider(process.env.RPC_URL)
const erc20 = new Interface(['function transfer(address to, uint256 amount)'])

export async function previewTokenTransfer(
  from: string,
  token: string,
  to: string,
  amount: string,
  decimals: number
) {
  const data = erc20.encodeFunctionData('transfer', [to, parseUnits(amount, decimals)])

  const [block] = await provider.send('eth_simulateV1', [
    {
      blockStateCalls: [{ calls: [{ from, to: token, data }] }],
      traceTransfers: true,
      validation: false,
    },
    'latest',
  ])

  const call = block.calls[0]
  return {
    willSucceed: call.status === '0x1',
    gasUsed: BigInt(call.gasUsed),
    logs: call.logs, // decode Transfer events into a "you send / they receive" summary
  }
}

Note the decimals parameter. USDT and USDC on EVM chains usually use 6 decimals while most ERC-20 tokens use 18, so read decimals() from the contract instead of hardcoding a table.

What the confirmation screen should show

The full recipient address in checksummed form, with the address book label if there is one.
The network name and icon, next to the address.
The memo or tag, or a clear note that none is set when the recipient is an exchange.
The amount in tokens and in fiat, the network fee and the final "you send / they receive" figures from the simulation.
Warnings for a first-time recipient, a lookalike address, a contract address, or an amount far above the user's usual transfers.

Extra safeguards worth adding

A built-in test transfer flow: send a small amount, save the address, then send the rest to the saved entry.
Withdrawal allowlists with a waiting period before a newly added address becomes usable, a pattern many exchanges already use.
For ENS and other names, show the resolved address, normalize names per ENSIP-15 to block homoglyphs, and resolve the name again right before signing.

A checklist for your next send screen

Copy this into your next PR description or design review:

[ ] Addresses are validated with the chain's checksum, not a regex.
[ ] Invalid mixed-case EVM addresses are rejected, not lowercased.
[ ] The address is validated against the selected network.
[ ] Solana recipients get an extra "double-check this address" prompt, since the format has no checksum.
[ ] Contract recipients trigger a warning (eth_getCode).
[ ] Network selection is explicit and shown next to the address on the confirmation screen.
[ ] Memo or tag is mandatory for exchange deposits on XRP, XLM, TON, ATOM and EOS; RequireDest and SEP-29 are checked.
[ ] Zero-value, dust and unknown-token transfers are hidden or flagged in history.
[ ] Lookalike recipients are blocked with both addresses shown in full.
[ ] First-time recipients and unusually large amounts trigger a warning.
[ ] The transaction is simulated, and the confirmation screen shows the resulting balance changes.
[ ] Token amounts use decimals() from the contract.

FAQ

Does a test transaction protect users from address poisoning?

On its own, no, and it can make things worse. Poisoning bots watch for small outgoing transfers and respond within minutes with a lookalike address that lands in the sender's history. In the December 2025 case, the attack followed a 50 USDT test transfer. A test transaction protects against typos and wrong-network mistakes. To protect against poisoning, the address for the main transfer has to come from a saved contact or the original source, never from the transaction history. If your app offers a test-transfer flow, save the address after the test and reuse that saved entry for the full amount.

Can funds sent on the wrong network be recovered?

It depends on who holds the key to the destination address. If a user sent tokens to their own 0x address on a different EVM chain, they can usually add that network to their wallet and access the funds. If the destination was an exchange deposit address, only the exchange can help, and the outcome depends on its policy: some recover deposits for a fee and after days or weeks, some cannot. Funds sent to a stranger's address on any network are almost always lost. That is why network selection belongs in the UI before the transaction, not in the support queue after it.

Is checksum validation enough to stop mistakes?

No. A checksum catches accidental typos, and for EIP-55 a random typo passes the check only about 0.0247% of the time. Address poisoning and clipboard malware use real, valid addresses that the attacker controls, so they pass every checksum. Validation is the first of several layers. You still need network binding, lookalike detection against the user's history and contacts, a full-address confirmation screen and, ideally, a simulation of what the transaction will do.

Closing thoughts

Users already judge crypto platforms by fees, verification and supported assets, and safety at the moment of sending is part of that comparison. Every layer in this post is a few dozen lines of code or a single design decision. Put together, they turn "transactions are irreversible" from a disclaimer into a constraint your send flow is built around.

What does your team do on the send screen that is not on this list? Share it in the comments.

What Changed in Crypto Product Design in 2026?

Azalea — Wed, 23 Sep 2026 14:48:18 +0000

Crypto apps are becoming easier to use because more blockchain complexity is moving out of the interface.

Users still interact with wallets, networks and transactions, but the product increasingly handles the technical steps behind them. A broader overview of what changed for everyday crypto app users in 2026 points to the same shift across authentication, custody and payments.

Key Takeaways

Passkeys and embedded wallets simplify onboarding.
Smart accounts can combine several blockchain actions into one flow.
Gas sponsorship reduces the need to manage network tokens manually.
Chain abstraction hides some multichain complexity.
Stablecoins are being integrated into familiar payment flows.

Passkeys Are Changing Onboarding

Crypto onboarding has often required passwords, email verification and separate wallet setup.

Passkeys offer a simpler authentication flow based on public-key cryptography. Users can authenticate with a device PIN, fingerprint or face recognition instead of entering a password. Google documents passkeys as a phishing-resistant alternative to traditional password login.

Embedded wallets take this further by putting wallet functionality inside the application. A user can create or access an onchain wallet without starting with a separate wallet installation and connection flow.

For developers, authentication and wallet creation are becoming part of the same product experience.

Smart Accounts Reduce Manual Steps

Traditional Ethereum wallets expose many blockchain operations directly to the user.

Smart account infrastructure allows developers to combine transactions, sponsor gas and introduce more flexible permissions.

A flow that previously required several approvals can sometimes become a single user action. The underlying transactions still happen, but the interface can present the whole operation as one task.

This makes the application responsible for more of the transaction flow.

Gas Can Move Into the Background

Users should not need to understand gas mechanics just to complete a basic action.

Account abstraction supports sponsored transactions, allowing an application or another party to cover transaction costs in supported flows. EIP-7702 also introduces mechanisms for sponsored execution.

The fee still exists. The product can decide how it is handled and presented instead of forcing every user to maintain a balance of the network's native token.

Chain Switching Is Becoming Less Visible

Multichain products add another layer of friction. An asset can be available on one network while the user needs it on another.

Chain abstraction and intent-based systems aim to hide some of this complexity. Instead of selecting networks, managing bridges and handling routing manually, users can express the outcome they want while the infrastructure handles execution.

For developers, this means designing around the user's goal rather than exposing every blockchain step.

Stablecoin Payments Look More Like Fintech

Stablecoins are increasingly being integrated into payment products rather than presented as a separate crypto experience.

Stripe, for example, is expanding infrastructure around stablecoin payments, payouts and cards. The customer-facing flow can remain familiar while blockchain settlement happens underneath.

A payment interface does not need to expose every wallet, network and settlement detail to the customer.

Compliance Is Part of the Product

Regulation also affects product design.

Jurisdiction, identity verification, asset availability and transaction limits can change what a user is allowed to do. Those requirements appear directly in onboarding and transaction flows.

Developers therefore have to account for compliance when designing the product itself, not only during backend implementation.

The Design Problem Has Changed

Crypto products are moving toward a simple model:

User chooses the outcome.
The product handles more of the mechanics.

Passkeys handle authentication. Embedded wallets reduce onboarding friction. Smart accounts handle more complex transactions. Sponsored gas removes one manual step. Chain abstraction hides network differences. Stablecoin infrastructure can make blockchain payments look like ordinary fintech.

The challenge for developers is deciding what to hide and what users still need to see before they approve an action.

The blockchain can stay in the backend without making the product feel opaque.

Your Crypto Wallet Is Not Your Account: Understanding What the App Actually Controls

Azalea — Mon, 21 Sep 2026 23:23:13 +0000

A crypto wallet can look a lot like a regular banking app. You open it, see a balance, copy an address, and press Send.

But your wallet app is not your blockchain account, and your crypto is not literally stored inside the app.

Understanding this difference makes crypto much easier to reason about – especially when something goes wrong.

The wallet is the interface

On Ethereum, an account is an on-chain entity that can hold ETH and tokens and interact with smart contracts. An externally owned account (EOA) is controlled by private keys.

The wallet app is the software you use to interact with that account.

It can:

show your balance by reading blockchain data;
create transactions;
ask you to approve an action;
sign transactions;
broadcast them to the network.

The assets themselves remain recorded on the blockchain. Ethereum's documentation puts it simply: users don't store the cryptocurrency inside the wallet – they control the keys that allow them to act on the account.

So deleting a wallet app does not automatically delete your crypto.

Then what actually gives you control?

For a typical self-custodial wallet, the important pieces are the Secret Recovery Phrase and the private keys.

A recovery phrase can be used to restore the wallet and generate its accounts. Each account has its own private key, which is used to control that particular account.

That's why your wallet password is not the same thing as ownership of the assets.

For example, in MetaMask, a password can unlock the wallet on a device, while the Secret Recovery Phrase is what allows the wallet to be restored.

A useful mental model is:

Wallet app → interface
Account → blockchain identity
Private key → authorization
Blockchain → asset state

Self-custody changes the model

This is also why a self-custody wallet feels different from an exchange account.

With a self-custody wallet, you control the private keys. With a custodial exchange, the platform manages the keys and processes transactions on your behalf.

That creates a very different recovery model.

Forgot your exchange password? There may be a standard account recovery process.

Lost the credentials that control a self-custodial wallet? There may be no company that can simply reset access for you. MetaMask explicitly warns that it cannot recover a wallet when the required recovery credentials are lost.

What happens when you press Send?

The wallet does not physically move coins from one app to another.

Instead, it prepares a transaction and asks you to authorize it. For a traditional Ethereum account, the transaction is signed with the account's private key and then submitted to the network.

The blockchain processes that transaction and updates its state.

This is why crypto security is about more than protecting an app password. The bigger question is:

What exactly are you authorizing with your wallet?

A wallet may be just the interface, but the signature you approve can change what happens to your assets.

One more complication: smart wallets

The private-key model is not the only approach anymore.

Ethereum also supports contract-based accounts, where authorization can be defined by smart-contract code rather than a single traditional private key. This is part of the broader account abstraction model.

So the statement “your wallet is your private key” is useful as a beginner's shortcut, but it is no longer a complete description of every modern wallet.

The simplest way to think about it is this:

Your wallet is the tool you use to access and authorize actions. Your account is the identity on the blockchain. The blockchain records the assets and transactions.

Once these pieces are separated, crypto wallets become much less mysterious – and the security risks become much easier to understand.