> For the complete documentation index, see [llms.txt](https://docs.sat20.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sat20.org/xie-yi-yu-an-quan/channel-contracts/channel-contracts.md).

# 通道合约

通道合约（Channel Contract）是聪网早期用于协调 BTC L1 与 SatoshiNet L2 动作的公共协议设施。它与私人 STP 通道不同，也与 SatoshiNet 智能合约不同。

私人 STP 通道管理的是两个 peer 之间的资产控制关系，通道中的资产归属可以由双方最新承诺交易判定。通道合约管理的是公共资产池或公共业务状态，通道合约中的资产不属于通道任意一方，而应理解为属于聪网公共设施；其中可能包含用户寄存的资产，用户可以按合约规则取回。

## 核心定位

通道合约的主要目的，是协调用户发起的 L1/L2 动作：

1. 用户把 BTC L1 资产发送到合约通道地址。
2. 合约识别这笔用户发起的动作。
3. 合约在 SatoshiNet 上执行对应分发、发射、退款、提现或状态更新。
4. 当需要从 L2 回到 L1 时，合约协调 descend / de-anchor 和 L1 输出。
5. 合约记录每个用户动作、结果交易和可查询状态。

通道合约不是为了给公共池资产提供私人通道那种承诺交易安全。公共池资产没有“属于本 peer 或 remote peer”的二分归属，也没有用户可单方面广播的最新 commitment 来取回整个池子。它更像一个由协议约束的跨层公共设施：用户通过明确动作进入，合约按规则处理，结果由 L1/L2 交易和 indexer 事实验证。

## 与私人 STP 通道的区别

| 维度   | 私人 STP 通道                              | 通道合约                                               |
| ---- | -------------------------------------- | -------------------------------------------------- |
| 资产归属 | 资产属于通道两端 peer，可由最新承诺状态分配               | 资产属于公共设施或合约池；用户寄存部分按合约规则取回                         |
| 安全机制 | RSMC、承诺交易、撤销、CSV、惩罚、强制关闭               | 协议规则、合约状态、共同签名、L1/L2 交易和 indexer 证据                |
| 用户退出 | 用户持有最新 commitment，可单方面 force close     | 用户按合约规则 withdraw、refund、close 或等待合约处理结果            |
| 主要动作 | open、splicing、unlock、lock、close、punish | deploy、invoke、deposit、withdraw、launch、refund、close |
| 目标   | 保护单个用户与 Core Node 之间的资产控制权             | 为公共资产穿越、资产发射、公共池状态提供跨层协调                           |

因此，通道合约文档不能把通道合约描述成“用户资产仍由承诺交易保护的业务层”。这是私人 STP 通道的安全语义，不是通道合约的资产语义。

## 与智能合约的区别

通道合约和智能合约也不同。

| 维度   | 通道合约                                             | 智能合约                                       |
| ---- | ------------------------------------------------ | ------------------------------------------ |
| 主要位置 | L1/L2 连接处，围绕通道地址和跨层动作运行                          | SatoshiNet 全局执行环境                          |
| 主要目的 | 协调 L1/L2 资产动作，处理公共设施中的用户请求                       | 在 L2 上运行可编程应用状态机                           |
| 状态来源 | 合约运行状态、invoke history、L1/L2 交易、ascend/descend 记录 | 合约 VM 状态、canonical Result TX、区块 state root |
| 资产控制 | 公共池资产和用户寄存资产按合约规则处理                              | 合约地址资产由 VM 执行结果授权花费                        |
| 适合场景 | 资产穿越、资产发射、公共跨层设施                                 | AMM、限价单、预测、EVM、自然语言合约等应用                   |

核心进化在于验证范围：通道合约主要由通道两端节点围绕通道状态、共同签名和 L1/L2 动作推进；聪网智能合约则进入全网共识，由整个聪网验证合约调用、canonical Result TX 和 contract state root。

当前 PWA 市场中的 AMM 和限价单仍属于 L2 市场通道合约能力，不属于聪网智能合约。测试网中同时存在智能合约模板 AMM / LimitOrder 和 EVM `ConstantProductAMM` / `LimitOrderBook` 样本，它们只能从 PWA `工具 -> 智能合约` 入口交互，用于验证全网共识合约路径。

随着 SatoshiNet 智能合约能力成熟，部分应用逻辑可以逐步进入智能合约中的模板合约、EVM 合约或 Agent 合约实现。通道合约仍应保留那些真正需要连接 L1/L2、协调跨层动作、管理公共设施资产池的能力，尤其是 `transcend.tc` 和 `launchpool.tc` 这类能力。

## 核心通道合约

### `transcend.tc`

`transcend.tc` 是资产穿越通道合约。它面向任意资产的 L1/L2 进出，尤其用于公共穿越场景。

它的核心语义包括：

1. 支持指定资产在 BTC L1 与 SatoshiNet L2 之间进入和退出。
2. 用户发起 `deposit` 时，把 L1 资产交给通道合约识别和处理，并在 L2 获得对应分发。
3. 用户发起 `withdraw` 时，在 L2 提出退出请求，合约协调 L2 资产销毁或锁定，并在 L1 给用户输出资产。
4. 合约需要维护公共池中 L1 未 ascend 的 UTXO、L2 可用资产和必要的 descend / de-anchor 动作。
5. 如果 L2 公共池中已有足够资产，合约可以直接向用户分发；如果不足，才需要进一步协调 ascend。
6. 如果 L1 可用 UTXO 不足以支持 withdraw，合约需要先协调 descend / de-anchor，形成可用于 L1 输出的资产。

`transcend.tc` 的重点不是交易撮合，也不是用户私人通道安全，而是公共资产穿越能力：让用户发起跨层动作，并让合约协调 L1/L2 之间的资产平衡。

### `launchpool.tc`

`launchpool.tc` 是资产发射通道合约。它把资产部署、铸造、L2 anchor、用户 mint、达到发射水位后的分发，以及失败或关闭时的退款组织成一个跨层流程。

它的核心语义包括：

1. 部署资产发射参数，例如资产协议、ticker、总量、单地址限制、发射比例、预留比例、绑定聪参数等。
2. 根据资产协议执行 L1 部署和铸造动作，例如 ORDX、BRC20、Runes。
3. 将铸造结果引入聪网，形成发射池可管理的 L2 资产。
4. 用户在 SatoshiNet 上发起 mint / 参与动作，合约记录每个用户的有效和无效输入。
5. 当达到发射条件或到期条件后，合约执行 launch，把资产按规则分发给参与用户、部署者或基金会相关地址。
6. 对无效输入或失败场景，合约执行 refund。
7. 如果发射失败或合约关闭，合约按规则把剩余资产退回部署者或相关参与者。

`launchpool.tc` 体现了通道合约的另一个特点：它不是单纯 L2 应用，也不是单纯 L1 发行工具，而是把 L1 资产协议、L2 发射状态、用户参与记录和跨层资产动作串成一个公共流程。

## 公共资产池语义

通道合约管理的资产应按以下方式理解：

1. 合约池中的公共资产不属于通道任意 peer。
2. 用户转入合约的资产，在合约规则确认前处于寄存或 pending 状态。
3. 用户可取回的资产，由合约记录、invoke history、L1/L2 交易和 indexer 结果共同证明。
4. 合约利润、保留资产、发射底池、退款资产等，都需要按合约规则区分。
5. 合约池不能用私人通道的 local / remote balance 语义解释。

这也是通道合约与私人 channel 的根本区别。私人 channel 的核心问题是“双方谁拥有多少资产”；通道合约的核心问题是“公共设施如何根据用户动作和协议规则处理资产”。

## 用户发起原则

通道合约动作通常由用户发起，而不是由 Core Node 单方面决定。

用户动作可以发生在 BTC L1，也可以发生在 SatoshiNet L2：

1. L1 动作：用户向合约通道地址发送资产，或携带合约调用参数。
2. L2 动作：用户向合约地址提交 invoke 交易。
3. 合约处理：合约根据当前区块、用户输入、资产状态和合约运行状态接受或拒绝动作。
4. 结果动作：合约生成分发、退款、withdraw、launch、close 等结果交易。

Core Node 或 peer 可以参与签名、广播、监控和推进状态，但用户动作和合约规则才是合约处理的起点。

## 验证要求

钱包、区块浏览器、indexer 和 AI Agent 在解释通道合约时，应能验证：

1. 合约类型和合约参数。
2. 合约通道地址。
3. 用户 invoke / deposit / withdraw / mint 输入。
4. 用户输入对应的 L1/L2 txid、vout、资产、金额和确认状态。
5. 合约是否接受该输入，拒绝原因是什么。
6. 合约生成的结果交易，例如 anchor、de-anchor、launch、refund、withdraw。
7. 用户当前可领取、已领取、已退款或仍 pending 的资产状态。
8. 合约池中的公共资产、用户寄存资产、保留资产和利润是否能被区分。

AI Agent 将通道合约余额按公共池、用户寄存、可退款、可提现、已分发或 pending 等状态解释，而不是简单视为某个用户可直接控制的余额。

## 与后续模板合约的关系

早期 `.tc` 模板中包含了 AMM、swap、limit order 等业务逻辑。但从协议演进看，这些更像 SatoshiNet 应用层逻辑，未来更适合由智能合约中的模板合约实现。

通道合约应重点保留那些真正需要连接 L1/L2、协调跨层动作、管理公共设施资产池的能力。当前最核心的通道合约是：

1. `transcend.tc`：公共资产穿越。
2. `launchpool.tc`：资产发射和跨层分发。

其他交易类、做市类和应用类逻辑，应优先纳入智能合约体系，用 canonical Result TX、state root 和 GAS 来提供更清晰的 L2 共识边界。

## 参考

* SAT20Labs 关于通道合约的说明：<https://x.com/SAT20Labs/status/2062547908852080933>
* SAT20Labs 关于通道合约的说明：<https://x.com/SAT20Labs/status/1951655721600532693>