Skip to content

ERC712

Overview

ERC712 (Ethereum Typed Structured Data Hashing and Signing) is an Ethereum improvement proposal that defines a standard for typed hashing and signing of structured data. Proposed in 2017 by Ethereum founder Vitalik Buterin and others, the standard aims to solve the security and usability issues of off-chain signing, providing users with a safer and more readable signing experience.

Before ERC712, when users signed off-chain messages, they saw only an unintelligible hexadecimal string, making it possible for malicious applications to trick users into signing dangerous transactions. ERC712 introduces structured data signing, enabling wallets to display signing content in a human-readable format so users can clearly see what they are signing, greatly improving security. ERC712 has become the de facto standard for off-chain signing in DeFi, NFT, DAO, and other Web3 applications.

Core Features

Structured Data Signing

The most important innovation of ERC712 is the introduction of typed structured data signing: - Type definitions: Explicitly define the types of data structures, such as Person{string name, address wallet} - Nesting support: Supports complex nested data structures - Array support: Can include array-type fields - Type safety: Prevents data from being tampered with or misinterpreted through the type system

This gives signed data clear semantics, allowing wallets to parse and display it to users.

Domain Separator

ERC712 introduces the concept of a domain separator to prevent replay attacks: - Name: The name of the DApp or protocol - Version: Protocol version number - Chain ID (chainId): Blockchain network identifier, prevents cross-chain replay - Verifying Contract (verifyingContract): The contract address that will use this signature - Salt: Optional additional random value

The domain separator ensures signatures are only valid in a specific context and cannot be reused in other DApps, chains, or contracts.

Human-Readable Signing Interface

Wallets can display ERC712 signing requests in a structured table format: 

MyDApp requests signing:

Domain Information:
  Name: Uniswap V2
  Version: 1
  Chain ID: 1 (Ethereum Mainnet)
  Contract: 0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D

Message Content:
  owner: 0x1234...5678
  spender: 0xabcd...ef00
  value: 1000000000000000000 (1 ETH)
  nonce: 5
  deadline: 1735689600

Compared to traditional hexadecimal hashes, this display format allows users to clearly understand the signing content.

Preventing Signature Collisions

ERC712 prevents signature collisions between different data structures through a type hash mechanism: - Type hash (typeHash): Each data structure has a unique type hash - Structured hash: Data is hashed in a canonical order - Determinism: The same data always produces the same hash

Even if two different data structures happen to have the same field values, their ERC712 signatures are completely different.

Standard Advantages

Security Enhancement: ERC712 significantly improves the security of off-chain signing. Users can see clear data content before signing, preventing phishing website deception. The domain separator mechanism effectively prevents replay attacks and signature abuse.

Standardization: As an Ethereum standard proposal, ERC712 has been widely adopted, forming a unified off-chain signing specification. Both developers and users can trust this standard.

User Experience: The human-readable signing interface greatly improves user experience. Users no longer need to blindly trust applications but can verify the correctness of signing content.

Development Convenience: Various Ethereum libraries (ethers.js, web3.js, web3.py, etc.) have built-in ERC712 support, allowing developers to easily implement ERC712 signing functionality.

Gas Efficiency: Off-chain signing does not consume Gas; Gas is only needed when submitting the signature to the chain for verification. This allows many operations to be completed off-chain, reducing costs.

Error Prevention: Typed data structures reduce the possibility of developer errors. Encoding and decoding follow explicit rules, reducing ambiguity.

How It Works

The ERC712 signing process consists of the following steps:

  1. Define Domain Separator 

    bytes32 DOMAIN_SEPARATOR = keccak256(abi.encode(
    keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"),
    keccak256(bytes(name)),
    keccak256(bytes(version)),
    chainId,
    verifyingContract
));

  2. Define Data Types 

    bytes32 PERMIT_TYPEHASH = keccak256(
    "Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)"
);

  3. Build Structured Data Hash 

    bytes32 structHash = keccak256(abi.encode(
    PERMIT_TYPEHASH,
    owner,
    spender,
    value,
    nonce,
    deadline
));

  4. Generate Final Signing Hash 

    bytes32 digest = keccak256(abi.encodePacked(
    "\x19\x01",
    DOMAIN_SEPARATOR,
    structHash
));

  5. Sign the digest, generating v, r, s signature parameters.

