Clear Signing vs Blind Signing: What Your Wallet Can Show

The prompt is a decoder, not a guarantee

A wallet does two things when you sign: it applies your private key to a hash, and it renders the request so you can decide. The first is mechanical and always succeeds. The second depends entirely on whether the wallet recognizes the structure of what it is being asked to sign, and whether the prompt tells you everything the signature can do is a separate question.

That gap between rendering and meaning is where blind signing lives. MetaMask’s signature-phishing page describes off-chain signatures as allowing the dapp collecting one “to use the signed message at a time of their choosing,” and notes that “transaction data is so rarely readable by humans” that a user can be told they are depositing tokens while actually granting an unlimited approval.

What each signature type puts on screen

eth_sign and raw message signing. Ethereum.org’s JSON-RPC documentation defines eth_sign as calculating a signature over keccak256("\x19Ethereum Signed Message:\n" + len(message) + message). The prefix marks the result as an Ethereum-specific message signature, and the page says this “prevents misuse where a malicious dapp can sign arbitrary data (e.g., transaction) and use the signature to impersonate the victim.” The prefix identifies the signature; it does not make the bytes interpretable. EIP-712’s motivation states the underlying problem plainly: signed messages were “an opaque hex string displayed to the user with little context about the items that make up the message.”

EIP-712 typed data. The standard encodes a struct type, a domain and a message, so a wallet that implements it can show the fields. The domain carries a name, a version, a chainId, a verifyingContract and optionally a salt; the specification says the user-agent “should refuse signing if it does not match the currently active chain” and may use the verifying contract for “contract specific phishing prevention.” It also states that the standard “does not include replay protection,” leaving it to the application to reject a repeated signature.

An ERC-20 approval. The token interface lists approve(address _spender, uint256 _value) and allowance(address _owner, address _spender), plus an Approval event. There is no deadline parameter. MetaMask’s approval prompt shows the dapp’s name and URL, offers “verify contract details” for the contract address, lets you edit the cap under “custom spending cap,” and shows the gas cost. The page warns that the cap “can and often does drastically exceed” the amount you actually hold.

Permit-style signatures. MetaMask’s approval page describes the EIP-3009 model, where you sign a permit instead of sending an approval transaction, bundling the approval and the transfer together so the approval costs no gas. The authorization then exists as a signature rather than as a stored allowance.

Every entry in the third and fourth columns is wallet-dependent. Check your wallet’s current prompt rather than assuming a capability.

A worked example: the same approval, decoded and raw

Take a token with 6 decimals and a balance of 250. A dapp asks for an approval of 1,000,000 tokens.

• amount in base units = 1,000,000 × 10^6 = 1,000,000,000,000
• the same number in hex = 0xE8D4A51000
• zero-padded to the 32-byte argument slot = 0x000000000000000000000000000000000000000000000000000000E8D4A51000
• full calldata = the approve selector 0x095ea7b3, then the padded spender address, then that padded amount

A wallet that decodes the call can render “allow this spender to move 1,000,000 tokens.” A wallet that does not shows a 138-character hex string in which the only readable parts are the spender’s address and an amount you have to convert by hand.

Now compare the cap with the balance:

• 1,000,000 − 250 = 999,750 more than you hold
• 1,000,000 ÷ 250 = 4 complete sweeps of the current balance before the allowance is used up

The allowance is a ceiling on what the spender may take, not a transfer, and it is not limited by your balance. The unlimited case is the same arithmetic at the top of the range: 2^256 − 1 = 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,935, which is about 1.16 × 10^77 base units, or 1.16 × 10^71 tokens at 6 decimals. A ceiling that large will never bind.

Nothing in that approval expires. The ERC-20 interface has no deadline argument, and MetaMask’s page describes an approval as applying until the dapp has used the amount, at which point a new approval is needed. A permit signature is different: its fields are whatever the type defines, and the prompt can only show the ones your wallet decodes.

Where the naive reading goes wrong

“The prompt named the site, so the contract is the right one.” The name and URL at the top of the prompt are what the requester claims. MetaMask puts “verify contract details” next to them precisely because the label is not proof of the contract.

“A signature with no gas fee cannot move anything.” Producing an off-chain signature broadcasts nothing and costs nothing, and that is the point: whoever holds it can submit it later.

“The cap is the most I can lose.” The cap can exceed your balance, and setApprovalForAll grants control of every NFT of a given contract rather than one token amount. Read the function, not just the number.

“An unlimited approval is always an attack.” MetaMask’s approval page notes that many legitimate dapps request essentially unlimited access to avoid repeated approval transactions and their gas costs. The risk sits in the spender and the contract, and an existing approval can be revoked.

“Typed data means verified.” EIP-712 standardizes encoding and domain separation. It states that it does not include replay protection, and the domain fields only help if the wallet checks them.

What the primary sources do and do not say

Ethereum.org’s JSON-RPC page documents what eth_sign computes and asserts that the prefix prevents a class of impersonation. It does not say which wallets enable eth_sign, which block it, or what any prompt displays.

EIP-712 defines the scheme, the domain separator fields and the purpose of displaying structured data for verification. It does not mandate what a wallet must render, and it explicitly leaves replay protection to the application.

The ERC-20 page lists the interface, including approve and allowance; it defines no expiry because the interface has none. The MetaMask pages describe MetaMask’s own prompts and warnings. They say nothing about other wallets, which is why the capability, not the product, is what this article describes.

A rule for refusing a signature

1. Name the function and every argument. If you cannot say what will be called and with which values, refuse.
2. Check the chain and the verifying contract. A familiar site name is not a contract address.
3. Read the approval amount and set your own cap. Assume it will not expire, and treat an amount above your balance as unlimited in practice.
4. Treat an off-chain request as a transaction that has already been sent. It costs no gas because nothing is broadcast yet, not because nothing can happen.
5. Revoke approvals you no longer use. The token allowance guide covers how to review and revoke them.

If the prompt is a hex blob and the wallet offers no decoded view, that is the answer to the question you are being asked: you cannot read it, so do not sign it.

How these sources were checked

Ethereum.org, “JSON-RPC API” (eth_sign), retrieved 2026-10-23. EIP-712, “Typed structured data hashing and signing,” retrieved 2026-10-23. Ethereum.org, “ERC-20 token standard,” retrieved 2026-10-23. MetaMask Help Center, “What is a token approval?”, retrieved 2026-10-23. MetaMask Help Center, “Signature phishing,” retrieved 2026-10-23.