先明确查询对象与适用范围
区块链发售模式的设计文档怎么查，首先要确定需要了解的是代币如何创建、如何分配，还是发售流程如何执行。这些内容可能分布在不同文档中，查询时应分别定位。本篇讨论以太坊ERC-20同质化代币的通用技术基础，不涉及具体项目发售安排的核验。
从标准文档确认接口边界
以太坊开发者文档中的ERC-20说明介绍了余额、总供应量、转账和授权等接口。这些接口让应用能够用统一方式与代币合约交互。
查询设计文档时，可先判断所描述的功能属于标准接口，还是项目另外定义的规则。采用ERC-20本身，无法说明发售对象、分配比例、释放周期或退款条件；这些内容需要对应的业务说明与实现证据。
从实现文档追查供给机制
OpenZeppelin的ERC-20文档展示了通过继承标准实现、在构造函数中铸造初始供应量并分配给部署地址的示例，同时提供供给机制相关文档入口。它也说明，decimals用于显示换算，合约中的数量运算仍使用整数。
这类文档适合帮助理解代币如何产生。查阅具体设计时，应继续寻找初始供应量的来源、后续铸造条件以及相关权限说明。示例中的一次初始化分配，不能据此推断其他合约也采用相同规则。
让设计说明与实现对应起来
整理查阅结果时，可把每项规则对应到文档位置、合约功能和适用版本。例如，供应量说明应区分当前已创建数量与设计上限；数量描述则应注明是链上整数还是经过精度换算的显示值。
代币合约的说明未必覆盖全部发售流程。如果文档只解释余额与转账，就仍需查找负责分配或释放等业务的设计说明。缺少对应内容时，应将该规则标记为尚未核实，避免用标准功能补全项目事实。
常见问题：接口能证明什么
查询totalSupply能否确认最终发售总量？该接口返回代币总供应量，不能单独解释其中多少用于发售，也不能证明未来不会增发。判断这些问题还需要供给规则及实现。
有ABI是否就有完整设计文档？ABI可以帮助识别和调用合约接口，但通常不能完整表达业务目标、权限约束与异常处理。技术标准、实现说明和业务设计需要结合阅读，各自回答不同层面的问题。