ERC-7015 创作者署名：谁签的名，谁才算作者

一个很常见的错位

很多 NFT 合约并不是艺术家自己的钱包部署的。发起交易的可能是平台的部署服务、代运营的机构钱包、首个收藏者，或者某个智能账户钱包。于是出现了一个尴尬的默认规则：区块浏览器和平台把“提交部署交易的那个地址”当成创作者。真正的作者可能只是在链下签过一份文件，链上却查无此人。

ERC-7015 想纠正这个错位。它在标准仓库中的状态是 Review（同行评审中），属于尚在完善的提案，不是普遍生效的规范——这一点决定了下文的所有边界。

署名的做法：先签名，再部署

按照提案，署名的流程分三步：

1. 创作者对一组参数做 EIP-712 结构化签名。被签名的参数包含合约名称、符号、元数据哈希等与这个 NFT 合约相关的信息，形成一个 structHash。
2. 部署合约时，合约在部署交易中发出一个 CreatorAttribution 事件，事件字段里带上创作者地址、上述结构哈希和签名本身。
3. 任何平台或检视器都可以离线重建签名摘要、从签名中恢复出签名者地址，并验证恢复结果与事件中声明的创作者地址一致。

提案特别说明了两个字段的省略逻辑：chainId 不放进事件，因为可以从交易数据推断；verifyingContract 也不放，因为签名验证时的验证合约必须等于事件的发出者，也就是这个代币合约本身。验证通过的集合要匹配 ERC-1271 对合约钱包签名的处理，所以智能账户钱包签的名也能被认可。

结论是：如果事件存在且签名验证通过，署名应给 creator 字段对应的地址，而不是发部署交易的账户。

它能证明什么，不能证明什么

这个标准证明的是一件很具体的事：某个地址在某个时点对“部署这样一份合约”签署过授权。它能显著减少“代部署导致署错人”的问题，也给平台一个统一的核验入口。

但它不能证明：

• 图是谁画的。签名声明的是对合约部署的授权，不是著作权法意义上的创作证明。艺术归属纠纷要靠合同、创作过程记录和法律途径解决。
• 元数据内容没被换过。签名覆盖的是部署时刻的参数哈希，后续元数据改动需要别的机制（例如 ERC-4906 更新通知类接口）配合。
• 平台一定认账。标准还在评审阶段，是否展示、是否采信该事件完全取决于平台自己。链上没有这个事件的合约海量存在，没有事件不等于伪造，有事件也只是多了一条可核验线索。

买家可以做的核验

如果你看中的合集声称支持 ERC-7015，可以要求或在区块浏览器上自查：这个合约的部署交易里有没有 CreatorAttribution 事件；如果有，用支持该标准的工具跑一遍签名恢复，看恢复地址是否就是宣称的创作者地址。没有这个事件时，也别急着下结论——现阶段大多数存量合约都不带这个事件，署真凭据仍然要回到项目页面、社交账号历史、签约记录这些链外证据的交叉验证。反过来，如果你是准备发合集的创作者，正在考虑让部署方代刷交易，这个签名机制提供了一个比“事后发推澄清”更硬的选择：签名一旦进入部署交易，任何浏览器的任何索引器都能独立复核，澄清成本从每次纠纷一场降为零次。署名问题本质上是个索引问题——链上从来都有事实，缺的是让人查得到的字段。

风险提示：NFT 署名与版权归属问题可能涉及法律争议，本文仅为技术机制说明，不构成任何投资建议或法律意见。