Today I was looking at the trust table for the @BabylonLabs_io lending pool, and while I was at it I scanned the section about stablecoins. I hadn’t planned to read closely, but the words "collateralization rate" caught my eye, so I went back and read it again.
I always thought on-chain USD stablecoins escape only two paths: either they’re fiat-custodied and centrally backed like USDC; or they’re overcollateralized like DAI, using assets such as ETH. In that setup, Bitcoin—this "biggest but least flexible" asset—has never truly been used directly. At most, it indirectly gets routed into DAI’s collateral basket via WBTC, relying on trust through a wrapped layer. After checking, I found that TBV’s approach is designed to mint stablecoins directly from native BTC, without going through the wrapped step: BTC is deposited into a vault, a lightweight client on Ethereum verifies that deposit, and once verification passes the contract mints stablecoins at a predefined collateralization rate. There’s no middleman earning the spread, and no middleman who can run off with the funds. #baby
The redemption design uses the same logic as the lending scenario—no separate branch. First, the stablecoin is burned on the smart-contract chain. Then, the ZK proof of this burn action is generated off-chain, submitted to the vault to initiate a claim. Only after the challenge window ends will the BTC be unlocked and returned. Liquidation works the same way: when the price falls below the safety threshold, whitelisted liquidators destroy the stablecoin, submit the proof, and claim the BTC. The entire process reuses the same proof-verification mechanism; it doesn’t build a separate “wheel” just for the stablecoin scenario.
Personally, I think this design is more worth关注 than lending, because lending has at least a transitional “trust counterparty” setup as an alternative. For the stablecoin track, using BTC for native collateral was basically blank territory before. Whether it can truly run depends on how the collateralization rate is set and what the anchoring stable module’s PS M mechanism looks like. These two parts’ documents only say “optional” and “predefined,” without giving specific numeric ranges. I didn’t find that part.
For fiat-collateral, overcollateral, or native BTC-collateral stablecoins—which one would you choose first? #baby $BABY $BTC
I always thought on-chain USD stablecoins escape only two paths: either they’re fiat-custodied and centrally backed like USDC; or they’re overcollateralized like DAI, using assets such as ETH. In that setup, Bitcoin—this "biggest but least flexible" asset—has never truly been used directly. At most, it indirectly gets routed into DAI’s collateral basket via WBTC, relying on trust through a wrapped layer. After checking, I found that TBV’s approach is designed to mint stablecoins directly from native BTC, without going through the wrapped step: BTC is deposited into a vault, a lightweight client on Ethereum verifies that deposit, and once verification passes the contract mints stablecoins at a predefined collateralization rate. There’s no middleman earning the spread, and no middleman who can run off with the funds. #baby
The redemption design uses the same logic as the lending scenario—no separate branch. First, the stablecoin is burned on the smart-contract chain. Then, the ZK proof of this burn action is generated off-chain, submitted to the vault to initiate a claim. Only after the challenge window ends will the BTC be unlocked and returned. Liquidation works the same way: when the price falls below the safety threshold, whitelisted liquidators destroy the stablecoin, submit the proof, and claim the BTC. The entire process reuses the same proof-verification mechanism; it doesn’t build a separate “wheel” just for the stablecoin scenario.
Personally, I think this design is more worth关注 than lending, because lending has at least a transitional “trust counterparty” setup as an alternative. For the stablecoin track, using BTC for native collateral was basically blank territory before. Whether it can truly run depends on how the collateralization rate is set and what the anchoring stable module’s PS M mechanism looks like. These two parts’ documents only say “optional” and “predefined,” without giving specific numeric ranges. I didn’t find that part.
For fiat-collateral, overcollateral, or native BTC-collateral stablecoins—which one would you choose first? #baby $BABY $BTC