先界定要查的“更新记录”
“自己发币挖矿”可能包含几类不同记录：代币合约何时部署、何时修改挖矿或铸币规则、某个地址何时获得代币、代币余额或总供应量如何变化。ERC-20 主要规定可替代代币的通用接口；名称、符号、余额和转账等功能可以由标准合约实现，但“挖矿”通常是项目额外设计的铸币、奖励或分发逻辑，不能仅凭代币名称判断。
因此，查询前应整理四项信息：使用的网络、代币合约地址、自己的钱包地址，以及已知的部署或奖励交易哈希。若没有交易哈希，也可以从合约地址关联的创建交易、区块高度和历史交易开始查。不要把钱包界面显示的余额变化直接当作完整的挖矿记录，应回到链上交易和合约状态核对。
用交易哈希和区块高度建立时间线
最直接的资料线索是交易哈希。部署交易可以确认合约创建过程，后续交易则可能对应转账、铸币、领取奖励或其他合约调用。Ethereum 的执行层 JSON-RPC 提供按哈希查询交易、按区块号或区块哈希查询交易，以及查询交易收据的方法，这些接口适合建立一条可复核的链上时间线。
查询时应记录交易哈希、所在区块、发送方、接收方、调用状态以及交易输入数据的基本信息。交易收据可作为判断交易是否被链确认的重要入口；若交易失败，不能据此认定代币已经发放。区块浏览器通常把这些字段整理成页面，节点 JSON-RPC 则适合程序化保存和比对。
如果需要查看某一时点的余额或合约状态，应固定区块参数，而不是始终读取最新状态。JSON-RPC 的状态查询可以使用具体区块高度，也可以使用 earliest、latest、safe、finalized 等区块标识。这样能避免后续交易发生后，当前余额覆盖了过去的状态。
核对合约代码与 ERC-20 数值
查询代币是否支持“挖矿”，重点不在代币名称，而在合约代码和可调用接口。节点可以通过 eth_getCode 获取指定地址的合约字节码；如果平台提供已验证的源码，应进一步查看是否存在 mint、奖励计算、质押领取或权限控制等逻辑。仅看到某个地址收到代币，并不能单独证明这笔转账属于挖矿奖励。
OpenZeppelin 的 ERC-20 示例展示了通过 _mint 向部署者分配初始供应量的做法。这说明铸币行为取决于合约内部的供应机制，而不是 ERC-20 标准自动产生。若要确认某次新增代币，需把交易调用、合约权限和供应量变化结合起来查看；若合约没有公开或可验证的挖矿逻辑，外部资料通常无法可靠还原完整规则。
余额和供应量在合约内部以整数保存，decimals 主要用于界面展示。例如显示为带小数的代币数量时，实际链上数值需要按照合约的 decimals 进行换算。比较不同时间的记录时，应始终使用同一套换算规则，否则可能把显示单位变化误认为代币数量变化。
一套可复核的查询流程
第一步，确认网络和合约地址。相同的地址格式可能出现在不同网络，必须先核对网络标识、合约代码是否存在，以及浏览器页面对应的链。第二步，定位部署交易和相关交易哈希，按区块顺序整理时间线。第三步，查看合约代码和可读方法，确认名称、符号、decimals、余额及供应机制。
第四步，对每个疑似奖励或铸币交易，比较交易前后相关地址的余额，并把查询区块固定在交易所在区块或其前后区块。第五步，保存查询使用的网络、区块高度、交易哈希、合约地址和原始返回值，方便日后复查。对于批量记录，可使用 JSON-RPC 库封装请求，但仍应遵循节点文档对参数格式的要求。
JSON-RPC 的数量通常采用带 0x 前缀的紧凑十六进制表示，零写作 0x0；地址、哈希和字节数据则按字节使用偶数位十六进制表示。格式错误可能导致请求失败或结果解析错误，因此导出资料时应同时保留原始十六进制值和人工可读的区块、数量。
常见问题与适用边界
问：只看区块浏览器的“代币转账”页面够不够？答：它适合快速定位记录，但不能单独证明转账就是挖矿奖励。还需要结合交易调用、合约代码、权限和区块高度判断。
问：余额突然增加是否代表合约更新了挖矿规则？答：不一定。余额变化可能来自普通转账、铸币、奖励领取或其他合约操作。应查对应交易，而不是只比较钱包页面前后数值。
问：为什么当前余额和以前保存的余额不一致？答：余额是某个区块高度下的状态。若查询时使用 latest，结果会随新交易变化；要复原历史记录，应使用具体区块高度，并核对网络、合约地址和 decimals。
问：没有源码还能不能查？答：可以查交易、区块、合约字节码和部分可读状态，但无法仅凭这些资料完整解释未公开的业务规则。此时应把结论限定为链上可观察事实，不对“挖矿”机制作未经验证的推断。