Use Cases

ERC20 Permit (ERC2612): Allows users to authorize token transfers via signature without first calling the approve function, saving one transaction's Gas fee.

Decentralized Exchanges (DEX): Users sign order information, orders are matched off-chain, and only go on-chain when executed, greatly reducing transaction costs. Examples include Uniswap V2/V3 and 0x Protocol.

NFT Marketplaces: Users sign NFT sell orders, and buyers can execute transactions directly without the seller first listing the NFT. Examples include OpenSea and LooksRare's off-chain order systems.

Multi-Signature Wallets: Multi-sig wallets like Gnosis Safe use ERC712 to let signers sign transaction proposals, collecting sufficient signatures before batch execution.

DAO Governance: Off-chain voting systems (such as Snapshot) use ERC712 signatures to record votes, then submit results on-chain, saving Gas and increasing participation.

Account Abstraction: Account abstraction proposals like ERC4337 use ERC712 to sign user operations (UserOperation).

Meta-Transactions: Users sign their transaction intent, and a relayer pays the Gas to execute on their behalf, enabling a Gasless experience.

DeFi Protocols: Lending protocols, liquidity mining, and other scenarios use ERC712 to simplify user interactions, such as the permit functionality in Aave and Compound.

Development History

September 2017: Vitalik Buterin, Martin Swende, and others proposed the EIP712 draft, aiming to standardize structured data signing.

2018: The EIP712 specification was gradually refined, with community discussion and testing.

2019: Major Ethereum libraries began implementing ERC712 support. Wallets like MetaMask began supporting human-readable display of ERC712 signatures.

2020: The ERC2612 (ERC20 Permit) standard was proposed, implementing token authorization signing based on ERC712. Widely adopted by DeFi protocols.

2021: The NFT market exploded, with OpenSea and other platforms adopting ERC712 for off-chain order systems. Off-chain governance platforms like Snapshot used ERC712 to record votes.

2022: ERC712 became the standard signing method for Web3 applications, adopted by virtually all major DApps. The account abstraction proposal (ERC4337) incorporated ERC712 as a core component.

2023 to present: ERC712 continues to evolve, supporting more complex data types and use cases. It has become an indispensable foundational standard in the Ethereum ecosystem.

Security Considerations

Wallet Compatibility: Not all wallets perfectly support ERC712. Developers should test compatibility with major wallets and provide fallback solutions.

Domain Separator Verification: Contracts must strictly verify the domain separator to ensure signatures come from the correct DApp and chain, preventing cross-chain or cross-contract replay attacks.

Nonce Management: Use nonces to prevent signature reuse. Each signature should have a unique nonce that becomes invalid after use.

Deadline Settings: Set an expiration period for signatures. Expired signatures should be rejected to prevent old signatures from being abused in the future.

Phishing Risk: Although ERC712 provides a readable signing interface, users must remain vigilant. Malicious websites may disguise themselves as legitimate applications to trick users into signing dangerous content.

Signature Verification: Contracts must correctly implement signature verification logic, using ecrecover to recover the signer's address and verify permissions.

  • ERC2612 - Token authorization standard based on ERC712
  • ERC4337 - Account abstraction standard, uses ERC712 to sign UserOperations
  • MetaMask - Mainstream wallet supporting ERC712 signature display
  • Offline Signing - ERC712 is the standard implementation for off-chain signing
  • Snapshot - Uses ERC712 for off-chain governance voting
  • EIP712 Proposal: https://learnblockchain.cn/docs/eips/EIPS/eip-712
  • ethers.js Documentation: https://docs.ethers.org/v6/api/hashing/#typed-data
  • Viem EIP712 Documentation: https://viem.sh/docs/actions/wallet/signTypedData
  • ERC2612 Permit: https://learnblockchain.cn/docs/eips/EIPS/eip-2612
  • OpenZeppelin EIP712 Implementation: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/cryptography/EIP712.sol
  • MetaMask Signing Guide: https://docs.metamask.io/wallet/how-to/sign-data/