LAK 合约审查报告

开发者导向的合约行为说明 · 不等同于安全审计

⚠️ 源码修订影响（2026-09-17）：6.3 的修复已合入仓库源码，但尚未部署。 Sepolia 上的 0xb25E69…DBF6 仍是修复前的字节码，与当前仓库源码不再逐位一致。 第 2 节的一致性核验结论只对修复前的提交成立；下一次部署（含主网）必须重新核验。

1. 结论摘要

2. 链上一致性核验（本次新增证据）

方法：拉取链上运行时字节码，与仓库编译产物 artifacts/LAK.sol/LAK.json 的 deployedBytecode 逐位比对。

链上元数据（Etherscan）

✅ 结论：链上运行的代码与仓库源码编译结果一致。 这一核验为后续"以仓库源码为审查依据"提供了依据。

3. 架构与继承

LAK
├── ERC20                    (OZ) 基础代币
├── ERC20Burnable            (OZ) 持有人自毁
├── ERC20Pausable            (OZ) 暂停
├── ERC20Permit              (OZ) EIP-2612 离线授权
├── AccessControl            (OZ) 七类角色
└── ReentrancyGuard          (OZ) 重入防护

重写点：decimals() / _update()
新增点：角色常量、经济参数、风控状态、事件、错误、业务函数

唯一状态变更入口：_update(from, to, value) —— 所有转账、铸造、销毁都经此函数 （contracts/LAK.sol:278），这是理解全部分发逻辑的关键。

4. 自定义逻辑清单（相对 OZ 标准实现的部分）

5. 参与者与可执行动作

5.1 任何持币人（无需角色）

5.2 MINTER_ROLE

5.3 BURNER_ROLE

5.4 PAUSER_ROLE

5.5 COMPLIANCE_ROLE

5.6 FEE_ROLE

5.7 ORACLE_ROLE

5.8 DEFAULT_ADMIN_ROLE

6. 关键实现细节与观察

6.1 _update 的三段式扣减（✅ 确认行为）

// :292-293  计提
if (burnRate > 0) burnAmount = (value * burnRate) / BPS;
if (feeBps > 0)   feeAmount  = ((value - burnAmount) * feeBps) / BPS;

// :296-299  销毁（总供应下降）
super._update(from, address(0), burnAmount);

// :302-306  手续费（进入 feeRecipient）
super._update(from, recipient, feeAmount);

// :308  净额到账
super._update(from, to, value - burnAmount - feeAmount);

6.2 🟡 totalBurned 的统计口径不完整

影响：totalBurned 是"协议强制销毁量"，不等于代币的累计销毁总量。 若对外以 totalBurned 作为"通缩证据"，口径会偏低。

建议：对外表述改为「协议销毁量」，或在前端同时展示 MAX_SUPPLY − totalSupply() 作为总销毁量。 （属语义/展示问题，非安全缺陷。）

6.3 ✅ 治理参数可导致转账全局回滚（本次新发现 · 已在源码修复）

修复已落地（2026-09-17，仓库源码；尚未部署）

• 指数上限：新增常量 MAX_INDUSTRY_INDEX = 10 × INDEX_SCALE（基准 100 → 上限 1000）， setIndustryIndex 两个参数均校验
• 灵敏度上限：新增常量 MAX_BURN_SENSITIVITY = BPS，setBurnPolicy 超限 revert SensitivityTooHigh
• 计算侧防御：currentBurnBps() 对 devEntertainment / devMusic / weightedDev 按 MAX_DEV_BPS 封顶 —— 即使将来新增写入路径绕过入口校验，也不可能溢出
• 上限以链上常量强制，与合约既有风格一致（硬顶 / 费率上限 / 销毁率上限同为常量）
• 回归测试 test/LAK.burn-params.test.js 已从「记录缺陷行为」改为「断言拒绝」，并新增 「把每个参数都推到允许的最大值后 currentBurnBps 不溢出、转账始终可用」一例
• 全量 54 项测试通过（本文件 12 项）；合约体积 14,428 / 24,576 字节（58.7%）

以下为修复前的原始记录，保留以便对照。

currentBurnBps()（:229）在三处做了算术，其中两处没有上限约束：

uint256 devEntertainment = entertainmentIndex > indexTarget ? ((entertainmentIndex - indexTarget) * BPS) / indexTarget : 0;
uint256 weightedDev = (devEntertainment * (BPS - musicWeightBps) + devMusic * musicWeightBps) / BPS;
uint256 total = baseBurnBps + (weightedDev * burnSensitivity) / BPS;   // ← burnSensitivity 无上限

