# Typed-data signatures: reading EIP-712 messages

EIP-712 defines how structured typed data is hashed and signed, including a domain that separates signing contexts. It can make wallet requests more interpretable, but does not make their requested permissions safe. Applications must still implement replay controls, and a signature may authorize valuable actions without an immediate on-chain fee.

Evidence: [Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712); [Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612)

Canonical: https://degreesofsatoshi.com/encyclopedia/eip-712-typed-data/
Published: 2026-10-02
Substantively modified: 2026-10-02
Independently verified by an automated reviewer: 2026-10-02T18:12:41.505Z
Data current through: 2026-10-02

AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied.

## Key facts

- **Structure:** The signed digest commits to typed message data and a domain separator. ([Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712))
- **Domain:** Domain fields can include name, version, chainId and verifyingContract. ([Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712))
- **Replay:** EIP-712 explicitly leaves application replay handling to implementers. ([Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712))

## Read both the domain and the action

The domain identifies the signing context, while the typed message describes the requested operation. A familiar application name does not replace checking the verifying contract, chain and message fields.

Look for the recipient or spender, asset, amount, deadline and nonce where the application defines them. Not every typed message uses the same field names or permissions.

Evidence: [Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712)

## A signature can be submitted later by someone else

A token permit can let a relayer submit a signed allowance authorization. The user may pay no gas when signing, yet the accepted permit can create spending authority.

“No gas” describes the signing step, not the absence of financial consequences. Do not classify every off-chain signature as a harmless login.

Evidence: [Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612)

## Readable fields do not enforce themselves

The verifying application must check the domain and implement appropriate one-time-use, deadline or idempotency rules. Including a field in a display is insufficient if the verifier does not enforce it.

A security review therefore examines both the message a wallet signs and the contract logic that accepts it.

Evidence: [Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712)

## Questions

### Does EIP-712 automatically prevent a signature from being used twice?

No. The standard specifies typed signing and domain separation. The application must reject unwanted repeats or make repeated execution harmless.

Evidence: [Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712)

## Claims and scope

### eip-712-typed-data-quick-answer

EIP-712 defines how structured typed data is hashed and signed, including a domain that separates signing contexts. It can make wallet requests more interpretable, but does not make their requested permissions safe. Applications must still implement replay controls, and a signature may authorize valuable actions without an immediate on-chain fee.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

### eip-712-typed-data-fact-structure

Structure: The signed digest commits to typed message data and a domain separator.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

### eip-712-typed-data-fact-domain

Domain: Domain fields can include name, version, chainId and verifyingContract.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

### eip-712-typed-data-fact-replay

Replay: EIP-712 explicitly leaves application replay handling to implementers.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

## Sources

- [Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) — Ethereum Improvement Proposals. Typed-data encoding and domain fields; replay protection is application-specific. Locator: Specification; Security Considerations. Retrieved: 2026-10-02T17:03:42.239Z.
- [Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) — Ethereum Improvement Proposals. Signed token allowances, deadlines, nonces and domain checks. Locator: Specification; Security Considerations. Retrieved: 2026-10-02T17:03:42.295Z.

## Revision history

- 2026-10-02: First publication after primary-source research and independent automated verification.

## Cite this entry

Degrees of Satoshi editorial project. “Typed-data signatures: reading EIP-712 messages.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/eip-712-typed-data/