作者：比特鹰蛋挞一、简介RichSwap是世界上第一个基于REE（RunesExchangeEnvironment）的无信任RunesAMMDEX，由OmnityNetwork构建。本文将解构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 钱包集成，提升用户体验。
- 价值捕获机制，如协议费用捐赠到 $HOPE•YOU•GET•RICH 池，支持代币价值。 相对于其他 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 的分片设计。
| 维度 |
RichSwap（REE/ICP） |
Saturn（Arch） |
| 结算层 |
BTC L1 |
BTC L1（原子交换/池子交易） |
| 执行层 |
ICP（REE Orchestrator + Chain-Key 阈值签名） |
Arch VM + 去中心化验证网络 |
| 产品形态 |
编排型多方交易 +（当前）Runes 交易前端 |
Uniswap v2 风格 AMM + LP 费收取 |
| 扩展/吞吐 |
取决于编排与打包策略；若无额外设计会受 CPFP 25 限制 |
账户分片重建规避 25-CPFP，上限可线性扩容 |
| MEV 防护 |
（公开资料未见成体系披露） |
SIGHASH 组合 + CPFP 集体保护 + FIFO + 规划 VDF |
| 资产识别 |
Runes 起步，其他协议需适配 |
Runes 预言机精确识别每 UTXO 的 Runes 数 |
| UTXO 管理 |
常规 CPFP/打包 |
额外费 + 加仓合并抑制 UTXO 膨胀 |
五、未来看点
作为 REE 的展示应用，RichSwap 将支持更多 BTCFi 场景，如借贷、质押和清算。Omnity 计划开放 Exchange 注册给合作伙伴，推动跨协议集成，实现图灵完备合约的更广泛应用（如原子借贷与交换）
目标是构建无桥接的 Bitcoin 原生 DeFi 生态，继承 Bitcoin 安全的同时提升可组合性。
