作者：比特鹰蛋挞
一、简介
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 安全的同时提升可组合性。
目前尚无回复
Select Language