DEV Community: Azalea

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.

What a Crypto App Should Do Before You Press “Send”

Azalea — Tue, 15 Sep 2026 17:22:35 +0000

A crypto transfer can look almost trivial on a phone.

Choose an asset. Enter an address. Type an amount. Press Send.

The blockchain sees something very different.

On Ethereum, a transaction is a signed instruction that can contain a recipient address, value, nonce, gas parameters and input data. Once signed and broadcast, it enters the transaction pool and waits for a validator to include it in a block. Eventually, the block can become finalized.

The interesting part is that the blockchain cannot tell whether the user meant to send the funds to that particular address.

That decision happens before the transaction reaches the network.

This makes the wallet interface more than a convenient way to access a blockchain. It is one of the last places where a human can catch a mistake.

The address is not enough

Wallet addresses are not exactly designed for humans.

An Ethereum address is a hexadecimal string. Copying one from a previous transaction is easier than trying to read it character by character. That convenience creates an opportunity for attackers.

A technique known as address poisoning exploits this behavior.

An attacker creates an address that looks similar to one the victim has used before and sends a transaction designed to make the malicious address appear in the victim's transaction history. If the victim later copies the wrong address from that history, the funds go somewhere else.

A 2025 study that measured address poisoning on Ethereum and BSC over two years identified 270 million attack attempts targeting 17 million victims. The researchers linked 6,633 incidents to at least $83.8 million in losses.

That's a useful reminder that "the user entered the wrong address" is not always a user problem.

Sometimes the interface has made the wrong address too easy to trust.

A wallet should make the recipient difficult to misread.

That can mean showing a recognizable name when one is available, making the beginning and end of the address easy to compare, supporting verified address books, and warning users when a destination looks suspicious or has not been used before.

The final confirmation screen should also show the actual destination, not just a shortened label.

The network should be impossible to miss

"Send USDT" is not enough information.

The asset and the network are separate pieces of information, and the same token can exist across multiple networks.

A useful confirmation screen should therefore make the combination explicit:

500 USDT
Ethereum
To: 0x71...92F4

That seems like a small interface decision, but it removes an entire category of ambiguity.

The same principle applies to mobile apps. A smaller screen creates pressure to hide information behind menus, but transaction confirmation is probably the wrong place to optimize for minimalism.

For a practical look at how mobile crypto apps combine wallet access, transfers, QR codes and transaction management, the ChangeNOW guide to mobile crypto app features is a useful reference.

The goal isn't to show every technical detail.

It is to show the details that can change the outcome.

Show what the transaction will actually cost

Fees are another part of the transaction that should not be left for the user to decode.

On Ethereum, gas measures the computational work required to execute a transaction. A simple ETH transfer requires 21,000 units of gas, while interactions with smart contracts can require considerably more.

The fee also isn't just an arbitrary number produced by the wallet.

Ethereum's fee model includes a base fee and a priority fee. The amount a user ultimately pays depends on gas used and the applicable fee parameters.

A good interface should translate that into something a person can understand:

Sending: 1 ETH
Network fee: 0.00025 ETH
Total deducted: 1.00025 ETH

The user shouldn't have to understand maxFeePerGas before sending money.

That's the wallet's job.

"What am I signing?" is a better question

There is another problem that becomes more important once a wallet does more than simple transfers.

A transaction doesn't necessarily mean:

Send this amount to this person.

It can also mean:

Interact with this smart contract.

Ethereum documentation distinguishes ordinary transfers from transactions that execute deployed smart contracts. In the latter case, the to address can belong to a contract, while the transaction's input data determines what the contract is asked to do.

That changes the UX problem.

Showing a contract address and a button labeled Sign doesn't tell most users much.

For a swap, approval, DeFi interaction or other contract call, the wallet should explain the intended effect in human-readable terms whenever it can.

For example:

You are authorizing:
Swap 500 USDC for ETH

Estimated result:
≈ 0.18 ETH

