韭菜复仇记

V2 is live, but what about the users of V1?

TermMax V2 has been up for more than a month, and I only took the time today to carefully go through the update log.

After reading it, my biggest feeling is——it seems like V1 users have been forgotten.

There are indeed many things that V2 has changed. Composable Base Yield automatically routes any unmatched funds into Aave and Morpho to earn floating yield. Atomic Order lets a single liquidity transaction cover multiple markets at once. Order Aggregator intelligently aggregates orders to help you find the best interest rate. And Smart Unwind supports closing positions early.

Everything sounds great. But the question is——what happens to the V1 pools?

The official says V2 will become the default version and V1 is going to be deprecated. If I have funds stored in V1, will they be migrated automatically later, or do I need to do it manually? During the migration, will I need to reauthorize and pay gas again? If I don’t want to migrate, can I still exit normally when the position reaches maturity? @TermMax

I looked through the docs but couldn’t find a clear answer.

I understand product iteration. The issues of V1 liquidity being fragmented and funds sitting idle also do exist. But when it comes to upgrading, what we fear most is that long-time users get left stranded halfway. There are plenty of cases in DeFi where user assets got stuck due to upgrades. Can TermMax make the transition方案 clean and well-handled? This is more important to watch than how many new features V2 adds.

One more thing I’m a bit concerned about—V2’s TVL is currently over $34 million, with Ethereum accounting for over $32 million. V2 has been live for nearly two months, yet funds are still heavily concentrated on Ethereum, while the depth of pools on other chains is almost negligible. A multi-chain unified entry has been built, but if capital doesn’t move, unifying the entry doesn’t help much.

The direction of V2 is correct, but the way the details are handled during the transition period will determine whether old users follow along or turn around and leave.

#termmax

It’s been over half a year since Dusk’s Hedger module went live—has anyone actually used it?

When Dusk EVM launched the mainnet, one term kept getting mentioned: “Hedger.” The official description is: “Hedger is Dusk’s confidential transaction module for the EVM. It combines zero-knowledge proofs with homomorphic encryption to achieve ‘privacy that’s controllable and fully auditable throughout.’” In plain English: you can run Solidity contracts on Dusk, transactions are private by default, but when you need to, you can grant access to regulators.

It definitely sounds like it solves the deadlock between “privacy vs compliance.” But after half a year, I went through the on-chain data and found a problem: nobody is using it.

Dusk EVM’s daily active addresses are still stuck in the double digits, and 70% of the blocks are empty. Has this “privacy module” called Hedger ever been called? Is there any transaction at all that uses Hedger for selective disclosure? You can’t find any of that data.
The project team’s update log only says “Hedger is live,” and doesn’t mention a word about whether anyone has used it for privacy transactions after launch. @Dusk

I asked a developer who has registered in the Dusk ecosystem: “Have you used Hedger?” They said: “I’ve used it on the testnet, but not on the mainnet yet. There are too few real usage examples in the documentation about Hedger, so I don’t know how to use it.”

A privacy chain that claims it was “built for regulated finance,” yet its most core privacy module has been live for half a year, with missing documentation examples, blank call data, and zero real-world use cases. It’s like buying a Porsche, with the most advanced engine under the hood—but half a year later, it’s never even been started. It’s not that the engine is bad; it’s that you have no idea whether it can actually run.

The technical direction of the Hedger module is correct—mixing zero-knowledge proofs with homomorphic encryption for the EVM does take it further than most privacy solutions. But technology doesn’t automatically mean people will use it. Until someone really uses Hedger to make the first compliant privacy transaction, and until on-chain data can prove Hedger is being called in real life, I’ll come back and reassess its value. Right now, it’s just a feature that exists technically but has no users.
#dusk $DUSK

I tried TermMax and almost didn’t manage to get in.

First, the conclusion—TermMax’s experience threshold is higher than I expected by a long shot.

This afternoon I specifically made half an hour free and intended to go through the whole process properly. I opened the app—the V2 interface really is good-looking: a dark theme, card-style layout, and each pool’s interest rate and maturity date laid out clearly. I thought the UI is better than the messy dashboards of many DeFi projects by more than one notch—finally, something that looks like a real financial product.

But after searching for a while, I couldn’t find the “Deposit” button anywhere.

The home page is a market list. When I tapped into a market it showed an order book, and then a position management page. I wanted to put money in—yet when I flipped through every tab, there was no obvious orange button. I fiddled around for five minutes, and only after checking community posts did I figure it out: I had to manually switch to the corresponding chain in the wallet first, then come back and refresh the page—the “Deposit” option would appear. I complained about this to a friend who’d used it before. He said I was lucky; the first time he connected, he didn’t even know he needed to switch chains, and he got stuck for half an hour thinking the app was broken. @TermMax

