我在最新公开测试网参数表里看到三个相同的0.4 BTC，对照后发现，它们限制的对象并不一样。单个金库最多0.4 BTC；一个借贷仓位内所有金库合计也最多0.4 BTC；Aave应用对同一地址的敞口上限仍是0.4 BTC。数字相同，三条规则却不能互相替代。
再往上一层，CapPolicy给Aave应用设置了10 BTC总上限，并在金库激活时检查。10除以0.4，理论上最多容纳25个“用满个人额度”的地址。这个25只是容量换算，不是预计用户数；有人只放0.1 BTC，地址可以更多，但累计激活量仍不能越过10 BTC。
容易读错的是把“我的额度没超”理解成“这次一定能激活”。假设应用已有9.8 BTC，新用户准备激活0.4 BTC，个人上限合格，应用总量却会升至10.2 BTC，不能通过容量检查。反过来，即使应用还有空间，一个地址已有0.3 BTC，也不能再加0.2 BTC。个人门槛和全局门槛要同时满足。也因此，前端如何提示容量不足，本身就是风险控制的一部分，否则用户很容易把规则拦截误判成钱包或网络故障。
@BabylonLabs_io 当前把这些列为比特币Signet与以太坊测试网配置，不能外推成主网永久参数。我认为它的重点不是“能锁多少”，而是把单个用户暴露和应用总风险分开控制。普通用户接下来应观察前端是否同时显示个人剩余额度、应用剩余容量，以及激活未完成时的退款路径。$BABY 相关基础设施要扩容，先要避免用户把“账户有额度”误读成“应用还有容量”。
#baby
再往上一层，CapPolicy给Aave应用设置了10 BTC总上限，并在金库激活时检查。10除以0.4，理论上最多容纳25个“用满个人额度”的地址。这个25只是容量换算，不是预计用户数；有人只放0.1 BTC，地址可以更多，但累计激活量仍不能越过10 BTC。
容易读错的是把“我的额度没超”理解成“这次一定能激活”。假设应用已有9.8 BTC，新用户准备激活0.4 BTC，个人上限合格，应用总量却会升至10.2 BTC，不能通过容量检查。反过来，即使应用还有空间，一个地址已有0.3 BTC，也不能再加0.2 BTC。个人门槛和全局门槛要同时满足。也因此，前端如何提示容量不足，本身就是风险控制的一部分，否则用户很容易把规则拦截误判成钱包或网络故障。
@BabylonLabs_io 当前把这些列为比特币Signet与以太坊测试网配置，不能外推成主网永久参数。我认为它的重点不是“能锁多少”，而是把单个用户暴露和应用总风险分开控制。普通用户接下来应观察前端是否同时显示个人剩余额度、应用剩余容量，以及激活未完成时的退款路径。$BABY 相关基础设施要扩容，先要避免用户把“账户有额度”误读成“应用还有容量”。
#baby