In this track: Advanced security reasoning
advanced · 4 MIN READ

EIP-712 domain mistakes

Signing and verification must agree on the intended domain fields.

LET’S PICTURE IT

Two departments cannot safely share forms while silently ignoring the office label.

SEE IT FOR YOURSELF
From a public address to a verified signatureStep 1 / 4
From a public address to a verified signaturePublic address0x0000…0001Share to receiveAnother personCan read the addressCannot sign for youPublic identifier ≠ secret authorizationLocal signerPrivate key stays hereSign the chosen requestSigned requestMessage + signatureSecret key not includedThe moving packet represents a signature, not a keySignatureCheck the exact messageCheck the signing contextVerificationAuthorization checkedIntent still mattersValidity and safety are different questionsWallet interfaceReads public dataRequests authorizationNetwork stateBalances and recordsIndependent verificationNo wallet is connected in this local illustration

An address is public receiving information. It is not the private key that authorizes actions.

Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.

Compare the complete schema

Inspect domain name, version and other selected fields alongside the primary struct definition. Similar wallet displays do not guarantee identical typed hashes.

Check chain and contract handling

A cached separator or hardcoded value can be wrong for the intended context. Analyze how the implementation derives and updates its domain information.

Avoid display-only assurances

Showing a correct-looking chain label does not protect a verifier that signs or checks different data. Match the actual digest construction on both sides.

Test every domain boundary

Use changed chain, contract, version and message-type fixtures where those fields are intended to separate authorizations. Include repeated use inside the valid domain.

Work through the boundary

expected domain → typed digest A
altered verifying contract → typed digest B
acceptance must follow the intended context

A simplified local review scenario. The example establishes a question to test, not a guarantee of production safety.

QUICK CHECK · NO PRESSURE

Is a correct wallet label enough if the verifier ignores that domain field?

Your progress stays in this browser.
Keep exploring the original referenceEthereum Improvement Proposals ↗

Original explanations by EtherTools. Examples are educational and source-linked; this site is independent of the Ethereum Foundation. Our approach.