Network fee:
≈ $1.40

Contract:
Verified contract name, if available

That is much more useful than presenting a wall of hexadecimal data.

Simulation is useful, but it isn't magic

Transaction simulation is becoming an important part of wallet security.

Instead of asking the user to sign first and find out what happened later, a wallet can simulate the transaction and estimate the expected balance changes or contract effects before broadcasting it.

That is a significant improvement in the user experience.

But simulation shouldn't be treated as a guarantee.

A 2026 study of transaction simulation phishing found more than 4,000 phishing contracts deployed between August 2024 and June 2025. The researchers identified more than 5,700 victims and approximately $3.48 million in losses, with 91.5% of those losses occurring on Ethereum.

The problem is subtle.

Some malicious contracts can behave differently during simulation and actual execution because their behavior depends on changing blockchain state. A simulation can therefore show a benign result while the eventual transaction behaves differently.

So the lesson isn't that simulation doesn't work.

It's that one security signal shouldn't become the entire security model.

Simulation is one layer. Address checks, contract reputation, readable signing information and user confirmation are other layers.

Warnings need to tell the user what to do

A red warning isn't automatically a useful warning.

Compare these two messages:

⚠️ Suspicious transaction

and:

⚠️ This is the first time you've sent funds to this address. Verify the full address before continuing.

The second one gives the user a decision to make.

That's important because security warnings often appear at exactly the moment when the user wants to finish the task. If the warning is vague, people are more likely to treat it as another piece of interface noise.

Research on wallet usability shows that this is still a real problem.

A 2025 study evaluated 53 popular Ethereum wallets specifically in the context of address poisoning. The researchers found that 16 wallets created a high risk by displaying fake token phishing transfers, while only three wallets displayed an explicit warning when users attempted to transfer funds to a phishing address.

That doesn't mean those three wallets are universally safe or that the other wallets are universally insecure.

It does show how much room there is for improvement in the way wallets communicate transaction risk.

The confirmation screen is a security feature

The best confirmation screen doesn't need to expose every blockchain parameter.

It needs to answer the questions a user actually has before signing:

What am I sending?

500 USDC

Which network?

Ethereum

Where is it going?

Alice
0x71...92F4

What will it cost?

Estimated network fee: $2.14

What am I authorizing?

Transfer / swap / approval / contract interaction

Did the wallet detect anything unusual?

First-time recipient / suspicious contract / simulation result

Then comes the final action:

Review and Sign

This is a better model than treating confirmation as the last visual step before a button click.

It is a checkpoint.

Good crypto UX should slow you down at the right moment

Most of the time, a wallet should feel fast.

You shouldn't need three screens to send funds to an address you've verified dozens of times.

But when something changes – a new address, a different network, an unusual contract interaction or a potentially risky approval – the interface should become more deliberate.

That's where good crypto UX differs from simply making transactions faster.

The objective isn't to remove friction everywhere.

It is to remove unnecessary friction while keeping the friction that helps a user catch an expensive mistake.

A blockchain will execute a valid signed transaction because the signature is valid. It doesn't know what the user intended to do.

The wallet sits between those two worlds.

That makes the Send screen one of the most important security surfaces in a crypto application.

The best crypto app isn't necessarily the one that gets you from balance to transaction hash in the fewest taps.

It's the one that gives you a good reason to pause before the tap that actually matters.

AI Agents Can Make Payments. The Hard Part Is Proving They Should.

Azalea — Mon, 14 Sep 2026 15:58:13 +0000

AI agents are moving beyond answering questions and recommending products. They can already search for items, compare options, interact with merchants and, in some cases, complete purchases on a user's behalf.

That creates a problem payment systems were not originally designed for: how does a merchant know that an AI agent is actually authorized to make a particular payment?

This is becoming an infrastructure problem, not just an AI problem.

