Phantom 上的原生 Bitcoin 兑换
生态系统
Phantom 用户一直可以在钱包内跨 Solana 和 EVM 链买入、兑换和交易。Bitcoin 是个例外。不是因为没有需求；而是因为原生 BTC 的执行方式不同。
Phantom 集成了 Garden 的 API 来解决这个问题。结果就是：在加密领域最常用的钱包之一内部直接完成原生 Bitcoin 兑换。
机会所在
钱包已经悄然成为加密领域战略上最重要的入口。用户在那里花费时间、养成习惯并做出决策。
Phantom 就是大多数用户心中 Solana 的所在。超过 1000 万个钱包。SPL 代币、EVM 资产和稳定币上的深度流动性。对 SOL 生态而言，它是默认界面。对于第一次接触加密就是在 Solana 上的一代用户来说，Phantom 就是起点。
但唯独缺少那个代表着 $1 trillion+ 持有价值、并且仍是大多数人想到加密时第一个想到的资产。Phantom 用户可以持有 Solana 资产、在大多数链上交易并管理稳定币。但如果他们想要 Bitcoin，就得去别处：一家 CEX、一个单独的桥、一个不同的产品。
钱包内接入 Bitcoin，意味着把用户留在他们已经选择的生态里。它意味着钱包到钱包的 BTC 结算，没有托管，没有跳转，没有摩擦。问题在于如何在不牺牲体验的前提下做到这一点。
集成
Phantom 将 Garden 的 API 集成为 Bitcoin 执行层，嵌入到其现有的兑换路由栈中。Phantom 负责用户看得见、摸得到的一切，界面、报价比较以及钱包体验。Garden 负责把原生 Bitcoin 跨链转移，而不托管它。
当 Phantom 用户发起 SOL 与 BTC 之间的兑换时，他交互的对象是 Phantom。在底层，Garden 的 solver 网络通过 HTLCs 原子化结算这笔兑换；这些密码学合约保证兑换要么完整完成，要么整体回滚。
订单流程
- 用户在 Phantom 内发起一笔兑换；SOL 换 BTC 或 BTC 换 SOL
- Phantom 的路由器向 Garden 的 API 查询实时报价，与其他可用路由一同比较
- 当 Garden 在价格和速度上胜出时，Phantom 调用 Garden API 发起订单
- Garden 的 solver 在目标链上锁定对应资产；用户将源资产锁入 HTLC 合约
- 原子兑换执行完成。用户直接在其 Phantom 钱包中收到原生 BTC 或 SOL
数据表现
该集成于 2026 年 2 月上线。上线首日，用户完成了 234 笔兑换，总额 $249K。没有激励计划。没有上线活动。需求本来就已经在钱包里了。
自上线以来，13,892 名独立 Phantom 用户通过 Garden 兑换了原生 Bitcoin，在 18,560 笔兑换中结算了超过 $12M 的总交易量。目前完成率为 99.8%。Phantom 用户期待 Bitcoin 兑换具备与钱包中任何其他交易同样的可靠性。
为什么选择 Garden
为 Bitcoin 的架构而生，而非绕开它
Bitcoin 的 UTXO 模型、其最终性特征以及基于 HTLC 的结算，都需要一个专门构建的执行层。Garden 正是围绕 Bitcoin 在 L1 上的运行方式来设计的。这让低于 30 秒的结算成为可能，也让可靠性数据在规模化后依然站得住。
协议层面的非托管
对于一个拥有 10M+ 用户的钱包来说，兑换流程中的任何环节都不能接受托管风险。Garden 从不持有用户资金。HTLCs 以密码学方式强制结算：兑换要么原子化完成，要么用户资金原路返回。
与消费者预期相匹配的可靠性
18K+ 笔兑换中 99.8% 完成。在未完成的 0.2% 中，70% 是 AML 筛查在 solver 侧阻止了订单发起。这意味着 Phantom 可以像对待它支持的其他任何资产类别一样，放心地上线原生 Bitcoin。
一次集成，完整的 Bitcoin 执行
Phantom 通过一次标准的 API 集成添加了原生 Bitcoin 路由。无需运行 solver，无需注入流动性池，无需维护单独的结算基础设施。
Last updated