我把当前公开测试网的建仓时钟并排看了一遍，最容易混淆的不是一个数字，而是“24小时过期”和“48小时过期”分别由谁造成、费用怎么处理。两种情况都会让金库进入过期，但经济结果并不完全一样。
正常流程中，Pre-PegIn先在比特币Signet等待12个确认，约120分钟；链下签名和确认工作与其并行，文档给出的正常建仓时间约2小时。若所需参与方没有在约24小时的ACK窗口内完成准备，说明协议侧建仓没有走完，金库过期，测试网的建仓费用会自动退回。比特币并未丢失，用户仍可等待退款时间锁打开。
另一种情况是链下准备已经完成，状态到了Verified，但用户没有在创建后的约48小时内主动激活。此时同样会过期，可费用不再退还，因为前面的协调工作已经发生。这里损失的是测试用的建仓费用，不是锁入的比特币本金。当前tRefund为3天，时间到后，用户只需用原比特币密钥签名，即可沿退款路径取回Pre-PegIn输出，不依赖服务商或其他参与方配合。
三天时间锁也不是随意把用户晾在那里。它被安排在正常激活窗口之后，避免同一笔比特币同时面临“继续完成建仓”和“提前退款”两条相互冲突的路径。等待降低了操作速度，却把失败后的资产归属写得更确定。
这组规则说明，@BabylonLabs_io 把“系统没准备好”和“用户没有完成最后一步”分开定责。前者退费，后者不退费，但两者都保留单边取回比特币的路径。我认为前端不能只显示一个过期，而应明确写出卡在哪个阶段、费用是否退回、退款倒计时从何时开始。
对$BABY 相关基础设施，接下来我会看三个指标：ACK超时率、Verified后未激活比例，以及退款路径的实际成功时间。安全不只是在失败时币还在，也包括用户能否立刻算清自己损失的是哪笔费用、还要等多久、下一步该签什么。
#baby
正常流程中，Pre-PegIn先在比特币Signet等待12个确认，约120分钟；链下签名和确认工作与其并行，文档给出的正常建仓时间约2小时。若所需参与方没有在约24小时的ACK窗口内完成准备，说明协议侧建仓没有走完，金库过期，测试网的建仓费用会自动退回。比特币并未丢失，用户仍可等待退款时间锁打开。
另一种情况是链下准备已经完成，状态到了Verified，但用户没有在创建后的约48小时内主动激活。此时同样会过期，可费用不再退还，因为前面的协调工作已经发生。这里损失的是测试用的建仓费用，不是锁入的比特币本金。当前tRefund为3天，时间到后，用户只需用原比特币密钥签名，即可沿退款路径取回Pre-PegIn输出，不依赖服务商或其他参与方配合。
三天时间锁也不是随意把用户晾在那里。它被安排在正常激活窗口之后，避免同一笔比特币同时面临“继续完成建仓”和“提前退款”两条相互冲突的路径。等待降低了操作速度，却把失败后的资产归属写得更确定。
这组规则说明，@BabylonLabs_io 把“系统没准备好”和“用户没有完成最后一步”分开定责。前者退费，后者不退费，但两者都保留单边取回比特币的路径。我认为前端不能只显示一个过期，而应明确写出卡在哪个阶段、费用是否退回、退款倒计时从何时开始。
对$BABY 相关基础设施，接下来我会看三个指标：ACK超时率、Verified后未激活比例，以及退款路径的实际成功时间。安全不只是在失败时币还在，也包括用户能否立刻算清自己损失的是哪笔费用、还要等多久、下一步该签什么。
#baby