In September 2026, Ant International, Mastercard and Visa announced that they had started working on a shared Know Your Agent (KYA) interoperability framework. The goal is to help payment networks, wallets, agent platforms and marketplaces identify and verify AI agents while allowing each participant to maintain its own risk and approval processes.

The interesting part is not the name KYA. It is the trust layer that has to sit between an AI agent and a financial transaction.

The payment flow is changing

A conventional online purchase is relatively straightforward:

User → Merchant → Payment Provider → Bank/Card Network

An agentic transaction adds another layer:

User → AI Agent → Merchant → Payment Infrastructure

The agent may be acting on the user's behalf, but the merchant still needs to understand what that authority actually means.

Suppose a user tells an agent:

Find a laptop under $1,500 with at least 16GB of RAM and buy it if you find a suitable one.

The agent has to search, compare products, choose an option and potentially complete the purchase without asking the user to approve every step.

The payment system needs more than an answer to “Is this a real agent?”

It needs to know who authorized it, what it was authorized to do and whether the final transaction stays within those limits.

Identity is only the first layer

Visa, Mastercard and Ant International already have technologies aimed at different parts of this problem.

Visa's Trusted Agent Protocol is designed to help merchants verify AI agents and establish the context of their requests.

Mastercard has been developing Verifiable Intent, which focuses on verifying that an agent's action corresponds to an instruction authorized by the user.

Ant International has developed its own Agentic Mobile Protocol for transactions involving digital wallets.

The new KYA initiative is therefore not simply about creating another payment method. It is about making different agent ecosystems work together.

That interoperability could become important for developers. If every payment network, wallet and marketplace uses a different system for agent identity and authorization, developers could end up maintaining another fragmented set of integrations.

A common set of trust signals could reduce that complexity while allowing individual networks to keep their own risk controls.

Authentication does not mean authorization

This is where the architecture gets more interesting.

Imagine an agent is successfully authenticated. The payment system knows which agent it is and who operates it.

That still does not answer the most important question:

What is the agent actually allowed to do?

A useful way to think about the problem is to separate four layers:

Agent Identity
      ↓
User Authorization
      ↓
Transaction Intent
      ↓
Execution + Monitoring

Each layer answers a different question.

Identity: Who is this agent?

Authorization: Which user or organization delegated authority to it?

Intent: What action was the agent authorized to perform?

Execution: Did the final transaction stay within those limits?

This separation matters because a legitimate agent can still make an unauthorized transaction.

For example, an agent might have permission to spend up to $1,500 but attempt to complete a $1,900 purchase after the final price changes.

The identity check would pass. The authorization check should not.

Spending permissions may become part of the API

For developers, this could eventually mean that an AI agent's payment credentials look less like a traditional card number and more like a set of constrained permissions.

Conceptually:

Agent: shopping-agent-42
User: verified-user
Maximum transaction: $1,500
Allowed category: Electronics
Allowed merchants: Approved merchants
Expiration: 24 hours
Additional approval: Required above limit

The exact implementation will vary by payment network, and the KYA framework is still being developed. There is no universal schema that developers can simply implement today.

But the underlying design problem is already clear.

Agents need enough authority to be useful without receiving unrestricted access to a user's money.

The same problem is appearing elsewhere

This is not limited to Visa and Mastercard.

India's National Payments Corporation is reportedly developing a registry for AI agents that will make transactions through UPI. The initial focus is on frequent, relatively small payments, with more complex use cases potentially coming later.

The direction is becoming clear: once an AI system can initiate financial transactions without a user manually approving every step, agent identity and delegated authority become part of payment infrastructure.

That also changes the security model.

A compromised card is one problem. A compromised agent with permission to make hundreds of transactions could be a very different one.

What happens when the agent gets it wrong?

This may be the hardest part of the problem.

Authentication and authorization can be implemented as technical mechanisms. Liability is harder.

Imagine an agent follows a user's instruction but misunderstands the product. Or a merchant's page contains content designed to manipulate the agent. Or the agent makes a purchase after its authorization should have expired.

