集成或审计任意 ERC20/ERC721 代币时…

在协议需要接受任意 ERC20/ERC721 代币、审计代币实现的标准符合性，或评估 fee-on-transfer、rebase、缺失返回值、黑名单等非标准代币风险时使用。

适用场景

解决思路

1. Phase 1 上下文发现：先确定分析场景——是构建代币合约（token implementation）还是协议与外部代币交互（token integration），确认平台（Ethereum、其他 EVM 链或其他），以及代币类型（ERC20、ERC721 或两者）。
2. Phase 2 Slither 分析（若为 Solidity 项目）：运行 slither-check-erc 做 ERC 符合性检查；运行 slither --print human-summary 分析复杂度与可升级性；运行 slither --print contract-summary 分析函数；运行 slither-prop 生成用于测试的属性。
3. Phase 3 代码分析：检查合约组成与复杂度、owner 权限与中心化风险、ERC20/ERC721 符合性、已知怪异代币模式、集成安全模式。
4. Phase 4 链上分析（若已部署）：在提供合约地址时查询代币稀缺性与分布、总供应量与持有者集中度、交易所上架情况、链上配置。
5. Phase 5 风险评估：输出已识别漏洞、非标准行为、集成风险，以及按优先级排序的修复建议。
6. 按 10 大类逐项评估：(1) 通用考量——安全审计、团队透明度、安全联系方式；(2) 合约组成——复杂度分析、SafeMath 使用、函数数量、入口点；(3) Owner 权限——可升级性、铸造、暂停、黑名单、团队问责；(4) ERC20 符合性——返回值、元数据、decimals、竞态条件、Slither 检查；(5) ERC20 扩展风险——外部调用/hook、转账手续费、rebase/收益型代币；(6) 代币稀缺性分析——供应分布、持有者集中度、交易所分布、闪电贷/铸造风险；(7) 怪异 ERC20 模式（24 种）；(8) 代币集成安全——安全转账模式、余额校验、白名单、包装器、防御性模式；(9) ERC721 符合性——转账到 0x0、safeTransferFrom、元数据、ownerOf、授权清除、token ID 不可变性；(10) ERC721 常见风险——onERC721Received 重入、安全铸造、销毁时清除授权。
7. 逐一排查 24 种怪异 ERC20 模式：重入调用（ERC777 hook）、缺失返回值（USDT、BNB、OMG）、转账手续费（STA、PAXG）、转账外余额修改（Ampleforth、Compound）、可升级代币（USDC、USDT）、可闪电铸造（DAI）、黑名单（USDC、USDT）、可暂停（BNB、ZIL）、授权竞态保护（USDT、KNC）、approve/transfer 到零地址时 revert、零值 approve/transfer 时 revert、多个代币地址、低 decimals（USDC: 6、Gemini: 2）、高 decimals（YAM-V2: 24）、transferFrom 中 src == msg.sender、非字符串元数据（MKR）、失败时不 revert（ZRX、EURS）、大额授权时 revert（UNI、COMP）、通过代币名进行代码注入、非标准 permit 函数（DAI、RAI、GLM）、转账金额少于 amount（cUSDCv3）、ERC-20 原生货币表示（Celo、Polygon、zkSync）等。
8. 对集成安全做专项检查：确认使用 SafeERC20 等安全转账包装器、校验实际到账余额（用 balanceAfter - balanceBefore 而非 amount 计算份额）、维护代币白名单、必要时使用包装器、在所有外部代币调用周围采用防御性模式。
9. 不要因『代币看起来标准、ERC20 检查通过』就跳过怪异代币模式排查——ERC20 符合性之外还有 20+ 种怪异模式，必须逐项对照数据库检查（缺失返回值、零值 revert、hook 等）。
10. 不要因『Slither 无问题』就认为集成安全——Slither 只能检测部分模式，会漏掉集成逻辑，必须手动完成全部 5 项代币集成标准分析。
11. 不要因『未检测到 fee-on-transfer』就跳过该检查——手续费可能是 owner 控制或有条件的，需测试所有转账场景并检查条件性手续费逻辑。
12. 不要因『存在余额检查』就认为处理安全——余额检查本身不足以防御所有怪异代币，需验证安全转账包装器、revert 处理与授权模式。
13. 不要因『代币由知名团队部署』就假设其行为标准——声誉不保证标准行为，必须分析实际代码与链上行为，不要依赖假设。
14. 不要因『集成使用了 OpenZeppelin』就认为安全——OpenZeppelin 库不防御怪异外部代币，需验证所有外部代币调用周围的防御性模式。
15. 不要因『无法运行 Slither』就跳过自动化分析——Slither 提供关键 ERC 符合性检查，需手动验证全部 slither-check-erc 标准或记录受阻原因。
16. 不要凭直觉判断『这个模式看起来没问题』——直觉会漏掉细微的代币集成 bug，需系统性地用代码证据检查全部 20+ 怪异代币模式。
17. 交付物包括：合规检查清单（所有评估类别的复选框）、怪异代币模式分析（全部 24 种模式的存在/缺失、风险等级与证据）、链上分析报告（如适用，含持有者分布、交易所上架、配置）、集成安全评估（如适用，含安全转账使用、防御性模式、怪异代币处理）、按 CRITICAL/HIGH/MEDIUM/LOW 排序并附具体修复方案的建议。

适用边界 · 注意事项

• 仅涉及不集成任何外部代币、也不发行代币的纯业务合约时，本分析的代币相关类别不适用。
• 非 EVM 平台且无法使用 Slither 等 Solidity 工具链时，Phase 2 自动化分析不可用，只能做手动代码审查。
• 未提供合约地址且无 RPC 端点时，无法执行 Phase 4 链上稀缺性与分布分析。