EIP-712 Typed Data Signing: What Your Wallet Is Asking You to Approve

You connect a wallet and see a form-like request instead of a transaction: an app name, chain, contract, deadline, and unfamiliar fields. There may be no gas fee, yet the signature can authorize something valuable. Understanding EIP-712 typed data signing is therefore a practical part of crypto wallet security, not just a developer detail.

This guide explains what EIP-712 structures, how a wallet arrives at the digest it signs, and what the standard does not guarantee. It is educational, not financial advice (NFA). A valid signature can grant authority that leads to loss, so verify independently, limit permissions, and do your own research (DYOR).

What Is EIP-712 Typed Data Signing?

EIP-712 defines a procedure for hashing and signing typed structured data. Instead of asking you to sign an opaque byte sequence, an application supplies named types, a signing domain, and a message whose fields follow those types.

Think of signing a blank receipt versus a completed purchase order. Both can carry your signature, but the order separates the supplier, item, quantity, price, and expiration into labeled fields. EIP-712 gives Ethereum applications a common way to construct the cryptographic equivalent of that structured order.

Common uses include off-chain orders, votes, login statements, token permits, and authorizations that a contract or service may verify later. Creating the signature normally does not itself submit a transaction or consume gas. That does not make it harmless: someone may later present the signed authorization on-chain.

The Four Parts of a Typed-Data Request

Part	Purpose	What you should inspect
types	Defines structs and field types	Unexpected fields or misleading names
primaryType	Names the main struct	Whether it matches the claimed action
domain	Separates app, version, chain, and contract context	Name, chain ID, verifying contract
message	Contains the actual values	Recipient, amount, nonce, deadline, scope

The domain can contain a human-readable name, version, chain ID, verifying-contract address, and salt. Applications include the fields that fit their context; not every domain contains every option. The standard says a user agent should refuse signing when the supplied chain ID does not match the active chain.

Domain separation matters because two applications might define the same-looking Order or Permit. Binding the digest to a distinct domain helps keep a signature intended for one context from being accepted as an identical message in another. It is a separation boundary, not a complete replay-defense system.

How the EIP-712 Digest Is Built

The process is easier to understand in layers.

1. The application describes a struct such as Order(address maker,address asset,uint256 amount,uint256 nonce).
2. The definition is deterministically encoded and hashed into a typeHash.
3. Message values are encoded by type and combined with the typeHash to produce hashStruct(message).
4. The domain is encoded and hashed into a domainSeparator.
5. The EIP-191 prefix 0x1901, domain separator, and message struct hash are combined and hashed with Keccak-256.
6. Your wallet signs that 32-byte digest with the selected account.

Nested structs are handled recursively. Dynamic values such as strings and byte arrays are represented by hashes of their contents. The specification defines the order so a front end, wallet, and verifying contract can independently calculate the same result.

OpenZeppelin's current EIP712 implementation provides domain-separator handling and the final _hashTypedDataV4 step. It leaves each protocol to implement type-specific struct encoding. A reputable library cannot rescue an incorrectly designed message schema.

eth_signTypedData_v4 and the Wallet Display

Wallets commonly expose EIP-712 through eth_signTypedData_v4. MetaMask's current sign-data documentation recommends version 4 for typed data, including arrays and nested data.

The RPC method transports the request between an application and wallet. It does not decide whether the request is honest. A wallet may render names and values in a readable confirmation, but a malicious application can choose deceptive field names or request excessive authority.

EIP-712 is therefore related to, but not identical with, clear signing. Typed fields make a better display possible. True clarity also depends on accurate labels, formatting, trusted context, complete decoding, and an interface that highlights consequential fields.

EIP-712 Does Not Provide Replay Protection by Itself

The EIP states this directly: the standard does not include replay protection. Domain separation reduces certain cross-domain collisions, but the application must define how an authorization becomes single-use or time-limited.

Typical controls include:

• a nonce consumed when the authorization is used;
• a deadline or expiry;
• the intended verifying contract and chain ID in the domain;
• an exact asset, amount, recipient, action, and account in the message;
• cancellation or revocation rules where required.

A nonce is like the serial number on a bank cheque. If the verifier records that number as spent, copying the cheque should not work again. If the application forgets to track it—or signs a message without enough context—the same valid signature may be reusable wherever the verifier accepts it.

Do not infer replay safety because a wallet displays “EIP-712.” Inspect whether the message includes a nonce and deadline, and rely on official protocol documentation or audited code to learn how they are enforced.

Security Risks and Failure Modes

A readable malicious request

Typed data can describe a harmful authorization perfectly. A token permit, marketplace order, or delegation may be validly formatted while granting more authority than intended. Read values, not just headings.

Misleading or missing context

An application controls its field names. A label such as beneficiary does not prove the address is safe. If the wallet omits nested fields, truncates an address, or fails to identify the verifying contract, reject the request.

Phishing and compromised front ends

A cloned site can request a genuine signature for an attacker-controlled contract. Confirm the browser origin separately from the EIP-712 signing domain, and verify contract addresses through official project documentation.

Signature reuse and broad permissions

Long deadlines, unbounded amounts, reusable nonces, or vague action fields increase the blast radius. A zero-gas prompt may authorize a relayer to execute later. For token permissions, compare the request with ERC-2612 Permit vs Permit2.

Smart-account differences

An externally owned account produces an ECDSA signature. A smart contract account may validate the same digest through ERC-1271 and programmable rules. Integrators need the correct path, and users should remember contract-wallet policies can change.

A Seven-Point Check Before Signing

1. Origin: Did you reach the app through a verified URL or bookmark?
2. Primary type: Does Permit, Order, Vote, or another type match what the interface promised?
3. Domain: Do the app name, chain ID, version, and verifying contract make sense?
4. Authority: What can the recipient, spender, operator, or delegate do?
5. Value: Is the token, amount, price, or limit exact and expected?
6. Lifetime: Is there a nonce, deadline, or expiry, and is it reasonable?
7. Clarity: Can you explain the result in one sentence? If not, reject it.

Frequently Asked Questions

Is EIP-712 safer than personal_sign?

It can give wallets more structured context and provides domain separation. Safety still depends on message design, wallet rendering, verifying logic, and your review. A malicious typed request remains malicious.

Does signing EIP-712 data send a transaction?

Usually no transaction is broadcast at signing time. The signature may authenticate you or authorize an action that another party submits later, so treat it as a potentially valuable credential.

Can I revoke an EIP-712 signature?

EIP-712 defines no universal revocation. A protocol may support nonce invalidation, order cancellation, allowance changes, or expiry. Check its official mechanism.

Why do wallets show different fields?

Wallets make different interface and decoding choices. Firmware, extension versions, hardware-screen limits, and nested-structure support can affect the display. Missing critical information is a reason to stop, not guess.

Is the signing-domain name the website domain?

Not necessarily. The EIP-712 name is supplied by the application. Verify the browser origin and on-chain verifying contract independently.

The Practical Takeaway

EIP-712 turns structured intent into a deterministic digest that wallets can display and applications can verify. Its useful ingredients are typed fields and domain separation. Its important limitation is equally clear: it does not make a request trustworthy or supply replay protection on its own.

Before signing, identify the action, domain, authority, value, nonce, and deadline. Reject missing or inconsistent details, keep permissions narrow, and verify through primary sources. This article is educational, not financial advice; crypto signatures can lead to total loss, so DYOR and use only funds you can afford to lose.