This wouldn’t be a big deal for experienced users, but at the time I was honestly stunned for a few seconds. A thought crossed my mind: TermMax’s interaction design assumes the default user is already an on-chain veteran. For newcomers, just finding the entry point alone can drive away half of them.

What really made me back out was the fees. I randomly picked a USDC pool—5.2% annualized, locked for 30 days. It looked fine at first. But then I pulled out a calculator and pressed it—on the Ethereum mainnet, authorization + deposit + confirmation: that’s three transactions as a baseline. Gas was around 20+ gwei at the time. Each one was about seven or eight bucks, and three of them added up to over twenty. If I wanted to deposit $500, the fees alone would eat nearly 5% of the收益.

And that’s not even counting the opportunity cost during the 30-day lock period. If the market drops sharply in the middle and I want to buy the dip, I can’t withdraw—so I’d just have to stare at it.

I sat there thinking for a full ten minutes, and finally I understood one thing: from the beginning, TermMax didn’t intend to serve retail users. Their Gas optimization is only so-so, and the interface wasn’t polished toward being beginner-friendly. Even the mobile interaction is overly complex. This thing is basically prepared for institutions and big players. They deposit hundreds of thousands or even millions in one go—so the Gas share is negligible, and a fixed 5% return is stable “happiness” for them.

#termmax

OpenDusk is live, and when I went through the proposals, I found they weren’t quite what I had expected.

Lately, the most discussed topic in the Dusk community has been the launch of OpenDusk governance voting. I finally get to vote on-chain. I was so excited that I clicked in to see what the first proposal was—then I went silent.

Three proposals were up: adjusting the staking minimum for a certain validator node, changing the effective time for the inflation parameters, and modifying the funding cycle of the community treasury. All of them are just fine-tuning technical parameters. These are the kind of proposals that ordinary users still don’t understand after reading them twice. There were no proposals about product direction, ecosystem priorities, or the cadence of the NPEX collaboration. Yes, you can vote with the DUSK you hold, but the only things you can decide are “micro-adjustments to the gas fee parameters.” As for what direction the project should go, what does that have to do with you? @Dusk

The participation rate is even more ridiculous. There are tens of thousands of DUSK staking addresses, yet the first proposal’s voting address count is fewer than fifty. A participation rate of only a few tenths of a percent is even lower than some DAOs with very low automation. In other words, governance power on this network is effectively held by only a handful of big stakers. Most people either don’t know they can vote, or even if they do, they think their votes won’t make a difference.

Some people say this is “normal for the early stage,” and I believed them. But Dusk mainnet has been live for almost eight months—how long does this “early stage” need to last? Another thing that worries me is that all the proposal content is initiated by the project team, and community members have not put forward a single proposal. The door to governance is open, but the power to propose still stays with the project team.

The direction of OpenDusk is right—granting the community governance power. But so far, this governance setup feels more like a “notification-style vote”: the project team sets the direction, runs the process, and asks the community to confirm it with a click. It doesn’t really have much to do with the amount of DUSK you hold. I’m still waiting for truly weighty proposals to show up—proposals that can genuinely spark debate within the community. When that day comes, I’ll come back and cast my first vote. In the current state of things, with the DUSK I have, there really isn’t much else for me to do besides staking and voting.

#dusk $DUSK

Dusk’s “sovereign compliance”—whose sovereignty, whose compliance?

Dusk positions itself as a “privacy chain regulated by oversight authorities.” The idea is: you can conduct privacy transactions, but regulators have the authority to inspect them. In the mechanism design, this power is delegated to “sovereign nodes”—held by compliance nodes that possess audit keys. When the regulator requests access, the node decrypts and provides the data. It sounds like it resolves the classic contradiction between “privacy vs. compliance.”

But I have a question: who decides who these “sovereign nodes” are? What are the selection criteria for sovereign nodes? If a sovereign node is attacked and the keys are leaked, does that mean the full transaction history of all users is exposed?

I read through Dusk’s documentation. Sovereign nodes are reviewed and appointed by the Dusk Foundation. The review criteria are “compliance and technical capability”—but it doesn’t specify detailed rules. If a sovereign node is controlled by a particular regulator, or is forced to hand over the keys, how much of users’ privacy remains under the framework of “sovereign compliance”? @Dusk

What concerns me even more is that, technically, this design can indeed achieve “privacy that is auditable”—transactions are hidden, but audit nodes can open them. Yet at its core, you’re not trusting cryptography; you’re trusting that the sovereign nodes won’t misuse their privileges. You’re not trusting mathematics; you’re trusting that institutions won’t do harm.

Dusk’s compliance narrative is certainly compelling in front of institutional clients. “We can put you on-chain while still meeting regulatory requirements”—for financial institutions with ample compliance budgets, that line is definitely valuable. But the prerequisite for “putting you on-chain” is that you must accept that sovereign nodes have the right to view your transactions. You’re an institutional client; you operate in a glass room, and when regulators want to look, they can. So whose privacy is this “privacy,” really—for public privacy or regulatory transparency? That is indeed what Dusk is trying to sell. But “sovereign compliance” itself requires that you trust some authority. In the end, whether this counts as “privacy” or “controlled exposure” depends entirely on which side your perspective is on.
#dusk $DUSK

