老青蛙BNB

There are currently two more rounds of the spot trading competition that you can participate in. The shopping vouchers given by the event will expire either today or tomorrow—so I’ll use them today first. $EUL $MIRA

To be honest, besides waiting for it to appreciate, BTC in my wallet seems to do nothing else. That’s also why I’ve been researching @BabylonLabs_io recently—I want my sleeping assets to start moving without taking on too much additional risk.
In the past, to make BTC earn yield, you either had to do cross-chain DeFi and worry about the bridge getting hacked, or switch to derivatives and worry about de-pegging. For retail users who just want to hold coins steadily, the options are very limited. Babylon, however, lets BTC directly participate in PoS consensus—you don’t have to turn it into another token, and you don’t have to leave the Bitcoin mainnet security boundary.
It uses Bitcoin’s native scripting capabilities to stake BTC to a PoS chain in exchange for rewards. Without cross-chain bridges or wrapped tokens, your BTC is still your BTC—it just has an added yield feature. This is completely different from converting to receipts and managing them like a financial product. It turns Bitcoin’s security into a rentable resource.
Of course, let me pour some cold water. Babylon is still early-stage, so audits and real-world validation will take time. Staking means liquidity is constrained; you’ll need to read the documentation thoroughly and understand details like unlock periods and slashing penalties—don’t just stare at the APR and ignore the risks.
This isn’t a magic tool for passive income. It’s just an addition to asset allocation thinking. If you’re bullish on BTC long-term and can afford the cost of trial and error, you can give it a try; otherwise, holding normally is more prudent. After all, “not losing more than you could have gained” matters. Whether you should move your coins through Babylon comes down to how you assess your own risk tolerance. #baby $BABY

$ETH This rebound is clearly stronger than $BTC . I don’t know if it will bring about a little fake-market rally 🤔

On a governance proposal submitted by Babylon to Aave, one word made me stop: transfer-restricted (transfer restricted). A token that has its own transfer functionality cut before issuance is something you don’t see very often.
First, let’s talk about the bookkeeping of ordinary wrapped coins. WBTC is essentially an IOU: you hand your BTC to a custodian, and on Ethereum they mint a token worth the equivalent amount for you. Whether it’s valuable or worthless depends entirely on whether the coins in the custodian’s wallet are still there. An IOU only has value if it can circulate—so it must be freely transferable.
Babylon’s vaultBTC has a different origin. After BTC is locked into Trustless Bitcoin Vaults (TBVs), an on-chain vault record is automatically generated. vaultBTC is a 1:1 mapping of that record, created exclusively as collateral for Aave. No one can mint it out of thin air. If you want to redeem the underlying coins, you have to provide a zero-knowledge proof; settlement then goes directly back to an address on Bitcoin.
Only when I line these up could I really taste the difference. WBTC’s issuance power sits with the custodian, while vaultBTC’s generation power is tied to the act of locking itself. WBTC’s credibility comes from a promise, while vaultBTC’s credibility comes from cryptographic conditions. WBTC wants to become money that circulates freely; vaultBTC, on the other hand, doesn’t even want to be money—it just wants to quietly serve as collateral.
But we should also be fair. Transfer restriction is a double-edged sword. Leaving the Aave scenario, it currently has almost no other use. On the liquidation side, you still need WBTC for instant settlement, and the old pipeline hasn’t been fully dismantled yet. So it’s still too early to say Babylon has “killed” wrapped coins.
Therefore, what’s truly new about vaultBTC isn’t that it’s also a kind of voucher, but that the voucher’s meaning is not the same as an IOU for the first time. Both names include BTC: one is an invoice issued by trust, and the other is a receipt stamped by rules. Whether they’re similar or not depends on what they’re backed by. @BabylonLabs_io #baby $BABY

