ERC-20 的世界里，任何浏览器都能数清一枚代币的总供应和每个地址的余额。ERC-7984 走的是相反路线：一份”保密 fungible 代币”接口，余额与转账金额对链上围观者不可见，只有合约自己的事件留下加密后的足迹。它在规范文本里给出的应用场景是发薪、保密 DeFi 与机构结算——恰好都是”金额本身是机密”的场合。这份草案（Draft）的特别之处不在零知识细节，而在一个很工程化的选择：所有金额都用”指针”表示。
指针：把数字搬出链
规范开宗明义：本标准的数值一律由保密指针（confidential pointer）表示，因此余额和转账金额是保密的；指针指向别处存放的数据，可以在链上也可以在链下，指针的解析、操作与存放方式属于实现细节。落到接口上，confidentialBalanceOf 返回的是指向某账户余额的指针而不是数字本身，confidentialTotalSupply 同理；转账函数族是 confidentialTransfer、confidentialTransferFrom 以及两个带 AndCall 后缀的收款回调变体。它要求实现 ERC-165 供工具探询，名字、符号、精度、contractURI 等元数据函数照常保留——也就是说，公开的部分照常公开，只有数字隐身。
操作者模型与三个事件
授权部分沿袭 ERC-20 的思路但换了开关名：setOperator 设定谁能替你转，isOperator 供查询，第三方动用余额走 confidentialTransferFrom。事件表值得逐条看：ConfidentialTransfer 在每笔转移时发出；OperatorSet 记录操作者变更；AmountDisclosed 则对应规范设计里最微妙的一环——当保密金额需要向某方披露（审计、对手方核验）时，这次披露本身也要在链上留下记录。对账工具与合规流程读到的就是这三类事件，而不是转账数字。
浏览器查不到的那一刻
把视角切回普通用户。装了这样一枚代币的钱包，最直观的体验差异是：区块浏览器上这笔转账可能只见交互记录不见金额，甚至金额字段以指针形式出现，第三方资产统计页对你余额显示为无法解析。核对一笔收款是否真实、数额几何，只能依赖钱包自己的解码与展示，或对方出示的披露凭证——信任重心从”链上透明”转移到”钱包与披露机制诚实”。这与 ERC-7945 保密交易代币：余额和转账金额藏进密文后，接口还兼容谁 讲的 ERC-7945 保密转账是同族问题，可以对照着读：一个侧重密文怎么放进兼容接口，一个把金额整体抽象成指针。
什么场景值得、什么场景别碰
规范给出的三个场景有共同前提：参与方之间有既有法律关系。发薪时员工余额不应同事可见；机构结算时对手方规模是商业机密；保密 DeFi 的订单簿金额本身可能构成市场信息。反过来，指望用它做匿名收割——给不特定公众发币还不想让人数钱——在依赖披露与审计的合规语境里反而是减分项，且链上行为模式即便金额加密仍可能被统计分析。这类边界与 dust 类攻击的教训类似：加密的是字段，不是行为。
和相邻两条隐私路线的分岔
保密代币不是只有一种做法，分岔点值得记住。一条路线是把金额做成密文塞进 ERC-20 兼容接口，链上仍然承载密文本身，另一条是本标准这样把金额抽象成指针、把数据搬离链上执行环境；还有一条是零知识证明路线，链上验证的是”余额非负、收支平衡”这类命题证明。三条路对钱包与浏览器的要求完全不同：前者需要解码密文，本标准要求解析指针，证明路线需要电路与合约一致。用哪种不是口味问题——它决定你的余额由谁能读、出问题向谁求证。判断顺序建议是：先问数据存在哪里，再问谁能解码，最后才问界面显示不显示数字。
现状核查
ERC-7984 状态为 Draft，接口虽简洁，但”指针解析”这一实现细节意味着两枚都声称符合标准的代币，钱包适配层可能完全不通用。评估任何自称保密代币的产品时，问题清单应当包括：指针指向哪里、谁能解码、有没有披露路径、审计覆盖了电路还是只有合约壳。
风险提示：保密代币的余额与流转无法经公开浏览器独立核验，涉及资产时请通过可信解码与披露渠道确认，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。