EIP-712

EIP-712 (Ethereum Improvement Proposal 712) is a standard for typed structured data signing. Unlike signing raw, opaque hexadecimal hashes, EIP-712 allows users to sign a human-readable representation of complex data structures, such as orders, permissions, or votes, before the data is hashed and verified on-chain. This provides cryptographic guarantees that the signer explicitly approved the exact, readable content, significantly improving security and user experience for decentralized applications (dApps) by preventing signature misuse.

The core innovation is the EIP-712 domain separator and type hashing. A signature is created by constructing a hash from: the domain separator (which includes the dApp's name, version, chain ID, and contract address), the specific data structure's type definition, and the data values themselves. This creates a unique, context-bound signature that cannot be replayed on other chains or contracts. Wallets like MetaMask can display this structured data in a readable format, allowing users to verify exactly what they are signing.

Common use cases for EIP-712 include gasless transactions (via meta-transactions or permit patterns), decentralized exchange order signing, and DAO governance votes. For example, the permit function for ERC-20 tokens uses EIP-712 to allow a token holder to sign an approval for a spender, which can then be submitted by a third party, saving the holder gas. This standard is foundational for secure off-chain agreement systems, moving complex logic off-chain while maintaining strong on-chain verification.

EIP-712 is a standard for typed structured data signing that allows users to sign a human-readable representation of complex data, rather than an opaque hexadecimal hash. It works by defining a type structure—including the domain separator (EIP712Domain) and the specific message types—that is hashed together with the data to create a deterministic signature payload. This process ensures the signer can clearly verify the exact content they are approving, which is a significant security and usability improvement over signing raw, unreadable hashes. The resulting signature is a standard secp256k1 signature, identical in format to a transaction signature, but generated for off-chain data.

The technical mechanism hinges on the EIP-712 Domain Separator, a unique hash that includes the contract's verifying address, name, version, chain ID, and salt. This separator cryptographically ties the signature to a specific context, preventing signatures from being replayed on different contracts or networks. The message data itself is encoded according to its predefined type hash, which is derived from the structure's field names and types. The final digest to be signed is keccak256(\"\\x19\\x01\" || domainSeparator || messageHash). This structured approach allows wallets like MetaMask to display a clear, formatted preview of the data, making signature phishing far more difficult.

A primary use case for EIP-712 is enabling gasless transactions via meta-transactions or systems like OpenZeppelin's ERC20Permit. Instead of paying gas to approve a token transfer, a user can sign an EIP-712 structured message off-chain, which a relayer can then submit to the blockchain, executing the approved action on the user's behalf. This standard is also fundamental for decentralized exchanges (DEXs) implementing limit orders, decentralized identity attestations, and any application requiring verifiable user consent for complex off-chain agreements. Its adoption represents a shift towards more secure and user-friendly blockchain interactions beyond simple value transfers.

The EIP-712 Domain Separator is a unique identifier that cryptographically binds a signature to a specific contract and blockchain, preventing signature reuse across different applications. It is defined as a struct containing fields like name, version, chainId, verifyingContract, and salt. Hashing this struct creates the DOMAIN_SEPARATOR, a critical component that ensures a signature for "Contract A" on Ethereum Mainnet is invalid for "Contract B" on Polygon. Developers must compute this separator off-chain and pass it as part of the signature verification data to the smart contract.

The EIP-712 Struct defines the schema of the data being signed, moving beyond raw hashes to human-readable type information. For a permit function, this would be a Permit struct with fields for owner, spender, value, nonce, and deadline. Each field has a name and an explicit type (e.g., address, uint256). This struct, along with the domain separator, is used to generate the type hash (TYPE_HASH). Both the DOMAIN_SEPARATOR and TYPE_HASH are typically stored as immutable constants within the smart contract for efficient on-chain verification using ecrecover.

A complete implementation involves coordinating off-chain signing and on-chain verification. Off-chain, a library like ethers.js constructs the domain and message objects, then calls signer._signTypedData(domain, types, message) to produce the user's signature. On-chain, the verify function reconstructs the signed digest by hashing the domain separator, type hash, and the hashed struct data (structHash). It then recovers the signer's address from the signature and compares it to the expected owner. This process enables secure, gas-efficient meta-transactions for functions like token permit or DAO votes.

EIP-712 is a standard for typed structured data signing that allows users to sign a human-readable representation of complex data, rather than an opaque hexadecimal hash. This process begins when an application, such as a decentralized exchange or a governance dApp, prepares a structured message containing specific domain separators and typed data like an order, vote, or permit. The signer's wallet presents this structured data in a clear, formatted manner, vastly improving security and user experience compared to signing raw, unreadable hashes.

The core of the flow involves constructing a unique EIP-712 domain separator, which includes critical chain-specific parameters like the name of the dApp, the version, the chainId, the verifyingContract address, and a salt. This domain is cryptographically hashed together with the type-encoded message data. The resulting hash is what the user's private key actually signs, creating a signature that is cryptographically bound to both the specific message content and the dApp's domain, preventing replay attacks across different contracts or networks.

For developers, implementing the flow requires defining a EIP712Domain struct and the specific message structs for their application using Solidity's abi.encode and keccak256. Off-chain, libraries like ethers.js or web3.js provide utilities such as signTypedData to handle the hashing and signing presentation. The final signature, along with the recovered signer address from ecrecover, is then submitted on-chain, where a smart contract verifies it against the stored domain separator and message hash to authorize the transaction.