ERC-3475 抽象存储债券：classId 加 nonceId 的两级账本怎么记账

2021 年 4 月 5 日创建、后来进入 Final 状态的 ERC-3475 有一个直白的副标题式野心：让任何一类债务关系都能在链上记账，而不用勉强塞进 ERC-20 或 ERC-721 的形状。它标题里的词是 Abstract Storage Bonds，抽象存储债券。动机部分写得也很坦率：当时的流动性凭证多半就是一个套着 ERC-20 壳的空名字，头寸里真正重要的信息——什么时候能赎、按什么条件赎、对不同批次适用哪套规则——全都住在合约外的网页上。这个标准想把这些信息收进一个合约自己的账本里。

两级编号撑起一类义务

它的账本形状是两级。第一级叫 classId，代表一个大类，比如某一期债券的整体条款；第二级叫 nonceId，挂在某个大类之下，代表一类发行条件或数据切片——同一期产品下不同起息日、不同赎回窗口的批次，就是同类下的不同 nonce。转账函数 transferFrom 收的是结构体数组，每一项是三元组：类型、序列号、数量。查询侧的 classValues 与 nonceValues 让钱包不读链下文档也能问到某个类型或某个批次的数值；issue、redeem、burn 分别处理发行、赎回与销毁，余额侧还有 totalSupply、activeSupply、redeemedSupply、burnedSupply 四个口径。元数据也分两层，classMetadata 与 nonceMetadata 各按编号返回一段说明文本。

这个形状的精妙之处在于它同时容纳两种世界：单个批次数量够大时它像同质代币，可以按份拆分流通；批次稀有到一定程度时它又接近 NFT，一张凭证对应一组独特条款。原文因此强调债券可以在二级市场上被分割和交换，而市场工具想兼容它，需要同时理解两种阅读方式。

和相邻标准对照能看得更准。ERC-1155 也有编号域和批量接口，但它的编号只是同质份额的标签，同一个编号下所有单位完全等价，条款信息没地方放；ERC-721 有唯一编号却没有数量概念，谈不上一类里不同批次。ERC-3475 的两级结构正卡在中间：classId 之下还可以按 nonce 细分，转账函数一次提交的是一张三元组清单，同一笔交易里可以同时挪动几个批次，这让按条款簿记的发行方省掉了部署一堆独立合约的开销。代价是钱包与市场要理解 Transaction 结构体这种新形状，接口比 20 和 721 都不顺手，普及自然慢。

状态在哪、条款在哪

需要冷静区分的是：这个标准把批次的数值、供应量和进度这类可查询数据放进合约，但合同意义上的兑付义务并不在字节里。违约发生时，链上账本只能证明条款写的是什么，不能替持有人执行现实世界的追索。按原文定义，Bank 是负责发行、赎回或销毁的实体，通常就是对资金池持有管理权限的那一方——合约记录透明度和发行方履约能力是两件完全不同的事。评估这类凭证时，谁发行、拿什么兜底、赎回资金池在哪一层，仍需从链下法律文件与资金流核验，账本只是把这些口径钉在了一个可公开核对的位置。

落地的现实

Final 状态说明规范冻结且被广泛审查，不等于被广泛部署。它的实现集中在少数结构化发行场景，普通钱包对它的支持也远不如对 20 和 721 那么顺手，用户界面经常把它降格成一串数字。接口本身也有几处容易误读：供应口径要分清是活跃量、已赎回量还是已销毁量，同一批凭证在不同查询下数字不同；赎回窗口与进度查询住在合约里，但窗口到期后资金是否真的到位，接口回答不了。读这种凭证最稳的方法是自己调一次 classMetadata 和 nonceValues，确认钱包显示的条款与合约里的一致，而不是只看页面文案。凭证不等于债权文书，机制与法律效力之间隔着的距离，任何标准都无法用接口抹平。本文为机制说明，不构成任何投资建议。