Wallet Transaction Signing Checklist: Seven Checks Before You Approve
A practical checklist for reviewing the site, network, action, recipient, token approval, fee and transaction simulation before signing.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
A wallet signature is the point where an intention becomes irreversible. Everything before the prompt — the article you read, the interface you clicked, the tab you had open — is still reversible in the sense that nothing has moved. Everything after it is on-chain and final. Ethereum.org states the consequence plainly: a transaction sent on Ethereum is irreversible, and unless you can identify the address owner and convince them to send your funds back, you will not be able to retrieve them.
That is why the signing moment deserves a fixed routine rather than a fast judgement. Seven checks, in order, take under a minute. The purpose of each one is to catch a specific class of mistake, not to feel thorough.
1. The domain you are actually on
Begin with where you are, not with what you are signing. Phishing does not need a clever payload; a cloned front end that asks for exactly the same signature is enough. The mechanism that makes this cheap is link preview spoofing, where the displayed link text shows a legitimate domain while the click resolves to an attacker’s site.
Read the host from the address bar yourself. Do not infer it from the logo, the page design, or the fact that the page loaded correctly. If you arrived from a link in a message, this check is the entire defence.
2. The network
Every signature is scoped to one chain, and the same address on Ethereum mainnet and on a sidechain holds different balances under different rules. A network mismatch is easy to miss because the interface may look identical while the prompt shows an unfamiliar chain name.
Confirm that the network named in the prompt matches the network you intended to use. If it does not, stop. This is the check that most often catches a legitimate-looking session that has quietly been pointed elsewhere.
3. The action being requested
Read the method, not the branding. Approve, Permit, Set Approval For All, Swap, Deposit, and Transfer are different actions with different consequences, and front ends present them in interfaces designed to look uniform.
The distinction that catches the most people is approval versus transfer. An approval grants a contract permission to move your tokens later and moves nothing now; a transfer moves them immediately. If the prompt is an approval, the exposure is forward-looking and the amount on screen is a ceiling rather than a payment.
4. The recipient and the spender
For a transfer, the recipient address must match the intended recipient exactly. Read it in full rather than comparing the first and last four characters, which is the abbreviated form most familiar addresses on a screen you trust.
For an approval, the spender is the contract that receives the permission. Confirm it against an address you obtained independently, not one displayed inside the page requesting the signature.
5. The token approval scope
If the action involves a token approval, three numbers matter: which token, which spender, and what limit. An unlimited allowance means the contract may move your entire balance of that token for as long as the approval stands, so ethereum.org’s guidance to set spend limits to only the amount necessary applies directly.
Approvals are also per-network. Revoking the one on mainnet does nothing to the same permission granted on an L2, and wallets frequently display both if you have connected to both.
6. The fee
Fee structure on Ethereum is two components: a protocol-set base fee that must be paid for the transaction to be valid, and a priority fee you choose as a tip to validators. The total is units of gas used multiplied by base fee plus priority fee, and unused gas is refunded.
Three failure modes are worth checking. A max fee too low may leave the transaction unconfirmed for a long time or dropped entirely. A priority fee far above what the current network demands is a measurable overpayment. And a gas limit too small for a complex contract interaction fails during validation with no gas consumed, while running out of gas mid-execution reverts the changes but still consumes the gas provided — so the outcome of a bad limit is not symmetric.
7. The simulation result, when your wallet offers one
If the wallet provides a transaction simulation, read it rather than dismissing it. Simulation tells you the state change the transaction intends to produce: which balances move, which contract is called, whether the outcome reverts. It is not a guarantee, and a simulation can be wrong about off-chain effects, but it is the closest thing to a preview that signing gives you.
For an approval, confirm that the simulation does not include a transfer. An approval that only writes an allowance should not also be moving funds.
Record the transaction while you still remember it
The check that determines whether you can respond to an incident is the one you do immediately. Note the hash, the chain, the spender or recipient, the amount, and the timestamp, in a place that is not the wallet itself.
If something does look wrong later, a transaction record lets you name the hash, the chain and the counterparty without guessing. Without one, you are reconstructing a session from memory at exactly the moment you have the least time to do it.
Related reading
- How to review token approval risks before connecting a wallet
- How to review wallet permissions after using a dapp
- How to use a block explorer as a transaction receipt