Who is responsible?

The user?

The agent provider?

The merchant?

The payment network?

The answer will influence how these systems are designed.

There are other open questions too: how quickly permissions can be revoked, how transactions are audited, what information merchants actually need to see and how privacy is maintained when several systems exchange identity and authorization data.

These issues become more serious when agents operate at machine speed.

A human might notice a suspicious purchase after one transaction. An automated system could repeat the same mistake many times before anyone intervenes.

The next payment layer may be a trust layer

Payment infrastructure is starting to account for an actor that is neither a traditional customer nor simply a machine.

An AI agent represents a person or business, interprets their instructions and takes actions on their behalf.

Payment systems therefore need to establish more than whether a transaction is technically valid.

They need to establish whether the agent had the right to make it.

That is why KYA is worth watching. The framework is still being developed, and there is no universal standard yet. But the direction is clear: agent identity, authorization, intent, permissions and auditability are becoming part of the conversation as AI moves from recommending actions to executing them.

The difficult part of agentic payments may not be teaching AI how to transact.

It may be building systems that can prove when it should.

MiCA After July 2026: What Actually Changes for Crypto Users and Developers

Azalea — Thu, 10 Sep 2026 15:26:35 +0000

MiCA After July 2026: What Actually Changes for Crypto Users and Developers

For a long time, MiCA was something crypto companies talked about as a future compliance problem.

That future has arrived.

The EU's Markets in Crypto-Assets Regulation has been fully applicable since December 2024, but 2026 was an important transition point for crypto-asset service providers. By July 1, 2026, the transitional period for firms operating under previous national regimes had ended at EU level. After that date, a provider offering crypto-asset services in the EU generally needs to operate under the MiCA framework or another applicable legal basis.

For developers, this changes the way compliance fits into a crypto product. It is no longer something that can sit entirely with the legal team. In many cases, regulatory requirements eventually become product requirements, database fields, API checks and user flows.

And for users, those changes are much more visible than the regulation itself.

MiCA is more than a licensing framework

MiCA creates a harmonised EU framework for crypto-assets and the companies that issue them or provide related services. It covers areas including crypto-asset service providers, stablecoins, disclosure, market conduct and consumer protection.

A developer does not need to read hundreds of pages of regulation to understand the practical idea.

If a platform is doing something with crypto on behalf of its users, the first question is increasingly:

What exactly is the service, and under which regulatory framework is it allowed to operate?

That question affects exchanges, custodians, brokers, wallet-related services and other crypto businesses.

It also affects how products are designed.

Consider a simple withdrawal flow.

Before regulatory requirements become product requirements, the flow might look like:

User → Enter address → Confirm → Transaction sent

In a regulated environment, the actual flow can be more complicated:

User
↓
Enter destination
↓
Compliance checks
↓
Additional information if required
↓
Risk decision
↓
Transaction processing

The blockchain transaction itself has not changed.

The surrounding software has.

July 1, 2026 changed the practical landscape

The end of the transition period is one of the most relevant dates for anyone building or using a crypto service in the EU.

ESMA stated that the transitional period would expire across the EU on July 1, 2026. After that point, firms providing crypto-asset services without the required authorisation can no longer rely on the old transitional arrangements.

That does not mean every crypto company suddenly disappeared on July 1.

It means the legal basis for providing regulated crypto services became much clearer.

For product teams, that creates a fairly practical task: the service needs to know where it is allowed to operate, what authorisation covers it, and what happens when a user falls outside the supported regulatory scope.

This is where regulation starts looking less like a legal document and more like system architecture.

What does this mean for crypto users?

The biggest change for an ordinary user is not likely to be a message saying "MiCA compliance enabled."

It is more likely to be another verification step.

A platform may ask for additional information during onboarding. A transaction may require an additional compliance check. A withdrawal to a self-hosted wallet may involve questions that did not appear in the same form before.

