> For the complete documentation index, see [llms.txt](https://docs.stacks.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stacks.co/learn/zh/bitcoin-staking/rewards-and-tranches.md).

# 协议债券与奖励机制

每个周期的奖励池流向：三批瀑布式分配、储备基金、覆盖率区间以及单向暂停。

奖励以 sBTC 形式累积到 pox-5 合约，并按固定的优先级顺序分配。债券最先获得支付，只有剩余部分才会流向仅 STX 质押者和储备池。这一排序就是整个设计：它以使仅 STX 的收益更具波动性为代价，稳定 BTC 侧收益。

分配按照自己的节奏运行。一个分配周期是一半的奖励周期，在主网中为 1,050 个比特币区块，或大约一周。因此，每个奖励周期有两次分配，一年大约 50 次。合约将该数字硬编码为每个债券每次分配目标的除数。

此处使用的术语定义见 [术语表](/learn/zh/bitcoin-staking/glossary.md).

## 资金瀑布，按顺序

分配并不是自动发生的。任何人都可以调用 `calculate-rewards`；它是无许可的，并且在每个分配高度最多只运行一次，第二次调用会以 `ERR_DISTRIBUTION_ALREADY_COMPUTED u30`拒绝。它还会断言当前所有活跃债券都出现在 `(list 6 uint)` 中，否则会以 `ERR_ACTIVE_BOND_NOT_INCLUDED u33` 失败。奖励不会自己到来；必须有人触发合约。

<div data-with-frame="true"><figure><img src="https://2842511454-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FH74xqoobupBWwBsVMJhK%2Fuploads%2FA6QAOhEP5EQlLCU1Ttc7%2Fstaking-reward-waterfall.png?alt=media&#x26;token=60248573-61ae-4999-9630-5e6ad8560e75" alt="A three-step waterfall diagram. The cycle&#x27;s reward pool flows first into the protocol bond tranche, which takes each active bond&#x27;s target yield in full. What remains, labelled the cycle excess, flows into a second step that splits eighty-five percent to the STX-only staking tranche and fifteen percent to the reserve fund tranche."><figcaption><p>每个周期的奖励池会先填充协议债券分层。只有该周期的超额部分才会进入仅 STX 质押分层和储备基金分层，它们按 85/15 分配。</p></figcaption></figure></div>

### 协议债券分层

每个活跃债券在其他任何分配前都会先获得其目标收益。每次分配：

```clarity
(target-yield (/ (/ (* total-sats (get target-rate bond)) u10000) u50))
```

也就是该债券质押的总 sats 乘以其以基点表示的目标费率，再除以一年 50 次分配。

债券的支付顺序由合约按规范顺序强制执行，若列表顺序错误则会以 `ERR_INVALID_BOND_PERIOD_ORDERING (u29)`拒绝： `stx-value-ratio`降序排列，并以债券索引升序作为平局判定。 `stx-value-ratio` 表示每 100 sats 对应的 uSTX，因此单位 BTC 上锁定 STX 最多的债券会优先获得支付。

当资金池无法覆盖所有债券时，这一点很重要。若剩余资金池足以覆盖某个债券，则该债券会获得其全部目标值；否则只能拿到剩余的全部。因此，缺口不会按比例分摊，而是完全由顺序靠后的债券承担，这意味着最低的 `stx-value-ratio` 债券。

债券的目标费率在整个期限内固定不变。它只在 `setup-bond` 时写入，且没有任何函数会修改它，因此该费率会在绑定期间的每次分配中一致适用。

大约 10% 的协议债券容量预留给通过池进行社区参与，同时也包括为白名单机构合作伙伴协商分配的额度。这是白皮书第 4.2 节中的分配政策。合约中没有容量或预留份额常量。

### 仅 STX 质押分层

超出协议债券义务之外的矿工收入就是 **周期超额**。它在仅 STX 质押分层与储备基金分层之间分配。仅 STX 质押者获得其中 85%，按质押份额比例分发。这一面向参与者的部分见 [质押到现有签名人-管理者](https://docs.stacks.co/operate/staking-stx/stack-with-a-pool).

如果某个周期完全没有仅 STX 质押者，那么这 85% 不会被留作未分配，也不会抬高每周期每代币奖励数值。 `未分配的质押者份额` 会把全部质押者份额并入 `reserve-deposit` ，而不是让其悬空。

### 储备基金分层

储备池获得另外 15%，由 `RESERVE_RATIO u1500` 相对于 10,000 基点分母来设定。储备池分成会先计算，剩余部分则归仅 STX 质押者：

```clarity
(reserve-cut (/ (* remaining-rewards RESERVE_RATIO) u10000))
(stx-staker-rewards (- remaining-rewards reserve-cut))
```

这种计算顺序与上文描述的优先级顺序相反，这是有意为之。瀑布层级位置是经济模型中的优先级标签；代码顺序则是算术运算。若不区分这一点来阅读合约，文档看起来就像是在和源码矛盾。

白皮书将 85/15 称为储备分配百分比的建议初始值。在主网中，它不是参数： `RESERVE_RATIO` 是合约常量，因此要更改该拆分比例就必须部署新合约。

储备的存在是为了缓冲协议债券缺口。

白皮书将储备描述为分成两个篮子持有：一个 BTC 篮子，以及一个由稳定币或短期国债组成的 USD 篮子，新贡献在存入时按比例拆分。在回撤时，BTC 篮子先被动用，USD 篮子是最后防线。pox-5 中并不存在这种篮子结构。合约只跟踪一个 `reserve-balance` ，以 sBTC 计价，因此双篮子拆分和回撤顺序属于链外的国库安排。

**合约内部没有任何东西可以将其动用。** `reserve-balance` 会在 `calculate-rewards` 中增加，并且只会在一个位置减少： `transfer-from-reserve`，它是 `define-private`，带有 `#[allow(unused_private_fn)]`，并且在合约中没有任何调用点。其注释本身明确说明了它的位置：“只能由节点作为共识的一部分（通过 SIP 流程）调用。”无论是债券管理员还是暂停管理员都无法触达它，因此释放储备资金需要硬分叉。以这种方式调用时，它会检查余额是否足以覆盖该金额（`ERR_INSUFFICIENT_RESERVE_BALANCE u51`），扣减 `reserve-balance`，并转出 sBTC。该错误常量只为这一路径存在，因此看起来像是未引用。

第二个私有函数 `transfer-stranded-rewards`也同样处于闲置状态，且适用范围更广：用于将 sBTC 移出合约的通用处理，例如因暂停而滞留的奖励。不同于 `transfer-from-reserve` ，它不做内部记账，也不对金额设置任何边界。

因此，储备会自动累积，且只会通过硬分叉释放。把这一点明确说出来很重要，否则看起来就像是个漏洞。

## 覆盖率

覆盖率是每周期奖励池除以每周期配对 BTC 义务。目标值为 2.0x，响应区间从 0.8x 到 2.0x 及以上。

在 PoX-5 启动阶段，这个区间由 Stacks Endowment 人工管理。合约中没有任何内容会计算、存储或响应覆盖率。预计 PoX-6 将支持链上自动区间响应。

## Andon 拉绳

Andon 拉绳独立于覆盖率区间，是链上唯一存在的熔断机制。

暂停管理员调用 `pause-rewards`。之后， `claim-rewards` 会在其 `(not (var-get rewards-paused))` 断言处失败，并回退为 `ERR_REWARDS_PAUSED u53`.

之所以这个刹车是真实存在的，是因为该角色由一个活跃主体持有。在已部署合约中，这两个管理员角色都初始化为同一个地址：

```clarity
(define-data-var bond-admin principal 'SP72DMR3MJKS7RVBY33JVV7EEJSQ1PYDVKDP10FX)
(define-data-var pause-admin principal 'SP72DMR3MJKS7RVBY33JVV7EEJSQ1PYDVKDP10FX)
```

在非主网网络上 `make_pox_5_body` 会在部署时把这两个字面量重写为配置中的管理员。 `TODO: this should be set to some predefined multisig for mainnet` 源码中的注释位于 `bond-admin` 之上，而不是位于 `pause-admin`.

暂停会停止领取。它不会重定向奖励，奖励仍会继续在合约中累积。

这是单向的。合约没有恢复暂停的函数，其注释也写明了这一点：“这是单向的：没有恢复暂停函数。一旦暂停，奖励仍可继续在此累积，而恢复需要硬分叉。”这种恢复就是 `transfer-stranded-rewards` 的用途。

## 这两个管理员角色

`bond-admin` 和 `pause-admin` 是不同的角色，分别存放在独立的数据变量中，也可分别转移，尽管它们最初都初始化为同一个地址。两者都是 Endowment 的运营职责。如果你把这页当作参与者阅读，你不会调用它们中的任何一个。

| 角色            | 设置                                                                                                      | 由以下操作轮换                     | 防护                          |
| ------------- | ------------------------------------------------------------------------------------------------------- | --------------------------- | --------------------------- |
| `bond-admin`  | 通过以下参数设置债券参数 `setup-bond`: `target-rate`, `stx-value-ratio`, `min-ustx-ratio`, `early-unlock-bytes`，白名单 | `set-bond-admin`，仅当前持有人可调用  | `ERR_UNAUTHORIZED u1`，受重入防护 |
| `pause-admin` | 通过以下方式实现的一次性奖励暂停 `pause-rewards`                                                                        | `set-pause-admin`，仅当前持有人可调用 | `ERR_UNAUTHORIZED u1`，受重入防护 |

二者都受以下限制 `contract-caller`，因此都无法通过中介合约转发。

## 来源

本页上的每一项合约级说法都已对照固定版本和已部署合约进行核验：

* [`pox-5.clar` 在标签 4.0.1](https://github.com/stacks-network/stacks-core/blob/4.0.1/stackslib/src/chainstate/stacks/boot/pox-5.clar)
* [`SP000000000000000000002Q6VF78.pox-5` 在主网](https://explorer.hiro.so/txid/SP000000000000000000002Q6VF78.pox-5?chain=mainnet\&tab=sourceCode)

10% 的社区预留和覆盖率目标及区间在合约中都未以任何形式出现。二者都属于设计层面，来自白皮书。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.stacks.co/learn/zh/bitcoin-staking/rewards-and-tranches.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
