Imagine your application wants a user to authorize an off-chain action:<\/p>\n
Transfer 100 USDC
to 0x…
nonce 42
deadline …<\/p>\n
You could serialize that data into a string and ask the wallet to sign it. But then subtle questions appear: Which serialization is canonical? Is 100 a string or an integer? Which contract is allowed to consume the signature? Can the same signature work on another\u00a0chain?<\/p>\n
EIP-712<\/strong> solves the encoding side of this problem by defining a deterministic way to hash and sign typed structured data. Instead of signing arbitrary JSON text, the wallet signs a digest derived from explicit Solidity-like types, the message, and an application-specific domain.<\/p>\n That makes EIP-712 particularly useful for permits, meta-transactions, order protocols, delegated actions, and other off-chain authorizations that are later verified on-chain.<\/p>\n Ethereum wallets can sign arbitrary messages using mechanisms such as personal_sign. This works well when the thing being signed really is a human-readable message.<\/p>\n Structured application data is different.<\/p>\n Suppose two applications serialize this object differently:<\/p>\n {“to”:”0x…”,”amount”:”100″}<\/p>\n and:<\/p>\n { They may represent the same intent to a developer, but they are different byte\u00a0strings.<\/p>\n Plain message signing also does not inherently describe Solidity types. A wallet sees bytes or text rather than an explicit structure such as address to, uint256 amount, and uint256\u00a0nonce.<\/p>\n EIP-712 defines a typed encoding and hashing scheme instead. Wallets can use that structure to present meaningful fields to the user rather than an opaque serialized blob.<\/p>\n Consider a transfer authorization:<\/p>\n const domain = { There are four important pieces.<\/p>\n Domain<\/strong> identifies the application context in which the signature is\u00a0valid.<\/p>\n Types<\/strong> define the exact structure and Solidity-compatible types being\u00a0signed.<\/p>\n Primary type<\/strong> is the root structure\u200a\u2014\u200aTransfer in this\u00a0example.<\/p>\n Message<\/strong> is the actual set of\u00a0values.<\/p>\n The domain is what gives EIP-712 its domain separation<\/strong>. Two applications can sign structurally identical Transfer messages without necessarily producing interchangeable signatures.<\/p>\n For production authorizations, two domain fields are especially important:<\/p>\n chainId chainId binds the signature to a network, while verifyingContract binds it to a particular contract address. Both become part of the EIP-712 domain separator and therefore affect the final\u00a0digest.<\/p>\n Without appropriate domain separation, a signature intended for one context may be meaningful in\u00a0another.<\/p>\n EIP-712 does not sign your JavaScript object or its JSON serialization.<\/p>\n Conceptually, the final digest\u00a0is:<\/p>\n keccak256( The 0x1901 prefix comes from the signed-data encoding scheme used by\u00a0EIP-712.<\/p>\n For our Transfer structure, its encoded type is effectively:<\/p>\n Transfer(address to,uint256 amount,uint256 nonce,uint256 deadline)<\/p>\n Hashing this definition produces the typeHash:<\/p>\n keccak256( The message\u2019s structHash is then calculated from the type hash and encoded field\u00a0values.<\/p>\n Conceptually:<\/p>\n keccak256( The domain is hashed using the same EIP-712 struct-hashing rules to produce the domain separator. Finally, the message struct hash and domain separator are combined into one\u00a0digest.<\/p>\n This digest\u200a\u2014\u200anot JSON.stringify(value)\u200a\u2014\u200ais what ultimately gets\u00a0signed.<\/p>\n That distinction is the reason JavaScript and Solidity can independently reconstruct exactly the same\u00a0value.<\/p>\n At this point, the full EIP-712 flow looks like\u00a0this:<\/p>\n With ethers v6, the high-level API is signer.signTypedData(domain, types, value). ethers handles the EIP-712 encoding and hashing internally.<\/p>\n A browser example can stay\u00a0compact:<\/p>\n import { BrowserProvider } from “ethers”;<\/p>\n const provider = new BrowserProvider(window.ethereum); Notice that the frontend does not manually hash individual fields. That is intentional.<\/p>\n Unless you are implementing infrastructure specifically around EIP-712 encoding, use the library implementation instead of recreating the algorithm yourself.<\/p>\n The important part is that the frontend schema must exactly match the Solidity\u00a0schema<\/strong>.<\/p>\n On-chain, OpenZeppelin\u2019s EIP712 contract reconstructs the domain-aware digest, while ECDSA performs signer recovery. OpenZeppelin explicitly documents the _hashTypedDataV4(structHash) plus ECDSA.recover pattern.<\/p>\n Here is the Solidity side of the same\u00a0example:<\/p>\n \/\/ SPDX-License-Identifier: MIT import {EIP712} from _hashTypedDataV4 combines the message struct hash with the contract’s EIP-712 domain separator and produces the final digest expected by the signature verification logic.<\/p>\n Using OpenZeppelin is preferable to manually maintaining EIP-712 domain and ECDSA recovery code. Apart from reducing code, it avoids subtle mistakes around domain construction and signature handling.<\/p>\n One additional production nuance: ECDSA.recover verifies signatures from EOAs. If your application must support smart contract wallets, account abstraction, or multisigs, you should also account for ERC-1271-style contract signatures rather than assuming every signer has an ECDSA private\u00a0key.<\/p>\n EIP-712 gives you deterministic structured signing and domain separation. It does not<\/strong> automatically make an authorization single-use.<\/p>\n Consider this perfectly valid signature:<\/p>\n Alice authorizes transfer X<\/p>\n If the contract accepts it today and nothing in contract state marks it as consumed, an attacker may simply submit the same authorization again.<\/p>\n That is why production messages commonly contain a\u00a0nonce:<\/p>\n uint256 nonce;<\/p>\n and the contract consumes\u00a0it:<\/p>\n mapping(address => mapping(uint256 => bool)) A deadline prevents an authorization from remaining usable indefinitely.<\/p>\n Meanwhile, chainId and verifyingContract provide domain-level protection against signatures being reused in different EIP-712\u00a0domains.<\/p>\n These controls solve related but different problems:<\/p>\n nonce -> prevents repeated execution The core rule is\u00a0simple:<\/p>\n A valid signature is not necessarily a valid authorization forever.<\/em><\/strong><\/p>\n Signature verification proves who signed a digest. Your contract still decides whether that authorization is currently acceptable.<\/p>\n Most EIP-712 bugs are not cryptography bugs. They are schema or authorization bugs.<\/p>\n 1. Different field order between frontend and Solidity.<\/strong> 2. Type mismatches.<\/strong> 3. Different domain name or version.<\/strong> 4. Missing nonce.<\/strong> 5. Missing deadline.<\/strong> 6. Using <\/strong>abi.encodePacked for the struct hash.<\/strong> 7. Incorrect domain assumptions around deployments or proxies.<\/strong> EIP-712 turns Ethereum signatures from loosely defined byte-string signing into deterministic, typed, domain-separated authorization.<\/p>\n The flow is straightforward once the layers are separated:<\/p>\n JavaScript object The standard handles how structured data becomes a signable digest<\/strong>. Your application still owns what that signature authorizes, when it expires, and whether it has already been\u00a0used<\/strong>.<\/p>\n That separation is the key to implementing EIP-712 correctly in production.<\/p>\n EIP-712 Explained: Sign and Verify Typed Data with ethers.js and Solidity<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":" Imagine your application wants a user to authorize an off-chain action: Transfer 100 USDCto 0x…nonce 42deadline … You could serialize that data into a string and ask the wallet to sign it. But then subtle questions appear: Which serialization is canonical? Is 100 a string or an integer? Which contract is allowed to consume the […]<\/p>\n","protected":false},"author":0,"featured_media":214414,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-214413","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/214413"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=214413"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/214413\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/214414"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=214413"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=214413"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=214413"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Why signing plain strings is not\u00a0enough<\/h3>\n
“amount”: “100”,
“to”: “0x…”
}<\/p>\nEIP-712 Explained: Domain, Types, and\u00a0Message<\/h3>\n
name: “ExampleApp”,
version: “1”,
chainId: 1,
verifyingContract: “0x1234567890123456789012345678901234567890”,
};
const types = {
Transfer: [
{ name: “to”, type: “address” },
{ name: “amount”, type: “uint256” },
{ name: “nonce”, type: “uint256” },
{ name: “deadline”, type: “uint256” },
],
};
const value = {
to,
amount,
nonce,
deadline,
};<\/p>\n
verifyingContract<\/p>\nHow the EIP-712 Hash Is\u00a0Built<\/h3>\n
0x1901 ||
domainSeparator ||
hashStruct(message)
)<\/p>\n
“Transfer(address to,uint256 amount,uint256 nonce,uint256 deadline)”
)<\/p>\n
abi.encode(
TRANSFER_TYPEHASH,
to,
amount,
nonce,
deadline
)
)<\/p>\nSigning EIP-712 Typed Data in JavaScript<\/h3>\n
const signer = await provider.getSigner();
const chainId = (await provider.getNetwork()).chainId;
const domain = {
name: “ExampleApp”,
version: “1”,
chainId,
verifyingContract: “0x1234567890123456789012345678901234567890”,
};
const types = {
Transfer: [
{ name: “to”, type: “address” },
{ name: “amount”, type: “uint256” },
{ name: “nonce”, type: “uint256” },
{ name: “deadline”, type: “uint256” },
],
};
const value = {
to: “0x0000000000000000000000000000000000000000”,
amount: 100_000_000n, \/\/ 100 USDC with 6 decimals
nonce: 42n,
deadline: BigInt(Math.floor(Date.now() \/ 1000) + 3600),
};
const signature = await signer.signTypedData(
domain,
types,
value
);<\/p>\nVerifying an EIP-712 Signature in\u00a0Solidity<\/h3>\n
pragma solidity ^0.8.20;<\/p>\n
“@openzeppelin\/contracts\/utils\/cryptography\/EIP712.sol”;
import {ECDSA} from
“@openzeppelin\/contracts\/utils\/cryptography\/ECDSA.sol”;
contract TransferAuthorizer is EIP712 {
struct Transfer {
address to;
uint256 amount;
uint256 nonce;
uint256 deadline;
}
bytes32 private constant TRANSFER_TYPEHASH =
keccak256(
“Transfer(address to,uint256 amount,uint256 nonce,uint256 deadline)”
);
mapping(address => mapping(uint256 => bool))
public usedNonces;
constructor() EIP712(“ExampleApp”, “1”) {}
function authorizeTransfer(
address expectedSigner,
Transfer calldata transfer,
bytes calldata signature
) external {
require(
block.timestamp <= transfer.deadline,
“Authorization expired”
);
require(
!usedNonces[expectedSigner][transfer.nonce],
“Nonce already used”
);
bytes32 structHash = keccak256(
abi.encode(
TRANSFER_TYPEHASH,
transfer.to,
transfer.amount,
transfer.nonce,
transfer.deadline
)
);
bytes32 digest = _hashTypedDataV4(structHash);
address recoveredSigner =
ECDSA.recover(digest, signature);
require(
recoveredSigner == expectedSigner,
“Invalid signature”
);
usedNonces[expectedSigner][transfer.nonce] = true;
\/\/ Execute the authorized business operation here.
}
}<\/p>\nEIP-712 Does Not Prevent Replays for\u00a0You<\/h3>\n
public usedNonces;<\/p>\n
deadline -> limits validity in time
chainId -> binds the domain to a chain
verifyingContract -> binds the domain to a contract<\/p>\nCommon EIP-712 Mistakes in Production<\/h3>\n
Transfer(address to,uint256 amount,…) must match exactly on both\u00a0sides.<\/p>\n
uint256, address, bytes32, and string are not interchangeable representations.<\/p>\n
ExampleApp version 1 and ExampleApp version 2 intentionally produce different domains.<\/p>\n
A correctly signed authorization may be replayable if contract state does not consume something unique.<\/p>\n
Without expiration, an unused signature may remain actionable much longer than intended.<\/p>\n
The standard EIP-712 struct encoding corresponds to the ABI-encoded values; OpenZeppelin’s documented pattern uses abi.encode.<\/p>\n
Your frontend must sign against the same effective EIP-712 domain the verification contract reconstructs. Contract addresses, chain changes, and domain-version changes should be treated as protocol changes, not frontend\u00a0details.<\/p>\nConclusion<\/h3>\n
\u2193
typed EIP-712 structure
\u2193
domain separator + struct hash
\u2193
EIP-712 digest
\u2193
wallet signature
\u2193
Solidity rebuilds digest
\u2193
recover signer
\u2193
apply nonce\/deadline\/business rules<\/p>\n