These processes are not all caused by MiCA alone. Crypto businesses also operate under broader AML/CFT and transfer-of-funds requirements.

But from a user's perspective, they can appear in the same place: the interface.

That is why understanding the practical side of MiCA is often more useful than simply knowing what the acronym stands for. A practical overview of the regulation, its licensing framework, stablecoin rules and the way compliance can affect users is available in this guide to MiCA.

The important part is not that users should expect every transaction to trigger a check.

They should understand why a regulated platform may sometimes need more information before processing one.

Self-custody is a different case

One of the easiest things to misunderstand about European crypto regulation is self-custody.

If you hold the private keys to your wallet, that does not automatically turn your wallet into a regulated crypto service.

MiCA is primarily concerned with regulated activities and intermediaries. A user controlling their own assets is different from a company holding or transferring crypto-assets on behalf of clients.

This distinction becomes especially important when designing wallet products.

A developer building a non-custodial wallet is not necessarily building the same regulatory product as a company providing custody.

The interface may look similar.

The legal responsibilities can be very different.

There is also another layer to consider: a self-hosted wallet does not make compliance obligations disappear when it interacts with a regulated service. A user may still encounter additional checks when moving assets between a regulated provider and a self-hosted address, depending on the transaction and the applicable AML/transfer-of-funds requirements.

So "self-custody" should not be treated as a synonym for "outside regulation."

Stablecoins have their own regulatory logic

MiCA also treats stablecoins differently from many other crypto-assets.

The framework distinguishes between asset-referenced tokens and e-money tokens, with specific requirements around issuance, governance, reserves and information provided to users. The European Commission describes these requirements as part of MiCA's prudential and consumer-protection framework.

This matters technically because stablecoins are increasingly used as infrastructure rather than simply as trading assets.

They can sit inside:

payment flows
treasury systems
exchange infrastructure
settlement systems
trading applications
automated financial workflows

When an asset becomes part of infrastructure, its regulatory status becomes an engineering concern too.

For example, a payment application may need to know whether a particular token can be offered to EU users, whether the relevant issuer meets the applicable requirements, and what restrictions apply to the service built around it.

The smart contract does not answer those questions.

The product architecture has to.

Compliance becomes an engineering problem

This is probably the most interesting consequence of MiCA for developers.

Regulatory requirements eventually become software.

A legal requirement can turn into:

if provider_is_authorized:
allow_service()
else:
restrict_service()

A reporting obligation can become an event pipeline.

A customer verification requirement can become an onboarding state machine.

A risk-control requirement can become a transaction screening service.

An audit requirement can become structured logs that cannot simply be deleted after the transaction is complete.

None of this means developers should try to translate legislation into code by themselves.

It means engineering teams increasingly need to understand the assumptions behind the systems they are building.

A compliance rule that arrives at the end of development is expensive.

A compliance requirement considered during architecture is usually much easier to handle.

How should developers think about a MiCA-ready product?

I would start with four questions.

1. What service are we actually providing?

"Crypto platform" is too vague.

Are you providing custody? Exchange? Execution? Transfers? Advice? Something else?

The answer determines which regulatory questions matter.

2. Who is the user?

Geography is not just a marketing parameter anymore.

If the product is available to EU users, the team needs to understand whether the service falls within MiCA or another regulatory framework.

3. Where does compliance happen?

If the answer is "somewhere in the backend," that is probably not enough.

Developers should know which API, service or workflow makes the relevant decision and what happens when the decision is negative or inconclusive.

4. Can the system explain what happened?

This is easy to overlook.

A compliance system that simply returns true or false may not be enough for a real production environment. Teams may need an auditable record of which checks were performed, when they were performed and what information was used.

That is where good engineering practices become particularly valuable.

MiCA is not finished yet

There is another reason not to treat MiCA as a completely finished rulebook.

The European Commission is currently reviewing the regulation and is consulting stakeholders on whether MiCA remains fit for purpose in light of implementation experience and developments in crypto markets and policy. The Commission's targeted consultation is open until September 30, 2026.

