The coat check at a wedding I worked used numbered paper tickets — tear one half, keep the other, one coat per number. Simple, as long as the machine only printed each number once.
It jammed halfway through the night and started reprinting numbers already gone out. Two people showed up holding ticket #114. Only one coat was ever hanging under that number.
The word that fits, as far as I can tell: the extra ticket — a claim issued more than once, because whatever prints the claims never checks what's actually hanging in back. Bitcoin liquid-staking tokens carry the same exposure: a receipt gets minted against a deposit, only as honest as the code that mints it.
In March, Solv Protocol's BRO vault let one BTC deposit mint more SolvBTC than it should have. A reentrancy bug let a single NFT deposit trigger a callback that issued a second batch of tokens before the first mint finished — security firm Halborn traced it to that double-minting path, about $2.7M worth. Users were reimbursed, but for a while the receipt token outran the Bitcoin behind it.
Babylon's own staking integration skips the receipt-token step for exactly this reason. A staked BTC vault carries three spending conditions pre-signed at creation — unstake, liquidate, slashing — enforced directly by the Bitcoin script itself, not a smart contract minting a claim on top of the deposit. There's no second token that could ever get issued twice, because there's no token.
What I keep sitting with: Solv could patch its contract after the exploit and reimburse users. A pre-signed vault can't be patched — whatever conditions get signed at creation are the conditions for the life of that vault. Trading a bug you can fix for a mistake you can't is its own kind of risk.
Ticket #114 is the number I still remember, more than the coat itself.
My own withdraw request from the testnet is still sitting in its challenge period — will report back once it actually lands in the wallet, not just the dashboard.
@BabylonLabs_io $BABY #baby
It jammed halfway through the night and started reprinting numbers already gone out. Two people showed up holding ticket #114. Only one coat was ever hanging under that number.
The word that fits, as far as I can tell: the extra ticket — a claim issued more than once, because whatever prints the claims never checks what's actually hanging in back. Bitcoin liquid-staking tokens carry the same exposure: a receipt gets minted against a deposit, only as honest as the code that mints it.
In March, Solv Protocol's BRO vault let one BTC deposit mint more SolvBTC than it should have. A reentrancy bug let a single NFT deposit trigger a callback that issued a second batch of tokens before the first mint finished — security firm Halborn traced it to that double-minting path, about $2.7M worth. Users were reimbursed, but for a while the receipt token outran the Bitcoin behind it.
Babylon's own staking integration skips the receipt-token step for exactly this reason. A staked BTC vault carries three spending conditions pre-signed at creation — unstake, liquidate, slashing — enforced directly by the Bitcoin script itself, not a smart contract minting a claim on top of the deposit. There's no second token that could ever get issued twice, because there's no token.
What I keep sitting with: Solv could patch its contract after the exploit and reimburse users. A pre-signed vault can't be patched — whatever conditions get signed at creation are the conditions for the life of that vault. Trading a bug you can fix for a mistake you can't is its own kind of risk.
Ticket #114 is the number I still remember, more than the coat itself.
My own withdraw request from the testnet is still sitting in its challenge period — will report back once it actually lands in the wallet, not just the dashboard.
@BabylonLabs_io $BABY #baby