06 · Token 标准：ERC20 / 721 / 1155 / 4626 / 6909 + Permit（★★★★☆）
06 · Token 标准：ERC20 / 721 / 1155 / 4626 / 6909 + Permit（★★★★☆）
全部要知道——以后几乎每天都会碰到。每个标准解决的是"资产怎么被统一表示、统一交互"的问题， 套利工程师需要在几秒内判断"这是哪种资产、能不能被我的合约安全处理"。 与
notes/09-ERC20与approve机制.md互补：那篇深挖 ERC20 字节级细节，本篇覆盖全部标准的横向对比。
0. 一句话本质
Token 标准的本质是"接口的社会契约"：只要一个合约实现了标准规定的函数签名， 所有钱包、DEX、协议都能不认识它的内部实现、仅凭接口就能安全地与它交互。 标准越通用（ERC20），生态越大但表达力越弱；标准越专精（ERC4626）， 表达力越强但生态适配需要时间——这是套利工程师判断"这个新协议值不值得对接"的第一道筛子。
1. ERC20：同质化代币的通用语言
核心接口：totalSupply / balanceOf / transfer / approve / allowance / transferFrom
- 两步授权模式：
approve(spender, amount)先授权，transferFrom(from, to, amount)再由被授权方代转—— 这是几乎所有 DEX/借贷协议"先拿到用户资金操作权、再执行业务逻辑"的基础模式。 - 两个历史坑：
- 返回值不规范：部分早期代币（如 USDT）的
transfer不返回bool，直接用标准 interface 调用会 revert， 必须用SafeERC20（用低级call+ 手动检查返回数据）兼容处理。 - decimals 差异：不是所有代币都是 18 位小数（USDC 是 6 位，WBTC 是 8 位）—— 套利路径计算里如果硬编码 18 位小数换算，会出现数量级错误。
- 返回值不规范：部分早期代币（如 USDT）的
- Approve 竞态（Approve Race Condition）：先 approve 100 再改成 50，中间如果对方已经用旧的 100 额度转账，
会出现"多转"的边界情况——这是为什么很多合约建议先
approve(0)再approve(newAmount)。
2. ERC721：非同质化代币（NFT）
核心接口：ownerOf(tokenId) / safeTransferFrom / approve(spender, tokenId) / setApprovalForAll
- 每个
tokenId唯一，ownerOf直接映射到具体所有者——这是 NFT 与 ERC20（只有总量和余额，无个体标识）的本质区别。 - 套利视角：NFT 本身流动性差、报价机制（地板价/稀有度溢价）与 AMM 定价逻辑完全不同， NFT 相关套利（如跨市场地板价差）需要专门的定价模型，不能套用 Token 的 AMM 思路。
3. ERC1155：多资产合约（半同质化）
核心接口：balanceOf(account, id) / safeBatchTransferFrom
- 一个合约可以同时管理多种资产类型（同质化 + 非同质化），每种资产有独立的
id， 且支持批量转账（一笔交易转多种资产），大幅省 gas（相比部署多个 ERC20/721 合约）。 - 常见于游戏道具、DeFi 头寸凭证（如某些协议用 1155 表示不同到期日的衍生品仓位）。
4. ERC4626：Tokenized Vault Standard（金库标准）
核心接口：asset() / deposit(assets, receiver) / withdraw / redeem / convertToShares / convertToAssets
- 解决的问题：在标准之前，每个收益金库（Yield Vault）都有自己的存取款接口， 聚合器/机器人要对接每个协议都要单独适配；ERC4626 统一了"存入底层资产、获得份额代币（本身也是 ERC20）"的接口。
- 套利工程意义：只要一个金库实现了 ERC4626，你的机器人就能用同一套代码批量对接所有兼容金库，
比较不同金库的实际年化收益（
convertToAssets(shares)随时间的增长率），是收益率套利/最优资金配置策略的标准数据源。
5. ERC6909：更省 gas 的多代币标准（ERC1155 的轻量替代）
- 解决的问题：ERC1155 的批量转账/余额查询在 gas 上仍有优化空间，尤其在需要频繁小额结算的场景（如 AMM 内部头寸记账）。
- ERC6909 去掉了 ERC1155 强制的"批量转账事件+回调检查"等开销，接口更精简， 近年被部分新一代 AMM（如 Uniswap V4 的 hooks 体系）用作内部资产记账标准， 目的是把"多资产账本"的 gas 成本降到最低。
6. Permit / Permit2：见 05-钱包与账户.md §6
已在钱包模块详述——这里补充一点 Token 标准视角的细节：
- 是否支持 EIP-2612 Permit 是判断一个 ERC20 "现代化程度"的标志之一（USDC 支持，很多老代币不支持）。
- 不支持原生 Permit 的代币，可以通过用户对 Permit2 合约做一次性
approve， 之后所有接入 Permit2 的协议都能用签名代替交易——相当于给所有 ERC20 补一层统一的"签名授权"能力。
7. 标准横向对比表
| 标准 | 资产形态 | 核心特征 | 典型套利/工程场景 |
|---|---|---|---|
| ERC20 | 同质化 | 简单余额+授权 | 现货/DEX 套利的基础资产 |
| ERC721 | 非同质化 | 唯一 ID | NFT 跨市场价差 |
| ERC1155 | 半同质化 | 多资产+批量转账 | 游戏道具、多到期日衍生品仓位 |
| ERC4626 | 同质化份额代表底层资产 | 存取款标准化 | 收益率比较/最优配置套利 |
| ERC6909 | 半同质化（轻量） | 更省 gas 的多资产记账 | 新一代 AMM 内部头寸记账 |
8. 前置名词小词典
- 份额代币（Share Token）：代表在某个金库/池子中所占份额的凭证，通常本身也遵循 ERC20。
- 回调检查（Receiver Hook）：
safeTransferFrom等方法会检查接收方合约是否正确实现了接收接口， 防止资产被转入"不知道怎么处理它"的合约而永久锁死。 - 无限额度授权（Infinite Approval）：
approve(spender, type(uint256).max)， 常见于减少重复授权交易，但也放大了单点信任风险。
9. 常见误区
- ❌ "所有 ERC20 都是 18 位小数" → USDC/USDT 等主流稳定币是 6 位，WBTC 是 8 位，必须逐代币核实
decimals()。 - ❌ "approve 后立刻改额度是安全的" → 存在竞态窗口，建议清零后再设置新值。
- ❌ "ERC4626 的份额价格永远只涨不跌" → 底层策略亏损/黑天鹅事件下份额价值同样可能下跌，"标准化接口"不等于"保本"。
- ❌ "NFT 套利可以用 AMM 公式定价" → NFT 缺乏连续流动性，实际成交价格发现机制和同质化代币完全不同。
10. 与套利实践的对应 / 自检问题
对应：07-DEX与做市.md（DEX 交易的资产载体几乎全是 ERC20）、
08-DeFi协议全景.md（Vault/Yield 协议大量使用 ERC4626）、
11-量化套利系统.md（"价格聚合"模块必须处理不同 decimals 的换算逻辑）。
自检：
- 为什么在计算跨代币套利路径的利润时，必须先确认每个代币的
decimals()？ SafeERC20具体解决了 ERC20 标准的哪个历史遗留问题？- 如果你要对接 50 个不同的收益金库协议，ERC4626 标准给你节省了什么工作量？
- ERC1155 和 ERC6909 都能表示"多资产"，它们的核心权衡差异是什么？
── Q&A / 更正记录区（按日期追加）──
原始讨论记录见
Q&A/（按日期归档，保留完整来回过程）；本节是同步后的结论摘要， 只增不删——若后续发现本篇正文表述不准确，按更正记录追加在此，不删改正文， 保留"原来写的是什么 → 后来发现哪里不准 → 更正为什么"的轨迹。规范见Q&A/README.md。
- (2026-07-26 建立。暂无 Q&A——后续围绕本篇的提问/质疑/更正在此累积。)