先确认项目身份与查询范围
“inv币”可能只是简称、社区称呼或多个项目共用的名称。开始查询前，应先确认它所在的网络、代币合约地址、挖矿合约地址，以及所谓“挖矿”究竟指区块奖励、流动性挖矿、质押奖励还是合约内部的积分和代币分配。仅凭代币名称或搜索结果，无法可靠判断历史规则。
如果项目使用的是兼容以太坊的网络，可以进一步记录规则变化涉及的区块高度、交易哈希和事件日志。查询范围应明确到某个历史区块，因为同一合约在不同区块的状态可能不同。
利用历史区块数据定位规则变化
以太坊客户端通过JSON-RPC提供统一的节点访问方式，其中历史类方法用于读取从创世区块开始的区块、交易、交易回执和相关记录。查询历史挖矿规则时，可围绕具体区块检查合约交易、交易回执和事件日志，确定奖励参数何时被设置、修改或停止。
区块参数通常可以使用十六进制区块号，也可以使用earliest、latest、safe、finalized等标识。要复原过去的状态，应使用明确的历史区块号，而不是只查询latest。读取余额、合约代码、交易计数、存储数据或执行只读调用时，区块高度会决定返回的是哪个时间点的状态。
JSON-RPC的数量值采用带0x前缀的紧凑十六进制格式，零表示为0x0。实际查询时还要注意节点、网络和客户端是否支持目标方法，以及节点是否保存了所需的历史数据。返回结果应与交易回执、事件日志和区块信息相互比对。
检查合约是否通过代理升级
挖矿规则可能写在普通合约中，也可能通过代理合约调用实现合约。OpenZeppelin的代理资料说明，代理可以把调用委托给实现合约；在ERC1967模式下，实现地址保存在特定存储槽中，并可通过升级操作改变。这样一来，用户看到的代理地址可能长期不变，但实际执行的规则代码可能发生变化。
核查时应区分三个地址：用户交互的代理地址、当前或历史实现合约地址，以及负责升级的管理员、升级逻辑或Beacon地址。再根据合约事件和升级交易确定每个实现版本的生效区块，并分别查看对应代码。只读取当前实现合约，可能无法解释较早时期的奖励计算方式。
UUPS和透明代理的升级逻辑位置不同，Beacon代理还可能由独立的Beacon统一指向实现合约。因此，发现代理结构后，不能仅凭合约名称推断规则，还应结合实现地址变化、升级事件、初始化调用和权限控制进行核验。
如何整理一份可复核的历史规则
可以按时间顺序建立记录：先写明网络和合约地址，再列出规则生效区块、触发交易、相关事件、实现合约地址，以及该阶段能确认的奖励计算或参与条件。对于无法从链上直接读出的内容，例如前端展示口径、社区公告或未上链的说明，应单独标注为待外部资料核实。
若规则由合约存储变量决定，可在不同历史区块调用只读方法或读取相关存储槽，并将结果转换为合约定义的单位。若规则由每笔交易的参数或事件体现，则应检查交易输入、日志主题和事件数据。解析前必须确认ABI与当时的实现版本相匹配。
这类核验只能说明链上记录呈现出的规则和执行结果，不能自动证明项目方所有宣传内容，也不能据此推断未来是否继续挖矿。查询结果应保留区块号、交易哈希和合约版本，方便其他人重复检查。
常见问题
问：只查代币合约就能知道挖矿规则吗？答：通常不能。代币合约主要记录余额、转账和授权等功能，挖矿奖励可能由独立的质押、农场或分配合约负责，需要定位实际执行奖励计算的合约。
问：代理合约地址没有变化，是否代表规则没有变化？答：不代表。代理可以把调用转发到新的实现合约，规则代码仍可能改变。应检查实现地址和升级记录。
问：查到某个区块的奖励参数，能否代表整个历史时期？答：只能代表该区块对应的状态。要描述一个时期，至少需要确认前后规则变更点，并检查中间是否存在升级或参数调整。
问：没有归档节点怎么办？答：可以先确认目标节点是否保留历史状态和交易数据，再使用区块浏览器或其他独立数据源交叉核对。不同服务的支持范围可能不同，不能把一次查询失败直接当成链上没有记录。