> 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/glossary.md).

# 比特币质押术语表

比特币质押文档中使用的术语：保证金、保证金时间线、分批、覆盖率、提前退出，以及 PoX-5 词汇。

Bitcoin 质押（PoX-5）文档集中使用的术语。

## 协议债券

一个为期 12 个周期的双资产承诺，约六个月：在 Bitcoin L1 上的 BTC 时间锁，与在 Stacks L2 上的 STX 锁定相配对，二者通过密码学关联，目标是 BTC 侧的 Tranche 1 收益。该术语是合约常量 `BOND_LENGTH_CYCLES u12`.

## 第0天 / 第175天 / 第182天（债券时间线）

第0天是两条腿都必须完成锁定才具备资格的截止点；注册必须在债券开始高度之前完成。第175天是 L1 时间锁的最小解锁高度。它恰好位于债券 L2 结束前半个奖励周期，即主网上 1,050 个 Bitcoin 区块，约七天。第182天结束 L2 上的绑定期；STX 会在下一个周期边界解锁。

如果 L1 锁定的解锁高度低于第175天，注册时会被拒绝。

## 绑定期

单笔债券完整的 12 个周期期限，从第0天到第182天。共有六个绑定期并发且错峰运行，每两个周期开启一次。债券索引 *n* 在债券索引 *n+6* 开始时结束，这就形成了六层深度的重叠。

## 签名者周期（奖励周期）

奖励周期的另一种说法：2,100 个 Bitcoin 区块，主网上约 14 天。它由一个奖励阶段加上其后续的 100 区块准备阶段组成。本页上的其他周期数字都由它推导而来。

## 分配周期

半个奖励周期，主网上 1,050 个 Bitcoin 区块，也是计算时钟奖励所依据的周期。每个奖励周期有两次分配，约每年 50 次，这也是每个债券按分配计算的目标收益的除数。

## 锁定脚本

L1 这一腿是一个具有两个花费分支的 P2WSH 输出。时间锁分支要求在 CLTV 高度之后由质押者签名。提前退出分支要求披露一个 32 字节的预像，满足债券的提前解锁子脚本，并由质押者签名。质押者通过哈希承诺与脚本绑定， `sha256(sha256(to-consensus-buff? staker))`，而不是通过明文推送。这就是为什么 L1 债券本质上是单质押者的，不能被池化。

两条分支都需要质押者自己的签名，而不仅仅是时间锁那一条： `staker-unlock-bytes` 在分支选择之外无条件执行于 `OP_ENDIF`之后。因此，提前退出花费除了提前解锁子脚本要求之外，还需要质押者的签名和这份 32 字节承诺预像。

## BTC SPV 证明

在注册时提供的比特币侧证明，用于表明 L1 时间锁输出存在且已确认。在构建注册之前，有两个硬性上限很重要：

* **每次注册最多 10 个锁定输出点。** `register-for-bond`的 `btc-lockup` ok 分支的类型为 `outputs: (list 10 {…})`，验证折叠会把其 `seen-outpoints` 累加器上限设为 `u10`。重复的 `(txid, output-index)` 会失败，并返回 `ERR_DUPLICATE_LOCKUP_OUTPOINT u46`。你可以把 BTC 分散到多个时间锁 UTXO 中，但不能超过十个。
* **Merkle 证明的深度不能超过 14。** 证明的 `leaf-hashes` 字段的类型为 `(list 14 (buff 32))`.

## Tranche 1：活跃协议债券

瀑布分配中的第一站。任何收益分配之前，所有活跃债券都会先拿到其目标收益。根据白皮书第 4.2 节，大约 10% 的 Tranche 1 容量保留给通过池参与的社区成员。完整说明见 [奖励与分层](/learn/zh/bitcoin-staking/rewards-and-tranches.md).

## Tranche 2：仅 STX 质押者

第二站。仅 STX 质押者按其质押份额比例获得该周期超额收益的 85%。

## Tranche 3：储备基金

第三站。获取该周期剩余超额收益的 15%。

## 周期超额收益

超出该周期 Tranche 1 义务的矿工收入。Tranche 2 和 Tranche 3 分割的就是这部分：85% 给仅 STX 质押者，15% 给储备金。

## 瀑布分配

三层之间的奖励优先级顺序：先债券，然后把超额收益在仅 STX 质押者和储备金之间拆分。债券按递减的 `stx-value-ratio` 顺序支付，任何短缺都会完全落在该顺序中的最后几笔债券上，而不是按比例分摊。其效果是 BTC 侧收益更稳定，而仅 STX 的回报更具波动性。

