Blind Signing and "What You See Is What You Sign"

This article has three layers:

1. Layer 1: The Intuition: Blank checks
2. Layer 2: Real-World Use: Permit phishing, the Bybit incident, and "clear signing" in hardware wallets
3. Layer 3: eth_sign, personal_sign, EIP-712, and the structure of Permit

Layer 1: The Intuition

1.1 Blank Checks

Someone hands you a piece of paper with a string of gibberish on it: "0x8f3a...e21c, please sign to confirm." You sign it.

Later, you find out that this gibberish translates to: "I hereby agree to grant the transfer rights of all USDC in my account to 0xBad... ."

This is blind signing. The signing algorithm itself has no issues; the problem is that you do not know what you are signing.

1.2 Why Off-chain Signatures Are More Dangerous

Many people assume that "as long as you don't send a transaction or spend gas, there is no risk." However, there is a type of signature that is off-chain and costs nothing, yet can be taken by others and executed on-chain:

• You sign a Permit message, and the website displays "Signature successful, claiming your airdrop."
• The attacker takes your signature, submits their own transaction, authorizes your tokens to themselves, and then transfers them away.

Throughout this entire process, no transaction request ever appeared in your wallet; there was only a single "signature."

Layer 2: Real-World Use

• Permit / Permit2 phishing: Annual reports from on-chain security firms show that signature-based phishing is already one of the largest sources of losses for cryptocurrency users, with single victims losing tens of millions of dollars in individual cases. Common pretexts include: claiming airdrops, verifying wallets, free mints, and "signing in."
• Bybit (2025): The signer saw transaction data on the hardware wallet that could not be directly understood, leaving them to rely solely on the website's display, which had been tampered with (see "The Bybit Incident and Frontend Integrity"). In the aftermath, there has been unprecedented industry demand for "hardware wallets must clearly display multi-sig transaction content."
• Hardware wallet "clear signing": Manufacturers like Ledger and Trezor are promoting the direct display of decoded transactions on device screens, such as "Authorize Uniswap to use 1000 USDC, valid until [date]," rather than a string of hexadecimal code.
• Wallet security prompts: MetaMask, Rabby, and others display prominent warnings for Permit-type signatures and parse out the spender (the authorized party) and the allowance.

Layer 3: Principles and Engineering

3.1 Ethereum's Various Signing Methods

3.2 The Structure of EIP-712

{
  "domain": { "name": "USD Coin", "version": "2", "chainId": 1,
              "verifyingContract": "0xA0b8...eB48" },
  "primaryType": "Permit",
  "message": {
    "owner":   "0xYourAddress",
    "spender": "0xAttackerAddress",
    "value":   "115792089237316195423570985008687907853269984665640564039457584007913129639935",
    "nonce":   0,
    "deadline": 1893456000
  }
}

Translated into human language: "I allow 0xAttackerAddress to spend all my USDC from now until January 1, 2030."

In this case, the astronomical number value is $2^{256} - 1$, meaning "unlimited allowance" (see "Unlimited Allowance"). Once signed, anyone can submit this signature to the USDC contract's permit function, and the authorization will be recorded on-chain; subsequently, the spender can call transferFrom to transfer the funds.

3.3 Permit2

Permit2, introduced by Uniswap, is a universal authorization contract: a user first performs an on-chain authorization (usually unlimited) for Permit2, and thereafter, various applications only need the user's signature to move the tokens. This provides a better user experience, but it also means: a single fraudulent signature can move all the tokens you have authorized to Permit2.

3.4 Engineering Principles of "What You See Is What You Sign"

1. Do not support eth_sign, and do not use personal_sign for raw hexadecimal;
2. Only sign content that can be fully decoded: transaction calldata must parse out the function name and parameters; EIP-712 must identify the spender, allowance, and expiration;
3. If it cannot be decoded, reject it, rather than "displaying raw data for the user to judge themselves" (see "Fail-closed");
4. Display the most prominent warning for authorization-type signatures: "This is equivalent to giving your assets to X";
5. Signature requests must be triggered directly by a user's click; they must never pop up automatically when a page loads;
6. For multi-sig wallets, the signer must be able to decode the transaction independently of the webpage (on the hardware wallet screen or using another tool), such as checking whether the operation field is a dangerous delegatecall.

Summary