How to Read a Transaction Before You Sign It

Every loss that involves a user clicking something ends at the same screen: a confirmation prompt that was approved without being understood. It is the last checkpoint, and for most people it is a formality — a dialogue to dismiss on the way to the thing they wanted to do.

Learning to read it takes about ten minutes and closes the largest remaining gap in most people's security. Here is what the fields mean and what the dangerous shapes look like.

The four questions a prompt should answer

• What am I sending, and how much — including whether the amount is capped or unlimited.
• Who receives it, or which contract gains permission over it.
• What will my balances look like afterwards, which is the only summary that matters.
• Which network is this on, because the same address on the wrong chain is a different destination.

If the interface cannot answer all four, that is not a reason to proceed carefully. It is a reason to use a different wallet, because the information exists and some wallets simply choose to show it.

Simulation is the feature that matters

The most useful development in wallets over the past few years is transaction simulation: the wallet runs the transaction against current chain state and shows the resulting balance changes before you sign. Instead of interpreting calldata, you read a plain summary — this leaves, that arrives.

A malicious transaction is usually obvious in that view even when it is opaque in the raw data, because the outcome is the thing being hidden. Wallets differ sharply here, which is why our self-custody wallet table weights signing clarity above every other axis.

What a normal transaction looks like

A simple transfer names a recipient, an amount and a fee, and nothing else. A swap shows one token leaving, another arriving, and usually a minimum received figure reflecting your slippage tolerance. A deposit into a protocol shows tokens leaving and a receipt token arriving.

In every case the shape should match what you asked for. If you clicked "swap 100 USDC for ETH" and the summary shows a different token leaving, or an approval rather than a swap, stop — the mismatch is the signal, and it does not need further interpretation.

What the dangerous ones look like

• An approval when you expected a swap, particularly for an unlimited amount.
• A signature request with no gas and no clear summary — often a gasless permit granting spending rights.
• Any prompt where the amount reads as unlimited, maximum, or an implausibly large number.
• A recipient address that does not match anything you recognise, on a transfer you initiated.
• A simulation the wallet cannot produce, which sometimes indicates the transaction is designed to behave differently when executed.

Verify on the device, not in the browser

February 2025 settled this argument. Attackers compromised a developer machine at Safe{Wallet} and served tampered JavaScript that showed Bybit's signers a routine transfer while altering the underlying transaction. Roughly $1.5bn left. The contracts were fine; the display lied.

The conclusion generalises to anyone with a hardware wallet: the screen on the device is produced by firmware the website cannot touch, and the screen in your browser is not. For anything that matters, read the device. That is the reason it has a screen, and the reason our hardware wallet table scores display quality and clear-signing support so heavily.

Addresses and networks: the two boring checks

Check the first and last four characters of a recipient address, and one group in the middle. Clipboard-hijacking malware swaps a copied address for the attacker's, and the swapped one is chosen to match at the ends, which is exactly where people look.

Then check the network. The same address exists on every EVM chain and is controlled by the same key, but tokens are chain-specific: sending a token on the wrong network usually means it is recoverable only by someone who controls that address on that chain — which may be an exchange that will not help you. Wallets that switch networks automatically for a given site remove most of this risk, which is one reason our self-custody wallet table credits it.

Batched transactions and what they hide

Some interfaces bundle several actions into one signature — approve and swap, or claim and stake. That is convenient and it means one confirmation now authorises several distinct things, only one of which you may have read.

With simulation, the bundle is still legible because you see the net effect. Without it, a batch is the easiest place to hide an extra step, and the honest advice is not to sign one from a site you have not used before.

A habit that costs fifteen seconds

Before every signature, ask what you expect to happen, then check that the summary says the same thing. Where they disagree, cancel — you can always retry, and a cancelled legitimate transaction costs nothing but a moment.

Attackers rely on the gap between intent and attention, and the gap is widest when you are rushed, tired, or excited about a mint that closes in four minutes. That is not incidental. It is the design.

If you want a single rule that survives every new attack pattern: never sign anything whose outcome you could not describe out loud to somebody else. The wording matters — not "I know what this site is", but "I know what leaves my wallet and what arrives". Everything in this article is a way of getting to that sentence before the signature rather than after it.