Signing messages vs transactions: why “no gas” does not mean “no risk”

How a wallet signature request differs from a transaction, what personal_sign and EIP-712 typed data actually show, why off-chain permits can move tokens later, and how to read a signature prompt calmly—EIP and wallet-doc literacy, not investment advice.

Most people learn one rule early: a transaction costs gas, so it must be the “real” step. A signature request costs nothing and never shows up as a pending transaction, so it feels harmless. That instinct is exactly what signature phishing exploits. This page explains the difference between signing a message and signing a transaction, and how to read the prompt before you click Sign.

How it works: same key, different kinds of data

Your wallet uses one private key for everything. What changes is what gets signed and where the result goes.

Transaction. Your wallet signs the transaction and broadcasts it to the network. It uses a nonce, costs gas, and lands on-chain where an explorer can show it.
Plain message (personal_sign). According to ERC-191, these messages get the prefix "\x19Ethereum Signed Message:\n" plus the message length before signing. The prefix starts with the byte 0x19, so the signed data can never be a valid Ethereum transaction. MetaMask’s developer docs describe personal_sign as the method most often used for sign-in challenges such as Sign-In with Ethereum.
Typed structured data (EIP-712, eth_signTypedData_v4). EIP-712 was written because signed messages used to appear as “an opaque hex string … with little context.” It defines a domain (name, version, chainId, verifyingContract) plus a typed message, so wallets can show you the fields. The EIP also notes that it saves gas because signing happens off-chain, and that a contract can later check the signature on-chain.

That last point matters most. A typed-data signature can be a permission slip that someone else submits later. ERC-2612 (permit) lets a token holder set an allowance with a signed message instead of an on-chain approve. The spec says plainly that “the caller of the permit function can be any address.” It also says the deadline can be set so that permits “effectively never expire.” Uniswap’s Permit2 docs describe a similar signature-based allowance and transfer system that works with any ERC-20 after a one-time approval of the Permit2 contract.

Why “gasless” prompts get abused

MetaMask’s signature-phishing article lays out the pattern. A fake dapp asks for an off-chain signature and says it is for something routine, like a deposit, a claim, or an NFT listing. The signature actually grants a token allowance or lists assets, and the attacker uses it “at a time of their choosing.” You never broadcast a transaction and never pay a fee, so nothing in your history looks wrong until the tokens move. ethereum.org’s security page describes the related airdrop-claim pattern: an unexpected asset shows up and points you to a site where you are asked to connect and approve.

How to verify: read a signature like a contract

Check the origin first. Before any field, confirm the site URL your wallet shows is one you opened from your own bookmark. A perfect-looking prompt from the wrong domain is still the wrong domain.
Name the type. Is this a transaction, a plain-text message, or typed data? A plain sign-in message should read like a sign-in: your domain, a nonce or time, and no amounts.
In typed data, read the domain. Look at name, chainId, and verifyingContract. EIP-712 says the wallet should refuse to sign if the chainId does not match the active chain. A domain name you don’t recognize is a reason to stop.
Look for permission words. Permit, spender, value/amount, deadline/expiration, nonce. If those appear and you didn’t ask to approve anything, decline. A very large value or a far-future deadline deserves the same caution as an unlimited token approval.
Treat warnings as stop signs, and silence as neutral. MetaMask’s security alerts can label requests “Warning” or “Malicious.” Its docs also say simulations “do not guarantee detection of all threats.” See transaction simulations and wallet previews.
Never sign anything that asks for seed words. No legitimate signature needs your recovery phrase.

If you think you signed something bad, the steps in how to revoke a token approval still apply. Check allowances, including any Permit2 allowances, on a tool you reached from an official link.

What we will not do

We will not rank wallets, signature-decoding tools, or “protection” add-ons. We will not tell you which dapps to sign for. We will not give trade or price commentary on any token mentioned in the specs.

TakeawayA signature can be a permission slip someone else cashes later. No gas and no pending transaction does not mean no risk. Check the site, the domain, the spender, the amount, and the deadline, or don’t sign.

Related free docs

Sources

ERC-191 — Signed Data Standard (0x19 prefix; personal_sign version byte 0x45; signed data cannot be a transaction)
EIP-712 — Typed structured data hashing and signing (domain fields; chainId refusal guidance; off-chain signing motivation; replay/frontrunning notes)
ERC-2612 — Permit extension for EIP-20 signed approvals (any caller may submit; deadline semantics)
Uniswap Docs — Permit2 overview (signature-based allowances and transfers; one-time token approval)
MetaMask Docs — Sign data (personal_sign vs eth_signTypedData_v4; eth_sign deprecated)
MetaMask Help — Signature phishing (vendor education; not an endorsement)
MetaMask Help — Security alerts (Warning vs Malicious; no detection guarantee)
ethereum.org — Ethereum security and scam prevention (airdrop scams; read before signing)

Educational content only — not investment advice. This page explains how wallet signatures work as a literacy topic; it does not recommend any wallet, tool, network, or asset to buy, sell, or hold.

← All docs