Last week a friend asked me, what exactly is different about @BabylonLabs_io Trustless Bitcoin Vaults from WBTC? I talked for ten minutes about cryptography—he fell asleep. Later I used a house analogy, and he understood in a minute.
WBTC is like transferring ownership of your house to an intermediary. The intermediary gives you a receipt, and then you use that receipt to borrow money elsewhere. The biggest receipt is called WBTC—the one that holds everyone’s house for them—managed by a custody company called BitGo. If one day you want your house back, it depends entirely on whether that intermediary is still around and whether they still follow the rules.
TBV uses a different approach: you take the property deed and use it as collateral. The house never leaves your name for a single day. The vault is a separate UTXO on Bitcoin. When you deposit funds, you pre-sign transactions with the conditions locked in: in any given situation, who is allowed to move what can’t be changed. To withdraw money, you must provide cryptographic proofs. BitVM3 verifies authenticity on Bitcoin. That “intermediary” role is removed completely.
What’s truly valuable in the analogy is the second half. “Trustless” isn’t that nobody is trusted—it means you minimize the part that must be trusted. You can openly verify the math; you can only pray for the intermediary’s character. Babylon never removed trust itself—it removed the *object* of trust.
But of course, the analogy isn’t perfect. With house collateral there are still manual steps like appraisal and registration. TBV also has its own registration venue, and both whitelisted liquidators and oracles still stand at key stages. Trust is reduced, not eliminated—claiming “zero trust” is an overpromise.
So the one-sentence version is: WBTC hands both the house and the keys to someone else; TBV only hands the rules to mathematics. No moving, no handing over keys. The BTC/“big coin” is still yours—you don’t rely on anyone being good, you rely on rules that nobody can change. #baby $BABY

On the @BabylonLabs_io staking page, I saw a line of small text saying that your BTC would be in a slashing/forfeiture (punishable) state—I paused for a few seconds. The words “slashing” and “forfeiture” were enough to scare people off; I’m not the only one it repelled.

Later, once I dug into how the mechanism works, I found out that this line of text is read backwards.

First, figure out who the slashing is meant to target. Proof-of-Stake chains are most afraid of validators signing two blocks at the same height; the chain forks. So every chain keeps a “blade” ready for slashing. The problem is that most protocols write the “blade” too broadly—offline gets penalized, missed signatures get penalized too. Users see the word “slashing” and run.

Babylon’s “blade” is tightly scoped: it triggers only in one situation—when the Finality Provider you selected repeats the signature at the same height. It relies on EOTS signatures: you use it once safely, and the second use automatically exposes the private key. Anyone can then execute the slashing/forfeiture without waiting for anyone’s judgment. The trade-off is that 0.1% of the delegated amount is directly destroyed on Bitcoin, and the FP is permanently removed from the system. Going offline isn’t punished; you just temporarily can’t earn rewards.

Once I understood this, I wasn’t worried anymore. For slashing to be valid, three things must be met: first, a provable double signature; second, the exposed private key comes after; and finally, the Covenant Committee must co-sign. If any one is missing, it can’t be executed. Your own private key is never touched from start to finish, and after slashing, the remaining BTC is returned along the original route.

Compare that to the BABY validator scenario where a double-signing slash is 5%, and Babylon’s 0.1% on BTC is a restrained parameter.

However, staying calm doesn’t mean it’s risk-free. The 0.1% only covers the present. The official documentation states plainly that in the future, as more BSNs are integrated, the slashing conditions may be expanded based on each chain’s needs. The committee co-signing layer is also a trust point. If you truly want to reduce risk, the old reliable method is still to diversify delegations—don’t put all your BTC on a single FP.

So whether that 0.1% is scary or not doesn’t come down to the proportion; it depends on the trigger conditions. People who don’t understand the mechanism are deterred by two words, and the returns go to those who do understand. The “blade” is really meant to prevent malicious actors, not you the staker. #baby $BABY

Where are the coins alpha grabbed today?

$STORJ These project parties are all scrambling to make a quick exit—bear-market is coming.

Yesterday I double-checked the staking data for <0-9>@BabylonLabs_io </0-9> and entered the two figures into a calculator. I pressed through, cleared everything, and re-entered them twice. The vault holds 56,853 BTC locked up; at the current price that’s roughly $3.7 billion. But BABY’s circulating market cap is only a bit over $50 million.

When the market judges how much a project is worth, the usual move is to check the market-cap rankings, then glance at the unlock schedule. The pricing logic is pretty routine. But the staking protocol keeps a second ledger—how much value users actually lock in real assets—and that rarely gets placed side-by-side with market cap for comparison.