Dusk’s PLONK vulnerability: a privacy layer with a $600,000 market cap was almost broken through by a forged proof

After I read the security report disclosed by OtterSec on April 30, 2026, I just sat there for about five minutes. The dusk-plonk verifier had never verified the four polynomial commitments provided by the prover. In simple terms, an attacker could forge a fake zero-knowledge proof to mint DUSK tokens and transfer illicit proceeds without any real assets. This is a privacy protocol designed for regulated financial markets, yet its cryptographic core contains a flaw that enables attackers to create tokens out of thin air. This is a foundational infrastructure that claims to give institutions confidence in putting things on-chain—while such a basic defect exists in the privacy layer.

The compliance narrative in the whitepaper looks great, but the code nearly left an infinite minting backdoor. You could say the vulnerability has been fixed. But a vulnerability like this appearing in the validation step of the privacy layer is a slap in the face of the project’s “privacy-first” positioning. A project that makes money from ZK had trouble with its ZK implementation. After reading the report, the first question that popped into my head was—if a privacy chain built on ZK has this kind of bug in its ZK implementation, what else can possibly go right? Dusk’s market cap has already fallen quite a bit from its peak; the $600,000 figure, when translated to the token’s price at the time, means that if the attacker used this vulnerability to mint large amounts of tokens, the price could be directly smashed through. @Dusk

I pulled up a Dusk audit report and skimmed it. The auditor was Dust Labs. The audit scope only covered some modules—was the dusk-plonk verification logic included within that scope? I couldn’t find a clear statement. If the core privacy-layer code was omitted from the audit, or if the audit simply didn’t cover it, then the value of that audit report needs to be reassessed. Audits aren’t something you do once and then you’re done.

I’m not saying Dusk can’t be trusted, but for a project that writes “privacy” into its name, to have such a fundamental vulnerability in the most core ZK verification layer, it’s hard for me to convince myself to keep holding it. Let’s wait until the cryptographic core has gone through a few more rounds of verification. For now, I’m putting it back on my watch list to see whether any new vulnerabilities are disclosed afterward. If the same module breaks again, then it won’t just be a technical problem—it’ll be a process problem. #dusk $DUSK

Babylon is no longer a staking protocol—it’s turning into a secure exchange for Bitcoin

I dug into Babylon’s latest data. The TVL peak hit $7.2 billion, and it’s currently stabilizing above $5.6 billion. More than 56,000 BTC are locked in the protocol and have never left the Bitcoin mainnet. At this scale within DeFi, it already exceeds the TVL of most chains.

What Babylon is really doing is far bigger than “staking and earning.” At its core, it’s building a “secure exchange.” BTC holders rent out their security capital, while PoS chains rent that security to protect their networks. You lock BTC not to collect yield, but to turn your BTC into a layer of security infrastructure and sell it to the chains that need it. One BTC holder provides security; multiple PoS chains buy security; and the Babylon protocol matches them in the middle. This isn’t a staking pool—it’s a bilateral market. @BabylonLabs_io

This market already shows signs of demand. Multiple PoS chains have expressed integration intent, and the supply side of BTC holders is also growing. But the problem is that the price discovery mechanism hasn’t taken shape yet. The rental rate is currently set by the project’s issued BABY tokens, not by the market’s supply-and-demand dynamics. A real security market should have a price discovery mechanism determined by supply and demand. Babylon hasn’t reached that stage yet. Security itself should have a fair price—set jointly by what stakers are willing to accept as rewards and what PoS chains are willing to pay as cost. Right now, the price is still determined by governance parameters, not by a market-driven equilibrium price.

It’s like an exchange that only has sell orders and no buy orders. BTC holders are highly willing to rent out security, but PoS chains that are willing to pay how much for that security have not truly entered the market. Once the demand side starts quoting prices, the price will be discovered for real. Babylon is still in the phase of building out supply, and demand-side order books haven’t truly formed yet.

The direction of turning BTC into a security infrastructure is correct, but it currently feels more like a supermarket priced by the project rather than a free market. Only after the pricing mechanism is truly decentralized and the demand side begins participating in price formation will this narrative fully hold. Until then, it’s still a centrally priced protocol, not a decentralized security market.
#baby $BABY

Babylon’s second round of staking: 23,000 BTC filled within 100 minutes

Babylon’s first round of staking used 1,000 BTC to fill up in 74 minutes, with 12,700 addresses participating. The second round just ended: the data is 23,000 BTC, filled within 100 minutes. Not 1,000—23,000. In 100 minutes, 23 times the BTC amount from the first round was locked into Babylon’s treasury. The growth rate of BTC staked is much faster than most people expected.