完整说明见 [奖励与分层](/learn/zh/bitcoin-staking/rewards-and-tranches.md).

## 覆盖率

每周期奖励池除以每周期配对 BTC 义务。目标是 2.0x，响应区间为 0.8x 到 2.0x 及以上，在 PoX-5 启动期由 Stacks Endowment 人工管理。合约既不计算它，也不对它做出响应；这是一个设计层面的构造。

## 储备基金

瀑布分配中的第三站。它累积该周期超额收益的 15%，以及任何没有仅 STX 质押者的周期中的 STX 质押者份额。

白皮书将其描述为分为两个“袖口”：一个 BTC 袖口和一个由稳定币或短期限国债构成的 USD 袖口，在存入时拆分，先动用 BTC 袖口，USD 袖口作为最后一道防线。该结构并不在 pox-5 中；pox-5 只跟踪一个 `reserve-balance` ，以 sBTC 计价。两个袖口是链下的金库安排。

合约内部没有任何东西可以动用它。 `reserve-balance` 在 `calculate-rewards` 中递增，并且只在一个地方递减， `transfer-from-reserve`，它是 `define-private`，带有 `#[allow(unused_private_fn)]`，并且在合约中没有任何调用点。它只能由节点作为共识的一部分来调用，因此要触及储备需要硬分叉。债券管理员和暂停管理员都无法触及它。

## PoX-5

实现 Bitcoin 质押的 Clarity 引导合约。它在 Epoch 4.0 取代了 PoX-4。PoX-5 运行一个由 Endowment  মধ্য介的启动流程，其中容量、比例和目标 APY 都由管理方式设定；PoX-6 是计划中的算法继任者。

## Epoch 4.0

激活 PoX-5 以及 SIP-044 的 Clarity 和共识变更的 Stacks 共识纪元：新的区块头版本方案、取消成本投票、恢复每区块 1,000 STX 的发行，以及移除 burn 地址。它在 Bitcoin 区块 960,230 处激活，并要求发布 4.0.1。

## 准备阶段

每个奖励周期最后 100 个 Bitcoin 区块，在每个周期重复一次，在此期间下一个周期的签名者和质押者集合被冻结。其间有六个入口会被拒绝，并返回 `ERR_STAKE_IN_PREPARE_PHASE (u47)`: `register-for-bond`, `update-bond-registration`, `stake`, `stake-update`, `announce-l1-early-exit`，以及 `unstake-sbtc`. `unstake` 会通过另一项检查被拒绝，并返回 `ERR_UNSTAKE_IN_PREPARE_PHASE (u28)`.

## 签名者管理器