I verified the figure of 56,853 from two sources. Babylon’s official dashboard matches third-party TVL statistics. Using today’s BTC price of $64,000, it comes out to about $3.6–$3.7 billion—making it the largest Bitcoin staking protocol locked across the entire network. On the other end, BABY has about 4 billion circulating coins, with a unit price around $0.013. That puts its market cap in the $50 million range. Divide the two and you get a multiple of over 70.

Only after looking at this level did it really hit me: the two ledgers measure fundamentally different things. TVL isn’t recording how much the project is worth; it’s recording how much money people are willing to hand over to these rules. Market cap is recording how much the market is willing to pay for the token’s functionality. One ledger is about security, the other about pricing; between them sits a BTCVaults revenue loop that hasn’t fully run yet.

Of course, a mismatch doesn’t automatically mean an undervaluation. If you switch to FDV, the multiple shrinks to the low 20s. The BTC currently in TVL doesn’t generate revenue for the protocol. Stakers earn inflation rewards—so this ledger isn’t connected to the token’s cash flows. Whether $50 million is expensive or cheap, I can’t draw a conclusion.

So what this set of data truly leaves behind isn’t an answer, but a question. Is the market correctly pricing BABY’s functional value, or is it overlooking the 50,000+ BTC in the vault that will eventually need to be reflected on the same balance sheet? What do you think the market is missing—exactly? #baby $BABY

$BTC 66600 Didn’t pass twice; the pressure at this spot is a bit high. First, let’s look for the downside and see if 61800 can hold, but I feel it won’t. After all, the platform that was finally reached just dropped immediately. The 66600 fake-move multi-task has already been completed

Before the Trustless Bitcoin Vaults whitepaper by Babylon, I carried two questions: what is the collateralization ratio, and where should the alert line be set. After reading it twice, I couldn’t find a parameters table, yet I got stuck on an example. Bob takes 1 BTC and borrows $50,000—if it falls below $50,000, it gets liquidated. The whole paper contains no LTV numbers. I was stunned; maybe I looked at the wrong thing.
In past lending and liquidation, the platform set the parameters. Collateral ratio, liquidation thresholds, and penalties were all written into the contract; the oracle quotes, and when it hits the line it closes the position. Users only watch the health factor. In short, the rules are written by the platform—trust is bundled into it too.
The thinking behind @BabylonLabs_io doesn’t follow this line. The vault is an independent UTXO. When you lock the coins, you pre-sign a batch of Bitcoin transactions, hard-coding the conditions: once you repay, you can redeem; if the market price falls below the agreed threshold, the other party can liquidate. The official calls this a “cryptographic proof of external contract state” that is gated and verified via BitVM3. The liquidation line isn’t a platform parameter; it’s the condition you hard-coded when you signed.
What changed my mind is that there’s basically no platform setting an alert for you here. The safety boundary is fixed at the moment you sign; afterward, you can only monitor prices yourself, adding collateral or repaying in advance. It’s still at the PoC stage, and the VaultBTC experiment market on Morpho only has liquidity of a dozen or so dollars.
The pitfall still has to be laid out. According to the whitepaper, liquidation is triggered by whitelisted liquidators watching the price—it’s not completely permissionless. The whole flow is still hanging on the oracle, so if the oracle quote is wrong, the judgment follows it and goes wrong too. These steps won’t steal your BTC, but they could get you liquidated by mistake.
So I think TBV isn’t really building a borrowing product with better parameters—it’s turning liquidation from a platform rule into cryptographic conditions that you have signed yourself. Will the big pie be forced-liquidated? The answer isn’t in the alert button; it’s in those transactions you signed. Whether you can withstand it with real money is another question.
#baby $BABY

