How to Read a Transaction Before You Sign It

Two of the largest losses in our Incident Tracker share a mechanism, and it is not the one people expect. Nobody guessed a key. The signers were shown one transaction and approved a different one.

This guide is about the gap between what a website says a transaction will do and what the transaction actually does — and about which screen resolves that disagreement.

Why the gap exists

When you interact with a web application that wants a transaction signed, several things are happening at once. The page constructs a transaction. Your wallet receives it. Your wallet — or a connected hardware device — displays some representation of it. You approve.

The description you read on the page is written by the page. It is marketing copy for the transaction. It is not derived from the transaction, and nothing forces the two to agree.

In the Bybit incident, the reported failure was exactly this: a routine transfer where the payload that executed differed from what the signing interface displayed. Approximately US$1.5 billion moved, according to the FBI’s own announcement. Multiple signers approved. Each was shown the same misrepresentation, so having several of them added nothing.

The hierarchy of screens

Not all displays deserve equal trust. In descending order:

1. A hardware wallet’s own screen. This is generated by the device from the transaction it has actually been asked to sign. It is the hardest thing in the chain for a compromised web page to influence — which is the entire reason the device has a screen at all.
2. Your wallet software’s confirmation dialog. Better than the page, but it runs on the same machine and, in the case of a browser extension, in an environment the page shares.
3. The web page’s description. Useful for understanding intent. Worthless as verification.

The Ledger Connect Kit compromise makes the point precisely. Malicious code was injected into a library loaded by many dapps, and it presented users with a draining transaction. Users who read the device screen before approving could see a transfer they had not asked for. Users who confirmed from the page description could not.

What to actually look at

On the device screen, for a transfer:

• The destination address — the whole thing, not the first and last four characters. Address-poisoning attacks work specifically by producing addresses whose ends match one you have used before.
• The amount and the asset. Confirm both, including the decimal position.
• The network. The right transaction on the wrong chain is still a loss.

For a contract interaction:

• The function being called, where the device can decode it. An unexpected approve, setApprovalForAll or permit when you believed you were staking or claiming is the signal to stop.
• The spender or operator address in an approval, which is the address you are authorising — not the contract you think you are using.
• Blind signing warnings. If the device says it cannot decode what it is being asked to sign, that is information, not an obstacle.

Out-of-band confirmation

For anything consequential, confirm the destination through a channel that is not the one proposing the transaction. If a page supplies an address, and the same page confirms the address is correct, you have verified nothing. This is the organisational version of the same control: the reason large-transfer procedures require confirmation by a separate route is that a single compromised channel can be internally consistent.

What this does not protect you from

• An approval you already granted. Reading transactions carefully from today does nothing about a standing allowance from last year. See checking your approvals.
• A compromised recovery phrase. No amount of care at signing time helps if someone else can reconstruct the account.
• A protocol that is itself broken. A perfectly legitimate transaction into a vulnerable contract is still exposed to that vulnerability. Most incidents in our tracker involve users who signed exactly what they intended.
• Fatigue. This is the real limit. Nobody reads the hundredth routine approval with the care they gave the first, and attacks are designed around that.

The honest summary

Reading what you sign is the single control that would have prevented several of the losses we log, and it is also genuinely difficult to sustain. Treat it as proportionate: routine small interactions do not need ceremony, and any transaction whose loss would matter to you deserves the device screen, the full address, and a pause.