ERC-6353 慈善代币：每笔转账自动切一小块捐出去

有些代币项目宣传过“每次买卖自动捐赠百分之几给慈善机构”。这种说法在机制上对应一个 2022 年 5 月 13 日创建的提案 ERC-6353，它给 ERC-20 加了一套自动分账接口。按 ercs 仓库的记录，这份标准现在的状态是 Stagnant——停滞，作者方长期没有推进。本文按原文拆它想做成的样子，以及为什么值得把这类宣传语拆开检查。

转账之外多送一笔

抽象层的定义很干净：ERC-20 的扩展，每笔转账自动把额外的一个百分比发给第三方。用途原文举了两个，一是代币持有人随转账自动向慈善机构捐款，二是做自动储蓄计划——转账时顺手划一块进自己的储蓄地址。接口侧的核心查询是 charityInfo，让任何程序能读出当前的捐赠地址与比例；getRate 单独返回费率。这套查询存在的意义是让“自动捐赠”从营销文案变成链上可读参数：买币前调一次，就知道你的每笔转账会被切走多少、切给谁。

白名单管住收钱的手

规范里最值得一提的是一套白名单管理函数：addToWhitelist 与 deleteFromWhitelist 维护一组允许的收款地址，getAllWhitelistedAddresses 供查询；更细的粒度上，setSpecificRate 可以给不同白名单地址配不同费率，setSpecificDefaultAddress、setSpecificDefaultAddressAndRate 设定默认收款方，deleteDefaultAddress 删除默认值。这些函数的存在说明设计者想让地址管理标准化：哪些机构有资格收钱、各收多少比例，由代币合约的属主类角色维护，而不是随便一个地址都能挂进分账。这也把风险点暴露得很清楚——白名单和费率的设置权在合约管理方手里，拥有这些权限的地址若被接管，分账可以被悄悄改道。

税费代币到处都有，提问模板一直有效

标准停摆了，它描述的模式却在链上遍地开花：自创的税费代币、回流代币、公益代币，形态五花八门，有的把收款地址写死在构造函数，有的做成可配置的费率与地址管理，有的干脆在 _transfer 内部藏着转账逻辑。拿 ERC-6353 对照现实，会得到一份四步核查清单。第一步看转账逻辑之外还发生了什么外部转账——合约源码或 charityInfo 类查询能否读到，读不到就有暗抽空间。第二步看白名单：getAllWhitelistedAddresses 是否列出全部有资格收钱的地址，还是资金可以流向任何未公示的地址。第三步问费率管理函数 setSpecificRate、setSpecificDefaultAddress 的调用权限归谁、权限变更有没有记录。第四步抽样几笔历史转账，链上核对实际抽取比例与宣称费率是否一致。四步走完，“每笔转账自动捐赠”是机制还是话术，基本就有答案了。标准没有部署量，但这套提问模板的分量一直都在。

Stagnant 状态下的阅读姿势

按 ercs 仓库记录，这份标准停在 Stagnant，没有被主流生态采纳。它仍然值得读，因为“转账自动抽取”这个模式本身在链上代币里长期存在，形态各异：有的写死地址，有的做成税费代币，有的干脆在转账逻辑里藏一段转账给项目方。ERC-6353 提供的价值是一份提问模板。看到任何“自动公益”“自动回购”“自动储蓄”的代币时，依次核对四点：转账函数里除了状态变更还发生了哪些外部转账，抽取比例是不是链上可读参数，收款地址是否可被单方更改、由哪个角色控制，历史抽取记录能否逐笔追查。四个问题都有肯定答案，宣传语才勉强对得上机制；有一个含糊，它就是一个需要继续挖的黑箱。标准停滞了，标准想解决的问题没有停滞，这正是读旧提案最实用的收获。

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