What to Check Before Signing a Wallet Transaction
A safety-oriented guide to reviewing recipient addresses, spending limits, chain selection and transaction simulations.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
Every signature is a decision made in an interface you did not design, describing something you cannot fully see. The practical goal is not to eliminate risk — it is to build a short, repeatable pass that runs before your attention has left the flow. There are five checks, and each of them answers a different question. Doing them in order takes under a minute once you have done it more than a few times.
1. What action is this, in plain words?
Name it for yourself before you look at anything else. “Swap” is not an action; “sending 0.5 token B for token C through the Uniswap v3 router on Ethereum” is. Interfaces routinely label a transaction with the user-facing outcome and omit the mechanical step that produces it, and that mechanical step is where the risk lives. If you cannot restate the action including the contract being called, you do not have enough information to sign, and the right move is to close the dialog and open the transaction details yourself rather than continue.
2. Is the recipient address the one you intended?
Address truncation is a deliberate feature and it defeats confirmation: the middle of a hex address is where two independently generated addresses will differ, and that is exactly the section the interface hides. Compare the first four and last four characters at minimum, and paste your source of truth rather than reading it off the screen you are verifying.
For a new recipient, this is the step that matters most — reused addresses are the low-risk case, and transfers to an address you have never sent to are where address-poisoning attacks operate. Those attacks seed your history with an address visually similar to one you have used, hoping you select it from an autocomplete list. If the address came from a list rather than from your own records, go and get it from your records.
3. Is the network what you think it is?
A transfer on the wrong chain is usually recoverable only through a third party, and bridges built to “recover” them are frequently the second scam in the sequence. The network indicator is small, sits in a different corner from the confirm button, and changes between visits — a site you used last week on one chain may default to another. Read it every time; do not let familiarity substitute for reading.
4. What is the value leaving your account?
Confirm the outgoing amount, the fee and the resulting balance. Gas estimation is where this hides: a transaction that appears cheap can carry a fee high enough to consume a meaningful share of a small balance, and a “set to zero” balance after execution is a known and avoidable outcome. If the remaining balance matters to you, check that the interface has not spent it on priority fees you did not ask for.
5. What does the simulation say — and did you read it?
Wallets increasingly simulate transactions before you sign and surface warnings about transfers to known-suspicious addresses, unlimited approvals, or changes that contradict the intended outcome. Simulation is genuinely useful and it is not a guarantee: it models the current state and a specific execution path, and a hostile contract can behave differently along paths the simulator does not enumerate.
The value of a warning is entirely in your reaction to it. A warning you dismiss without reading is worse than no warning, because it converts a signal into a habit. Read what the flagged item actually is before proceeding.
When simulation fails or the interface fights you
If a call is unfamiliar, the simulation is unavailable, or the interface is actively discouraging inspection — obfuscated buttons, a modified confirmation screen, a request to disable wallet security, a request to enter a seed phrase — the correct action is to abandon the flow regardless of how the transaction is labelled. Legitimate interfaces do not need you to stop verifying them.
Sign, then verify
The transaction is not finished when you sign. Record the hash and confirm it on a block explorer: confirm the status succeeded, confirm the recipient and value match what you reviewed, and confirm no additional transfer appeared that you did not authorise. That last check is what catches an approval that was bundled into the same transaction. Doing it closes the loop, and it is the difference between “I believed what I saw” and “I confirmed what happened” — which is the distinction that matters after something goes wrong.