Scrolling through my phone at dawn, I saw yet another new chain announcing that it has integrated Bitcoin security. It reminded me of those chains from three years ago that kept propping up their validators with crazily issued tokens—back then, their token price was already doomed by inflation before it even launched.
Following this announcement, I found the document at @BabylonLabs_io , and suddenly I realized that the “Bitcoin staking” narrative has another side to it: for new chains, it’s effectively a cost-cutting and efficiency-accounting deal.
First, credit where it’s due. The hardest part of a new chain’s cold start is security. If you “self-host” validators, you need to use high-inflation tokens to incentivize them—basically trading token price for security. Babylon lets new chains switch to renting BTC as collateral, paying rewards to Bitcoin stakers instead. That means no need for疯狂增发 tokens, and the value anchor is actually steadier. For users participating in mining on these new chains, reduced sell pressure is indeed a real benefit—and I think this logic holds.
But the reality is that security isn’t a commodity you can buy outright with money. What the new chain buys is verified eligibility. But who gets the authority to set the rules for judging whether stakers violate them? The answer lies in the policy and governance process. If the downstream chain’s governance transparency is insufficient, rules can be changed by a small group of people at any time—then this rented security could become meaningless paper, and miners would face the double risk of both token price and governance rules.
I won’t make any promise that a new chain will be more stable just because it uses BTC collateral, because disclosures of governance details are still a gap—and the gap itself is the risk. Would you pay for a new chain backed by BTC? By the time I finished writing this, the sky was just starting to brighten.
#baby $BABY

Bitcoin beat someone up 😱

Not long ago I had tea with an old friend and we talked about Bitcoin investment and wealth management. What everyone fears most is sending their coins to a platform just to get a different number—this obsession with maintaining control over assets is, in essence, the plainest form of psychological safety for old “cultivated” investors. The core of earning interest by holding coins and letting them “grow” is the transfer of the creditor’s claim: once the coin leaves your address, what you have left is only a fragile promise of redemption. If the platform goes under, that promise becomes worthless.
Until I handed over the document numbered @BabylonLabs_io , explaining that the coins could stay in their own addresses and earn interest, their first reaction wasn’t excitement—it was suspicion.
It was that suspicion that pushed me to study its underlying logic in depth. I found that, at the mechanism level, it redefines transactions: by embedding Timelock constraints into the mainnet scripts, Bitcoin can enter a contract-locked state without surrendering the private key—turning it into “active money” that can earn yield. Your coins always rest in your own address. There’s no cross-chain transfer; they’re simply wrapped in rules about time and conditions. The rewards are the price paid by the downstream PoS chain for that safety.
$RIF
It uses EOTS to bind behavior to assets: once the downstream chain performs a double signature, the mainnet-locked coins will be subject to forfeiture. “Trust” in the mechanism replaces “trust” in people. But the reality is that holding the coin doesn’t mean holding the power. That Script has already preset a path for forced execution. Who constrains the authority to change the downstream Policy? The document doesn’t answer that.
$ON
I verified the unlock-trigger process in the Babylon documentation three times, and the permission definition for the emergency circuit breaker remains unclear. I won’t fill this gap for the official—an information gap in itself is risk. How far do you think this kind of design, with coins in hand but power outside, can go? By the time I finished writing, the tea had already gone cold. #baby $BABY

Liang Wenfeng knows we should place multiple bids for the new stock offering 😄

Not everyone needs to open dozens of contract trades every day, but the default product logic of many DEXs assumes users are here for high-frequency trading. For those who occasionally rebalance, most of their margin sits idle most of the time; for yield-focused users, they don’t want to monitor the market all day. And if you want to gain exposure to gold and U.S. stocks, you still have to cut away from other platforms. I put these capital routes together and ran the same funds through the flow a few times—feels like @grvt_io is more like building an on-chain brokerage platform, rather than just an order-taking tool for crypto perpetuals.

The problem is that traditional DEXs usually only handle the moment of execution. After matching is done, what happens to idle funds, how low-frequency users should allocate strategies, and how different assets can share balances—all of that gets pushed back onto the users to solve themselves. Trading profits and investments are scattered across various protocols; every time you have a new need, you have to re-route asset approvals and re-check risks. $EVAA

With One Balance and unified margin, GRVT brings these kinds of requirements under one account system. Active traders can manage perpetual positions directly with a central limit order book. For low-frequency users, the trading account equity can keep earning interest through Earn on Equity. Yield-focused users can also allocate capital into strategy vaults like GLP, take strategy shares, and share in market-making returns—so they don’t have to constantly watch the screen, place orders, and rebalance every day.

