What is EIP-712?

An Ethereum standard for signing structured data, so a wallet can show a readable list of fields instead of an unintelligible hash.

It is what lets a signature request display the token, the spender, the amount, and the deadline in plain terms, which is why it matters for safety as well as convenience. Many permission grants and off-chain order signatures use it, including gasless approvals. A readable prompt is still only as trustworthy as the site that produced it, so the fields deserve reading rather than glancing at.

The mistake worth naming is thinking a signature is harmless because no transaction is being sent and no gas is being paid. A signature can authorize someone else to move your tokens, or to fill an order against your wallet, whenever they choose to submit it.

How it works

Before this standard, signing meant approving an opaque byte string, and the only honest thing a wallet could show was a hash. EIP-712 defines a way to describe the data's shape so the wallet can render it.

The standard has three moving parts (source: EIP-712):

• A type definition. The message declares its fields and their types, for example an owner address, a spender address, a value, a nonce, and a deadline.
• A domain separator. This binds the signature to a specific contract, a specific chain identifier, and a named application, so a signature harvested for one contract cannot be replayed against another.
• A deterministic encoding. Both the wallet and the verifying contract hash the structured data the same way, so what you saw is what the contract checks.

Two very common uses ride on it. Permit-style token approvals let you sign a permission off chain that someone else submits, so you spend no gas. Off-chain order books, including many nft marketplaces, take a signed order and settle it later when a counterparty appears.

The domain separator is the safety feature people overlook. Check that the contract address and the chain identifier in the prompt match the application you believe you are using.

Example

An illustrative permit prompt shows: owner, your address; spender, a router contract; value, 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,935; deadline, a timestamp far in the future. That value is the maximum a 256-bit number can hold, meaning unlimited. Signing it grants that contract permission over your entire balance of that token until you revoke it, without any transaction appearing in your history at the time you sign.

Why it matters when you buy

Buying through a decentralized venue or a marketplace usually means signing at least one of these, and the signature is where the risk sits rather than in the swap itself. Prefer venues and wallets that show the decoded fields, and review outstanding permissions periodically. For custodial routes that avoid signatures entirely, compare venues at the exchange pages.

Related terms

blind signing — the unreadable alternative this replaced, token approval — the permission usually being granted, approval revocation — how to withdraw it, chain id — part of the domain separator, eip — the proposal format, wallet drainer — what abuses these prompts.

Questions

Is signing a message safer than sending a transaction?

Not necessarily. A signature costs no gas and creates no immediate on-chain record, but it can authorize the same token movements a transaction would. Read the fields either way.

What should I check in an EIP-712 prompt?

The spender address, the amount, the deadline, and the domain: the contract address and chain identifier the signature is bound to. If the site name in the prompt does not match the site you are on, stop.

Can I revoke something I signed?

A permit that has not been submitted can be invalidated by using the nonce it depends on, and an allowance already granted can be set back to zero. Both require an on-chain transaction, so both cost gas.