Founders & Origins3 min readEthereum (ETH)

EIP-712: Putting Something Readable Before the Sign Button

A wallet can protect a key while leaving its owner unsure what a signature means. EIP-712 gave messages a structure that people could inspect—and left applications responsible for what those signatures authorize.

EIP-712: Putting Something Readable Before the Sign Button

3-Minute Fast Briefing

  • The ParadoxEIP-712, created in September 2017, standardizes the hashing and signing of structured messages.
  • The Turning PointDomain information separates signing contexts; an application must still handle repeated use of a signature.
  • The LegacyERC-2612 shows the stakes: a message can authorize a token allowance without the owner sending the approval transaction.

Chronological Timeline

2017-09-12A structure for messages

EIP-712 is created with named, typed fields and domain separation.

2020-04-13A signature becomes an allowance

ERC-2612 specifies permit, including a nonce and a submission deadline.

A key can sign something its owner cannot read

On September 12, 2017, Remco Bloemen, Leonid Logvinov and Jacob Evans introduced EIP-712. Its starting problem was ordinary: a wallet could display a long hexadecimal string and ask a person to sign it. The cryptography could work perfectly while the owner had little idea what the message contained. The proposal gave data a defined structure, with named fields and types, so a wallet could show the substance of the request.[1]

The change was more than cosmetic. A sender, a recipient and a quantity could be represented as distinct fields rather than an unexplained byte string. The specification also defined a signing domain, with applicable fields such as an application name, version, chain identifier and verifying contract. The same-looking message in a different context need not produce the same signing result. These fields describe context; they do not certify a business as honest.[1]

The labels become part of the decision

MetaMask’s developer documentation makes the interface consequence explicit. Its eth_signTypedData_v4 method presents structured data for inspection, and it tells developers to treat the main type name, domain name and field names as part of the security interface. A technically correct request with confusing labels can still be hard for a human to judge. The structure supplies an opportunity to explain; the wallet and application must use it well.[2]

Readability therefore answers only one question: what data is being signed? Whether that data authorizes a login, an order or access to tokens depends on the application that accepts it. This is a design inference from the distinction between message representation and application behavior. A neatly arranged confirmation is not, by itself, a recommendation to accept.[1][2]

A permission can travel ahead of a transaction

ERC-2612, created on April 13, 2020, provides a concrete example. Its permit message names an owner, a spender, a value, a nonce and a deadline. A valid submission sets the spender’s allowance to that value and advances the nonce. Anyone can submit the permit; the owner need not personally send that approval transaction. The signature itself does not transfer tokens, but the resulting allowance can enable a later transferFrom operation.[3]

The nonce stops that permit from being successfully reused after it is consumed. The deadline limits when it can be submitted; it does not automatically expire an allowance already established. Someone still has to submit an onchain transaction for permit to take effect. EIP-712 expressly leaves replay handling to applications. Reading a signature request thus means considering both its fields and the action that a receiving contract will perform. The button stayed small; the decision in front of it became more visible.[1][3]

Connected Lore & Universe

Connected Stories in this Universe

Explore the chain reaction of historical breakthroughs, blunders, and legends.

Sources & References

  1. [1]Source 1: EIP-712: motivation, domain separation and replay boundaryEthereum Improvement Proposals · 2017-09-12Accessed 2026-09-24
  2. [2]Source 2: MetaMask: structured signing and the user-facing security interfaceMetaMaskAccessed 2026-09-24
  3. [3]Source 3: ERC-2612: allowance, nonce, deadline and submission semanticsEthereum Improvement Proposals · 2020-04-13Accessed 2026-09-24
← Back to all storiesExplore all coins →