每一枚代币都是一个登记在册的股份:ERC-884 给 ERC-20 加装股东名册 图 1
每一枚代币都是一个登记在册的股份:ERC-884 给 ERC-20 加装股东名册 · 图 1

每一枚代币都是一个登记在册的股份:ERC-884 给 ERC-20 加装股东名册

多数代币标准的假设是:地址即持有者,转账即转让。股权不能这么算——公司法要求公司有正式的股东名册,谁持股、持多少、地址变更了怎么办,都要有据可查。ERC-884 创建于 2018 年 2 月 14 日,仓库记录状态为 Stagnant,灵感来自特拉华州修订后的普通公司法:该法承认用分布式账本维护公司股份记录的效力。标准于是提出一个方向相反的改革:不是让链模仿股票,而是让代币合约把股票登记处装进自己肚子里。

名册:地址先验身份再进合约

合约在 ERC-20 之外多了一本内部名册。每个被批准的地址带一条记录:地址本身、一个关联的哈希值,以及是否仍然有效。管理方通过 addVerified 添加地址和哈希,用 removeVerified 移除,用 updateVerified 更新哈希,对应发出 VerifiedAddressAddedVerifiedAddressRemovedVerifiedAddressUpdated 三条事件。转账被这道名册卡住:目标地址不在册,transfertransferFrom 就不成立。原文明确要求代币持有者身份经过验证,这意味着“匿名钱包收股份”在合约层直接不成立。

每一枚代币都是一个登记在册的股份:ERC-884 给 ERC-20 加装股东名册 图 2
每一枚代币都是一个登记在册的股份:ERC-884 给 ERC-20 加装股东名册 · 图 2

挂失与补发

股权登记绕不开丢钥匙的用户。标准给出 cancelAndReissue:把一个旧地址标记为已作废,用 isSuperseded 可以查询某地址是否被替换,用 getCurrentFor 查它对应现在哪个新地址。旧地址的余额被冻结在替换记录里,股份落到新验证地址。这个设计和银行挂失存单的逻辑同构,代价是每个地址的生命周期都可能带一条链上变更记录,查历史转账轨迹时必须叠加名册视图才准确。

名册的查询接口

面向审计的函数一组:isVerified 判断地址是否在册,isHolder 判断是否当前持股,hasHash 核对地址与哈希是否配对,holderCount 给出股东总数,holderAt 按序号取第 N 个股东地址。这五个函数拼起来就是股票法意义上的报告能力:名册可导出、可点算、可核验,标准文本引用该州公司法第 224 节来说明这组函数对应的就是股东名册的报告义务。原文也顺带讨论了 ERC-721:同一套名册机制完全可以给每个股份发一枚独立代币做股权证书,ERC-884 选择 ERC-20 是为了计数方便,证书路线留给 721 变体。

哈希值承担什么

名册记录里的 hash 不是随便填的占位符。原文单独一节讨论它:哈希关联着该地址背后的身份验证凭据——法律登记材料的摘要。hasHash 允许任何人核对某地址当前登记的哈希,换哈希必须走 updateVerified 留下事件。这样“地址背后是谁”就有了链上锚点:纠纷时可以证明登记过的是哪份材料,虽然材料正文仍在链下,摘要对不上就当场露馅。地址作废后 getCurrentFor 把新旧地址串起来,整条替代链保证任何一次持股变更都能同时回答法律层与合约层两个问题。

从名册到报告的闭环

holderCountholderAtisHolder 三个函数组合起来,任何第三方都能离线复算一份股东报告:先取总数,再逐个地址点验余额,结果和公司法要求的记录义务对得上。这个闭环是 ERC-884 与其他合规代币方案的分水岭——多数方案只在法律文档里承诺名册,它把名册本体做进合约状态,报告由任何人随时可重跑。也正因如此,管理员密钥的历史行为成为审计焦点:addVerified 的每一条事件都应该与线下的尽调记录逐条对账,对不上的那次添加就是名册最大的裂缝。

读它时要带的边界感

第一,标准描述的州法环境是美国特拉华州,它不声称任何跨地区效力,其他地区对应的合规路径必须按当地法律另行核验。第二,Stagnant 状态说明它没有活跃实现社区,把它当作一份合规代币设计样本比当作可用方案更准确。第三,名册机制把中心化管理员的权限写进了合约:谁能添加验证地址,谁事实上控制谁能持股,检查这类合约时权限密钥和事件历史比代币符号更重要。本文只讲机制,不涉及任何证券属性判断。

本文为机制说明,不构成任何投资建议。