NewbieToNode
4.3k Posts
NewbieToNode
Square Verified+Planting tokens ๐ฑ Waiting for sun ๐ Watering with hope ๐ง Soft degen vibes only
Traders League Badge Expert
Frequent Trader
4.3 Years
179 Following
33.0K+ Followers
27.7K+ Liked
1 Badges
Posts
All
Quotes
Videos
Live
@BabylonLabs_io
One sentence in the Trustless Bitcoin Vaults (TBV) documentation completely changed how I thought about multi-vault liquidation.
I was looking for what happens when a single borrowing position is backed by multiple vaults.
I expected liquidation to be proportional. If three vaults secured one borrowing position, I assumed each vault would contribute its share of the collateral being seized.
Instead, the documentation describes something much more specific.
When multiple vaults back a single borrowing position, TBV seizes a prefix of the ordered vault list, stopping once enough collateral has been taken to satisfy the target seizure.
I actually paused and read that sentence again.
The mechanism isn't "take a little from every vault."
It's "take vaults from the front of an ordered list until the target is reached."
That immediately made me wonder how the ordered list itself is constructed. The documentation explains the seizure rule, but on this page it doesn't explain what determines the order.
Is it based on when vaults are created? Is another protocol rule involved? Can borrowers influence it before opening a position?
The liquidation mechanism is documented. The construction of the ordered list is the part I'm still trying to understand, because it seems fundamental to how multi-vault positions behave in practice.
@BabylonLabs_io
#baby $BABY
One sentence in the Trustless Bitcoin Vaults (TBV) documentation completely changed how I thought about multi-vault liquidation.
I was looking for what happens when a single borrowing position is backed by multiple vaults.
I expected liquidation to be proportional. If three vaults secured one borrowing position, I assumed each vault would contribute its share of the collateral being seized.
Instead, the documentation describes something much more specific.
When multiple vaults back a single borrowing position, TBV seizes a prefix of the ordered vault list, stopping once enough collateral has been taken to satisfy the target seizure.
I actually paused and read that sentence again.
The mechanism isn't "take a little from every vault."
It's "take vaults from the front of an ordered list until the target is reached."
That immediately made me wonder how the ordered list itself is constructed. The documentation explains the seizure rule, but on this page it doesn't explain what determines the order.
Is it based on when vaults are created? Is another protocol rule involved? Can borrowers influence it before opening a position?
The liquidation mechanism is documented. The construction of the ordered list is the part I'm still trying to understand, because it seems fundamental to how multi-vault positions behave in practice.
@BabylonLabs_io
#baby $BABY
Verified
@BabylonLabs_io
I opened Babylon's latest Trustless Bitcoin Vaults (TBV) documentation expecting to spend more time understanding BitVM3. Instead, I found the redemption flow being explained through BABE almost immediately.
That sent me to the Research section to understand why.
The paper identifies one of BitVM3's biggest practical limitations: roughly 42 GiB of off-chain storage per garbled circuit. BABE is introduced to address that constraint, claiming around a 1000ร reduction in storage requirements while preserving BitVM3's low on-chain verification costs.
I went in thinking the hardest part of TBV was the cryptography itself. I came away thinking the bigger challenge may have been making that cryptography practical enough to operate.
If those efficiency gains carry through to production, they could matter well beyond the research paper. Lower storage requirements could reduce one of the operational costs behind native Bitcoin-backed borrowing through TBV, making the protocol more practical to run at scale.
One phrase also stood out to me: "preserving BitVM3's on-chain savings." I don't think that's enough to conclude BABE completely replaces BitVM3. It reads more like an evolution of the same direction. What is clear, though, is that someone learning about TBV today is introduced to BABE first.
That changed how I read the documentation. Instead of asking whether Bitcoin can verify these proofs, I'm now more interested in what Babylon's engineers see as the next practical bottleneck once storage overhead is reduced this dramatically.
@BabylonLabs_io #baby $BABY
I opened Babylon's latest Trustless Bitcoin Vaults (TBV) documentation expecting to spend more time understanding BitVM3. Instead, I found the redemption flow being explained through BABE almost immediately.
That sent me to the Research section to understand why.
The paper identifies one of BitVM3's biggest practical limitations: roughly 42 GiB of off-chain storage per garbled circuit. BABE is introduced to address that constraint, claiming around a 1000ร reduction in storage requirements while preserving BitVM3's low on-chain verification costs.
I went in thinking the hardest part of TBV was the cryptography itself. I came away thinking the bigger challenge may have been making that cryptography practical enough to operate.
If those efficiency gains carry through to production, they could matter well beyond the research paper. Lower storage requirements could reduce one of the operational costs behind native Bitcoin-backed borrowing through TBV, making the protocol more practical to run at scale.
One phrase also stood out to me: "preserving BitVM3's on-chain savings." I don't think that's enough to conclude BABE completely replaces BitVM3. It reads more like an evolution of the same direction. What is clear, though, is that someone learning about TBV today is introduced to BABE first.
That changed how I read the documentation. Instead of asking whether Bitcoin can verify these proofs, I'm now more interested in what Babylon's engineers see as the next practical bottleneck once storage overhead is reduced this dramatically.
@BabylonLabs_io #baby $BABY
Verified
@BabylonLabs_io
I expected the trust model in Trustless Bitcoin Vaults (TBV) to be simple.
While reading Babylon's documentation, I got to the section listing what a depositor relies on. It names the Bitcoin network, the co-signed Bitcoin script created at vault creation, the Ethereum network, and the target application. I genuinely thought that was the complete picture.
Then one sentence right below it made me stop and reread the page.
The docs add that, beyond the chains themselves, residual trust still sits with the protocol's governance and emergency-response multi-sigs, describing them as transitional safety nets that the protocol can retire over time.
On the same page, Babylon also explains that a depositor doesn't need a federation of signers to cooperate when redeeming BTC through the protocol's intended redemption path.
Reading those two statements together changed how I understand the word trustless.
I don't read it as "every trust assumption has already disappeared." I read it as a protocol that clearly documents the trust assumptions that still exist today, while designing the system so those assumptions can become smaller over time.
I actually appreciate that approach more than pretending the journey is already finished. Knowing where the remaining trust sits is just as important as knowing where it has already been removed.
The part I'm most curious about now is what Babylon considers the milestone for retiring those transitional safety nets. Is it driven by governance, technical maturity, security audits, or some combination of all three?
@BabylonLabs_io #baby $BABY
I expected the trust model in Trustless Bitcoin Vaults (TBV) to be simple.
While reading Babylon's documentation, I got to the section listing what a depositor relies on. It names the Bitcoin network, the co-signed Bitcoin script created at vault creation, the Ethereum network, and the target application. I genuinely thought that was the complete picture.
Then one sentence right below it made me stop and reread the page.
The docs add that, beyond the chains themselves, residual trust still sits with the protocol's governance and emergency-response multi-sigs, describing them as transitional safety nets that the protocol can retire over time.
On the same page, Babylon also explains that a depositor doesn't need a federation of signers to cooperate when redeeming BTC through the protocol's intended redemption path.
Reading those two statements together changed how I understand the word trustless.
I don't read it as "every trust assumption has already disappeared." I read it as a protocol that clearly documents the trust assumptions that still exist today, while designing the system so those assumptions can become smaller over time.
I actually appreciate that approach more than pretending the journey is already finished. Knowing where the remaining trust sits is just as important as knowing where it has already been removed.
The part I'm most curious about now is what Babylon considers the milestone for retiring those transitional safety nets. Is it driven by governance, technical maturity, security audits, or some combination of all three?
@BabylonLabs_io #baby $BABY
Verified
$93 versus more than $15,000.
That comparison made me stop while reading Section 3 of the Trustless Bitcoin Vaults (TBV) whitepaper from @BabylonLabs_io
I was trying to answer one practical question: what does it actually cost to dispute an invalid claim?
The paper compares two designs. Under the current TBV architecture, it estimates a Bitcoin mainnet challenge transaction at about $93. Under the earlier BitVM2 approach, the equivalent challenge cost more than $15,000. That's roughly a 170ร reduction.
The interesting part isn't just the number. It's what changed to make it possible.
Instead of verifying the ZK proof directly on Bitcoin, the current design uses a garbled-circuit challenge process that reveals a secret only when an invalid claim is challenged. The paper says reducing the amount of on-chain work is what makes much smaller security bonds practical.
That changed how I read the design. The breakthrough wasn't simply making disputes trust-minimized. It was making them inexpensive enough to become practical for native Bitcoin-backed borrowing.
The next thing I'm watching is whether those estimated costs remain close to reality as TBV progresses beyond testing. If Bitcoin transaction fees rise sharply during periods of heavy network congestion, do the economic assumptions behind the dispute process still hold up?
#baby $BABY
That comparison made me stop while reading Section 3 of the Trustless Bitcoin Vaults (TBV) whitepaper from @BabylonLabs_io
I was trying to answer one practical question: what does it actually cost to dispute an invalid claim?
The paper compares two designs. Under the current TBV architecture, it estimates a Bitcoin mainnet challenge transaction at about $93. Under the earlier BitVM2 approach, the equivalent challenge cost more than $15,000. That's roughly a 170ร reduction.
The interesting part isn't just the number. It's what changed to make it possible.
Instead of verifying the ZK proof directly on Bitcoin, the current design uses a garbled-circuit challenge process that reveals a secret only when an invalid claim is challenged. The paper says reducing the amount of on-chain work is what makes much smaller security bonds practical.
That changed how I read the design. The breakthrough wasn't simply making disputes trust-minimized. It was making them inexpensive enough to become practical for native Bitcoin-backed borrowing.
The next thing I'm watching is whether those estimated costs remain close to reality as TBV progresses beyond testing. If Bitcoin transaction fees rise sharply during periods of heavy network congestion, do the economic assumptions behind the dispute process still hold up?
#baby $BABY
Verified
I opened Section 9 expecting to find a list of supported chains.
Instead, I found a rollout sequence.
@BabylonLabs_io describes Trustless Bitcoin Vaults (TBV) as enabling native Bitcoin to be used as collateral across chains and applications. The whitepaper explains how that capability is intended to arrive.
Native Bitcoin-backed borrowing starts with Ethereum and EVM rollups. Solana is described as a future implementation. Expansion to additional ecosystems, including chains like Solana and Sui, comes only after the core Vault and Liquidator services demonstrate stability, with further rollout subject to Babylon governance.
The next section answered why.
Every supported chain needs its own deposit smart contract, built for that chain's execution environment and token standard. The architecture is chain-agnostic. The deployment is intentionally sequential.
That changed how I read the phrase "any chain."
I no longer see it as describing what's available today. I see it as the design goal the protocol is working toward, reached one ecosystem at a time rather than all at once.
I'm now watching what Babylon eventually considers the real multi-chain milestone. Is it simply adding another supported network, or reaching the point where integrating a new chain becomes routine instead of a bespoke engineering effort?
#baby $BABY
Instead, I found a rollout sequence.
@BabylonLabs_io describes Trustless Bitcoin Vaults (TBV) as enabling native Bitcoin to be used as collateral across chains and applications. The whitepaper explains how that capability is intended to arrive.
Native Bitcoin-backed borrowing starts with Ethereum and EVM rollups. Solana is described as a future implementation. Expansion to additional ecosystems, including chains like Solana and Sui, comes only after the core Vault and Liquidator services demonstrate stability, with further rollout subject to Babylon governance.
The next section answered why.
Every supported chain needs its own deposit smart contract, built for that chain's execution environment and token standard. The architecture is chain-agnostic. The deployment is intentionally sequential.
That changed how I read the phrase "any chain."
I no longer see it as describing what's available today. I see it as the design goal the protocol is working toward, reached one ecosystem at a time rather than all at once.
I'm now watching what Babylon eventually considers the real multi-chain milestone. Is it simply adding another supported network, or reaching the point where integrating a new chain becomes routine instead of a bespoke engineering effort?
#baby $BABY
Verified
@BabylonLabs_io
Twenty minutes to generate. Forty-three gigabytes to store, per counterparty.
Those two numbers changed how I think about Trustless Bitcoin Vaults (TBV).
The whitepaper explains that borrowers can generate and store their own fraud-detection circuits, allowing them to independently verify dishonest behavior without relying on a professional operator.
Large borrowers are expected to handle that overhead themselves. For smaller borrowers, the paper introduces professional operators to generate and store those circuits instead.
The operator still can't spend your BTC. Every transaction still requires your signature. But if you never generate and store those circuits yourself, the operator becomes the party maintaining the infrastructure that enables independent fraud detection on your behalf.
The protocol makes self-operation possible. What I'm less certain about is how many borrowers will actually choose it once the operational cost becomes tangible.
That's one of the questions I'm most interested in exploring as native Bitcoin-backed borrowing through TBV is exercised on the public testnet.
#baby $BABY
Twenty minutes to generate. Forty-three gigabytes to store, per counterparty.
Those two numbers changed how I think about Trustless Bitcoin Vaults (TBV).
The whitepaper explains that borrowers can generate and store their own fraud-detection circuits, allowing them to independently verify dishonest behavior without relying on a professional operator.
Large borrowers are expected to handle that overhead themselves. For smaller borrowers, the paper introduces professional operators to generate and store those circuits instead.
The operator still can't spend your BTC. Every transaction still requires your signature. But if you never generate and store those circuits yourself, the operator becomes the party maintaining the infrastructure that enables independent fraud detection on your behalf.
The protocol makes self-operation possible. What I'm less certain about is how many borrowers will actually choose it once the operational cost becomes tangible.
That's one of the questions I'm most interested in exploring as native Bitcoin-backed borrowing through TBV is exercised on the public testnet.
#baby $BABY
Verified
I went back two pages because I thought I'd missed a dependency.
I hadn't.
The self-claim path wasn't waiting for the Vault Provider to come back.
It had already been committed when the vault was created.
That changed the recovery model for me.
Most conversations around Trustless Bitcoin Vaults (TBV) focus on malicious actors. This part of the protocol is preparing for operator absence instead.
Using the pre-committed Winternitz One-Time Signature (WOTS), the depositor can reclaim BTC even if the Vault Provider disappears or stops cooperating, according to the TBV design.
Recovery isn't added after failure.
It's committed before failure exists.
I didn't expect "operator disappearance" to be treated as a protocol state rather than an operational exception.
The next thing I'm watching is whether this recovery path behaves just as predictably in the public TBV testnet as it does in the protocol design.
@BabylonLabs_io
I'll only think differently about $BABY if these recovery guarantees remain just as reliable once TBV moves beyond early deployments and real operators begin disappearing, rotating, or failing under normal operating conditions.
#baby $BABY
I hadn't.
The self-claim path wasn't waiting for the Vault Provider to come back.
It had already been committed when the vault was created.
That changed the recovery model for me.
Most conversations around Trustless Bitcoin Vaults (TBV) focus on malicious actors. This part of the protocol is preparing for operator absence instead.
Using the pre-committed Winternitz One-Time Signature (WOTS), the depositor can reclaim BTC even if the Vault Provider disappears or stops cooperating, according to the TBV design.
Recovery isn't added after failure.
It's committed before failure exists.
I didn't expect "operator disappearance" to be treated as a protocol state rather than an operational exception.
The next thing I'm watching is whether this recovery path behaves just as predictably in the public TBV testnet as it does in the protocol design.
@BabylonLabs_io
I'll only think differently about $BABY if these recovery guarantees remain just as reliable once TBV moves beyond early deployments and real operators begin disappearing, rotating, or failing under normal operating conditions.
#baby $BABY
Partly True
@BabylonLabs_io
I thought Section 5.1 had a mistake.
Three actions were marked Trustless.
The fourth wasn't.
Borrower withdraws collateral โ Trustless.
Liquidator liquidates collateral โ Trustless.
Large lender withdraws from the lending contract โ Trustless.
Borrower deposits collateral โ Trusts k-of-n liquidators and j-of-m large lenders.
I went back expecting I'd misread the table.
I hadn't.
The whitepaper explains the mechanism: vault creation requires a threshold of liquidators to co-sign so a single liquidator can't censor a new deposit.
What surprised me wasn't the exception itself.
It was that the table never asks whether Trustless Bitcoin Vaults (TBV) are trustless.
It asks whether each action is.
I'd been treating "trustless" as a property of the vault.
Babylon documents it as a property of the operation.
Now I'm wondering whether vault creation is the only place TBV deliberately keeps a trust assumption, or whether the same design boundary appears elsewhere in the protocol.
I'll only think differently about $BABY if that boundary stays consistent as TBV expands.
#baby $BABY
I thought Section 5.1 had a mistake.
Three actions were marked Trustless.
The fourth wasn't.
Borrower withdraws collateral โ Trustless.
Liquidator liquidates collateral โ Trustless.
Large lender withdraws from the lending contract โ Trustless.
Borrower deposits collateral โ Trusts k-of-n liquidators and j-of-m large lenders.
I went back expecting I'd misread the table.
I hadn't.
The whitepaper explains the mechanism: vault creation requires a threshold of liquidators to co-sign so a single liquidator can't censor a new deposit.
What surprised me wasn't the exception itself.
It was that the table never asks whether Trustless Bitcoin Vaults (TBV) are trustless.
It asks whether each action is.
I'd been treating "trustless" as a property of the vault.
Babylon documents it as a property of the operation.
Now I'm wondering whether vault creation is the only place TBV deliberately keeps a trust assumption, or whether the same design boundary appears elsewhere in the protocol.
I'll only think differently about $BABY if that boundary stays consistent as TBV expands.
#baby $BABY
@BabylonLabs_io
I stopped on the TBV vault diagram because I couldn't find the point where the loan gained new rules.
The redemption path was already there.
So was liquidation.
So was slashing.
I went back through the flow thinking I'd missed something.
I hadn't.
The interesting part of Trustless Bitcoin Vaults (TBV) isn't where native Bitcoin is locked. It's that the valid spending conditions are committed when the vault is created, not introduced later as the loan evolves.
That changed how I read the design.
I had been looking for the moment the protocol decided what should happen next.
Instead, it had already decided what could happen. The rest of the loan is just proving which of those predefined conditions has been satisfied.
To me, that's the real trade-off behind native Bitcoin-backed borrowing. The protocol commits to a finite set of outcomes up front instead of relying on an intermediary to interpret new situations later.
The question I'm left with isn't whether that model works.
It's whether borrowers will eventually want flexibility that can't exist once those spending conditions have already been committed.
#baby $BABY
I stopped on the TBV vault diagram because I couldn't find the point where the loan gained new rules.
The redemption path was already there.
So was liquidation.
So was slashing.
I went back through the flow thinking I'd missed something.
I hadn't.
The interesting part of Trustless Bitcoin Vaults (TBV) isn't where native Bitcoin is locked. It's that the valid spending conditions are committed when the vault is created, not introduced later as the loan evolves.
That changed how I read the design.
I had been looking for the moment the protocol decided what should happen next.
Instead, it had already decided what could happen. The rest of the loan is just proving which of those predefined conditions has been satisfied.
To me, that's the real trade-off behind native Bitcoin-backed borrowing. The protocol commits to a finite set of outcomes up front instead of relying on an intermediary to interpret new situations later.
The question I'm left with isn't whether that model works.
It's whether borrowers will eventually want flexibility that can't exist once those spending conditions have already been committed.
#baby $BABY
Partly True
@BabylonLabs_io
I reread one paragraph in Babylon's TBV paper because it didn't match the mental model I'd built from other BitVM bridge designs.
I assumed the challenge window existed to catch invalid proofs.
That wasn't what stood out.
The paper keeps coming back to a different point. Anyone can challenge a claim, including the vault owner.
Some BitVM bridge designs rely on a permissioned challenger set. If that group misses fraud or fails to respond, the security model depends on them.
Trustless Bitcoin Vaults (TBV) doesn't make that assumption.
The protocol keeps the challenge process open instead of deciding in advance who is responsible for protecting the system.
Until then, I'd treated the waiting period as dead time between verification and settlement. After rereading that section, it looked more like part of the security model itself.
The waiting period isn't what makes TBV trustless. The permissionless challenge process does. The waiting period gives that mechanism time to work.
That's the same trade behind TBV's native Bitcoin-backed borrowing. Native BTC collateral doesn't depend on trusting a designated challenger before settlement can be finalized.
Every valid claim waits through the same challenge window. Not because every claim is suspicious, but because the protocol can't know in advance which claim will actually need to be challenged.
I'm now watching whether this design still feels practical under real network usage. If the permissionless challenge process continues to hold under load, I'll understand TBV very differently than I did when I first opened the paper.
#baby $BABY
I reread one paragraph in Babylon's TBV paper because it didn't match the mental model I'd built from other BitVM bridge designs.
I assumed the challenge window existed to catch invalid proofs.
That wasn't what stood out.
The paper keeps coming back to a different point. Anyone can challenge a claim, including the vault owner.
Some BitVM bridge designs rely on a permissioned challenger set. If that group misses fraud or fails to respond, the security model depends on them.
Trustless Bitcoin Vaults (TBV) doesn't make that assumption.
The protocol keeps the challenge process open instead of deciding in advance who is responsible for protecting the system.
Until then, I'd treated the waiting period as dead time between verification and settlement. After rereading that section, it looked more like part of the security model itself.
The waiting period isn't what makes TBV trustless. The permissionless challenge process does. The waiting period gives that mechanism time to work.
That's the same trade behind TBV's native Bitcoin-backed borrowing. Native BTC collateral doesn't depend on trusting a designated challenger before settlement can be finalized.
Every valid claim waits through the same challenge window. Not because every claim is suspicious, but because the protocol can't know in advance which claim will actually need to be challenged.
I'm now watching whether this design still feels practical under real network usage. If the permissionless challenge process continues to hold under load, I'll understand TBV very differently than I did when I first opened the paper.
#baby $BABY
@BabylonLabs_io
The first thing I expected from Trustless Bitcoin Vaults (TBV) was that Bitcoin would eventually need to understand Ethereum.
If native Bitcoin is being used as self-custodial collateral for borrowing on Ethereum, surely Bitcoin has to verify something about Ethereum's state.
I kept reading because I wanted to find where that happened.
I never did.
TBV is designed so Bitcoin never has to understand Ethereum's state.
Bitcoin never runs the verifier for Ethereum's state, and it never learns what that state is. Verification happens off-chain. Bitcoin's role is narrower. It enforces the protocol's settlement conditions without ever interpreting Ethereum's state.
The more I followed the architecture, the more one pattern stood out. Nothing in the design asks Bitcoin to interpret Ethereum's state. The architecture consistently preserves Bitcoin's existing validation model.
That completely changed what I thought Babylon was optimizing for.
I originally assumed the goal was to make Bitcoin capable of securing borrowing on another chain.
Now I think the bigger goal is preserving Bitcoin's existing security assumptions while extending what native BTC can be used for. That's why TBV is built around self-custodial borrowing without wrapping BTC, bridging it, or relying on intermediaries.
The interesting trade-off is where the complexity goes.
The proofs, challenge process, and dispute logic don't disappear. Babylon deliberately keeps them outside Bitcoin, so extending Bitcoin's utility doesn't require changing Bitcoin's validation model.
The question I'm left with isn't whether this design works. It's whether Babylon can continue preserving Bitcoin's validation model as TBV expands to support more use cases.
#baby $BABY
The first thing I expected from Trustless Bitcoin Vaults (TBV) was that Bitcoin would eventually need to understand Ethereum.
If native Bitcoin is being used as self-custodial collateral for borrowing on Ethereum, surely Bitcoin has to verify something about Ethereum's state.
I kept reading because I wanted to find where that happened.
I never did.
TBV is designed so Bitcoin never has to understand Ethereum's state.
Bitcoin never runs the verifier for Ethereum's state, and it never learns what that state is. Verification happens off-chain. Bitcoin's role is narrower. It enforces the protocol's settlement conditions without ever interpreting Ethereum's state.
The more I followed the architecture, the more one pattern stood out. Nothing in the design asks Bitcoin to interpret Ethereum's state. The architecture consistently preserves Bitcoin's existing validation model.
That completely changed what I thought Babylon was optimizing for.
I originally assumed the goal was to make Bitcoin capable of securing borrowing on another chain.
Now I think the bigger goal is preserving Bitcoin's existing security assumptions while extending what native BTC can be used for. That's why TBV is built around self-custodial borrowing without wrapping BTC, bridging it, or relying on intermediaries.
The interesting trade-off is where the complexity goes.
The proofs, challenge process, and dispute logic don't disappear. Babylon deliberately keeps them outside Bitcoin, so extending Bitcoin's utility doesn't require changing Bitcoin's validation model.
The question I'm left with isn't whether this design works. It's whether Babylon can continue preserving Bitcoin's validation model as TBV expands to support more use cases.
#baby $BABY
Partly True
@BabylonLabs_io
I assumed liquidation meant the protocol already had the BTC.
The Aave proposal for Babylon's Trustless Bitcoin Vaults (TBV) proved me wrong.
I kept reading liquidation as one event.
The proposal treats it as two.
The lending market settles immediately.
The BTC doesn't.
A permissionless liquidator fronts WBTC at a small premium, then waits through Bitcoin's dispute window before becoming entitled to claim the BTC held in the vault.
The part I hadn't noticed wasn't the delay.
It was who absorbs it.
The lending market never waits for Bitcoin's slower clock. The liquidator does. The premium isn't just an incentive to liquidate. It's compensation for bridging two settlement timelines that can't move at the same speed.
I'm watching how the liquidator's exposure is handled during that waiting period if the settlement path doesn't unfold as expected.
$BABY only becomes interesting to me if that gap stays reliable when the system is under real market stress.
#baby
I assumed liquidation meant the protocol already had the BTC.
The Aave proposal for Babylon's Trustless Bitcoin Vaults (TBV) proved me wrong.
I kept reading liquidation as one event.
The proposal treats it as two.
The lending market settles immediately.
The BTC doesn't.
A permissionless liquidator fronts WBTC at a small premium, then waits through Bitcoin's dispute window before becoming entitled to claim the BTC held in the vault.
The part I hadn't noticed wasn't the delay.
It was who absorbs it.
The lending market never waits for Bitcoin's slower clock. The liquidator does. The premium isn't just an incentive to liquidate. It's compensation for bridging two settlement timelines that can't move at the same speed.
I'm watching how the liquidator's exposure is handled during that waiting period if the settlement path doesn't unfold as expected.
$BABY only becomes interesting to me if that gap stays reliable when the system is under real market stress.
#baby
Verified
@BabylonLabs_io
I stopped reading the Trustless Bitcoin Vaults (TBV) paper at one sentence.
TBV lets native Bitcoin secure borrowing on Ethereum without wrapping or bridging. The paper then described proving an Ethereum state transition without asking Bitcoin to understand Ethereum.
I went back three sections because I assumed I'd misunderstood it.
I hadn't.
Bitcoin never evaluates the SNARK verifier. It never learns Ethereum's state either.
BitVM3 moves that work into an off-chain challenge process. A claim is posted to Bitcoin and waits behind a challenge-window timelock. Bitcoin enforces that window regardless of whether the claim is challenged. If nobody successfully disputes the claim, settlement continues. If a challenger proves the claim false, a second mechanism, a hashlock triggered by the revealed secret from that failed proof, prevents the payout.
That changed how I think about TBV.
Bitcoin isn't verifying Ethereum.
It's enforcing the conditions under which a claim is allowed to settle.
The computation stays off-chain. Bitcoin's role is to enforce the protocol's security conditions without ever interpreting another chain's state.
The part I'm watching now isn't the happy path.
It's the failure path.
When the challenge window becomes busy, how often does it actually get exercised? And what does that look like on the TBV public testnet when multiple claims are active at the same time?
$BABY only becomes interesting to me if that dispute process remains predictable under real network conditions.
#baby
I stopped reading the Trustless Bitcoin Vaults (TBV) paper at one sentence.
TBV lets native Bitcoin secure borrowing on Ethereum without wrapping or bridging. The paper then described proving an Ethereum state transition without asking Bitcoin to understand Ethereum.
I went back three sections because I assumed I'd misunderstood it.
I hadn't.
Bitcoin never evaluates the SNARK verifier. It never learns Ethereum's state either.
BitVM3 moves that work into an off-chain challenge process. A claim is posted to Bitcoin and waits behind a challenge-window timelock. Bitcoin enforces that window regardless of whether the claim is challenged. If nobody successfully disputes the claim, settlement continues. If a challenger proves the claim false, a second mechanism, a hashlock triggered by the revealed secret from that failed proof, prevents the payout.
That changed how I think about TBV.
Bitcoin isn't verifying Ethereum.
It's enforcing the conditions under which a claim is allowed to settle.
The computation stays off-chain. Bitcoin's role is to enforce the protocol's security conditions without ever interpreting another chain's state.
The part I'm watching now isn't the happy path.
It's the failure path.
When the challenge window becomes busy, how often does it actually get exercised? And what does that look like on the TBV public testnet when multiple claims are active at the same time?
$BABY only becomes interesting to me if that dispute process remains predictable under real network conditions.
#baby
Any other Top 300 creators in the GRVT Booster campaign facing this?
I'm ranked #56 on the Global Leaderboard and all eligibility requirements are completed, but the Verify button is still disabled even though the verification window is open.
I've already updated the app, cleared cache, force stopped it, and confirmed I'm using the same Keyless Wallet.
Is anyone else experiencing the same issue, or is it just my account?
#GRVT @grvt_io @Binance Wallet @Binance Customer Support
I'm ranked #56 on the Global Leaderboard and all eligibility requirements are completed, but the Verify button is still disabled even though the verification window is open.
I've already updated the app, cleared cache, force stopped it, and confirmed I'm using the same Keyless Wallet.
Is anyone else experiencing the same issue, or is it just my account?
#GRVT @grvt_io @Binance Wallet @Binance Customer Support
๐ $DODO Surges Over 40% โ Bulls Take Control!
After weeks of consolidation, $DODO has broken out with strong momentum, climbing more than **42%** and reclaiming key resistance levels.
๐ Support: $0.024โ0.025
๐ฏ Resistance: $0.030
As long as price holds above the breakout zone, the bullish structure remains intact. A clean move above **$0.03** could fuel the next leg higher.
Are you holding $DODO or waiting for a pullback? ๐
After weeks of consolidation, $DODO has broken out with strong momentum, climbing more than **42%** and reclaiming key resistance levels.
๐ Support: $0.024โ0.025
๐ฏ Resistance: $0.030
As long as price holds above the breakout zone, the bullish structure remains intact. A clean move above **$0.03** could fuel the next leg higher.
Are you holding $DODO or waiting for a pullback? ๐
๐ Another tokenized stock is coming to Binance!
AAOIB/USDT represents Applied Optoelectronics (AAOI) on Binance's bStocks platform, giving eligible users on-chain exposure to the underlying stock.
As Binance continues expanding bStocks, tokenized equities are bringing traditional markets closer to crypto.
Would you trade tokenized stocks instead of using a traditional broker? ๐
AAOIB/USDT represents Applied Optoelectronics (AAOI) on Binance's bStocks platform, giving eligible users on-chain exposure to the underlying stock.
As Binance continues expanding bStocks, tokenized equities are bringing traditional markets closer to crypto.
Would you trade tokenized stocks instead of using a traditional broker? ๐
Verified
๐งต What's Actually Going On With Iran Right Now
If you've seen #TrumpMeetsOnWiderIranOffensive blowing up, here's the full picture:
The backstory: A temporary ceasefire between the US and Iran has effectively collapsed amid renewed fighting. The US says Iran attacked commercial shipping in the Strait of Hormuz โ one of the world's most important energy chokepoints. In response, Washington expanded military strikes and reimposed a naval blockade targeting Iranian ports.
The escalation: Trump has now held a Situation Room meeting with his full national security team to discuss a significantly broader campaign, extending beyond operations around the Strait of Hormuz. He has also warned that critical infrastructure, including power plants and bridges, could become targets if Iran refuses to negotiate.
The wildcard: US officials are closely watching "Pickaxe Mountain," a heavily fortified underground nuclear-related facility believed to be difficult to destroy even with bunker-buster weapons.
Why it matters for markets: The Strait of Hormuz handles a significant share of global oil and LNG shipments. Any prolonged disruption can push energy prices higher, increase inflation risks, and drive volatility across global markets โ including crypto. During geopolitical shocks like this, Bitcoin and other major assets often react more to macro risk sentiment than on-chain fundamentals.
Stay sharp, watch the headlines, and manage risk accordingly. ๐ง
#TrumpMeetsOnWiderIranOffensive
If you've seen #TrumpMeetsOnWiderIranOffensive blowing up, here's the full picture:
The backstory: A temporary ceasefire between the US and Iran has effectively collapsed amid renewed fighting. The US says Iran attacked commercial shipping in the Strait of Hormuz โ one of the world's most important energy chokepoints. In response, Washington expanded military strikes and reimposed a naval blockade targeting Iranian ports.
The escalation: Trump has now held a Situation Room meeting with his full national security team to discuss a significantly broader campaign, extending beyond operations around the Strait of Hormuz. He has also warned that critical infrastructure, including power plants and bridges, could become targets if Iran refuses to negotiate.
The wildcard: US officials are closely watching "Pickaxe Mountain," a heavily fortified underground nuclear-related facility believed to be difficult to destroy even with bunker-buster weapons.
Why it matters for markets: The Strait of Hormuz handles a significant share of global oil and LNG shipments. Any prolonged disruption can push energy prices higher, increase inflation risks, and drive volatility across global markets โ including crypto. During geopolitical shocks like this, Bitcoin and other major assets often react more to macro risk sentiment than on-chain fundamentals.
Stay sharp, watch the headlines, and manage risk accordingly. ๐ง
#TrumpMeetsOnWiderIranOffensive
Verified
@NewtonProtocol
I went looking for what's actually in the Model Registry.
Newton describes it as an onchain marketplace where anyone can publish, discover, and compose agents into agent swarms. I assumed I'd find it already populated. Multiple teams. Competing agent models. The kind of ecosystem I thought the registry had already been built to support.
Newton's own roadmap says otherwise.
The initial agent built on the Protocol is a Recurring Buy Agent, built by Magic Labs, the team behind Newton itself.
Publishing, discovery, and composable agent swarms are described in the roadmap as what comes next.
That reframed something I'd been assuming.
The registry's governance model is already documented. Staking, registration, and operator accountability are defined before a broader marketplace of independent participants is documented.
The governance arrived before the ecosystem.
As Newton Mainnet Beta expands, today's documented starting point is one in-house agent. The roadmap describes a broader marketplace than the one documented today.
I don't know whether that means the incentive design is simply waiting for outside participants, or whether beginning with a single, team-built agent is exactly how you'd want to validate the mechanism before opening it to everyone. Both readings fit what's documented.
I'm less interested in whether one agent is enough for Mainnet Beta than in what changes once the Model Registry begins governing operators @NewtonProtocol didn't build. That's the point where the marketplace stops being a roadmap and starts becoming infrastructure.
$NEWT becomes more interesting to me once those governance rules begin applying to independent participants rather than only the protocol's own starting point.
#Newt
I went looking for what's actually in the Model Registry.
Newton describes it as an onchain marketplace where anyone can publish, discover, and compose agents into agent swarms. I assumed I'd find it already populated. Multiple teams. Competing agent models. The kind of ecosystem I thought the registry had already been built to support.
Newton's own roadmap says otherwise.
The initial agent built on the Protocol is a Recurring Buy Agent, built by Magic Labs, the team behind Newton itself.
Publishing, discovery, and composable agent swarms are described in the roadmap as what comes next.
That reframed something I'd been assuming.
The registry's governance model is already documented. Staking, registration, and operator accountability are defined before a broader marketplace of independent participants is documented.
The governance arrived before the ecosystem.
As Newton Mainnet Beta expands, today's documented starting point is one in-house agent. The roadmap describes a broader marketplace than the one documented today.
I don't know whether that means the incentive design is simply waiting for outside participants, or whether beginning with a single, team-built agent is exactly how you'd want to validate the mechanism before opening it to everyone. Both readings fit what's documented.
I'm less interested in whether one agent is enough for Mainnet Beta than in what changes once the Model Registry begins governing operators @NewtonProtocol didn't build. That's the point where the marketplace stops being a roadmap and starts becoming infrastructure.
$NEWT becomes more interesting to me once those governance rules begin applying to independent participants rather than only the protocol's own starting point.
#Newt
@grvt_io
Whenever I read "Insurance Fund," I assume that's where a liquidation story ends.
GRVT's documentation kept going.
If large liquidations push the Insurance Fund into deficit, GRVT calculates a Socialized Loss Haircut by dividing the Insurance Fund Deficit by Total Client Equity across the exchange.
That percentage applies only to withdrawals made while the deficit exists.
I stopped reading there and went back through the worked example.
A liquidation leaves the Insurance Fund 200 USDT underwater against 4,000 USDT of total client equity. The result is a 5% haircut. Charlie withdraws 500 USDT during that window. He receives 475 USDT, while the Insurance Fund receives the remaining 25 USDT. Once the deficit returns to zero, the haircut disappears with it.
That changed how I understood the insurance fund.
I'd been treating it as the final buffer.
The documentation makes withdrawal timing part of the loss allocation.
The haircut isn't determined by the position that created the loss.
It's determined by who chooses to withdraw while the deficit still exists.
The mechanism doesn't just account for losses.
It makes the timing of an exit part of how those losses are distributed.
I'm watching whether traders begin treating the Insurance Fund alongside price and margin during periods of market stress, or whether most people only discover this mechanism after a withdrawal settles for slightly less than expected.
#grvt
Whenever I read "Insurance Fund," I assume that's where a liquidation story ends.
GRVT's documentation kept going.
If large liquidations push the Insurance Fund into deficit, GRVT calculates a Socialized Loss Haircut by dividing the Insurance Fund Deficit by Total Client Equity across the exchange.
That percentage applies only to withdrawals made while the deficit exists.
I stopped reading there and went back through the worked example.
A liquidation leaves the Insurance Fund 200 USDT underwater against 4,000 USDT of total client equity. The result is a 5% haircut. Charlie withdraws 500 USDT during that window. He receives 475 USDT, while the Insurance Fund receives the remaining 25 USDT. Once the deficit returns to zero, the haircut disappears with it.
That changed how I understood the insurance fund.
I'd been treating it as the final buffer.
The documentation makes withdrawal timing part of the loss allocation.
The haircut isn't determined by the position that created the loss.
It's determined by who chooses to withdraw while the deficit still exists.
The mechanism doesn't just account for losses.
It makes the timing of an exit part of how those losses are distributed.
I'm watching whether traders begin treating the Insurance Fund alongside price and margin during periods of market stress, or whether most people only discover this mechanism after a withdrawal settles for slightly less than expected.
#grvt
Log in to explore more content