I tried to nail down one specific detail of the Trustless Bitcoin Vaults design and ended up with two different answers from two different write-ups of the same Temp Check. One account describes the post-liquidation step as open to permissionless liquidators, who can swap a seized vault for WBTC at a small premium to settle the borrower's debt. Another account of the identical proposal describes a permissioned set of arbitrageurs purchasing those escrowed vaults instead. Same mechanism, same May 25 filing, two different words for who gets to participate.
It matters because permissionless and permissioned are not stylistic synonyms in DeFi, they describe who needs approval to earn the liquidation spread. If it is permissionless, anyone with capital can compete to liquidate, closer to how Aave already runs today. If it is permissioned, some allowlisted group sits between a defaulted vault and its resolution, which reintroduces exactly the kind of gatekeeper the whole pitch is built to avoid.
I lean toward permissionless being the intended design, since Babylon's own materials describe the vault layer as removing signer consortiums and discretionary control everywhere else in the system. But intent is not the same as a published spec, and oracle design plus full trust assumptions were explicitly pushed to a later ARFC stage rather than settled now.
So which is it: how trustless can I call a system when outside reporting on its own governance filing cannot even agree on who is allowed to touch the last step of it?
Babylon's liquidation design is probably permissionless in spirit but is not yet unambiguous in the public record, and that gap between intent and documentation is worth watching before the ARFC stage locks it down for good.
@BabylonLabs_io $BABY #baby $BANK
It matters because permissionless and permissioned are not stylistic synonyms in DeFi, they describe who needs approval to earn the liquidation spread. If it is permissionless, anyone with capital can compete to liquidate, closer to how Aave already runs today. If it is permissioned, some allowlisted group sits between a defaulted vault and its resolution, which reintroduces exactly the kind of gatekeeper the whole pitch is built to avoid.
I lean toward permissionless being the intended design, since Babylon's own materials describe the vault layer as removing signer consortiums and discretionary control everywhere else in the system. But intent is not the same as a published spec, and oracle design plus full trust assumptions were explicitly pushed to a later ARFC stage rather than settled now.
So which is it: how trustless can I call a system when outside reporting on its own governance filing cannot even agree on who is allowed to touch the last step of it?
Babylon's liquidation design is probably permissionless in spirit but is not yet unambiguous in the public record, and that gap between intent and documentation is worth watching before the ARFC stage locks it down for good.
@BabylonLabs_io $BABY #baby $BANK