More importantly, the participants have changed. In the first round, retail users could still grab a little. In the second round, the per-transaction staking cap was 500 BTC—worth over $30 million at current prices—so retail users simply can’t reach it. The largest staker is Lombard, with 7,166 BTC, accounting for 30% of the total in the second round. Another is Solv Protocol, with 6,009 BTC. Lombard just raised $16 million in July from Polychain Capital. Solv Protocol is a Bitcoin liquidity protocol backed by institutional funds as well. Retail users’ names? Not a single one was seen. @BabylonLabs_io

After Babylon went live on the mainnet, the 1,000 BTC cap was filled within six Bitcoin blocks, and network fees surged from $0.26 to $132 in 90 minutes. When the second round started, a similar fee spike appeared again—but this time it wasn’t because retail users were scrambling. Instead, institutions used scripts to compete with batch bidding. As soon as the staking window opened, transactions flooded in. While retail users were still figuring out how to connect their wallets, the quota had already been swept up by institutions.

Babylon co-founder David Tse previously said, “Looking forward to an exciting moment on the Bitcoin mainnet,” and that moment indeed arrived—but under the spotlight are institutions, not retail users. Babylon’s total staked amount jumped from 1,000 BTC to 23,891 BTC, and TVL surged to more than $1.4 billion. What retail users can see is only changes in on-chain data; they can do nothing themselves. In the first round, you could still say “too slow.” In the second round, you don’t even have the qualification to participate. It’s not that people don’t want to take part—the threshold is no longer within reach for retail.

Babylon’s staking is shifting from a “retail game” to an “institutional game.” What retail users can do is watch the data changes, then continue to hold BTC and do nothing.
#baby $BABY

Babylon’s 12,720 users have built up $5.0B in TVL

I went through Babylon’s latest on-chain data. I’ve confirmed that the staked TVL is 913 BTC, with an additional 454 BTC of staking still pending. The number of users participating in staking has surpassed 12,600. Over twelve hundred people have locked in more than $5 billion worth of BTC.

This number made me think for a while. With 12,600 users staking an average of roughly 4.4 BTC each, at current prices that’s about $350,000. This isn’t retail investors playing around—these are whales. Babylon’s first-stage staking cap was 1,000 BTC, and just six Bitcoin blocks filled it up. Retail investors didn’t even get a chance to compete; the quota was gone. Twelve thousand-plus users sounds like a lot, but against a $5 billion TVL, this user count is actually pitiful. The average stake per user is far above typical DeFi protocols.

What concerns me more is that once the 1,000 BTC limit was filled, the delayed/queued staking amounts had already accumulated to 1,330 BTC. Some people want to stake, but the quota is already full, so they can only queue and wait. Demand is definitely there and strong, but on the supply side, scarcity turns this demand into a game for a small number of people.@BabylonLabs_io

Twelve thousand users supporting $5 billion in TVL shows that Babylon is still, for now, a whales’ playground. Want to get in as a retail user? Wait until the quota opens up. The first-stage cap of 1,000 BTC is indeed far too low—six blocks filled it, and retail couldn’t react in time. No one knows when the second stage will arrive, and the third stage of multi-layer staking is still on the way. Until then, Babylon’s staking remains a whale-only game. What retail users can do is simply watch the quota get snapped up, then keep their BTC in cold storage. Only when the limit expands from 1,000 to 10,000 to 100,000 BTC will retail finally get a chance. At this stage, retail doesn’t even have the right to sit at the table.

#baby $BABY

Babylon’s slashing mechanism: a code bug can burn your BTC forever

Babylon’s most core innovation is its slashing mechanism. Implementing slashing on Bitcoin—something no one had done before. Technically, it’s definitely ahead of its time, but that’s also where the problem lies. In Hindenburg Risk Assessment Report, there’s a line I’ve read several times: “Slashing is enforced cryptographically — an honest software bug can burn your BTC irreversibly.” An honest software bug can burn your BTC permanently. Not a hacker attack, not malicious wrongdoing—your chosen validator’s code has a bug, and by accident it triggers the slashing conditions, and your BTC is gone. Even more terrifying: if multiple validators run the same buggy client, a single bug can simultaneously burn everyone’s BTC. In this system, slashing isn’t “get punished for doing bad things”—it’s “get punished for making mistakes.”@BabylonLabs_io

Babylon uses EOTS (extractable one-time signatures) as the cryptographic foundation for slashing. If a validator double-signs, its private key is exposed, and the attacker can directly take the corresponding BTC. In the paper, this mechanism is beautifully presented—do evil, get punished, a logical closed loop. But in the real world, code bugs, node restart race conditions, network latency, and other factors may cause an honest validator to accidentally trigger double-signing. And in that instant, BTC worth hundreds of millions of dollars is destroyed forever. Bitcoin isn’t Ethereum—there’s no rollback, no governance vote to restore slashed assets. If you’re wrong, you’re wrong; if it burns, it burns. After it’s burned, no one can help you get it back.

