CRC20协议中，为什么LEAF 不直接用 SATS做交易对，而采用AXBT。 而第三方搞的BONS 代币则选择直接支持 SATS/BTC 做交易对。 以上哪种方案更安全？ LEAF 用 AXBT 的方案，在当前 Bitcoin L1 约束下整体更安全。 为什么更安全 1. 账本与状态更纯净（核心优势） LEAF 的池子完全在 CRC-20 账本内运行（LEAF ↔ AXBT），规则统一，不需要每笔交易同时处理原生 BTC UTXO 和 CRC-20 余额的混合状态。这显著降低了模板交易、状态同步和索引器记账出错的概率。 2. 真实 BTC 被隔离在专用金库 AXBT 背后的 BTC 锁在 Taproot CDP vault 中，有明确的： 超额抵押（约 110%–150%，取决于选择的锁定期 k） 预签名的 owner exit 和 liquidation exit CSV 时间锁 先确认有效花费者获胜的竞争机制 池子交易出问题不会直接动到金库里的 BTC，反之亦然。这是明确的风险隔离。 3. 实现复杂度更低 当前软 covenant（模板交易 + Taproot 脚本路径）在处理「共享池状态 + 大量动态原生 sats」时非常吃力。LEAF 主动回避了这个难点，把难的部分留给专用 CDP，而不是塞进 AMM。 BONS 直接用 SATS 的风险更高 必须在同一套系统里同时处理原生 BTC UTXO 和 CRC-20 状态，模板交易和状态管理更复杂，bug 面更大。 Bitcoin L1 上做共享状态的 AMM 天然困难（UTXO 争用、同区块成交受限、MEV/抢跑、重组影响、报价与确认之间的价格漂移等）。订单簿原子交换相对安全，复杂池子则放大这些问题。 BONS 开源 indexer 自己也公开了若干已知问题（环境依赖共识、早期 oracle 可重放性、marker 解析差异等）。 直接把真实 sats 放进池子，一旦模板或 covenant 实现有缺陷，更容易导致资金锁定或异常流动。 两者都无法回避的共同风险 都是 meta-protocol，核心规则主要靠索引器 + 客户端验证，而非 Bitcoin 共识强制。Indexer 分歧或实现差异会影响余额正确性。 软 covenant 本身存在 footgun（金额或模板稍有偏差就可能锁死资金）。 都还处于早期实验阶段，官方反复强调只用能承受全部损失的资金。 总结 维度LEAF + AXBTBONS + SATS 池子状态纯度高（纯 CRC-20）低（混合原生 BTC） 真实 BTC 隔离有（专用 CDP）无（直接进入交易） 实现复杂度较低较高 当前相对安全性更高较低 LEAF 的 AXBT 方案是更保守、更符合当前 L1 能力边界的设计；BONS 的直接 SATS 方案用户体验更直接，但技术风险更高。