约束缺失点

后果（已实证）

以下结论由 test/LAK.burn-params.test.js 在本地 Hardhat 网络复现，非纯推演。

若 autoBurnEnabled = true，且治理方设定了大额 entertainmentIndex 与 burnSensitivity：

weightedDev * burnSensitivity  →  超过 2^256  →  Solidity 0.8 溢出检查 → revert

由于 currentBurnBps() 被 _update（:291）在符合计费条件的每一笔转账中调用：

等价于一次 unpause 无法恢复的链上冻结，必须靠额外治理操作才能恢复可用性。

风险评级：低（需要 ORACLE_ROLE + BURNER_ROLE 同时设置极端参数，而两者当前均由多签持有）， 但后果严重，且此前的自查报告（Solhint / Slither / 覆盖率）未覆盖这一类"参数组合导致运行期回滚"的问题 —— 自动化工具检查的是代码缺陷，而这是参数组合造成的可用性故障。

建议

1. 主网版本为 entertainmentIndex / musicIndex 增加合理上限（如 ≤ 100 × INDEX_SCALE 量级）；
2. 为 burnSensitivity 增加上限校验；
3. 在 setIndustryIndex / setBurnPolicy 中加入一次"试算"（调用内部计算并确认不溢出）；
4. 运营侧设定硬性规则：修改参数的同一笔治理操作应先在小额转账上验证。

6.4 🟡 手续费豁免同时免除销毁

:290 的条件是「双方都不豁免才计费」，意味着任一豁免地址参与的交易：

• 不产生手续费 ✓（设计意图：避免做市磨损，见白皮书 4.4）
• 也不产生行情销毁 ← 容易被忽略的一点

影响：若把大量地址（如运营账户、合作方）加入豁免名单，通缩机制的实际作用范围会被显著缩小。

建议：豁免名单应保持最小化并对外公示；白皮书中"零手续费场景"的表述可补充"同时不计入销毁"。

6.5 🟡 rescueToken 的信任边界

IERC20(token).safeTransfer(to, amount);   // :268

token 为调用方指定的任意地址，理论上可以是恶意合约。现有防护：

判定：风险可接受。 该函数仅能由 DEFAULT_ADMIN_ROLE（多签）调用，且调用方需主动指定恶意地址。

6.6 🟡 冗余防御分支

:301 feeRecipient == address(0) ? address(0) : feeRecipient —— 由于构造函数与 setFeeRecipient 均拒绝零地址，该分支逻辑不可达（与自查报告 5.3 一致）。保留无害，可精简。

6.7 ✅ 与各文档的一致性核对

7. 未覆盖范围与不确定性

本报告未做的事（不代表已完成）：

• ❌ 未做动态测试、模糊测试（fuzzing）、形式化验证
• ❌ 未审计 OpenZeppelin 依赖本身（假定其正确性由上游审计背书）
• ❌ 未评估经济模型、代币分配与市场行为的合理性
• ❌ 未做跨链组件（Solana / BRC-20）审查
• ❌ 未评估治理流程、密钥管理与多签操作规范
• ❌ 未评估合规与监管定性（见 ISSUANCE-STRUCTURE.md）

已知不确定性

8. 行动建议

⚠️ 上述建议中，凡涉及源码改动的，均须重新编译、重新部署、重新验证并重做多签交接（合约不可升级）。 建议与第三方审计的发现合并处理，一次性进入主网版本。

🔴 本条现已触发：6.3 的修复已于 2026-09-17 改动源码，因此必须走完 重新编译 → 重新部署 → 重新验证 → 重做多签交接。当前 Sepolia 部署仍是修复前版本、 与仓库源码不一致；下一次部署应把本修复与第三方审计的发现合并为同一个版本，避免改两次。

9. 免责声明

本报告为开发者导向的合约行为说明，由项目方使用链上公开数据与自有源码自行整理，不构成第三方安全审计、不构成安全认证、不构成形式化验证，也不构成任何投资建议或法律意见。

报告中的"确认行为"指有代码位置支撑的实现描述；"观察"与"不确定性"指基于阅读的推断，可能不完整或有误。在主网部署前，本合约仍须经独立第三方审计机构的完整审计。

报告日期：2026-09-16 · 审查对象：0xb25E69F0D1f07A4e473DAdf93Af5f9322AA5DBF6（Sepolia） · 源码：contracts/LAK.sol（310 行）