There’s currently no real-world, battle-tested precedent for slashing mechanisms. The first deployed slashing system on Bitcoin was the first to manage assets worth tens of billions of dollars, and the first to face real attackers. These three “firsts” stacked together make me not very confident. Babylon’s slashing mechanism may look great in the paper, but between the paper and the mainnet is an entire production line. Until the code is verified, and edge cases are understood and ironed out, I won’t put BTC in. It’s not that I don’t believe the technology—it’s that I don’t trust new weapons that haven’t been tested before going into the real battlefield. Let it actually run smoothly first. When no slashing events have happened yet, that can be the most dangerous time.#baby $BABY

On the Babylon proposal for Aave, I looked into it and found that vaultBTC is a restricted token.

On May 26, Babylon Labs posted a temperature-check proposal in the Aave community, aiming to integrate native Bitcoin as collateral into Aave V4. No wrapping, no cross-chain bridge, no custodian—BTC would be locked in Taproot UTXOs. It sounds like BTC finally has a “clean” use case in DeFi.

I reviewed the technical details of the proposal and found it deploys two Aave V4 Spokes: one handles borrowing and lending, and the other handles liquidation and settlement. The collateral exists in the form of vaultBTC. But vaultBTC is a “transfer-restricted ERC-20 token,” meaning it can only be transferred between fixed whitelisted addresses.

That’s where I paused. A “trustless” BTC lending scheme, yet the collateral token cannot be transferred freely. Users deposit BTC to receive vaultBTC, but they can’t just send it to others—they can only move it between addresses specified by the project. What’s the difference from wrapped BTC? WBTC at least can be transferred freely.

@BabylonLabs_io

I asked someone who has worked on lending and borrowing in DeFi: “How’s the liquidity of a collateral token that can’t be transferred freely?” He said: “There’s no liquidity. If you can’t transfer it, you can’t sell it, can’t do market making, and can’t reuse it in a loop as collateral. It’s just an accounting receipt.”

Babylon’s proposal does address the “cross-chain bridge risk” problem, but it doesn’t solve the “composability” problem. You lock BTC in, and you get back a non-movable receipt. It’s indeed safe—because nobody can touch it. But precisely because nobody can touch it, its usefulness in DeFi is extremely limited.

Also, this Aave proposal is still in the temperature-check phase and is a long way from a full launch. Once it truly runs, I’ll see what kind of liquidity vaultBTC can achieve. For now, it’s just an ERC-20 token with its hands tied.

#baby $BABY

The annualized return from Babylon BTC staking is currently around 1%. The lock-up period ranges from 7 to 90 days. The rewards are paid in BABY.

I looked at this number for a long time. A 1% annualized return, while BTC cannot be moved during the lock-up period. If BTC rises by 5% during that time, your opportunity cost is 4%. If it rises by 10%, your opportunity cost is 9%. BTC’s annualized volatility is 50% or higher. A 5% gain over 7 days isn’t unusual. I asked someone who has held BTC for more than five years: “For a 1% annualized return, would you be willing to lock your BTC for 3 months?” He said: “No. BTC can go up by more than 1% in a single day. If you lock it in, you can’t sell even if it pumps.”

More importantly, the rewards are paid in BABY. If BABY’s price drops during the staking period, your actual return could be negative. How much has BABY fallen from the time it launched? Check the chart yourself. With a 1% annualized return, after subtracting BABY’s depreciation, how much do you actually end up with? Nobody has figured that out. @BabylonLabs_io

Babylon indeed solves the cross-chain bridge problem—no wrapping, no bridging, and you don’t have to hand BTC over to anyone. BTC always stays on the Bitcoin mainnet, and its security is truly a step higher than most BTCFi solutions. But the price of that security is lock-up. You lock your BTC to earn 1% in BABY, while taking the risks of missing out on BTC price increases, the risk of BABY depreciating, and the smart-contract risk if the protocol has issues. Three risks exchanged for a 1% return. I asked someone who runs DeFi strategies: “With that risk-to-reward ratio, do you think it’s worth it?” He said: “Not worth it. A 1% return doesn’t even beat inflation, and you still have to lock it up. Better not to stake.”

A 1% return, no ability to move your funds during the lock-up period, and rewards paid in BABY—those three conditions stacked together make it impossible for the math to work out. Unless you never intended to sell in the first place and you don’t care how far BABY falls. Otherwise, staking is trading a definite lock-up for an uncertain return. After I ran the numbers, I decided to keep my BTC in a cold wallet and not stake. Not staking means at least I won’t lose.

