I opened a vault on the TBV testnet last night, borrowed against it on Aave v4, then closed the whole thing out just to watch redemption finish end to end. No fee showed up anywhere in that cycle — makes sense, it's testnet, nothing's actually live yet. But closing that loop made me curious where a real fee would eventually land once this runs on mainnet, so I went digging in the whitepaper for the answer.
Found something in the fee-routing section I wasn't expecting. It's not a simple fee-split. It's an auction. Protocol fees from vault activity accrue in BTC, not BABY. Those BTC fees then get auctioned off, priced in BABY. Whoever bids BABY wins the BTC — and the BABY they paid gets burned on the spot. No treasury, no team deciding when to sell. Just code converting usage into a permanent cut to supply.
Sat with that against what I'd just done on testnet. My deposit, my borrow, my repay, my redemption — none of that action itself creates the burn. The burn only fires when someone downstream actually wants the BTC enough to spend BABY bidding for it.
Kind of like a vending machine stocked full to the top. Doesn't matter how full it is if nobody puts a coin in — the stock was never the revenue, the coin drop is.
That's a different bet than "BABY should be worth more because of how much BTC is locked." It's closer to: BABY's value depends on auction demand, not lockup size. You could run my exact testnet cycle a million times over and burn nothing, if nobody's bidding on the other side.
Worth saying plainly — this whole auction-and-burn design is still a proposal in the paper, not shipped, and it needs Babylon governance to actually go live.
Still turning over whether that auction demand shows up once mainnet fees are real, or whether it just relocates the "why is BABY cheap" question from TVL to fee volume instead.
@BabylonLabs_io $BABY #baby $1000RATS $KOMA
Found something in the fee-routing section I wasn't expecting. It's not a simple fee-split. It's an auction. Protocol fees from vault activity accrue in BTC, not BABY. Those BTC fees then get auctioned off, priced in BABY. Whoever bids BABY wins the BTC — and the BABY they paid gets burned on the spot. No treasury, no team deciding when to sell. Just code converting usage into a permanent cut to supply.
Sat with that against what I'd just done on testnet. My deposit, my borrow, my repay, my redemption — none of that action itself creates the burn. The burn only fires when someone downstream actually wants the BTC enough to spend BABY bidding for it.
Kind of like a vending machine stocked full to the top. Doesn't matter how full it is if nobody puts a coin in — the stock was never the revenue, the coin drop is.
That's a different bet than "BABY should be worth more because of how much BTC is locked." It's closer to: BABY's value depends on auction demand, not lockup size. You could run my exact testnet cycle a million times over and burn nothing, if nobody's bidding on the other side.
Worth saying plainly — this whole auction-and-burn design is still a proposal in the paper, not shipped, and it needs Babylon governance to actually go live.
Still turning over whether that auction demand shows up once mainnet fees are real, or whether it just relocates the "why is BABY cheap" question from TVL to fee volume instead.
@BabylonLabs_io $BABY #baby $1000RATS $KOMA