Wallet UX That Prevents Loss: Simulation, Warnings and Recovery

Most user losses in self-custody do not come from broken cryptography. They come from signing something the user did not understand, approving a contract that should never have been trusted, or losing access to keys with no way back. A wallet's job is to make each of those outcomes hard. This post covers the four areas where wallet engineering has the largest effect on loss prevention: transaction simulation, allowance hygiene, phishing heuristics and recovery.

Simulate before you sign

A signing prompt that shows a hex calldata blob is a decision the user cannot make. Simulation runs the transaction against the current chain state before it is signed and presents the outcome in terms the user recognises: which tokens leave the wallet, which arrive, which approvals change and which contracts are touched. Users are far more likely to stop when a prompt says "this will send all of your tokens to an unknown address" than when they see a function selector.

Implementing simulation well has some engineering rules. Run it against a node you control or a provider with a clear consistency guarantee, because stale state can produce a misleading result. Diff balances and allowances before and after, not just the top-level transfer, since malicious contracts route value through internal calls. Treat a failed simulation as a warning, not a block; some legitimate transactions depend on state that changes in the same block. And show the user when simulation was unavailable rather than silently skipping it.

Message signing needs the same care

Off-chain signatures are now a common attack vector: typed-data permits that grant token allowances, marketplace listings at a zero price, and intent signatures that authorise a solver to move assets. Decode typed data into the same human-readable format as transactions. If a message is opaque, say so explicitly and require an extra confirmation step.

Allowance hygiene

Token approvals outlive the transactions that needed them. An unlimited allowance granted to a contract a year ago remains a standing authorisation for that contract, or anyone who compromises it, to drain the token. Wallets can reduce this exposure through defaults and visibility:

• Default to exact-amount approvals and require an explicit choice for unlimited.
• Show existing allowances per token with the spender's identity and last use, and make revocation a one-tap action.
• Flag when a transaction grants an allowance to an address that is not the contract the user is interacting with.
• Warn when a spender contract is upgradeable or was deployed very recently.

These features are cheap to build and they change behaviour, because they turn an invisible risk into something the user can see and act on.

Phishing heuristics

Wallets sit at the point where phishing succeeds or fails. No single heuristic catches everything, and each one produces false positives, so the design goal is layered signals with proportionate friction.

1. Domain reputation: block lists and allow lists for dApp origins, with recent-registration and look-alike detection.
2. Address heuristics: destinations that share leading and trailing characters with a recently used address, addresses with no history, and addresses that appear in known drainer patterns.
3. Contract heuristics: unverified source, proxies whose implementation changed recently, and approval targets that are externally owned accounts rather than contracts.
4. Behavioural context: a first interaction with a site that immediately requests a broad permit is more suspicious than the same request from a site the user has used for months.

Severity should map to friction. A low-confidence signal earns an inline note; a high-confidence match earns an interstitial that requires the user to type a confirmation. Never silently block, because users who cannot understand why a transaction fails will move to a wallet with fewer protections.

type RiskSignal = { code: string; severity: 'info' | 'warn' | 'block'; detail: string };

export function assessDestination(to: string, ctx: WalletContext): RiskSignal[] {
  const signals: RiskSignal[] = [];
  const twin = ctx.recentAddresses.find((a) => looksAlike(a, to) && a !== to);
  if (twin) {
    signals.push({ code: 'address-lookalike', severity: 'warn', detail: `Resembles ${short(twin)}` });
  }
  if (!ctx.knownContracts.has(to) && ctx.tx.grantsApproval) {
    signals.push({ code: 'approval-to-unknown', severity: 'block', detail: 'Approval to an unrecognised spender' });
  }
  return signals;
}

Recovery that does not reintroduce a custodian

A seed phrase is a single secret with no recovery path, and for mainstream users that model fails constantly. Two families of designs address this without handing keys to an operator.

Social recovery, usually built on smart accounts, lets a user designate guardians (other devices, trusted people, or a service) who can collectively authorise a key rotation after a delay. The delay is the security control: a legitimate owner can cancel a recovery they did not initiate. Guardian sets need to be changeable, and the wallet must make it obvious when a recovery is pending.

MPC-based recovery splits the key into shares, typically one on the device, one with a recovery service and one backed up to cloud storage or a second device, with a threshold of two. The user can lose any one share and still recover, and the service alone cannot sign. The design questions are about share refresh, what authenticates a user to the recovery service, and how to prevent the recovery flow itself from being phished.

Measuring the right thing

Wallet teams tend to measure conversion through signing prompts, which rewards removing warnings. Add counter-metrics: the share of transactions where a warning was shown and the user declined, allowances revoked, and recoveries completed. Loss prevention is not visible in a funnel, but the absence of loss is the product, and the wallets that earn long-term trust are the ones that occasionally talk a user out of a transaction.