判断一个 BTCFi 方案是否真正“Trustless”，不能只看正常流程能否运行，更要看在极端情况下——比如参与者失联、协议停摆、服务方拒绝配合时——用户是否仍然能够独立取回自己的 BTC。
在这一点上，@BabylonLabs_io 提出的 Trustless Bitcoin Vaults（TBV）提供了一种非常值得讨论的设计思路：它并不是简单地把 BTC“锁进一个多签或托管合约”，而是把退出路径本身前置写入比特币主链的安全模型中。
一、TBV 的核心思路：把“最坏情况”写进设计里
传统 BTCFi 或跨链方案中，用户通常面临一个隐含假设：
只要系统正常运行，就能赎回资产。
但问题在于，一旦系统不正常——比如：
Vault Provider 下线
验证服务停止响应
协议治理出现争议
或者前端/中间层被攻击
用户往往会陷入“链上资产存在，但无法操作”的困境。
TBV 的设计试图打破这一点，它的关键在于：
在创建 Vault 的同时，就已经在比特币侧预先生成了可执行的退出路径。
也就是说，用户并不是在“需要时才想办法退出”，而是在进入系统的第一步，就已经拥有了“未来退出的钥匙”。
二、预签名交易 + WOTS：让退出路径独立于协议状态
TBV 的安全性核心来自两个关键机制：
1. 预签名交易（Pre-signed Transactions）
在 Vault 创建阶段，系统会生成一组预签名交易，这些交易定义了：
正常赎回路径
延迟赎回路径
以及在异常情况下的 fallback 路径
这些交易已经在比特币网络层面“准备好”，不依赖后续服务方在线。
2. WOTS 密钥 + Claimer Artifacts
用户同时持有：
WOTS（Winternitz One-Time Signature）密钥
Claimer artifacts（用于证明所有权与触发条件的材料）
当 Vault Provider：
离线
拒绝响应
或协议进入非正常状态
用户可以直接使用这些材料发起 self-claim（自我赎回）。
三、Self-Claim 机制：真正的“最后行动权”
TBV 最关键的设计在于 self-claim 机制。
当正常赎回路径失效时：
用户提交 self-claim 交易
进入预设的挑战窗口（challenge window）
若无人成功反驳或阻止
BTC 自动回到用户控制地址
这个过程的本质是：
把“是否允许你取回 BTC”的权力，从服务方转移回比特币脚本规则本身。
即使：
协议暂停
前端不可用
Vault Provider 完全消失
只要用户持有正确的密钥与证明材料，仍然可以完成资产恢复。
四、TBV 的意义：不是“无桥接”，而是“可退出性优先”
很多人会把 TBV 理解为：
“一种无需桥接的原生 BTC 抵押方案”
但这其实只说对了一半。
更本质的变化是：
TBV 重新定义了 BTCFi 的安全边界
它关注的不是：
系统是否高效
是否去中心化
是否无需信任中介
而是一个更底层的问题：
当一切都失败时，用户还能不能拿回自己的 BTC？
如果答案是“可以”，那么这个系统才具备真正意义上的 trustless 属性。
五、现实约束：仍然是测试网阶段
需要强调的是，目前 TBV 仍处于测试网阶段，这意味着：
恢复流程尚未经历大规模实战压力测试
用户需要自行备份所有恢复文件
self-claim 过程可能需要约 3 天完成
操作复杂度高于普通托管或桥接方案
因此，它更像是一个“安全模型的验证阶段”，而不是完全成熟的金融基础设施。
六、真正的自托管：权力在“最后一步”是否仍属于用户
TBV 引出的一个更深层问题是：
自托管的本质到底是什么？
很多人认为自托管意味着：
私钥在自己手里
资产不在交易所
没有第三方托管风险
但 TBV 提醒我们：
真正的自托管，不只是“资产由谁保管”，而是“发生问题时，谁拥有最后的行动权”。
如果在极端情况下：
你无法触发退出
你必须依赖某个服务方
或者系统状态决定你是否能取回资产
那么这种“托管风险”依然存在，只是被隐藏了。
七、结语
Babylon 的 TBV 并不是在解决“如何更高效地使用 BTC”，而是在回答一个更基础的问题：
在一个可能失效的系统中，如何确保用户永远拥有退出权？
它把 BTCFi 的安全模型从“运行时信任”推进到“失败时仍可自救”的层级。
这也是它最值得关注的地方。