EIP-712 Typed Data
Pronunciation: E-I-P-7-1-2 TYPT DAY-tuh
Definition
EIP-712 Typed Data is an Ethereum standard for hashing and signing structured data with explicit types and domain information so wallets can present more meaningful authorization details.
Overview
How it works and why it matters
EIP-712 specifies a way to hash and sign structured data in Ethereum-style applications so interfaces can display typed fields instead of an opaque byte string. It uses domain separation to bind a signature to intended application context. This can improve clarity but does not make all signed authorizations harmless.
Important technical and operational details
The control exists to reduce technical, fraud, and financial risk arising from blockchain transactions, signatures, smart contracts, clients, bridges, wallets, and public transaction data. It improves readability and domain separation but does not guarantee that a contract, spender, message, or requested action is safe. It should be interpreted alongside Cross-Chain Replay Attack because the concepts can affect the same decision without representing the same control, event, or risk.
The workflow identifies the exact network, contract, implementation, message, signer, asset, dependency, and expected state transition. Systems should verify domain and chain context, authoritative addresses, signatures, nonces, code or client versions, confirmations, and the difference between observable data and inferred ownership. In this context, implementations should verify type encoding, domain fields, chain and verifying-contract identifiers, nonce and expiry, displayed values, signature recovery, contract-wallet behavior, replay resistance, and consistency between the signed message and executed action.
It should connect the term to Approval Phishing where that relationship changes access, transaction treatment, investigation, communication, or recovery.
Records should retain transaction and block identifiers, contract addresses, network and chain ID, decoded input, signer, signature domain, client version, timestamps, confirmations, attribution source, alerts, decisions, and resulting state. Reorganizations, bridges, proxies, and off-chain dependencies require explicit treatment.
Related concepts
Cross-Chain Replay Attack; Approval Phishing; Contract Verification
Further reading
Example
A wallet requests a permit for token spending. Its EIP-712 message displays spender, allowance and deadline. If a user approves a very large allowance to an unfamiliar contract, a valid signature may authorize unexpected token movement.
Comparison
Typed-data signing does not imply on-chain execution and cannot guarantee that wallet interfaces display every security-relevant consequence. Inspect chain ID, verifying contract and the actual permission granted.
Key Takeaway
Read typed signing permissions carefully, especially spender, allowance, domain, and deadline.
Sources
- EIP-712: Typed Structured Data Hashing and Signing — Ethereum Improvement Proposals (2026-08-03)
- EIP-155: Simple Replay Attack Protection — Ethereum Improvement Proposals (2026-08-03)
- Ethereum Security and Scam Prevention — Ethereum Foundation (2026-08-03)