先明确查询范围
artt币质押挖矿的历史规则怎么查，首先需要确认具体项目、所属网络、活动对应的合约地址与目标时期。仅凭代币简称，无法确定哪个合约负责质押与奖励，也无法确认历史规则。
目前缺少能够核验ARTT具体活动的项目公告、合约地址及历史记录，因此不能确定其锁定期限、奖励计算方式或规则变更情况。下述方法适用于以太坊及采用相近合约机制的链上活动，不直接覆盖平台内部记账的产品。
区分规则逻辑与参数状态
Ethereum.org的智能合约结构说明将合约解释为地址上的程序，包含数据与函数；状态变量持久保存在链上，函数可以读取或修改状态，事件则记录执行中的相关信息。
据此，历史规则核验要同时关注计算逻辑与当时参数。若活动将期限、奖励速率等写入状态变量，当前读取到的数值只能说明当前状态，不能自动证明过去也采用相同数值。持久存储也不表示变量永远不变。
按时间对应证据
整理历史规则时，可将每项待核验内容对应到目标时间、相关区块、合约代码及参数变更交易。例如，要判断某项期限是否发生调整，需要找到控制期限的逻辑，以及能证明该时期参数取值的记录。
交易和事件日志可以提供变更线索，但合约未必为每一次参数修改生成完整事件。没有找到某类日志，不能直接认定规则未变；还需结合函数逻辑和可取得的历史状态核对。
代理合约需要追溯实现版本
OpenZeppelin的4.x代理文档说明，代理可以把调用委托给实现合约；部分机制允许更换实现地址，信标代理则通过信标获取实现地址。文档也列出了实现升级、管理员变化与信标变化的相关事件。
如果目标活动采用可升级代理，同一个入口地址可能在不同时期执行不同代码。核验时应将目标时期对应到当时的实现合约，再检查相关逻辑。是否存在升级机制、是否发生过升级，都需要具体证据，不能推定ARTT采用了这些设计。
常见问题与结论边界
只看当前合约代码够不够？通常不足以证明历史规则，因为参数可能变动，代理背后的实现也可能更换。只看升级事件是否足够？也不够，升级记录主要帮助定位版本，仍需分析该版本如何处理相关参数。
最终记录应写清适用时期、合约地址、规则内容及证据位置。缺少历史参数、旧版本代码或链上对应关系时，应将相关项标为尚未核实，避免把技术上的可能性写成项目已经发生的事实。