So the regulatory environment is still evolving.

That is not necessarily a bad thing.

Crypto infrastructure is changing quickly, and regulation built around an earlier version of the market will inevitably need to be tested against new products, stablecoins, tokenisation models and financial applications.

For developers, this means one thing above all: avoid building compliance assumptions too deeply into the product.

Make them configurable where possible.

Keep regulatory logic separate from core transaction logic.

Document why a particular restriction exists.

And make it possible to update the system when the rules change.

The practical takeaway

MiCA is often discussed as a question of licences and regulation.

For developers, the more interesting question is what happens after the licence is obtained.

The real work moves into product design.

Who can access the service?
Which assets can be offered?
When is additional verification required?
How are transactions screened?
What information has to be stored?
How can the system demonstrate what happened?

Those are software questions as much as legal ones.

And that may be the biggest shift MiCA brings to European crypto infrastructure: compliance is becoming part of the product itself, rather than something that happens around the product.

Claude in Fintech: 5 Workflows Where AI Agents Can Actually Save Time

Azalea — Wed, 09 Sep 2026 17:12:06 +0000

Financial teams have plenty of work that looks small on paper and takes hours in practice.

A compliance analyst may need to review a customer file, collect information from several documents, check transactions, prepare a case summary, and then pass everything to another person for review. The same pattern appears in financial research, fraud investigations and reporting.

This is where AI agents are becoming more interesting than a basic chatbot.

Anthropic has introduced financial-services agents that can work across multi-step tasks, use external tools and data, and keep a human involved before an important action is taken. The company has also announced integrations with financial data providers and examples involving KYC, fraud, financial research, modelling and AML investigations.

Here are five workflows where that approach can reduce manual work.

1. KYC and customer due diligence

KYC is a natural candidate for workflow automation because the work often starts with documents and ends with a reviewable case.

Anthropic lists KYC screening among its financial-services agent templates. The workflow can involve building an entity file, reviewing source documents and preparing an escalation package for a compliance professional.

The interesting part is what happens between those steps.

An agent can work through the available material and organize the relevant information before a compliance analyst makes the final call. That leaves the person with a prepared case instead of a collection of documents that still needs to be sorted manually.

There is a concrete example from Parcha. According to Anthropic, the company used Claude for customer due diligence and reduced one workflow from three months to five minutes.

That figure comes from a specific customer case, so it should not be treated as a general benchmark for KYC teams. Still, it shows why document-heavy compliance work is being considered for agentic systems.

2. Fraud investigation

Fraud detection is another area where the investigation itself can involve a lot of repetitive work.

A suspicious case may require looking at transaction information, documents and other risk signals before an analyst can understand what happened. An AI agent can help assemble that context and produce a case summary for review.

Inscribe is one example cited by Anthropic. The company uses Claude for fraud detection, document verification, risk analysis and KYC/KYB checks. Anthropic reports that the time required for a fraud review went from 30 minutes to 90 seconds in the cited case.

In another customer example, Inscribe reported a 70-fold increase in processing output.

Again, these are company-specific results rather than an industry-wide measurement. They are useful mainly because they show the type of work being delegated to an AI system: collecting and assessing information around a fraud case, rather than simply generating a piece of text.

That distinction matters.

A fraud analyst still needs to understand the evidence and decide what should happen to the case. The agent can take care of part of the preparation.

3. Financial research

Financial research presents a slightly different problem.

The difficult part is often not writing the final report. It is getting the right information first.

Anthropic has connected Claude with financial research and data platforms including FactSet, S&P Capital IQ, MSCI, PitchBook, Morningstar, LSEG and Daloopa. Other connectors include Dun & Bradstreet, Fiscal AI and Financial Modeling Prep.

A research workflow can therefore look something like this:

Research question → financial data → analysis → draft report → analyst review

