先明确要查哪一类历史规则
“存币挖矿”这一名称本身不能说明活动采用什么技术。查询前应明确活动名称、所属网络、目标时间，以及要核实的具体条款，例如参与条件、计算方式或退出限制。这里讨论的是涉及智能合约时的通用核对思路，不代表任何具体项目的规则已经得到确认。
历史核对需要回答两个不同问题：当时对外公布了什么，以及当时程序如何执行。文字说明与链上逻辑不是同一种证据，不能只凭其中一项推断全部事实。
理解合约代码与状态的区别
以太坊智能合约文档将合约解释为部署在特定链上地址的程序，由代码和状态数据组成，用户通过交易调用其功能。这意味着理解执行规则时，既要关注程序逻辑，也要关注相关数据。
由此可见，仅查看今天展示的代码或数值，不足以直接确认过去某个时点的规则。核对材料需要与目标时间对应；如果只有当前信息，应把结论限定为当前可见内容，而不是将其写成历史事实。
地址不变，不代表执行逻辑始终不变
OpenZeppelin代理合约文档说明，代理可以将调用委托给实现合约，部分架构支持升级；信标代理则通过信标获取实现地址。文档也包含不可升级的代理形式，因此不能把所有代理都视为可升级。
查询历史规则时，如果目标采用可升级代理，就需要区分用户交互的地址与对应时期的实现版本。单独记录一个地址，或者只阅读最新实现，可能遗漏版本差异。反过来，也不能仅凭使用代理就断言项目曾修改规则。
把结论组织成可以核对的证据链
可以按“待核实条款、目标时间、对应说明、合约版本、相关状态、尚缺证据”整理材料。每个结论都应说明它证明的是公开表述还是程序行为，适用于哪个时期，以及是否存在无法确认的环节。
两份技术文档能够解释为什么需要区分这些层次，却没有提供某项存币活动的历史公告、合约地址或变更记录。因此，不能据此写出具体活动的奖励比例、开放日期或规则调整经过。
常见问题与适用边界
只看智能合约能否还原全部活动规则？未必。以太坊文档指出，合约本身不能直接获取链下信息，需要借助预言机等机制。因此，涉及链下条件的事项，不能只靠合约代码推断完整规则。
没有历史版本时能否用当前规则代替？不宜。更准确的写法是说明当前可见内容，并明确历史情况尚未核实。如果活动不依赖链上合约，上述技术核对思路也不能替代对其历史条款的查证。