ERC-1523 把保单做成 NFT：链上保险资产的字段与边界

保险保单天生是”非同质”的：绑定特定客户、特定标的、特定保费与期间，理论上和 NFT 的数据结构一拍即合。ERC-1523 就是在 2018 年 10 月 10 日提出的这个想法：给保单定义一套 ERC-721 之上的最小标准结构。按 ercs 仓库记录，这份提案状态为 Stagnant，但它保留了完整的技术文本，是观察”现实资产上链该带哪些字段”的现成样本——比大多数 RWA 叙事的白皮书具体得多。

合规门槛：三张接口缺一不可

提案写法是强约束：一份合规的 ERC-1523 保单必须遵守 ERC-721 代币标准，同时实现 ERC-721 Metadata 与 ERC-721 Enumerable 接口，合约给出接口标识 0x5a04be32。Enumerable 被列为主接口而不是可选扩展，原因值得注意：保险场景需要直接回答”这份合约管下到底有多少张保单、清单是什么”，供核保与审计核对，靠事后数事件不够硬。name 与 symbol 允许实现者自行选择值，标准不强制叫”保险”。

保单元数据：用路径哈希当属性钥匙

这份标准最有辨识度的设计是保单属性扩展。属性不写死成固定字段表，而是用”属性路径”标识——例如某字段的路径是 /properties/name，取 keccak256 哈希作为链上的属性键，配套 policyMetadata 之类的查询函数按键取值。这样任意复杂的产品条款（承保范围、免赔额、特别约定）都能在不改合约结构的前提下逐键写入和读取，合约层面只维护”键（路径哈希）到值”的映射。提案把这套结构用于所有保单共有的字段，各险种差异则留给路径体系自身扩展。

必须分清的三层：链上字段、承保事实、法律效力

把这三层分开，才不会被”保单上链”四个字带偏。第一层是链上字段：合约里确实记录了一组可查询的属性，这是可验证的事实。第二层是承保事实：链上写”承保某标的至某日期”，与保险公司核心系统是否真的出过这份保单、理赔时是否按同一版本条款执行，是两套账。第三层是法律效力：合约字段既不能创设保险合同，也不能替代监管要求的信息披露；出险时说话的是保险合同与所在地法律，不是以太坊状态。ERC-1523 文本自身只承诺”标准 API”，从不自称解决后两层——这类老标准的克制反而值得警惕其后来者：凡是宣称”保单写进合约就自动生效”的表述，都属于机制上不存在的能力。

路径哈希这套设计还留了两个常被忽略的操作细节。其一，键是属性路径字符串的哈希，人类不可读——链上只有 0x 开头的 32 字节，没有字段名，因此合规实现必须同时发布路径字典（哪个哈希对应哪个条款字段），否则链上记录准确但无人能读懂，可验证性形同虚设。字典本身放哪里又成问题：放进合约是正解，放在网页上的字典随时可换一版。其二，保单是长命资产，一份寿险合约要跟几十年，路径体系一旦写死就不能更名改义——把某键从”年缴保费”改注为”月缴保费”，历史数据全体失真，这类语义漂移在 ERC-1523 层面没有任何防护，只能靠实现者在字典扩展时另立路径而非复用旧路径。核对既有保单 NFT 时值得让项目方出示路径字典与版本历史；若他们只出示后台界面，那么真正的主账本仍是后台数据库，链上代币只是它的一面装饰镜。

对持有人的实际意义

这份标准部署稀少，现实里遇到”保单 NFT”时更应逐项核验：合约是否真实现了它声称的接口（用 ERC-165 探测即可初筛）、属性查询函数返回的值与保单纸质条款是否逐项一致、批改续保时合约属性由谁有权改写。同时记住 NFT 转移与保险合同权益的关联并不自动成立：把保单代币转给另一个地址，保险合同上的权益人是否随之变更，取决于合同条款与保险法，链上转账本身大概率不产生这个效力。本文为机制说明，不构成任何投资建议。