一、先确认资料是否来自可追溯的一手来源
核验代币开发资料时，第一步是确认页面的发布主体、文档路径、版本信息和引用关系。关于ERC-20，适合优先查阅以太坊官方开发者文档中的代币标准说明，以及OpenZeppelin官方Contracts文档中的ERC-20实现说明。前者侧重标准接口和通用行为，后者侧重可复用合约实现，两者关注点不同但可以相互印证。
仅有博客、论坛帖子、社交媒体截图或未经注明来源的代码，不足以证明某个接口属于ERC-20标准。资料还应能追溯到EIP-20等标准文本，避免把某个项目的自定义功能误认为所有代币都必须具备的功能。
二、用标准接口核对资料是否准确
ERC-20用于表示可替代代币，即同一合约中的代币通常具有相同的类型和价值属性。核验资料时，可以检查其是否正确说明了常见查询、转账和授权接口，包括name、symbol、decimals、totalSupply、balanceOf、transfer、transferFrom、approve和allowance，以及Transfer和Approval事件。
接口名称相同并不代表合约行为完全相同。还要核对函数的输入输出、可见性、状态可变性、事件触发条件，以及供应量如何创建和销毁。资料若只展示transfer代码，却没有说明授权、余额更新和事件记录，就不能据此判断实现完整符合标准。
三、区分标准要求与库的实现选择
以太坊官方标准资料适合回答“ERC-20通常需要哪些接口”，而OpenZeppelin文档适合回答“如何基于成熟实现构建合约”。例如，继承OpenZeppelin的ERC20合约可以复用基础逻辑，再通过构造函数设置名称、符号并铸造初始供应量。这属于一种实现方式，不应被表述为唯一写法。
资料核验时应特别标记可选扩展和项目自定义逻辑。name、symbol和decimals常用于展示或兼容性，但具体供应机制、铸币权限、销毁功能、暂停转账、黑名单及访问控制，可能需要额外模块或自定义代码。只有标准明确要求的内容，才能直接归入ERC-20基础规范。
四、重点检查decimals和供应量的解释
decimals表示用户界面如何把合约内部的整数余额转换为可读数值，并不意味着EVM在合约内部执行小数运算。合约保存的是整数，界面通常按照10的decimals次方进行换算。因此，资料中若把decimals描述成改变底层算术类型，或者直接把显示数量当作合约传入数量，说明存在理解偏差。
核验时应同时查看初始供应量的单位、铸造参数的单位和余额查询结果的换算方式。不能仅凭“供应量为某个数字”判断代币实际显示数量，还要确认该合约的decimals设置及调用方是否进行了正确换算。
五、把安全提示与标准能力分开核验
ERC-20的transfer和transferFrom能够把代币转入地址，但标准本身并不要求接收方合约必须具备代币接收通知或处理逻辑。因此，把代币转到不支持处理ERC-20的合约地址，可能造成代币无法按预期取回。该问题说明的是标准交互边界，不等于所有ERC-20合约都存在相同漏洞。
看到“解决方案”时，应检查其适用范围。例如，限制向代币合约自身转账、增加误转提取机制或采用其他代币标准，都可能改变兼容性和使用方式。资料若声称某项限制适用于所有场景，应进一步核对是否会影响依赖普通transfer行为的其他合约。
六、常见问题与实用核验清单
常见问题一：一段能编译的代码是否就是标准代币？不是。还需核对接口、事件、余额和供应量变化，以及授权流程。问题二：使用OpenZeppelin是否自动保证业务安全？不是。库能提供通用实现，但权限配置、铸币规则、升级机制和业务限制仍需单独审查。问题三：资料中的示例地址和数量能否直接复用？不能，应先确认网络、合约地址、版本和用途。
实用清单包括：确认来源主体和版本；回到标准原文核对接口；对照权威库的API和实现；区分必需接口、可选扩展与项目自定义功能；检查decimals和内部整数单位；审阅供应量及权限逻辑；核对Transfer、Approval等事件；最后在目标网络的区块浏览器中核对已部署合约源码、ABI和实际调用结果。这样才能把“资料说法”“代码实现”和“链上事实”分别验证。