先明确：通证模型设计文档通常查什么
通证模型设计文档不是单一格式的文件，可能分散在白皮书、技术文档、治理规则、代币合约说明和审计材料中。查阅时应重点寻找几类信息：通证的用途与持有者权利、发行总量或供应上限、初始分配、释放与锁定规则、铸造和销毁机制、转账限制，以及合约管理员能够执行的特殊操作。若文档只介绍通证用途，却没有说明供应变化和权限边界，模型信息通常是不完整的。
第一步：确认通证标准与合约身份
对于以太坊及兼容网络上的同质化通证，可以先查看文档是否明确采用 ERC-20 或兼容实现。ERC-20 关注的是合约与外部应用之间的通用接口，包括余额查询、总供应量、转账、授权、代扣转账，以及相关事件。名称、符号和小数位通常用于展示或识别，但它们本身不能说明通证是否具有治理、质押或其他业务功能。
查文档时还要把网络名称、合约地址和部署版本对应起来，避免将测试网、旧合约或同名通证混为一谈。仅凭名称、图标或网页宣传不能确认合约身份；应以项目文档中明确列出的地址和网络为核对起点，再检查链上合约是否提供预期的标准接口。
第二步：核对供应机制，而不只看一个总量数字
设计文档应说明初始供应量如何产生，以及未来供应是否可能变化。需要分别检查初始铸造、后续铸造、销毁、迁移和回购等机制，并确认相应权限属于谁、是否可撤销、是否受时间锁或多签等流程约束。一个写有“固定供应”的文档，如果合约仍保留无限制的铸造能力，就需要进一步解释两者之间的关系。
还应区分链上最小单位与界面显示数量。ERC-20 合约内部通常使用整数记录余额和供应量，decimals 只规定钱包、浏览器等界面如何换算显示；它不是供应量上限，也不会自动限制发行。查文档时应确认公式、单位和示例是否一致，防止把链上整数直接当作用户看到的通证数量。
第三步：对照分配、释放与实际可转移状态
分配表应至少列出团队、社区、生态、激励、国库或其他类别的数量或比例，并说明这些份额何时进入可转移状态。不能只看“分配比例”，还要查释放周期、 cliff、线性释放、解锁触发条件和接收地址。若文档只给出计划而没有对应合约或托管安排，结论应限定为“文档中的设计”，不要当作已经执行的事实。
审阅时可建立一张对照表：类别、计划数量、接收地址、锁定合约、开始时间、释放规则和当前可用余额。对每个类别分别核对总量，确保比例与数量采用同一计量单位；若存在跨链部署，还要确认各网络的供应是否共享、映射或独立计算。
第四步：检查权限、限制与异常处理
标准接口并不等于没有额外规则。应在设计文档和合约说明中查找暂停转账、黑名单、地址限制、交易额度、手续费、代理升级、铸造、销毁和管理员变更等功能。每项功能都应写明触发者、影响范围、是否有事件记录，以及权限是否能够转移或撤销。文档没有提及某项能力时，不能据此断言合约一定不存在该能力。
ERC-20 的转账机制还存在一个通用风险：通证可以被发送到没有处理通证能力的合约地址，接收方未必会收到回调或通知，资产可能因此无法取回。设计文档应说明存入业务合约所采用的方式，例如授权后由合约执行代扣转账，并提供误转处理方案。检查时也要特别关注把通证直接发送至通证合约地址或其他不支持接收的地址的情形。
如何判断文档是否足够可靠
可以用“文档—接口—链上状态”三层交叉核对。文档层回答设计目标和规则；接口层确认合约是否具备标准方法与事件；链上状态层用于核对总供应量、余额、权限地址和交易记录。三者不一致时，应记录差异、注明核验范围和时间，而不是用其中一层替代另外两层。
OpenZeppelin 提供的 ERC-20 实现说明了常见的继承式实现方式、初始铸造和小数位处理思路，但采用某个通用实现并不能自动证明项目的分配计划、权限配置或经济模型合理。查阅具体项目时，仍需查看其实际部署代码、参数和管理权限。
常见问题
问：有 ERC-20 接口就代表通证模型透明吗？答：不代表。接口主要解决可互操作的基础功能，供应、分配、释放和管理员权限仍需单独核对。
问：decimals 越大，通证总量就越多吗？答：不一定。decimals 主要影响显示换算，必须结合链上总供应量及换算单位判断。
问：白皮书写明固定供应，是否可以直接相信？答：不能仅凭文字确认，应同时检查铸造权限、供应上限和实际合约逻辑。
问：查不到完整设计文档怎么办？答：应明确标注缺失项，转而核对可获得的合约接口、链上状态和权限信息，不要用推测补全文档内容。