Once the rewards are paid in BTC, the lock-up period is shortened to within a few days, and the BABY price stabilizes, then I’ll come back and recalculate everything. #baby $BABY

Some place launched Babylon staking, but when I checked the terms, I found it’s not self-custody

On July 22, a certain platform launched a Babylon Bitcoin staking service. Users can stake BTC directly on the platform to earn yield via the Babylon protocol, with an annualized return of about 1%. No cross-chain bridge is needed, no wrapping is needed, and the BTC stays on the Bitcoin mainnet.

It sounds like Babylon has finally gone mainstream. But when I reviewed the platform’s terms, I noticed a detail: the staked BTC is held in custody by the platform, and users cannot transfer those BTC during the staking period. The platform runs the Babylon staking flow for you, manages the timelock script on your behalf, and claims BABY rewards for you. You don’t have to do anything—your收益 automatically arrives. But that also means you give up self-custody. Babylon’s core idea is “staking BTC without trusting a third party.” In the platform’s version, trusting a third party is precisely the prerequisite.@BabylonLabs_io

Babylon has long emphasized that it’s different from cross-chain bridge solutions—no bridge, no wrapping, and no handing BTC to anyone. In the platform’s product, the BTC indeed doesn’t leave the Bitcoin mainnet, but the control of the private keys is not in your hands. When you click the “stake” button on the platform, what you’re essentially buying is a centralized custodial product—its underlying layer uses Babylon’s protocol. A 1% annualized return, minus the platform’s cut, means you may end up with even less. You assume Babylon’s protocol risk, the platform’s custody risk, and the risk of BTC price fluctuations, in exchange for less than a 1% return.

I’m not saying the platform’s product is bad. For BTC holders who don’t want to tinker with technical workflows, it’s a convenient entry point. But “convenient” and “self-custody” are two different things. What makes Babylon attractive is self-custody; what the platform is selling is custody. Understanding Babylon using the platform’s version would lead you to misunderstand what this protocol is truly doing. Until you figure that out, I won’t put my BTC into the platform’s staking pool.

#baby $BABY

Babylon doesn’t have its own token, but BTC stakers are still locked up.

When I was reading Babylon’s materials, I found something interesting: Babylon doesn’t issue its own tokens. It doesn’t create tokens, doesn’t do L1, and doesn’t do L2. It’s basically a protocol that lets BTC holders lock their Bitcoin in a timelock script to provide economic security for a PoS chain—and then they receive the rewards. No governance token, no staking token, and no inflation model. @BabylonLabs_io

This is different from EigenLayer’s logic—EigenLayer has an EIGEN token for governance, and re-staked ETH earns yield. Babylon is more like a “Bitcoin security rental market.” You lock your BTC, others rent your BTC security and pay you rent. No intermediate tokens, no additional inflation. In an industry full of tokens, this design is indeed rare.

But the problem is that Babylon’s staking still has a lock-up period. You lock your BTC into a timelock script—how long you’re locked depends on the specific staking pool you participate in. Some are a few weeks, others are a few months. During the lock-up period, your BTC can’t move. You can only watch as the BTC price fluctuates.

I asked a friend who does BTC staking: “How long are you locked for?” He said: “Three months.” I said: “What if BTC goes up during those three months?” He said: “Then you can only watch. Once it’s locked, you can’t take it out.”

Babylon solves the risk of cross-chain bridges, but it doesn’t solve the risk of lock-up. Without bridges, without wrapping, and without third-party custody, the security has indeed taken a step up. But you still have to lock your BTC in, and during the lock-up you still have to bear the opportunity cost of price volatility. A tokenless protocol can still lock your BTC. And this lock is harder to break than tokens. #baby $BABY

The dilemma of a BTC holder

I know an old friend who holds 10 BTC. He’s had them since 2017—he’s been through three bull markets and two bear markets, and he has never sold. A few days ago, we had dinner, and he asked me, “What do you think about Babylon’s BTC staking?”@BabylonLabs_io

I asked him, “Weren’t you never interested in DeFi before? Why suddenly now?” He said, “Because this is BTC that turns into more BTC. Not BTC that turns into some empty air-token. I hold my BTC and don’t sell. There’s no interest every year. If I can safely grow a few percent in additional BTC, why wouldn’t I?” That’s the core demand logic behind Babylon. For someone who has held BTC for more than five years, the only reason to take their coins out of a cold wallet is: “Use the earnings to pay in BTC.” Not BABY. Not any other token. It’s BTC.

Babylon recently partnered with Gomining, which just happens to address this need. BTC holders lock their BTC into Babylon’s vault and receive Gomining’s Bitcoin mining rewards—BTC payback. But the issue is, this collaboration is currently available to only 1,000 BTC. 1,000 BTC—less than 2% of Babylon’s total TVL. Even if my old friend wants to join, he might not get a spot.

