ERC-7538 乘数代币：不写 decimals，用 multiplier 改显示余额

以太坊代币的 decimals 是个整数，意思是“真实单位等于链上整数除以十的幂”。这个约定服务了几千个代币，但天花板也很清楚：步长永远是十的幂，想支持“零点五个单位”的转账 increments 别扭，想让余额按通胀或通缩节奏整体缩放更无能为力。ERC-7538（Multiplicative Tokens）换了个思路：不改链上整数，只改显示层——在代币元数据里放一个乘数（multiplier），界面数字等于链上整数乘上乘数。按以太坊 ercs 仓库的记录，提案状态为 Draft，创建于 2023 年 10 月 18 日，篇幅很短，规则却很硬。

元数据里的一行字段，合约里的一条禁令

标准的落点在 ERC-1046 的 tokenURI：兼容 ERC-1046 的代币（文本点名 ERC-20 与 ERC-1155）若使用乘数，必须在其解析出的元数据里实现 MultiplierMetadata 接口——一个 multiplier 字段，值是精确的十进制字符串，未定义时默认按一处理；同时声明 decimals 为不再支持。最严格的一条在合约层：使用乘数的代币合约不得再提供名为 decimals 的方法。这不是风格偏好而是排歧：两套缩放规则同时存在时，不同钱包迟早会算出两个余额。乘数用字符串而非定点数，标准给出的理由是精度——避免二进制浮点的经典误差；同时要求乘数必须为正数，因为零和负数会让显示层出现无法自洽的画面。钱包被建议尽力完整显示大数或小数的余额，而不是自作聪明地截断。

谁来乘这个数：一致性与四舍五入的暗礁

标准动机部分给出的对比值得复述：decimals 的步长只能是十的幂，支持零点五这样的转账增量就得绕路；代币自带通胀或通缩机制时，乘数可以整体平移显示口径而不动任何持仓整数；借 ERC-1046 的元数据通道走，多数场景还顺带省 gas，不必为缩放额外加存储字段。兼容性条款则一点不温和：凡 ERC-1046 兼容标准里名为 decimals 的方法都不能与乘数共存，老代币想迁移必须先删掉旧方法，钱包、资源、前端全链条都得适配。选这条路线的团队，实际是在用接口纯度换显示灵活性——评估这类代币时，先确认删干净了没有，比确认乘数等于几更优先。

从生态位看，乘数方案瞄准的是 decimals 长期管不住的一批边界：游戏或积分型代币想要非十的幂步长、金库份额想随收益自动调整显示口径、集合凭证想让一枚对应可变权重。它也常被拿来与界面倍率类方案比较——那一类把缩放完全留在展示层、不动元数据契约，本提案则要求把乘数写进可被任何工具解析的标准字段，并把旧的 decimals 通道拆掉，换取一致性。两种路线没有绝对优劣，但对集成方而言，字段写死在元数据里的版本更容易形成全网一致的余额，代价是升级迁移更重。

显示层方案的全部风险在于“人人要乘同一个数”。任何一个忘记乘、乘反、或在自己代码里硬编码旧乘数的集成方，都会给用户看错余额——这类错误在转账界面可能演变成实际损失。标准的安全考虑部分直接点名：乘数处理不当造成的舍入误差可能被恶意行为者利用，合约必须准确处理乘数。对读数据的人来说，习惯也需要更新：看到这类代币，余额正确性取决于三层信息是否一致——合约字节码（确认确实没有 decimals 方法）、tokenURI 元数据（读到乘数的当前值）、以及展示工具是否真的按元数据行事。还要留意乘数被治理调整的时间点：调整前后的历史截图里“同一个数字”代表的链上整数并不相同，做账与审计时以整数口径对账，显示口径只用于阅读。机制很简单，风险全在执行纪律。本文为机制说明，不构成任何投资建议。