先确认“挖矿”具体指什么
“挖矿”在代币项目中可能指多种机制，例如通过流动性或质押获得奖励、按照区块或时间增发代币、完成任务领取代币，或者早期采用独立的工作量证明网络。不同机制对应的代码位置和链上证据不同，因此查询前应先确认 LRC 所在的区块链、代币合约地址，以及问题中的挖矿是发行机制、流动性奖励还是其他活动。仅凭代币简称无法唯一确定合约。
第一步：核对代币合约与基础信息
应先从项目公告、官方文档或区块链浏览器确认合约地址，并检查合约的网络、名称、符号、小数位和总供应量。ERC20 接口通常提供 totalSupply、balanceOf、transfer、approve 和 transferFrom 等功能，这些接口主要描述代币如何查询和转移，并不自动说明代币如何产生。
还要查看合约是否公开源代码，以及部署者、管理员或其他角色是否拥有铸币、暂停转账、修改参数等权限。OpenZeppelin 的 ERC20 实现本身不规定具体的供应机制，项目需要在派生合约中加入铸币逻辑。因此，看到一个合约符合 ERC20 标准，不能直接推断它支持某种挖矿。
第二步：定位发行和奖励逻辑
在已验证的合约代码中，可重点搜索 mint、_mint、burn、reward、claim、stake、deposit、withdraw、pending、emission、rate、start、end 等函数或变量。_mint 通常用于增加总供应量并向指定地址分配代币，但具体的调用条件、奖励计算和权限仍取决于项目自行编写的逻辑。
如果奖励合约与代币合约分开，还需要同时核对两个或多个合约之间的调用关系。奖励合约可能负责记录存入数量、时间和用户份额，再调用代币合约完成发放。此时只阅读代币合约，可能只能看到“可以铸币”，却无法知道谁能领取、如何计算或何时停止。
第三步：用链上记录复核历史变化
合约代码回答“规则如何设计”，交易记录回答“规则是否被执行”。可按区块高度或时间范围检查合约部署、参数设置、铸币交易、奖励领取和管理员操作。ERC20 的 Transfer 事件通常可用于追踪代币转移；铸币时，事件常表现为转出地址为零地址，但具体分析仍应结合合约代码和交易调用数据。
如果规则曾经升级，需要区分不可升级合约、代理合约和外部配置合约。代理模式下，用户交互的地址可能长期不变，而实际逻辑由实现合约提供。查询历史规则时，应记录每次实现合约变更、关键参数修改及其生效区块，避免只看当前代码后倒推早期规则。
适用条件与证据边界
上述方法适用于部署在公开区块链、能够取得合约地址和交易记录的代币系统。若合约未验证、奖励由链下系统计算、历史页面已失效，或项目使用多签和人工发放，单靠 ERC20 接口可能无法完整还原规则。智能合约本身也不能直接读取链下现实信息，依赖预言机或外部系统的规则需要额外核对相关数据来源。
提供的材料只能支持智能合约和 ERC20 的通用原理，不能据此确认 LRC 某一具体合约的历史挖矿参数、开始时间、结束时间、奖励数量或参与条件。涉及这些具体结论时，应以对应合约代码、区块高度、事件日志和项目公开记录相互印证。
常见问题
问：只看代币总供应量变化，能确定挖矿规则吗？答：不能。供应量变化可以提示存在铸币或销毁，但无法单独说明奖励对象、计算公式、权限或生效时间。
问：看到 mint 函数就代表任何人都能挖矿吗？答：不能。函数可能只允许奖励合约、管理员或特定角色调用，实际权限要结合 require 条件、角色配置和历史交易检查。
问：历史规则和当前规则不一致时看哪一个？答：应按目标时间对应的区块高度查看当时生效的代码和参数，并把后续升级或配置变化单独列出。当前页面或当前合约状态不能自动代表过去的规则。