先明确要查的“通证模型”包含什么
通证模型设计文档通常不只是代币合约说明，还可能包括通证用途、发行与销毁规则、分配安排、释放计划、治理权限以及与其他合约的交互方式。查找资料前，应先区分项目白皮书、代币经济学说明、技术文档、合约源码和链上验证页面，它们承担的作用不同。白皮书偏重目标和规则，技术文档偏重实现，合约源码与链上数据则用于核对实际执行情况。
如果项目声称使用可替代通证标准，ERC-20 可以作为基础检查框架。可替代通证的特点是同一合约中的单位通常具有相同属性和价值表示方式；这与每个资产都具有独特编号和属性的非同质化通证不同。不能仅凭“兼容 ERC-20”就推断项目的分配、公平性或治理安排。
从哪些位置查找设计文档
较稳妥的查找顺序是：先在项目官方文档的导航、开发者栏目或版本库中寻找 Token、Tokenomics、Economics、Supply、Vesting、Governance 等章节，再对照项目公布的合约地址和网络。若只有宣传页面而没有供应机制、权限和合约说明，文档完整性就需要谨慎评估。
随后可查阅代币合约的公开源码、接口说明和链上读取结果。ERC-20 常见的查询接口包括名称、符号、精度、总供应量、账户余额、转账、授权额度和授权转账；相关事件通常包括转账记录与授权记录。接口只能帮助确认合约如何被调用，不能替代对增发权限、暂停权限、黑名单或其他自定义逻辑的审查。
阅读文档时重点核对哪些字段
第一组是基本身份信息，包括名称、符号和 decimals。精度主要用于展示和换算，合约内部仍以整数记录余额和供应量。因此，文档中的“一个通证”与合约实际传入的最小单位可能不是同一个数值，查看总供应量和余额时必须结合精度理解，避免把显示值与底层整数直接混淆。
第二组是供应机制。应寻找初始发行量、后续增发、销毁、回购、铸造权限和供应上限的明确说明，并确认这些规则是否由合约强制执行。若文档只写“总量固定”，却没有对应的合约限制或可核验权限说明，这个结论就不够完整。
第三组是分配与释放。文档应说明团队、社区、生态、激励或其他类别的分配逻辑，以及锁定和释放条件。对于线性释放、按事件释放或由管理账户执行的安排，应进一步确认时间边界、执行角色和异常处理方式，而不能只看一张比例图。
第四组是权限与风险控制。需要关注谁可以增发、销毁、暂停转账、修改参数或管理账户，以及权限是否可撤销、是否由多签或治理流程控制。文档中的角色名称不等于实际安全边界，仍应与源码和链上权限状态相互核对。
如何用 ERC-20 接口核对合约
可以先读取 symbol、decimals 和 totalSupply，再读取若干地址的 balanceOf，检查文档中的单位、精度和供应量表述是否一致。之后查看 Transfer 事件，观察初始发行、转账和销毁是否符合文档所说的规则；对于需要第三方代扣的场景，还应理解 approve、allowance 和 transferFrom 之间的关系。
如果使用开发工具或区块浏览器，应记录查询所用的网络、合约地址和区块状态，因为同名通证可能部署在不同网络，地址也可能不同。对于代理合约，还要区分代理地址与实现合约，并检查升级权限。发现源码未验证、接口缺少自定义函数说明或文档与链上结果不一致时，应把差异列为待确认事项，而不是自行补全结论。
常见问题与适用边界
ERC-20 设计本身不包含接收方回调机制。用户把通证直接转入一个没有处理通证功能的合约地址时，资产可能无法被该合约使用；因此，项目文档应说明存入流程，用户也不应把 transfer 直接转给未知合约。某些协议会要求先授权，再由协议合约通过 transferFrom 完成存入，但具体做法必须以目标协议的实现为准。
还要注意，标准接口不代表所有实现行为完全相同。项目可能加入暂停、黑名单、税费、转账限制、可升级逻辑或其他自定义规则，这些功能会改变实际使用方式。查文档的目标不是只确认“是不是 ERC-20”，而是建立一条从设计说明、源码、权限到链上行为的对应关系。
如果找不到完整设计文档，可先整理一份核对清单：合约地址和网络、通证标准、精度、当前与最大供应量、铸造和销毁权限、分配与释放规则、转账限制、升级机制、异常资产处理方式，以及每项信息的可验证依据。无法确认的部分应明确标记为未知，不应依据名称、宣传语或单一接口结果推断项目结论。