合约里的安全联系人：ERC-5437 想让漏洞报告有门可敲

发现一枚热门 NFT 合约有严重缺陷，第一反应常常是“我该告诉谁”。公告发得太快会先发给了小偷，私信项目方又可能石沉大海。ERC-5437 试图给智能合约装一部“安全热线”：合约地址本身就能查出官方的加密接收渠道。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该提案状态为 Stagnant。

接口只做一件事：把钥匙公开

核心是必须实现的 getSecurityContact(type, data)：传入一个类型字节，返回加密用的 publicKey 与投递用的 extraData。type 的合法区间是十六进制 0x10 到 0x7f，两头区间保留给未来；类型表里规定了常见的加密方案，例如 RSA 或 PGP 一类的公钥格式，公钥以 ASCII armored 形式返回。报告者用这把公钥加密漏洞详情，再按 extraData 指明的目的地投递——链上地址给出，链下投递自便。选填件还包括 setSecurityContact（更新联系人并发出变更事件）、securityNotify（允许带价值的通知）和 bountyPolicy（悬赏政策查询）。整套设计的重心只有一句：让“官方收信地址”成为任何人可用一笔免 Gas 的 view 调用查到的事实，而不是猜出来的。

Stagnant 之下的现实

提案自 2022 年创建，如今处于 Stagnant，主因是社区推进停滞、实际部署稀少。这意味着今天绝大多数 NFT 合约并不会回答这个查询，把“没查到安全联系人”当成“项目方不在乎安全”并不公平，反之查到也不等于承诺了赏金或响应时限。接口文本里连 setSecurityContact 都还带着“考虑在定稿前移除”的批注，可见其未完成度，引用细节必须以仓库正文为准。

今天的白帽动线

维护者一侧的成本与顾虑

为什么这么直观的接口用者寥寥？站在项目方立场能算清这笔账：公开加密接收渠道等于向全网广播“来我这里找洞”，接收能力弱的团队宁愿不声明；设置联系人还牵出责任叙事——“收到不回复”会成为舆论把柄；加密公钥的托管、轮换、撤销本身又是运维成本。更现实的是，头部协议普遍已经接入漏洞赏金平台与托管披露服务，合约里再嵌一份联系人显得冗余。规范文本里那些“考虑移除”的批注，正是这种两难在文档上的投影。对普通用户的含义：查不到 getSecurityContact 不代表项目不设防，评估安全姿态应看赏金计划历史、代码审计记录与事件响应速度这三样更硬的证据。

从接口到实践的最小闭环

若把它当作项目方的防御清单，落地路径其实很短：在合约里实现 getSecurityContact，type 用 0x10、公钥用 GnuPG 生成的 RSA/3072、extraData 填符合 RFC 2822 的邮箱；用离线设备保管对应私钥，为密钥设置轮换事件 SecurityContactChanged；对外公告链上查询方法本身。这套动作传递的信号比“我们重视安全”的口号具体得多——它证明团队预设了接收通道、准备了密钥管理、并且默认所有通信可加密。对发现漏洞的人，一个能加密直达的官方地址，就是缩短秘密披露窗口最短的一块砖。

给报告者的检查单

发信前自查三件事：公钥是否属于该合约当前事件声明的联系人、信封是否只装复现步骤不含资产动用、目的地是否与 extraData 一致。三问都过再发送。

在这个接口普及之前，负责任的披露仍靠人把流程走对：先在授权测试环境或模拟中确认问题，绝不挪用他人资产、不抢先在公开渠道贴细节；优先找项目公告页、代码仓库安全说明、知名漏洞赏金平台这类正式渠道；沟通期保持秘密披露，给对方合理的修复窗口，修复前不做交易获利。披露本身是防御性工作，边界在于只报告、不利用。本文为安全防护科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。