官方的 MASTR 标志 MASTR 支持这项工作
目录
← 知识库首页

Technical reference

EIP-712 domains: what stops a signature travelling to another application?

Readable fields help, but the signed domain and replay controls still matter.

Source-based reference · Updated 12 September 2026

研究文章和参考条目以英语发布。导航提供七种语言。

本文目录
  1. The domain is part of the signed data
  2. Replay protection is another requirement
  3. Read these fields together
  4. Sources

The domain is part of the signed data

EIP-712 separates typed-message structure from domain information such as application name, version, chain ID and verifying contract. The signature commits to the encoded message and domain. A familiar application name alone is weak evidence: a malicious application can ask the wallet to display that name too.

Read the whole authorisation. Which chain and verifying contract? Which spender, amount and action? Which nonce and expiry are enforced?
Read the whole authorisation. Which chain and verifying contract? Which spender, amount and action? Which nonce and expiry are enforced?
查看完整图表

Replay protection is another requirement

The standard does not itself provide replay protection. The application needs to reject already-used or expired authorisations where repeated execution would be unsafe. A nonce in the interface is only useful when verification checks and consumes the intended nonce.

Read these fields together

Compare the chain ID and verifying contract with the application you intended to use. Then inspect the spender, recipient, value, deadline and nonce in the actual message, where those fields exist. A harmless-looking title cannot reduce the authority of the signed contents. For a reproduced finding, retain the complete typed-data payload rather than just the wallet's shortened preview.

Sources

相关阅读

MASTR

支持独立研究

这里的调查、原始证据和指南均可免费阅读。自愿捐赠帮助支付研究成本,让 MASTR 能够继续提供工具。

打开钱包