How to read a signature request before you sign

Three kinds of request

• Message. A plain text message proves that you control an address. A normal sign-in request names the site, the address, a nonce and a timestamp. By itself it cannot transfer tokens.
• Typed data. Structured data, standardised by EIP-712, shows named fields such as owner, spender, value and deadline. This is how permit signatures work.
• Transaction. An on-chain instruction that spends gas and can move ETH, set allowances, call contracts or install new permissions.

The danger is not the button label but the actual object in the wallet window. A page can say “Sign in” while your wallet is showing typed data for a permit, or a transaction that calls approve. Trust the wallet prompt, not the site underneath it.

What a safe-looking login can hide

A legitimate sign-in flow on Ethereum often uses Sign-In with Ethereum, a plain message that says who is asking, which address is signing and why. That is low risk when it matches the site you intended to use. Attackers copy that pattern because people are used to clicking through it.

The trick is substitution. Instead of a plain message, the site asks for typed data whose fields grant a token allowance or an account-level permission. Because typed data has readable field names, it can look official, especially on mobile screens that show only part of the request. “One-click claim”, “session upgrade” and “gasless login” are common labels for this bait.

Permits, Permit2 and operator approvals

A permit signature creates a token allowance without your sending an approval transaction first. The spender later submits the signature on-chain and takes the allowed amount. Uniswap’s Permit2 system extends this pattern so many apps can use the same approval hub once your token has approved Permit2 itself.

• For fungible tokens, look for fields such as spender, amount or value, nonce and deadline.
• For NFTs, watch for setApprovalForAll or operator-style fields. That permission covers every NFT in the collection, including ones you buy later.
• A long deadline, a very large amount or a spender you do not recognise are enough reason to reject the request.

Since the Pectra upgrade, an EIP-7702 authorisation is another signature to treat with care. It lets your account point to contract code. In normal use a wallet sets this up for code it has vetted. A website asking you to authorise unfamiliar code is asking for account-wide control.

How to read the request field by field

1. Check the site name and URL first. A genuine message for the wrong site is still wrong.
2. Identify the kind of request. If it is a transaction, what contract are you calling? If it is typed data, what is the domain and primary type?
3. For approvals, note who gets power: the spender, operator or delegate.
4. Read the limits: token amount, NFT scope, nonce and deadline. A signature that does not expire is much riskier than one that lapses in minutes.
5. Look for chain context. A request meant for Ethereum should not appear when you thought you were on Base, and vice versa.
6. If you still want to continue, paste the data into the signature decoder and compare the decoded output with what the app claimed it would do.

After you signed something by mistake

Speed matters because a permit can be used the moment the attacker sees it. A plain message does not move funds on its own, but an approval transaction, a permit, a Permit2 signature or an operator approval can.

1. Check and revoke live allowances with token approvals.
2. Use wallet health to see whether the account now has suspicious delegation or broad approval exposure.
3. If the wallet holds material value, move remaining assets to a clean wallet before you investigate at length.
4. Keep the raw request, the site URL and the transaction hash. They help support staff and incident responders understand exactly what was signed.