链上也要签字画押：ERC-5289 让合约问一句“条款你读了吗”

关于 NFT 最流传也最经不起推敲的一句话，是“买了 NFT 就拥有作品版权”。标准文本自己就把这层窗户纸捅破了：NFT 被宣传成持有和证明版权的方式，在实践中几乎从未如此——绝大多数 NFT 在法律上没有任何约束意义，少数有法律含义的，往往也只是给第一任持有人一份有限许可，对后来的买家什么都没说。ERC-5289（2022 年 7 月 16 日创建，提案状态 Review）想补的正是这段“链上动作与线下条款脱节”的缝：让合约能标准化地问一句“这份文件你签过吗”，并把答案记在链上。

文档库、签名位与时间戳

这份标准的构件不多。一个“法律文档库”合约负责三件事：用 legalDocument(documentId) 公布文档内容链接——标准推荐放 IPFS，格式要求 PDF、HTML 这类通用格式；用 documentSigned(user, documentId) 回答某个地址是否签过；用 documentSignedAt 给出签署时间。地址真正签字的动作是调用 signDocument(signer, documentId)，成功即广播 DocumentSigned(signer, documentId) 事件，链下则留下一个可取证的链条：链上的某个地址在某时刻确认了对某份哈希可定位文档的同意。更精巧的是请求环节：合约不强行拦路，而是借助 ERC-5568 的信号机制在用户调用时“弹出”签署请求——回滚数据里编码着文档库地址和文档编号，钱包前端据此提示用户先签合同再继续。换句话说，它把“先读条款再点确认”做成了可选配的链上流程，而不是靠用户自觉。

它想解决、且只解决 NFT 版权问题的一半

为什么 NFT 圈需要它？标准动机部分给出一个常被忽略的断层：很多项目确实准备了使用授权书、版税协议或实体兑换合同，但这些文件躺在帮助中心，谁看过、谁同意过，没有任何记录。5289 提供的是“同意发生过”的可验证痕迹——将来若发生争议，链上能出示地址、时间、文档编号三要素，比“网站条款发布于某年”的举证颗粒度细得多。但同样必须把边界钉死：第一，实现 5289 不会把 NFT 变成版权证书，文档本身写了什么才是关键，接口只保管签字回执；第二，链上签名在多少法域具有法律效力是律师的问题，标准文本特意声明作者们不是律师、文件不构成法律建议；第三，签署记录绑定的是地址而非自然人，钱包转手后“前主人签过的约”是否约束新持有人，取决于条款文字而不是这条事件。

看到“链上合同”四个字之后的核对动作

如果某个项目宣传“全部条款上链可验证”，可以把期待值校准到具体动作：先查文档库合约的 legalDocument 给出的链接是否能打开、内容是不是完整协议而非占位符；再对目标合约做 ERC-165 探测（它要求实现 165），确认 signDocument 的调用是否真的发生在mint或交易主路径上，而不是一个装饰性的独立合约；最后检查自己的签署状态 documentSigned，确认回执归属的是你将要长期持有资产的那个地址。一个只把协议 PDF 挂上 IPFS、却从不记录任何签署的“公证系统”，严格来说只完成了一半的语义。这条路线也不是孤例：ERC-8325 走的是把资产法律锚点结构化登记的思路，而 5289 专注于“用户点头”这个动作本身。本文解释的是接口与举证痕迹，不构成法律意见，也不构成任何买卖建议。

从取证视角看它和“电子协议”的区别

传统网站的格式合同留证方式是“条款页面带发布日期”，争议时平台方需要证明两件事：你在某时刻看过该版本、该版本确实如此内容——第一件几乎拿不出直接证据。5289 这类公证结构把链条压缩成一条：文档内容按哈希定位、同意行为带地址与时间戳，两个证据点都落在不可改的公共账本上。差异在转手场景最锋利：藏品的下一任买家无法主张“我签过”，他只能主张条款随代币流转——条款是否随转，答案写在文档文字里，链上签署记录只证明前任同意过。也正因为如此，标准正文才强调它解决的是 privity（合同相对性）层面的接口问题，不替你判断哪国法院会采纳这种证据、也不替你写条款。一个常见的误读要顺手拆掉：DocumentSigned 事件证明的是“该地址确认过该文档”，不是“该自然人签了具有法律约束力的合同”——地址与身份的对应、条款本身的合法性，仍然在协议之外。把它当作更细颗粒度的取证基础设施去理解，期待就不会跑偏。