Users who want to play RWA also have a very straightforward reason to use it. GRVT provides on-chain price exposure to traditional assets like gold and stocks, letting you manage both crypto assets and RWA perpetual contracts in a single interface. Operations involving account status and fund settlement are then verified by ZKsync Validium and zero-knowledge proofs, keeping the boundaries of self-custody as tight as possible. $SXT

The core value of this structure isn’t that it stacks features endlessly—it’s that the same pot of capital can earn interest from trading and be used for strategy allocation, without the hassle of moving back and forth. That’s why GRVT doesn’t just serve high-frequency perpetual players; it also covers low-frequency, yield-oriented users and RWA users. Of course, you still need to evaluate risks separately—interest-earning conditions, strategy drawdowns, and things like traditional-asset opening gaps. Its positioning really does go beyond a typical perpetual DEX, but whether it can reliably handle all these needs—we’ll have to keep watching. #grvt

After deploying the automation strategy to an intelligent wallet, I found that while account abstraction solves the transaction-sending problem, it does not define the boundary of the agent’s permissions. Batch transactions and gas prepayment reduce signatures, but when I deliberately swap the target protocol and increase the allowance, the wallet can still construct a UserOperation. After comparing the EntryPoint validations with the strategy contract’s returned data, I confirmed that the final limitation comes from @NewtonProtocol rather than the wallet interface.
$BILL

The core value of account abstraction is to improve the experience: it can bundle multi-step calls and handle gas. But once the automation agent is connected, the intelligent wallet only gains more flexible execution capability. Which assets and protocols the agent can call, and how much allowance it can spend, still requires additional rules management. A more flexible execution wrapper does not mean the actions are inherently safe.
$PALU

Newton Protocol neatly fills the gap in the decision and constraint layer. Strategy constraints predefine which tokens the agent may access, as well as the target protocols and allowance limits. simulatePolicy rehearses asset changes before execution, then passes the result to the smart account for validation. Account abstraction is responsible for completing on-chain calls, while Newton Protocol determines whether the call complies with the user’s intent. Even if the agent changes routes, it still cannot step outside the permission boundaries defined by the contract.

This establishes a sensible division of responsibilities. The smart wallet makes on-chain operations more convenient, and Newton Protocol ensures that automation permissions remain controllable—usefulness and manageability need not sacrifice each other. The more important verification for what comes next is whether, when a strategy update and account recovery occur at the same time, the old permissions can be thoroughly cut off. The smart wallet provides the execution body, but safety instructions must have an independent and verifiable emergency brake mechanism. True automation trust is built on perfect decoupling between execution and constraints.#newt $NEWT

Stealing strategies happens often not because someone accidentally slipped their words, but because on-chain records reveal all your hidden cards. Nowadays, most DEXs default to publishing wallet addresses and fund-flow directions. If others follow the timeline and watch a few times, your initial position direction and your DCA/add-later cadence are completely exposed. @grvt_io is all about trading privacy—not bragging about being invulnerable to copycats, but truly reducing the direct on-chain exposure of your trading intent.

I reviewed on-chain data from an active address once. A single transaction record might not show much, but when you overlay transfers with balance changes, you can clearly see when they built positions, where they topped up/added to protect, and when they reduced exposure. Retail traders may not care, but for whales and market makers, this is a disaster: getting front-run and having your strategy copied. Slippage also tends to get worse.

The real issue lies in the public execution environment where everything is on-chain. Once orders and account states are written in plain text to the blockchain, data analytics tools can map out a complete behavioral profile. The money is still yours, but the strategy path becomes public data. The larger the capital, the more regular the actions—and the cost of having your intent exposed becomes far more painful.

GRVT’s solution is to separate verification from disclosure. Orders are handled off-chain in an order book, while settlement uses Validium based on ZKsync. Transaction data stays off-chain; only zero-knowledge proofs are used to verify state updates. There’s no need to publicly reveal all margin and trade details. This greatly increases the difficulty for others to reverse-engineer your strategy from on-chain data.

That said, we should also be objective: privacy protection doesn’t mean absolute invisibility. Your on-chain transfers, interactions with external wallets, and even your order-placement habits may still leave traces. GRVT solves the problem of public exposure surfaces—not making you fully disappear. This direction has real value, but where the privacy boundaries truly are, and what the long-term results look like, still needs time to be tested. #grvt