适用范围与证据目标
这里讨论以太坊执行层JSON-RPC及ERC-20相关概念，不直接推广到所有区块链。核验应先明确主张：地址是否有代码、账户持有多少代币、某次转账是否发生，分别需要不同证据。接口文档解释查询含义，具体地址的结论还需要对应的链上返回结果。
两个来源分别支持什么
ethereum.org的JSON-RPC说明介绍了节点查询接口、十六进制编码和区块参数。查询余额、代码或合约状态时，区块参数决定所取状态的位置，因此研究记录必须保留这一条件。
OpenZeppelin的ERC-20文档解释了余额、总供应量、授权额度、显示精度及相关事件，也列出了具体实现行为。它可以帮助解释数据，但不能证明某个待核验地址采用了该实现。
让地址与查询条件完整对应
可复核记录应包含网络标识、完整合约地址、接口方法、参数、原始响应及区块位置。单独一张名称或余额截图，通常缺少重现查询所需的上下文。
latest指向随链推进变化的状态；复核历史结论时，固定区块高度并记录区块哈希，更便于确认双方比较的是同一位置。使用safe或finalized时，也应保存实际对应的区块信息。不同节点返回不一致，需先排查网络、区块和同步状态是否一致。
把返回值解释成恰当的结论
eth_getCode用于查询指定区块上的地址代码；查到代码仍不足以确认代币身份或完整行为。ERC-20余额应对应balanceOf，供应量应对应totalSupply；eth_getBalance查询的是原生资产余额，不能直接作为ERC-20余额证据。
显示数量还需要对应decimals。OpenZeppelin实现的默认精度不代表所有合约都相同。研究记录应同时保存原始整数、实际取得的精度及换算方式，避免将显示差异误判为资产变化。
常见问题：事件能否代替状态
事件适合核对操作记录，某个区块的余额或授权额度则需要对应状态查询。例如，OpenZeppelin文档说明，其实现中transferFrom消耗授权时可以不发出Approval事件，因此仅汇总这类事件未必能还原剩余额度。
核验转账证据时，应对照交易回执、日志所属合约及区块位置，避免把其他合约的同名事件混入。最终结论宜明确写出查询对象、区块条件和观察结果；代币名称相同、接口有返回值，都不足以单独证明项目归属。