铸造者不等于作者：ERC-5375 如何用同意证明给 NFT 署名

很多人默认“谁铸造，谁是作者”。现实里这两种角色经常分离：合约批量铸造、懒铸造（lazy mint）、不擅长技术流程的艺术家委托平台代铸——铸造交易里的 tx.origin 或 msg.sender 都只能说明谁发起了那笔交易，说明不了作品出自谁手。ERC-5375 想补的就是这块：给 NFT 加一个标准化的署名信息，并用签名证明“被署名的人确实同意被署名”。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该标准标注为 Final，2022 年 7 月 30 日创建，依赖 ERC-55、ERC-155、EIP-712、ERC-721 与 ERC-1155。

authorInfo 放在元数据的最外层

标准引入的新字段叫 authorInfo，位置在 NFT 元数据文档的顶层：支持 ERC-721 元数据扩展的合约，tokenURI 指向的 JSON 必须包含它；支持 ERC-1155 的则是 uri 指向的文档。字段内部由两部分组成。consentInfo 是给验证者用的辅助信息，记录 EIP-155 链编号、代币编号和合约地址；authors 是作者数组，每一项至少含一个遵循 EIP-55 校验和大小写规则的作者地址，数组允许为空——也就是说合规实现可以不声明任何作者，但不能没有这个字段。

同意证明怎么签

当作者条目带上 consent 信息时，就构成一份作者同意证明（Author Consent Proof）。它由三部分组成：consentData（含版本号、签发者地址、以及作者愿意认证的元数据字段清单 metadataFields）、作者的 EVM 公钥，和一份对 Author 结构（合约地址 subject、代币编号 tokenId、字段内容 JSON metadata）做的 EIP-712 签名。验证者不需要信任铸造方的一面之词：从元数据里的字段内容重建签名消息，恢复出签名地址，再和声明的作者地址对一下，就能确认“这位作者是否同意被这样署名”。标准还特别写明：metadataFields 只是顶层字段的子集，作者可以只对自己认可的那几项负责。

标准自己划下的关键边界

摘要是整份文本最该被读者记住的一句：同意证明不是作者证明。地址可以没有参与创作而签下一份同意；反过来说，这份标准验证的是“同意被署名的意愿”，不是“作品确实由此人创作”这一事实。它解决的场景是防止合约或铸造方未经授权把别人写成作者，而不是鉴别一幅画是谁画的。把它当版权登记用，是用错了工具。

验证者视角的三个追问

第一问：这份 consent 到底认证了什么？签名结构 Author 里的 metadata 只覆盖 metadataFields 列出的字段，作者完全可以只认证图像哈希而不认证价格描述——验证时应当把重建消息所用的字段集合与元数据逐项比对，而不只看签名能不能恢复出地址。第二问：为什么作者数组会是空的？标准允许 authors 为空数组，合规与“有署名”是两回事，空数组的项目等于主动放弃了这一层信息。第三问：minter 为什么不让作者自己铸？标准列举的典型场景正是答案：合约铸造、懒铸造、不谙技术的作者委托中介代铸——铸造地址与创作者分离越常态，authorInfo 越有存在的必要。同时记住摘要里那句限定：地址可以在没有创作作品的前提下签出同意，这份接口把“声称他人是作者”的成本抬高了，但作品归属的最终裁判仍然是事实与法律，不是 JSON 字段。再补一个工程细节：标准要求所有地址遵循 EIP-55 的校验和大小写规则，验证脚本若直接用全小写或全大写形式做字符串比对，会在大小写敏感的检查里误判“签名地址与声明地址不符”，这是实现层最容易制造的假阳性，遇到此类报错先归一化校验和再下结论。

作为持有人或买家，可以按这个顺序核验：先取 tokenURI 看 authorInfo 是否存在、数组是否非空；若有 consent，检查 consentInfo 三元组与链上代币是否一致，再用 EIP-712 恢复签名地址；最后记住所有验证结论都只覆盖“同意”，作品本身的版权归属仍以作者明示的许可条款为准。本文为协议机制科普，不构成任何投资建议，也不构成版权法律意见；标准内容以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。