Separating identical-looking messages
A signature authorizes a particular encoded message, but applications need to agree on what that message means. Domain separation adds context before hashing or signing. In EIP-712, the signing domain can include an application name, version, chain identifier, and verifying contract. Two services can use the same order fields without treating each other's signatures as interchangeable, provided they choose and validate appropriate domains.
1 source for this section
A concrete signing example
Imagine two trading applications both asking a user to sign an order for ten tokens. The order fields alone do not explain which application is allowed to execute it. Including the intended contract and network in the domain narrows that authority. A version field can also distinguish an upgraded format from an older one. Wallets can display these fields, allowing a person to compare the requested authorization with the application they intended to use.
2 sources for this section
Replay protection still needs state
Domain separation does not automatically make an authorization single-use. The same valid order may still be submitted repeatedly within its intended domain unless the application checks a nonce, records fills, enforces a deadline, or otherwise consumes the permission. EIP-712 explicitly does not provide replay protection by itself. A useful review therefore asks two separate questions: where is this signature valid, and what prevents it from being exercised more times than the signer intended?
2 sources for this section
The source notesEvidence & further reading3 sources
- EIP-712: Typed structured data hashing and signing Ethereum Improvement Proposals · Primary source · accessed 2026-09-21
- EIP-155: Simple replay attack protection Ethereum Improvement Proposals · Primary source · accessed 2026-09-21
- Ethereum transactions Ethereum.org · Primary source · accessed 2026-09-21