In all interactions in the Web3 world, 'signing' is the ultimate action of exercising power. It is akin to stamping your seal or signing a contract in the traditional world. However, due to the complexity of blockchain interactions and the imperfections of user interfaces, signing has become one of the most dangerous steps where users are most likely to incur losses. This topic will systematically analyze signature security, starting with core principles, delving into the fatal risks of 'blind signing,' and revealing the technical logic behind it with real cases.

Part One: Core Security Principles of Signing - What You See Is What You Sign (WYSIWYS)

'What You See Is What You Sign' (WYSIWYS) is the gold standard for assessing the security of all signing operations. It requires:

  • Human Readability: The wallet interface must translate underlying, machine-readable transaction data (such as hexadecimal encoded calldata) into clear, unambiguous natural language, accurately describing the actions that will be triggered by the signature.

  • Intent Consistency: The expected outcome that users see on the interface must be completely consistent with the results that the signature executes on-chain or in the backend.

Any signature that violates the WYSIWYS principle can be considered 'blind signing.' When you engage in blind signing, you do not actually know what you have authorized; you are merely trusting a vague, potentially maliciously constructed hash value or piece of data.

Part Two: In-Depth Case Analysis - The OpenSea Signature Phishing Incident

In early 2022, the large-scale NFT theft incident that erupted on the OpenSea platform is the most painful lesson of blind signing risks. Its attack process reveals the core pattern of signature phishing:

  1. Prerequisite: The user has authorized the NFT

    • When listing an NFT for sale on OpenSea, users must perform an approve or setApprovalForAll operation, authorizing OpenSea's trading contract (Wyvern Protocol) to transfer that NFT on their behalf. This is a necessary and legitimate step.

  2. Core of the Attack: Phishing for Offline Signatures

    • Constructing Malicious Data: The attacker carefully constructs a 'sell order' data on their server in accordance with the OpenSea trading protocol (Wyvern). This data contains the target NFT information they wish to steal, setting the buyer address as themselves and the purchase price to 0 ETH.

    • Inducing Users to Sign: The attacker uses phishing emails, fake airdrop websites, and other methods to lure users into connecting their wallets and signing the aforementioned malicious 'sell order' data.

    • The Occurrence of Blind Signing: At that time, when users were asked to sign on the phishing website, wallets like MetaMask displayed a pop-up that only showed a meaningless hash value (Message to sign: followed by a string of 0x...). Users could not tell that this represented a transaction of 'selling my NFT for 0 ETH.' Users mistakenly thought this was just an ordinary login verification and clicked 'sign.'

  3. Completing the Attack: Submitting the signature on-chain

    • After obtaining the complete '0 ETH sell order' containing the user's signature, the attacker uses it as a parameter to call OpenSea's official, legitimate trading contract.

    • OpenSea's contract verifies that the signature is valid (it is indeed signed by the NFT owner), and that the NFT had been previously authorized to the contract. Thus, the transaction is executed, and the NFT is 'sold' to the attacker for 0.

Part Three: The Roots of Blind Signing and Challenges at the Protocol Level

Why did such a large-scale blind signing incident occur?

  1. Lack of Information in Wallet Interfaces: Early wallets (including MetaMask) lacked the ability to parse non-standard off-chain signatures (such as EIP-191's eth_sign), only displaying the raw hash of the data to be signed, leading to a 'black box' user experience.

  2. Evolution of EIP-712: To address the blind signing issue, EIP-712 (Ethereum Improvement Proposal 712) was born. It defines a structured, readable off-chain signing standard. When DApps use EIP-712, wallets can present the content of the signature to users in a clear key-value format (e.g., Sale Details: { Item: CryptoPunk #1234, Price: 0 ETH }). After the theft incident, OpenSea quickly upgraded to adopt EIP-712, greatly improving the security of the signing experience.

  3. The 'Borderless' Problem of Signatures: A deeper issue is that the signing behavior is not constrained by the browser's Same-Origin Policy. The Same-Origin Policy is a cornerstone of web security that limits how documents or scripts from one origin (domain) can interact with resources from another origin. However, a signature generated on evil-phishing.com can be seamlessly used by an attacker for contract interactions on opensea.io. If the signature protocol itself could bind to specific domain names, it would fundamentally eliminate such cross-origin phishing attacks. There are new protocol drafts being discussed, but they have not yet become widespread.


We understand that the parsing capabilities of wallets, the adoption of protocol standards (such as EIP-712), and the limitations of the signature mechanism itself are the fundamental reasons for the risk of blind signing. In the next piece, we will focus on practical defense strategies for users, highlighting how to actively manage authorizations and identify different types of signature requests.