Usually the assets are gone. A confirmed on-chain transaction is final, there is no issuer to reverse it, and nobody can compel the recipient to return anything. The exceptions are narrow: a custodian on both ends, a known counterparty willing to cooperate, or a wrong-network send where the same key controls the destination. Prevention is the only reliable control.
Part of our guide: Family Office.
The short version
- Settlement is final by design. No chargeback, no reversal, no central party with the authority to undo it.
- The realistic recoveries all involve a cooperating human or institution, never the protocol.
- Wrong network is often recoverable; wrong address usually is not. The distinction decides everything.
- A test transaction costs a fee and a few minutes and prevents the entire category.
- For an entity, this is a governance question: address verification and dual approval belong in the operating agreement or a written policy.
Why finality is the point
Irreversibility is a feature people chose deliberately. A network nobody can compel is also a network in which nobody can compel a refund. There is no issuer to call, no scheme rules, and no arbitration process, because the design removed the party who would have run one.
That is worth internalizing before it matters, because the instinct on discovering an error is to look for someone to appeal to. On-chain, for a self-custodied transfer to a valid address you do not control, there is nobody.
When recovery is actually possible
Both ends are custodial. If you sent from one exchange or custodian to another, and the receiving address belongs to a customer of a regulated institution, there is a party who can be contacted, who has know-your-customer records, and who may have a process. Not a guarantee, and it is a real path.
The recipient is identifiable and cooperative. A mistyped address that happens to belong to a counterparty you know, or an address whose owner can be reached, sometimes ends well. This depends entirely on goodwill.
Wrong network, same key. Sending an asset over the wrong chain to an address you control is frequently recoverable, because the destination is yours. The assets sit on a chain you did not intend to use and the same private key controls them. Recovery may need a wallet that supports that chain or, on a custodial platform, a support process that sometimes carries a fee.
Wrong token to a contract. Sometimes recoverable if the contract has an owner with a recovery function. Usually not.
Everything else is a loss.
What does not work
Reporting it to the network. There is no such body.
A blockchain “reversal” service. Anybody promising to reverse a confirmed transaction for a fee is describing something that does not exist. This is a well-worn second scam that targets people who have just lost money.
Sending a follow-up transaction to the same address with a message asking for return. Occasionally an identified recipient responds. Usually it adds a loss to a loss.
The prevention that actually works
Test transactions. Send a small amount, confirm receipt, then send the balance. It costs a network fee and a few minutes and it eliminates the entire category. Every serious operator does this and nobody who has skipped it and lost a transfer skips it again.
Whitelisted addresses. Most custodians allow a list of approved destinations with a time delay on additions. Adding an address once, verifying it once, and reusing it removes the per-transaction risk.
Verify the whole string, not the ends. Address-swapping malware substitutes a clipboard address that matches on the first and last characters, because those are what people check. Read the middle, or compare against a saved entry rather than reading at all.
Dual approval above a threshold. A second person checks the destination on any material transfer. This is the same control a multi-sig policy provides for authorization, applied to accuracy.
Confirm the network before the address. Most wrong-network sends come from an interface where the chain selector was set for a previous transaction.
What I actually see
The losses cluster around interruptions and urgency. Someone is doing a routine transfer, gets interrupted, resumes from memory, and pastes an address from the wrong place. The technical sophistication of the person is close to irrelevant, and the presence of a written procedure is the thing that predicts outcomes.
For entities the failure is more specific: no written policy at all. Transfers happen because the person who normally does transfers does them, with no verification step anyone else can observe. The company discovers it had no control only after the control would have helped.
The habit worth building is the boring one. Test transaction on any new destination, always, regardless of amount or how confident anyone is. It is the cheapest insurance available in this field and it is free.
Where this goes wrong
The single-point-of-failure version: one person, working alone, moving material amounts, with no verification anyone else sees and no test transaction.
The other specific failures: a whitelist that was populated in a hurry and never verified, so the wrong address is now the approved one. An address copied from an email, which is where address-substitution attacks land. A chain selector left on a previous setting. And, after the loss, a recovery service that takes a second payment.
For a company there is an additional consequence. A material loss from an unverified transfer, with no written procedure in place, is exactly the kind of fact a manager would rather not explain against a duty of care measured by what a reasonable person in that role would do.
The decision rule
- Test transaction on every new destination. No exceptions for amount or confidence.
- Whitelist destinations where the custodian supports it, with a delay on additions.
- Verify the middle of the address, or compare against a stored entry.
- Confirm the network first, then the address.
- Require a second approver above a stated threshold, written into policy.
- Write it down so the procedure survives the person who normally does transfers.
If a transfer has already gone wrong: establish whether the destination is custodial, whether it is a wrong-network send to an address you control, and whether the recipient is identifiable. If none of those, it is a loss, and no service can change that.
Where this sits
This is the operational edge of custody. Who may authorize a transfer is the governance question; this is the accuracy question, and they need separate controls. Custody for an entity determines whether a custodian’s whitelist and approval tooling is available to you at all. Records are what let a company reconstruct what happened.
Most custody thinking is about theft. A meaningful share of real losses are self-inflicted and preventable by a procedure that takes two minutes.
Sources
- CISA, Multi-factor authentication guidance
- FBI, Internet Crime Complaint Center
- FTC, Cryptocurrency scam guidance
- NIST, Special Publication 800-57, Recommendation for key management
- IRS, Digital assets
- CFTC, Digital assets
Related
- Should a crypto LLC have a multi-sig policy?
- Crypto custody for LLCs
- What is a qualified crypto custodian?
- What records should a crypto LLC keep?
- Private key succession planning
- Crypto custody
Last updated: 3 August 2026.
This article is general education, not legal, tax, or investment advice. Operational controls can reduce certain risks but do not eliminate them. Talk to a qualified professional about your own situation.