He asked me, “Then what should I do now?” I said, “Wait. Wait until the quota expands from 1,000 BTC to 10,000, then 100,000. By then, your BTC can truly start generating more BTC.” After hearing that, he didn’t say anything. He thought for a long time, and finally said, “Then I’ll keep holding.”

I’ve been thinking about what his “keep holding” really meant ever since. He wasn’t unwilling to participate—he simply wasn’t at the threshold level required to participate. The narrative of BTC turning into BTC is correct, but only when it’s truly open to everyday people does it become a valid narrative. Right now, it’s still a game for whales.

#baby $BABY

Babylon’s liquid staking is here, but the 50 BTC cap makes me uneasy

On July 29, pSTAKE Finance launched a Bitcoin liquid staking solution on Babylon. Users deposit BTC into Babylon’s trustless vault, and receive liquid staking tokens in return—earning Babylon’s staking rewards while still being able to use the asset in DeFi. No wrapping, no cross-chain bridges, and no giving up self-custody. The direction is right: the liquidity problem with BTC staking has always been a hard pain point—once locked, you can’t move it. This pSTAKE solution genuinely addresses that.

But there’s one line that worries me: a deposit limit of 50 BTC. Fifty BTC, at current prices, is just a bit over $4 million. A solution meant to address a “liquidity” problem—yet it sets its own liquidity cap first. pSTAKE’s explanation is “to ensure the protocol’s safety.” I understand that early on you need to control risk, but 50 BTC is nowhere near enough relative to Babylon’s TVL of 56,853 BTC—far less than one per mille. pSTAKE provides a liquidity exit for Babylon stakers, but the width of the exit is only 50 BTC. BTC that wants to leave will be stuck waiting in line; it won’t even get a turn. If stakers want to exit at scale, this liquidity window is simply not big enough. @BabylonLabs_io

I asked a friend who runs DeFi strategies: “If a liquidity solution sets a cap of 50 BTC, what do you think?” He said, “It shows they’re still testing. Once the cap is lifted, then you’ll have the truly usable version.” That’s true—but if it’s already being called “liquid staking” now, the real question is whether this liquidity can actually move when it matters.

I’ll come back and reassess once the cap is lifted.
#baby $BABY

Babylon’s third phase: one BTC staked to multiple networks

Babylon’s mainnet phase one has been running for a few months already. The 1,000 BTC staking cap was filled long ago; later it was gradually loosened, and now TVL has exceeded 5.6 billion. This phase is called “lock-only”—users lock their BTC, but the rewards aren’t truly available yet. Phase two’s activation hasn’t fully rolled out.

But the real highlight is phase three, officially called “multi-staking”—the same BTC can simultaneously provide security support to multiple PoS networks. One BTC, staked to several networks at the same time, earning multiple streams of rewards. It sounds like the ultimate form of a compounding machine.

I asked a friend who runs node operations: “If the same BTC helps secure multiple networks at the same time, and one of those networks is attacked, who gets blamed?” He said: “The staker. If you staked it and something goes wrong, the penalties come out of your deposit. No matter how many networks you’re running, when there are slashing events, they’re deducted from the same BTC.”@BabylonLabs_io

That’s the risk of multi-staking. You earn rewards across multiple networks, but the slashing risk stacks up. If one network has a problem, the deduction is from the same pot of money. I asked that friend: “So can the rewards cover the risks?” He said: “It depends on how high the returns are. If the combined annualized rate can reach more than 10%, it’s worth the gamble. If it’s only 3–5%, then you’d be better off not betting.”

Babylon’s third phase is currently still in the testnet stage. Some analysts believe this is the beginning of “one BTC earning multiple reward streams.” From a mechanism-design perspective, that’s indeed the case. But from the standpoint of risk pricing—when one asset bears multiple slashing risks—this math hasn’t really been worked out by anyone in a definitive way. After it’s been running on mainnet for a few months, the data will speak for itself.

#baby $BABY

Babylon’s “security illusion.” I dug through on-chain records

Babylon’s most central narrative is this: let Bitcoin holders stake BTC to provide security services for a PoS chain without giving up self-custody. No bridging, no wrapping, no handing BTC over to anyone. That narrative is undeniably sexy. If you’re someone who holds a large amount of BTC, wants to earn some yield, and doesn’t want the risk of having your funds compromised by cross-chain bridges, Babylon sounds like the answer. @BabylonLabs_io

But when I looked through the on-chain records, I found one thing. After Babylon’s mainnet launched, staking demand really did explode—the 1,000 BTC staking cap filled within a few hours. The problem was fees—Bitcoin network fees jumped from $0.26 to $132 within 90 minutes, a 500x increase. Not because of network congestion, but because Babylon’s staking launch triggered a Gas-fee bidding war. Users, eager to stake before everyone else, kept wildly raising their bids. Someone calculated the numbers: just the operational cost of participating in staking could eat up your future yield for several months—or even an entire year. You get a slot in the staking window, but once you pay the Gas fees, the yield you earn isn’t enough to cover the cost.

