突破 BTC 10 分钟魔咒： RichSwap 乐观执行+批量结算方案

作者：比特鹰蛋挞

一、简介

RichSwap 是世界上第一个基于 REE （ Runes Exchange Environment ）的无信任 Runes AMM DEX ，由 Omnity Network 构建。它允许在 Bitcoin Layer 1 上进行快速、无桥接、无托管的原生资产交换，支持 Runes-to-Runes 和 Runes-to-BTC 易。

REE 是一个 Bitcoin 可编程扩展协议，利用 ICP （ Internet Computer Protocol ）提供去中心化执行层，实现图灵完备智能合约，而不依赖跨链资产。

二、优缺点

亮点

• 支持 Runes 原生交易，无需桥接、包装或托管，相比 Stacks 或 Rootstock 等协议更原生和去中心化。
• 交易速度快（ 5 秒执行），利用 REE 的乐观执行和批量结算，远超 Bitcoin 主网的 15 分钟确认时间。
• 开源代码，促进社区贡献和透明度。
• 与 Xverse 等 Bitcoin 钱包集成，提升用户体验。
• 价值捕获机制，如协议费用捐赠到 $HOPEYOUGETRICH 池，支持代币价值。 相对于其他 BTC 可编程协议（如 Ordinals 或 BRC-20 ），RichSwap 提供真正的 AMM 流动性池和智能合约驱动交易，而非依赖多签名或中心化解决方案。

缺点

• 依赖 ICP 链执行合约，可能引入额外依赖和潜在单点故障，尽管结算在 Bitcoin 上。
• 定期维护中断服务（如安全和性能升级），可能影响用户体验。
• 作为新兴项目，流动性池可能初始较浅，导致滑点较高。
• Bitcoin 网络费用仍是主要成本，尽管优化了交易大小。

三、技术架构

RichSwap 是跑在 ICP 上的一个 Exchange （ canister 智能合约），维护若干 池（ Pool ）；每个池对映比特币上一笔/一组 UTXO （ Runes 为主）。撮合与风控在 ICP 上完成，产出 PSBT v2 ，谁的输入谁签（用户签用户的、池子由 ICP 的 Chain-Key 阈值签名签），合并后广播为原生 BTC L1 交易完成结算。

核心技术包括：

• Exchange （ RichSwap canister ） ：AMM/DEX 业务逻辑，维护多池；每个池绑定到 BTC UTXO （典型为 Runes 资产）。这是 REE 里的标准“Exchange”实现。

• REE Orchestrator （编排器） ：把各协议/池给出的路径与状态“收束”为一份 PSBT v2 ，协调多方签名、复核与广播（ REE 的通用能力，被 RichSwap 复用）。

• DPS （ Decentralized PSBT Signing ） ：去中心化 PSBT 签名机制把签名流程本身搬到 ICP 上，透明地收集/验证/合并签名。

• Runes/UTXO Indexer：在 ICP 侧读取 BTC 区块 /UTXO 并提供 Runes 元数据给合约做风控、余额与所有权校验。

• Bitcoin L1 （结算层） ：所有交易最终都是原生比特币交易，上链确认后才算落地。

• ICP 底座能力（给上面组件用） ：

  • Canister 智能合约执行/存储；
  • Chain-Key 阈值签名（ tECDSA/tSchnorr ） ：canister 能生成外链原生签名；
  • Bitcoin 集成：提供读取 UTXO / 发送原生 BTC 交易的接口。

四、RichSwap 与 Saturn DEX 对比

RichSwap 和 Saturn DEX 都是新兴的 Bitcoin Layer 1 (L1) Runes AMM (Automated Market Maker) DEX ，旨在实现无桥接、无托管的原生资产交换，支持 Runes-to-Runes 和 Runes-to-BTC 交易。两者均利用扩展协议（如 REE 和 Arch Network ）在 Bitcoin 主网上引入 DeFi 功能，避免侧链或 L2 的复杂性。

（一） RichSwap （ REE/ICP ）

优点

• 跨协议编排强：ICP 合约层能把多步骤交易在业务上捆绑，再以单笔/一组 PSBT 落到 L1 ，适合复杂 BTCFi 组合交易。
• 桥风险低：资产始终留在 BTC L1 ，避免桥的托管/铸造风险。
• 阈值签名运营：平台侧用 Chain-Key （ t-of-n ）管理“池子输入”，便于多签风控/轮换。

缺点

• 执行层外依赖：依赖 ICP 可用性与安全假设（与 Arch 的外执行层本质相同只是技术路线不同）。
• 生态兼容度：目前重点在 Runes，若要泛化到 Taproot Assets / 其它协议，需额外适配。
• 吞吐：若不采取像 Saturn 那样的“分片账户”设计，理论上仍会受 CPFP 25 未确认限制影响（这是任何基于 CPFP 的 L1 合约式编排都会遇到的上限）。

（二） Saturn （ Arch ）

优点

• L1 透明 AMM：原子交换 + 非托管流动性，完全公开的池子状态；文档明确“非托管且可验证”。
• MEV 防护成体系：签名域选择（ SIGHASH_ALL / SINGLE|ACP + 集体保护）、FIFO ，以及规划的 VDF ，对 mempool 狙击/夹击有针对性设计。
• 扩展性工程化：账户分片+重建状态绕过 25-CPFP 限制；初始 50 分片/池的目标 TPS 估算给出量化边界。
• Runes 预言机：解决“仅凭 tx hex 无法得知每个输出的 Runes 数量”的信息缺口。
• UTXO 管理：额外费 + 定期合并，限制池子 UTXO 膨胀。

缺点

• 操作复杂度：建池需要一次性准备 51 个 UTXO（ 1 个配置 + 50 个分片），对 LP 端“首笔操作”门槛较高。
• 费用模型：为控制 UTXO ，需要额外支付合并费用，长期是否会影响小额交易/做市，需要实测评估。
• 外执行层假设：同样依赖 Arch 网络的可用性/正确性（与 REE/ICP 的外执行层问题对称）。

RichSwap 在速度和扩展性上更具优势，适合追求高效的 DeFi 用户； Saturn 在 MEV 抵抗和状态同步上更稳健，强调 Bitcoin 纯正主义。两者互补，推动 Runes 生态成熟，但均面临 Bitcoin 固有限制（如费用和块时间）。若构建新 BTC 协议，可借鉴 RichSwap 的乐观执行和 Saturn 的分片设计。

五、未来看点

作为 REE 的展示应用，RichSwap 将支持更多 BTCFi 场景，如借贷、质押和清算。Omnity 计划开放 Exchange 注册给合作伙伴，推动跨协议集成，实现图灵完备合约的更广泛应用（如原子借贷与交换） 目标是构建无桥接的 Bitcoin 原生 DeFi 生态，继承 Bitcoin 安全的同时提升可组合性。