签名前先看懂要付出什么：ERC-6865 链上 EIP-712 可视化

钱包弹出的 EIP-712 签名请求，普通用户看到的常是一堆字段名和哈希。链下解码方案存在钱包厂内：协议太多、业务逻辑太杂、升级太快，解码器永远追不完，误译有时比不译更危险。ERC-6865 把翻译责任还给协议自己：被签的合约必须提供一个视图函数，把载荷翻译成“你会付出什么、会收到什么、这份签名活多久”。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该标准状态为 Draft，2023 年 4 月 10 日创建，依赖 EIP-712。

一个函数，三段答案

合规做法是合约在 verifyingContract 的实现里放入 visualizeEIP712Message(encodedMessage, domainHash)：前者是 abi.encode 打包的 EIP-712 消息，后者是域分隔符哈希。返回的 Result 结构由三块组成。assetsOut 是用户将付出的资产列表，assetsIn 是即将收到的列表，二者都是 UserAssetMovement 数组——每项带资产代币地址、代币编号与数量数组，涵盖 ERC-20 与 ERC-721/1155 两类场景。Liveness 则给出这份签名的生效起点 from 与到期时刻 to，且规范要求 from 必须早于 to。钱包拿到结构化结果，就能把一屏黑话换成一张清单。

钱包侧的调用条件也被定义：当 EIP-712 消息的域分隔符同时含 verifyingContract 与 chainId 字段时，钱包可以（MAY）在对应链的对应合约上调用可视化函数；域内缺这两个字段时，钱包应当（SHOULD）忽略本提案——这条边界防止把调用发向错误对象。

它防的到底是什么错

标准的靶心是钓鱼与误签：用户看不懂签名内容，攻击者把“授权转走你的 NFT”伪装成一次普通登录签名。把解码搬到链上还有三重工程红利，标准文本列为可扩、可信、可维护——由写合约的人负责翻译，比第三方逆向业务逻辑更接近真实语义，协议升级时翻译与代码同仓演进。

读者应当知道的两个前提

第一，可视化依赖“自愿 + 诚实”：合约若没实现该函数，或返回与真实逻辑不符的清单，标准本身没有强制手段——链上代码仍是最终事实，可视化是锦上添花的说明书。第二，钱包是否调用、何时调用、怎么展示，取决于钱包适配；同一份接口在不同钱包里的呈现深浅不一。

为什么钱包厂和协议方都该读这一页

标准把三条工程账算得很直：可扩，因为新增协议只需在自己的合约里带上视图函数，钱包不必为每个项目维护解析器；可信，因为翻译由掌握业务逻辑的一方提供，逆向猜测式的可视化有时比空白更误导；可维护，因为说明书与合约代码同仓演进，逻辑升级和文案升级在同一次部署里对齐。反面情形文本也写了：钱包遇到域分隔符缺少 verifyingContract 或 chainId 的消息应当整体跳过本机制，避免向错误的合约发起视图调用——这两项恰是 EIP-712 域标准字段，规范项目本来就该填全。对用户最有价值的字段其实是 Liveness：一份签名从 from 到 to 的有效期区间，把“这行授权会悬多久”从默认无限改成了显式承诺，from 必须早于 to 的校验让“永不过期”这种可疑写法无处藏身。也要如实标注局限：实现该函数的合约目前凤毛麟角，Draft 状态意味着它更像一份给钱包生态的议程清单而非可用现状；在此之前，交易模拟与第三方解码仍是普通用户的主要防线，可视化协议是它们值得联合的下一次升级。同时留一个思考给协议开发者：可视化函数与被描述逻辑同仓部署，意味着“说明书”本身也可能被升级或被权限替换，把 visualizer 的实现者权限纳入审计范围，和审计转账逻辑同等重要——毕竟对普通用户来说，弹窗里的清单几乎就是合约的全部人格。

给普通持有人的落地建议：看到签名弹窗只有字段名没有资产清单时，先确认这条 EIP-712 消息的域里有没有 verifyingContract；再结合交易模拟工具或第三方解码器交叉核对付出项；涉及 NFT 授权类签名时，把“付出清单”里的每一项都当成即将生效的权限来读，宁可慢一分钟，不要盲签一次。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。