# 3.3 结算引擎与治理模块

#### 3.3.1 结算引擎：确定性结算、分层路由与可追溯执行

结算引擎是 MetaPower 把“可验证事实”转化为“链上可执行动作”的核心组件。其目标是以确定性规则完成周期结算，并将收益、成本、惩罚与储备等资金流按治理参数进行分层路由，确保执行过程可追溯、可复核、可约束。

结算引擎的结算对象为资产包在周期窗口内的结算输入数据包，结算流程由三段组成：

* 结算输入定稿：从可结算队列读取预言机数据包与证明评分，确认窗口连续性与去重
* 结算计算：按统一口径计算毛收益、成本项、可扣减项与净收益
* 资金路由执行：按参数将净收益分配到不同资金池并记录结算事件

结算的输入与输出定义如下：

* 输入：`bundle_id`、统计窗口、预言机聚合值、证明评分、风险标记
* 输出：结算事件（Settlement Event）、资金流分配记录、资产状态更新、治理指标更新

结算事件包含最小字段集合：

| 字段                          | 描述                    |
| --------------------------- | --------------------- |
| event\_id                   | 结算事件唯一标识              |
| bundle\_id                  | 资产包标识                 |
| window\_start / window\_end | 结算窗口                  |
| gross\_revenue              | 毛收益                   |
| energy\_cost                | 能源成本                  |
| om\_cost                    | 运维成本                  |
| other\_deductions           | 其他扣减                  |
| net\_revenue                | 净收益                   |
| scores                      | 证明评分集合                |
| risk\_flags                 | 风险标记集合                |
| routes                      | 路由结果（分配/回购/储备/再投资/惩罚） |
| signatures                  | 结算多签集合                |
| timestamp                   | 时间戳                   |

结算引擎采用“分层路由”的资金结构，将净收益拆分为若干资金流出口，每个出口受治理参数约束：

* 生态分配池：用于节点、验证者、开发者与生态激励
* 回购销毁池：用于市场回购与销毁执行
* 风险储备池：用于波动缓冲、违约损失与应急处置
* 再投资预算池：用于并购、扩张与资产升级
* 惩罚处置池：用于作恶惩罚与仲裁费用

路由执行遵循固定顺序与边界条件：

1. 先满足风险储备的最低覆盖要求
2. 再执行惩罚扣减与异常资产降权
3. 然后按参数比例执行生态分配、回购销毁与再投资
4. 若出现极端波动或风险事件，则自动缩减可分配部分并提高储备比例

结算权重由证明评分与风险标记共同决定。资产包的实际可计入收益为：

* 基础净收益 × 结算权重
* 结算权重由在线、有效产出、能耗一致性、运维可信度等评分综合生成
* 评分未达标将触发降权、延迟结算或暂停结算入口

伪代码示例：

```
function settle(bundle_id, window):
    pkt = read_finalized_oracle_packet(bundle_id, window)
    scores = read_proof_scores(bundle_id, window)

    if pkt.isolated or scores.reject:
        route_to_reserve(bundle_id, window)
        update_state(bundle_id, "DEGRADED")
        return

    gross = calc_gross(pkt)
    cost  = calc_cost(pkt)
    net   = max(gross - cost, 0)

    w = settlement_weight(scores, pkt.risk_flags)
    net_adj = net * w

    reserve_need = reserve_requirement(bundle_id)
    reserve = min(net_adj, reserve_need)
    remaining = net_adj - reserve

    penalty = compute_penalty(bundle_id, window, scores, pkt.risk_flags)
    remaining = max(remaining - penalty, 0)

    routes = apply_routes(remaining, governance_params())
    emit_settlement_event(bundle_id, window, gross, cost, net_adj, reserve, penalty, routes)
    update_metrics(bundle_id, scores, pkt.risk_flags)
```

***

#### 3.3.2 治理结构：参数化治理、权限边界与应急机制

治理模块的目标是将系统关键变量参数化，并通过明确的权限边界与审计轨迹，使治理可执行、可约束、可复核。治理不等同于投票本身，而是对协议演化、风险边界与资金使用的制度化管理。

治理对象分为四类：

* 结算参数治理：分配比例、回购比例、储备比例、降权规则、抽检强度
* 风险边界治理：熔断阈值、异常判定规则、对手方名单、资产评级规则
* 协议升级治理：合约升级、模块替换、预言机集合调整
* 预算与资金治理：再投资预算池使用、生态激励预算、审计与安全预算

治理机制采用“分层治理”以防止单点操控：

* 社区治理层：负责一般参数与预算方向
* 安全委员会层：负责紧急熔断、漏洞响应、黑名单隔离
* 审计与仲裁层：负责争议裁定、证据核验、申诉处理
* 执行层多签：负责关键合约与资金路由的最终执行签名

治理提案采用标准化模板，确保每个提案都可被形式化评估：

| 字段                 | 描述          |
| ------------------ | ----------- |
| proposal\_id       | 提案标识        |
| scope              | 结算/风险/升级/预算 |
| changes            | 变更参数集合      |
| rationale          | 变更理由        |
| impact\_analysis   | 影响评估        |
| rollout\_plan      | 发布计划        |
| rollback\_plan     | 回滚计划        |
| voting\_window     | 投票窗口        |
| execution\_delay   | 执行延迟        |
| required\_quorum   | 法定人数        |
| required\_majority | 通过门槛        |

治理执行采用时间锁与延迟执行，确保变更可被审查并预留反应窗口。涉及资金与安全的提案需要更高门槛与更长延迟。

***

#### 3.3.3 激励与惩罚：激励相容、反作恶与申诉仲裁

MetaPower 的激励设计以激励相容为约束，核心原则是让作恶的期望收益小于作恶的期望成本。系统通过三层手段实现：

1. 结算降权：评分不达标直接降低结算权重
2. 经济惩罚：对虚报、离线套利、篡改数据等行为扣罚保证金或收益
3. 系统隔离：触发阈值后暂停结算入口并进入审计处置

惩罚对象包括数据源、资产包运营方、运维方与关键签名者。惩罚动作由规则触发，避免选择性执法。

惩罚动作集合：

| 动作          | 含义          |
| ----------- | ----------- |
| WeightDown  | 降低结算权重      |
| DelaySettle | 延迟结算并抽检     |
| Slash       | 扣罚保证金或收益    |
| Suspend     | 暂停结算入口      |
| Quarantine  | 隔离数据源或对手方路径 |

申诉仲裁采用证据驱动流程：

* 提交申诉：提供证据索引与时间窗口
* 证据核验：核对文件哈希、事件签名与原始数据
* 仲裁裁定：维持惩罚、部分解除或完全撤销
* 结果执行：更新状态机与结算记录

仲裁结果进入治理与审计轨迹，形成制度化先例，推动规则迭代而非依赖个案处理。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://metapower-1.gitbook.io/metapower-docs/di-3-zhang-xie-yi-ti-xi-yu-ji-shu-lan-tu/3.3-jie-suan-yin-qing-yu-zhi-li-mo-kuai.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.