The model does not need to rely entirely on information already inside the model. It can work with external sources provided through the available tools.

This also connects with research from the Bank for International Settlements. BIS has discussed the use of generative AI in economic analysis, financial supervision and payment oversight, and has pointed to retrieval-augmented generation (RAG) as one way to improve the reliability of outputs by connecting models with verified and specialized information.

Cabe destacar one practical point here: source access does not remove the need to check the result. It changes where some of the manual work happens.

Instead of searching through several systems and then starting the analysis from scratch, an analyst can review the material assembled by the workflow.

4. Financial models and reporting

Spreadsheets are another place where AI assistance can fit into an existing financial workflow.

Anthropic says Claude can work with Excel, PowerPoint and Word through Microsoft 365 add-ins. Context can also move between applications. For example, work started in a financial model can continue when preparing a presentation.

Citadel is one of the examples Anthropic gives. Its investment professionals use Claude for Excel to create and update coverage models, separate signal from noise and pressure-test their work.

The useful part here is not simply asking an AI to “analyze an Excel file.”

A more practical workflow is closer to:

Financial model → analysis → scenario work → checks → summary → presentation

Some of those steps are repetitive. Others require financial judgment.

The division between them is important. A model can help with the preparation and analysis while the professional remains responsible for the financial interpretation.

5. AML and compliance investigations

AML investigations combine several of the problems found in the other workflows: large amounts of information, repeated checks and a need to document what happened.

Anthropic says FIS is working with the company on an agent intended to reduce AML investigations from days to minutes. The companies are also working on agents for areas including credit decisioning, fraud prevention and deposit retention.

The proposed workflow is fairly straightforward:

Alert → gather relevant information → review transactions and context → organize evidence → prepare the case → compliance review

The last step should not be overlooked.

Financial institutions operate in an environment where decisions can have regulatory and customer consequences. An agent preparing an investigation is a different proposition from an agent independently deciding what happens to an account.

That is one reason human review remains part of the financial-services agent model described by Anthropic.

Where should the human stay in the workflow?

This is probably the most important part of the discussion.

The Financial Stability Board has identified several risks associated with AI in financial services, including model risk, data quality, cyber risk, third-party dependencies and concentration around service providers.

The FSB has also noted that generative AI in financial institutions has so far been used heavily for operational efficiency.

That suggests a practical way to think about agentic AI in finance.

For a lower-risk task, an agent might prepare a draft that someone checks.

For an investigation, it might gather evidence and organize the case before a specialist makes the decision.

For a consequential financial or compliance decision, the level of human oversight needs to be much higher.

The Office of the Comptroller of the Currency, together with the Federal Reserve and FDIC, issued revised model risk management guidance in 2026. The guidance emphasizes areas such as validation, monitoring, governance, access controls, data management and auditability. It also notes that generative and agentic AI are developing quickly and are not directly within the scope of that particular guidance.

So the regulatory picture is still developing.

What makes a good fintech AI workflow?

Looking at these examples, a pattern appears.

The strongest candidates for agentic workflows tend to involve:

repetitive manual steps;
large amounts of financial or documentary information;
several tools or data sources;
outputs that can be reviewed;
a clear point where a human takes responsibility.

That does not mean every financial process should become autonomous.

Quite the opposite. For regulated work, knowing where the agent stops can be just as important as knowing what it can do.

The practical takeaway

Claude's financial-services use cases are mostly interesting when they are treated as workflows rather than isolated AI features.

KYC can involve document review and case preparation. Fraud teams can use AI to speed up investigations. Researchers can connect Claude with financial data providers. Analysts can work with financial models and reporting tools. AML teams can use agents to prepare investigation material.

The common thread is fairly simple: the agent handles part of the work around a decision, while the professional remains responsible for the decision itself.

For fintech teams, that may be a more useful starting point than asking whether AI can replace an entire role.

Sometimes saving time means removing the five steps nobody wanted to do manually in the first place.