How to Check a Transaction Before Signing

First: not every signature is a transaction

Fact: wallets produce two materially different things. A transaction is submitted to the network, costs a fee, and changes state. A message signature is produced off-chain, usually costs nothing, and is handed to whoever asked for it.

Off-chain signatures are not harmless. A typed-data signature — the format used for structured requests such as token permits and trading orders — can authorise a later on-chain action by someone else. Because no funds move at the moment you sign, and often no fee is charged, the prompt feels lighter than it is.

Absence of an amount in a prompt does not mean nothing of value is being granted. Read the request type first.

Clear signing versus blind signing

Blind signing means approving a request whose contents you cannot meaningfully read. The data a wallet receives is machine-readable calldata: a function selector and a list of encoded values. It is accurate and complete, but it is written for software — an amount may appear as a raw integer with no decimal point or ticker, and an address carries no name.

Wallets bridge that gap by decoding, but only when they recognise the contract. When the protocol is new, the interface has been tampered with, or a hardware device has no reference for the call, the reader is back to hex — and historically that final confirmation step is where several major losses were completed, according to the Ethereum Foundation.

Clear signing is the effort to make that last step readable: 'what you see is what you sign'. Instead of a selector and integers, the wallet shows a sentence describing the action, with amounts formatted and the protocol named.

Fact, with a limitation: clear signing improves interpretability. It does not make the underlying action safe. A perfectly readable request can still be a request you should decline.

ERC-7730, briefly — and why support varies

ERC-7730 is an Ethereum standard that defines a JSON 'descriptor' format. A protocol publishes a descriptor describing how its function calls and typed messages should be presented to a person, and a wallet that supports the standard uses it to render a readable prompt instead of raw data. The Ethereum Foundation's Trillion Dollar Security initiative helps steward an open registry of these descriptors.

That is all you need as a signer. Two practical consequences: a readable prompt usually means the wallet had a descriptor or its own decoding for that contract, and an unreadable prompt often means it simply had neither — not that the request is malicious.

• Support is not universal. Wallet adoption and descriptor coverage both vary, and many contracts have no descriptor at all.
• Coverage can change between wallets and between versions, so do not assume a readable prompt in one wallet means readable prompts everywhere.
• Readability is not approval. Understanding a request is the precondition for deciding, not the decision.

The pre-signing checklist

Work through whichever items apply to the prompt in front of you. Wallets present these differently, and some fields only appear for some request types.

1. Context — did you initiate this? An unexpected prompt, or one that appears after a page reload or a redirect, is reason enough to reject.
2. Domain — is the site the one you reached through your own bookmark? Compare the domain shown inside the wallet prompt with the one you intended.
3. Network — is the chain the one you meant? A correct-looking address on the wrong network is a routine, unrecoverable mistake.
4. Request type — transaction, approval, or off-chain signature? Establish this before reading anything else.
5. Destination — for a transfer, compare the full address against the recipient's own deposit screen, including characters in the middle, not just the ends.
6. Asset and amount — the exact token, and the exact quantity, including decimals. Confirm the token by contract address if there is any doubt about which one it is.
7. Contract — for an interaction, does the contract address match the application's published address? Unknown or freshly deployed contracts deserve more scepticism.
8. Spender and scope — for an approval, who is being permitted to move your tokens, and how much? Set a specific amount instead of an unlimited allowance whenever the interface allows.
9. Decoded details and simulation — where your wallet shows a decoded action or a preview of balance changes, read it. An outcome that does not match your intention is decisive.
10. Warnings — treat any wallet or explorer warning about the domain, contract or address as a stop, not a speed bump.
11. Hardware device screen — if you use one, read the device itself. Anything a compromised computer shows can differ from what the device is actually being asked to sign.
12. Unhurried decision — if any field is unclear, reject. Rejecting costs nothing; the request can always be made again once you understand it.

Approval scope, in practice

An approval is a standing permission. You are not sending tokens — you are recording on-chain that a particular spender may move up to a certain amount of a particular token from your address, at any time, until you change it.

Unlimited approvals exist because they save fees on repeat use. The trade-off is that the permission outlives the session, the interface and often your memory of granting it. If the spender contract is later compromised, the allowance is what gets used.

• Prefer a specific amount matching the transaction you are actually doing.
• Treat approvals as inventory: review what your address has granted, and revoke what you no longer use.
• An approval to a contract is a permission granted to whoever controls that contract now and in the future.
• Revoking is itself an on-chain transaction with a fee, and it applies per token, per spender, per network.

Wallet security alerts and simulation: useful, not authoritative

Depending on the wallet and the version, you may be shown some combination of the following: trust or reputation signals about a site, phishing warnings on known-bad domains, warnings about a contract or destination address, a simulation previewing expected balance changes, and specific warnings on signature requests such as unlimited approvals or permits.

These are worth having switched on. They catch a real share of ordinary attacks with no effort from you.

Operator claim, not verified fact: vendors describe their own coverage, and accuracy differs between products and releases. A simulation models an expected outcome under current conditions — state can change between preview and execution, and some contract behaviour depends on the caller or the block.

• A missing warning does NOT prove that an interaction is safe. Warning lists are reactive; a domain or contract that nobody has reported yet is simply unreported.
• A warning should not be dismissed because the site looks familiar. Familiarity is what a cloned interface is built to produce, and legitimate front ends do get compromised.
• No wallet vendor is infallible. Treat these features as one input alongside the checklist above, never as the check itself.
• If a simulation shows an outcome that does not match what you intended, that mismatch decides the matter on its own.

Reduce what a single mistake can cost

• Keep long-term holdings in an address that never interacts with applications.
• Use a separate, low-balance address for unfamiliar sites and new tokens.
• Send a small test transfer to any new destination before the full amount.
• Close extra tabs and pop-ups before signing, so you know which page produced the prompt.
• Refuse to sign while rushed, annoyed or pressured — that state is exactly what the attack is designed to produce.

Editorial guidance: this checklist reduces one category of loss. It does not guarantee safety, and a well-built attack can produce a prompt that passes every visible check.

Sources

• Ethereum documentation — transactions
• EIP-712: typed structured data hashing and signing
• EIP-2612: permit — signed approvals for ERC-20
• ERC-7730: structured data clear signing format
• Ethereum Foundation — Clear Signing announcement
• ethereum.org — add clear signing to your protocol with ERC-7730