What concerns me even more is that Babylon is currently in the first phase of its mainnet—called the “lock-only phase.” Users can lock BTC, but there’s no actual yield distribution yet. You lock it, you pay the Gas fee, and the yield is still “on the way.” So when exactly will it be released? The project says it will happen in “subsequent phases.” But when specifically? They don’t say.

I asked a friend who participated in Babylon staking: “You locked your BTC—did you get any yield?” He said: “I locked it, but I haven’t seen any yield yet. Right now, I’m just waiting.” Waiting for how long? He didn’t know.

Babylon’s direction isn’t wrong—turning BTC into an income-generating asset is indeed a real need. But the term “security illusion” wasn’t coined by me; someone in the community came up with it. Lock BTC, pay Gas fees, and still don’t receive the yield—that’s not staking. That’s just locking.

#baby $BABY

“10 billion BABY + 8% annual inflation” in Babylon—after I did the math, I went silent

Babylon’s token whitepaper looks pretty impressive at first glance. Total supply of 10 billion BABY, with an additional 8% inflation rate every year. What does 8% inflation mean? It means that no matter whether you hold it or stake it, every year an additional 800 million new BABY are minted: 4% goes to BTC stakers, and 4% goes to BABY stakers.

Sounds quite generous, right? But the question I’m thinking about is different: when 800 million more tokens appear each year, will demand be able to keep up?

What concerns me even more is how those 10 billion tokens are allocated. Community incentives 15%, ecosystem development 18%, R&D operations 18%, private sale investors 30.5%, core team 15%. Investors and the team together are 45.5%, almost half. There’s zero unlock in the first year; starting from the second year, they unlock linearly over four years. The community’s 15% does get fully unlocked, used for early airdrops and staking rewards. @BabylonLabs_io

This is the clever part of Babylon’s token model—tokens aren’t unlocked in the first year, so the community tokens can indeed circulate; investors and the team don’t sell in the first year, so selling pressure at launch is smaller. But what about the second year? That 30.5% from investors starts releasing linearly—every month brings a new wave of supply into the market. Can the demand accumulated during year one support the ongoing sell pressure that begins in year two?

I ran the numbers: total supply of 10 billion, 8% inflation every year, plus the investors and team starting linear releases from year two. On the supply side, it’s a continuously opening valve. On the demand side, for now, it mainly relies on the yield from BTC staking. BTC stakers receive BABY rewards—if they sell once they get the rewards, then the loop becomes: “project party prints coins → sends to stakers → stakers dump → price faces pressure.” What’s the difference from those earlier staking projects that were essentially “mine to sell”?

Babylon’s technical narrative is definitely sexy—letting BTC holders stake BTC directly, without bridging, without wrapping, and without third-party custody. But the tokenomics model is a different story. With total supply of 10 billion and 8% inflation each year, how much of that supply can the market actually absorb?

When the second year arrives and investor unlocks truly begin, the answer will be revealed.

#baby $BABY

KOL lock for 1 year plus linear release over the next 3 years—where are the retail investors’ lock-up rules?

GRVT’s TGE is set for July 21. Airdrop registration is open, with 28% allocated to the community. Everything that should be there is there.

But when I looked through the allocation table, I found a detail—KOL lock-up rules have been making the rounds: lock for 1 year, then linearly release over the next 3 years. If KOLs are locked for 4 years, then what about retail investors? How are retail investors’ airdrops locked? In the delayed-claim options it says how many times you get after how long, but it doesn’t say how long the tokens are locked for.@grvt_io

If the KOL lock-up rules are true, then the project team clearly understands that lock-ups are useful for stabilizing the price. They know to lock KOL tokens, but they didn’t plan to lock the retail allocation as well. Retail investors can claim their airdrops immediately—if they want to sell, they can. KOL tokens are locked for 4 years—if they want to sell, they can’t. The tokens that retail investors receive have no lock-up constraints, so they can dump them right at listing. KOLs get tokens but can’t sell them, so they can only watch retail investors sell. On the day a token is listed, the people who can sell have no lock-up pressure, while the people who have lock-up pressure can’t sell. In this kind of structure, what is the opening price propped up by? Faith?

GRVT’s move is indeed quite meticulous. They lock KOLs’ mouths with lock-ups, and let retail investors come in without lock-ups to take over. Since KOLs hold tokens that can’t be sold for 4 years, they naturally praise the project. Since retail investors hold an airdrop they can sell anytime, they naturally provide liquidity. But once retail investors sell out, the KOL tokens still aren’t unlocked.

So the answer to this question is very simple—retail investors don’t need lock-ups, because retail investors are liquidity by nature. KOLs being locked for 4 years is to keep them quiet. Retail not being locked is to make them the bag-holders. Different roles, different treatment.
#grvt