每个质押者都会委托给它的一个合约，无论是债券还是仅 STX。它通过由 `validate-stake!` 定义的 `signer-manager-trait`回调来拥有审批逻辑，并且奖励会先流向这里再继续分发。大多数集成方会使用现成的 signer-manager，而不是自己编写。参见 [质押到现有的签名者管理器](https://docs.stacks.co/operate/staking-stx/stack-with-a-pool).

## 签名者集合最低值

`SIGNER_SET_MIN_USTX u50000000000` 是 50,000 STX。这是分配给某个签名者的总 uSTX 的聚合阈值，既计算债券 STX，也计算仅 STX 的 STX，不设单个质押者最低值。达到或超过该阈值的签名者会获得该周期的收益分配；低于该阈值则停止分配。

## 提前退出

L1 锁定脚本的提前退出分支，需要提前解锁密钥和质押者共同参与。两者都不能单独移动这些币。

### 合约允许的内容

提前解锁子脚本由债券管理员在 `setup-bond`时按每个债券单独设置。合约自身的文档注释写道 `early-unlock-bytes` “应采用以下形式： `<pubkey> OP_CHECKSIG` 或一个 M-of-N `CHECKMULTISIG` 模板，并且 MUST 在栈上留下一个有效结果（它会被共享的 OP\_VERIFY 消耗）。”它作为不透明的 `(buff 683)` 按每个债券存储，而合约从不检查其形状。因此，签名者集合的形状是每个债券的策略选择，而不是协议常量。

### 实际部署的内容

在实践中，它始终是一个单独的共签公钥，使用 `OP_CHECKSIG`，由一个冗余、KMS 支持的提前退出签名服务管理的单密钥，而不是链上多签。这是操作层面的选择，不是协议约束。只说“M-of-N”会误导你去设计一个并不存在的多签；只说“始终只有一个密钥”，又会让你以为合约强制执行了某些其实并没有的东西。

### Stacks 侧调用

`announce-l1-early-exit` 是 Stacks 侧调用，而质押者必须自行发起： `contract-caller` 必须同时等于 `tx-sender` 和质押者参数，因此任何合约都不能代表他们来执行。它会把成员关系的 `amount-sats` 清零，同时保留成员行，这就是为什么 **配对的 STX 会一直锁定到期**.

每个债券只能宣布一次。对同一债券的第二次 announce 会回滚，并返回 `ERR_L1_EARLY_EXIT_ALREADY_ANNOUNCED u50`，所以调用者应先检查 `fetchHasAnnouncedL1EarlyExit` 。

### 顺序

合约不强制规定 `announce-l1-early-exit` 与比特币侧花费之间的顺序。就操作而言，顺序反正是固定的：共同签名者只有在 Stacks 上找到 announce 交易后才会签名，而一旦该公告落地，该头寸就会立刻停止赚取收益。仅从合约语义出发会得到错误的流程。

共同签名只在 CLTV 高度之前才需要。之后，质押者会通过 `OP_IF` 分支单独取回，不再涉及共同签名者。

sBTC 锁定参与者则使用 `unstake-sbtc` ，它没有提前退出门控，也没有公告步骤。

## sBTC 自动桥接

默认的奖励路径。矿工 BTC 会流入奖励池并自动桥接为 sBTC，而 pox-5 会用 sBTC 向每个 signer-manager 支付其奖励。随后 signer-manager 再向其质押者支付：默认是 sBTC；如果质押者使用支持此功能的 signer-manager 并在其中存了一个比特币地址，也可以通过 sBTC 提现将 BTC 发到 L1。

质押者将该地址存储在 `signer-calldata`中，这是一个不透明的 `(optional (buff 500))` 参数，属于 `stake`, `stake-update`, `register-for-bond` 和 `update-bond-registration`。pox-5 会把它传给 signer-manager 的 `validate-stake!` ，但不会解释它，因此可用的付款选项完全取决于该 signer-manager 的实现。 [Fastpool Max 500 signer-manager](https://explorer.hiro.so/txid/SPMPMA1V6P430M8C91QS1G9XJ95S59JS1TZFZ4Q4.fastpool-max500-signer-manager?chain=mainnet)例如，还允许质押者直接用 `set-payout-config` 和 `clear-payout-config`来设置或清除地址，并在其 `payout` 函数中通过 `.sbtc-withdrawal`.

## 滚转窗口

结束中的债券可以在不经过中间提现的情况下直接滚转为新债券，或者滚转为仅 STX 质押。它在债券的 L1 解锁高度开启，即债券 L2 结束前半个奖励周期，并且不会关闭。两者都会 `register-for-bond` 和 `stake` 在调用者已经持有债券成员资格时检查它；更早行动会返回 `ERR_ROLLOVER_TOO_EARLY (u48)`.

另一项非重叠测试会拒绝第一个周期早于旧债券结束的新头寸。这两个门槛只会在债券最后半个奖励周期同时通过，因此那是滚转最早可发生的时间。债券到债券的滚转只转移净 sBTC 差额；债券到仅 STX 的滚转会退还全部托管的 sBTC。

## 安灯绳

单向链上断路器。暂停管理员调用 `pause-rewards`，之后 `claim-rewards` 会回滚并返回 `ERR_REWARDS_PAUSED (u53)`。奖励会继续在合约中累积。没有恢复暂停的函数；恢复需要硬分叉。

## `BOND_GAP_CYCLES`

合约常量 `u2`。它同时设置了新债券在开始高度之前可以建立的时间窗口，以及新债券开放的节奏，这正是稳态下形成六个重叠的 12 周期债券的原因。

## 来源

本页上的每一项合约层断言都已对照固定版本和已部署合约进行核查：

* [`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)

覆盖率目标和区间来自 [SIP-045 §3.1.5](https://github.com/stacksgov/sips/blob/642af6804dacc80455c3d49ef66b62bc4fb209aa/sips/sip-045/sip-045-pox-5-bitcoin-staking.md#315-coverage-ratio-requirements) 及其 [白皮书](https://github.com/stacksgov/sips/blob/642af6804dacc80455c3d49ef66b62bc4fb209aa/sips/sip-045/sip-045-5.pdf)；没有任何合约会计算它们。L1 支付选项属于 signer-manager 逻辑，而不是 pox-5 逻辑：Fastpool Max 500 示例是已部署的合约 `SPMPMA1V6P430M8C91QS1G9XJ95S59JS1TZFZ4Q4.fastpool-max500-signer-manager`.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.stacks.co/learn/zh/bitcoin-staking/glossary.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.