老李说财经

#dusk $DUSK

I’ve always felt that KYC is particularly annoying in one specific way.

It’s not that the process is troublesome just once.

It’s that you’ve already submitted your name, address, documents, and all kinds of information on one platform—then when you switch to another platform, you have to do the whole thing again from the start.

Recently, while looking at Citadel 2 from @Dusk , I suddenly thought that maybe the question shouldn’t be framed this way at all.

Does a platform really need to know “who I am”?

Or is it actually only trying to confirm a few things:

Whether I’m from an allowed region;

Whether I’m old enough;

Whether I meet some investment eligibility requirements.

If it’s only to verify these conditions, then having to submit the entire set of identity documents every time is indeed a bit redundant.

Citadel’s approach isn’t about eliminating KYC.

Identity verification in the real world still needs to happen up front.

The difference is what comes after.

After the verification, once you have a credential, you can use ZK to prove that you meet a certain condition—without having to lay out and resubmit your full identity dossier to the next platform every time.

I think this distinction is pretty practical.

Proving that I’m “eligible” doesn’t mean I need to hand over all my information again and again.

Of course, don’t interpret this as absolute anonymity.

Whether devices, networks, and other attributes are unique enough can still affect how much privacy you have.

But at least it addresses one problem I’ve always found really annoying:

Platforms should only require proof of what they need.

Don’t assume they automatically take the entire set of information from scratch every time.

#dusk $DUSK

When I first saw “EVM compatible,” I didn’t really think much about it.

If Solidity can be used, Foundry can run, and wallets can connect, then isn’t it just the same old Ethereum stack you keep using?

Recently, after reading the DuskEVM Reference by @Dusk , I realized that in real deployments, you still can’t just be lazy like that.

The simplest example: DuskEVM now has its own sequencer.

When you get a transaction receipt, it means it has been packaged in—but that isn’t the same concept as the later settlement.

And there’s prevrandao.

On Ethereum, some developers casually use it for randomness-related logic, but Dusk’s official docs specifically warn that in DuskEVM you shouldn’t treat it as a secure, unbiased source of randomness.

If you don’t usually look at the Reference, it’s easy to just write it the same way you did before, out of old habit.

So now my understanding of EVM compatibility is much more grounded than before:

Yes, it can save a lot of migration costs—no problem there.

But “interface feels familiar” and “the underlying environment is the same” are not the same thing.

If you’re truly preparing to go live, you still have to review things like the sequencer, finality, and cross-layer state from scratch.

I actually quite like the fact that the official documentation spells these limitations out directly.

What I’m most afraid of isn’t that there are differences.

It’s that you think there aren’t differences.

#dusk $DUSK

Assume I bought an on-chain bond.

The money has already been deducted.

But the bond never arrived.

Or the other way around:

the bond has already been transferred to me, but the seller hasn’t received the money.

In ordinary transfers, this might just mean the transaction “failed.”

In finance, though, it means the entire principal is exposed to risk.

Recently, when I looked at the settlement design for @Dusk , the three letters “DvP” left the deepest impression on me.

Delivery versus Payment.

In plain language:

Don’t let the asset leg and the payment leg go their separate ways.

Ideally, bind them under the same settlement condition.

The money can be delivered—only then should the asset be delivered.

The asset can be delivered—only then is the payment truly considered complete.

That’s also why I now feel that:

Trade and settlement are fundamentally not the same thing.

Trade just means both sides agreed.

Settlement is what actually clears the money and the goods for real.

Dusk’s current emphasis on deterministic finality and a DvP-ready workflow, in essence, is about connecting these two things.

Dusk Trade also puts the coordination between the asset leg and payment leg, along with settlement, into the same workflow.

But don’t market it as “using DvP means there’s no risk.”

No.

If the trade ultimately fails to settle, you can still miss the price, and you can still temporarily run short on liquidity.

What it mainly solves is another issue:

Don’t let me pay money and not receive the asset.

Or don’t let the asset be delivered and the money never come back.

So my simplest understanding of DvP is this:

It doesn’t guarantee the transaction will always succeed.

It just tries to avoid failing in only half of the transaction.

I think that’s far more meaningful than simply saying “settlement is faster.”

研究 @TermMax 这几天，我有个变化挺明显。

现在再看到 “Fixed”，我不会下意识把它理解成“更安全”。

固定借款利率，确实能让融资成本更好算。

但股票做抵押，股票还是会跌。

Alpha 没有传统清算线，也不代表行情一定赶得上到期时间。

FT 的收益提前锁住了，流动性和抵押品风险也不会跟着消失。

所以看到最后，我反而觉得 TermMax 有意思的地方不是“把风险变没”。

它只是把很多东西说得更清楚了一点。

这笔钱要付多少成本。

到哪一天结束。

我为了拿这个收益，到底接了什么东西。

最坏的时候，会发生什么。

这些以前经常混在一个 APY 里看。

拆开以后，至少心里更有数。

所以这几天看下来，如果最后只让我记一句 #TermMax ，我大概会记这个：

确定性可以买，但风险不会凭空消失。

#dusk $DUSK

Imagine you’re about to buy $5 million worth of assets.

Before the order is even filled, the entire market already knows you’re buying.

They know which side you’re on.

They know how urgent you are.

They can even roughly guess how much more you still haven’t filled yet.

At this point, is “complete on-chain transparency” still necessarily a good thing?

Recently, when I looked at Hedger for @Dusk , what interested me wasn’t ZK, and it wasn’t homomorphic encryption.

It was the obfuscated order books it mentioned.

My first reaction was:

Finally, someone is taking seriously the fact that large capital doesn’t want to reveal its cards early.

If retail users place orders for a few hundred or a few thousand dollars, transparency isn’t a big problem.

But institutions aren’t like that.

The order intent itself is information.

Whether you plan to buy or sell, how much liquidity you need, how long you’re willing to wait—once those are exposed early, others can build strategies around your needs.

In the end, you might not be “hacked.”

But your execution price will be worse than it would have been.

That’s why I increasingly feel:

Transparency may be information for retail users; for large players, sometimes it’s an execution cost.

Hedger doesn’t want to turn exchanges into a black box.

It’s more like it’s trying to hide intents and exposures that shouldn’t be made public in advance, while still preserving execution verification and regulated audits.

I can understand that direction.

But I’m not ready to claim it has solved the problem yet.

Because DuskEVM / Hedger is still Testnet for now, and in the official description of the obfuscated order books, deployment is still upcoming.

What truly matters is whether, after going live, this design sacrifices price discovery, matching efficiency, or liquidity.

So my stance on Hedger is simple for now:

Whether the direction is right—I can basically tell.

Next, we’ll wait for the market to tell us whether it’s actually useful.

I used to trade leverage, and the situation I hated most was this:

You finally get the direction right, but you get liquidated first.

So when I see a structure like @TermMax for the first time—pay the Premium upfront, with no traditional liquidation line—it does feel a bit easier.

But today, when I looked at those HYPE contracts expiring on August 21, I got stuck on another issue again.

Let’s say I think HYPE will go up.

And in the end, it really did.

But it only rose after the contract expired.

For this position, that still doesn’t help.

The direction was correct.

The timing was wrong.

So now, when I look at this kind of structure, I don’t just casually say, “No liquidation means it’s comfortable.”

It’s only that before, I was afraid the market would sweep me out first.

Now I have to guess one more thing:

Whether it even makes it in time.

The Premium is paid first, and the Maturity is already fixed.

No traditional liquidation line doesn’t mean time isn’t important.

Sometimes the hardest thing to predict isn’t whether it will go up or down.

It’s when.

#TermMax

#dusk $DUSK

Imagine your wallet suddenly receives a sum of money.

On-chain, other people don’t know who sent it, don’t know who it was sent to, and can’t see the amount.

Sounds like maximum privacy.

But if I’m the recipient, I find out that:

I myself don’t even know who made the payment.

That’s a bit troublesome.

What if I receive the money by mistake?

What if there’s an issue with the source?

If company finance asks me who paid for this amount, I reply, “Can’t find out”?

So over the past couple of days, while looking at Phoenix 2.0 with @Dusk , what I’m actually most interested in isn’t how much it can hide.

It’s that it doesn’t blind both sides of the transaction.

Phoenix can hide the sender, receiver, and amount from the outside, but the receiver is still able to verify the source of the funds.

If the money needs to be refunded, the design also considers refund originators.

This is somewhat different from how I previously understood “anonymous transactions.”

It’s not trying to:

Make sure nobody knows what happened.

More like:

Bystanders don’t need to know who paid me;

But as the recipient, I still need to know where this money came from.

And when there are audit or compliance requirements, you can use viewing keys / selective disclosure to handle visibility.

I think this is more like the real-world problems that finance would actually face.

After all, what a company is really afraid of isn’t “the two parties in a transaction knowing each other’s identities.”

What they fear is a transaction that was originally only meant to concern two people, but ends up becoming a permanent record that everyone in the world can look up.

So I really like the Phoenix 2.0 design:

Privacy isn’t about putting everyone in the dark.

If someone shouldn’t be watching, then not seeing is enough.

AERO, I watched this Vault for a while today.

In the end, I didn’t really remember the APY. Instead, I kept thinking about one thing:

Where did the extra money come from—who paid it?

@TermMax is actually quite interesting.

When stablecoins are waiting for opportunities, they don’t necessarily have to just sit there. You can first go earn some base yield in markets like Morpho.

Then the Put portion will also pay you a premium.

At first glance, it looks like “two streams of yield.”

But that second chunk of money isn’t free.

When you collect the Put premium, it’s effectively you agreeing to another condition:

If the expiration trigger happens, you might have to take AERO at the заранее agreed price.

Once you break it down like that, I’m actually less inclined to stare at the “total APY.”

The first part is more like: if the money isn’t being used yet, don’t let it sit idle.

The second part is: someone else pays so that you take over part of the price risk.

Both pieces of money look like “yield,” but they’re not coming from the same place at all.

So, in the future, when I see products like this, I’ll probably ask first:

Whose money am I earning?

Then I’ll ask:

What risk am I taking over for someone else?

After you figure those two questions out, that APY starts to feel much more trustworthy.

#TermMax

#dusk $DUSK @Dusk

When I first started researching Dusk’s architecture, I had a pretty straightforward question:

Why does Dusk need to come up with DuskDS, DuskEVM, and Hedger? Wouldn’t it be simpler to put everything into a single chain?

Later, after going through the documentation, I realized that these three names can actually be understood in three sentences.

DuskEVM: Where things run.

Solidity, EVM, and related application logic mainly execute here, so developers don’t have to learn a completely unfamiliar stack from scratch just to build on Dusk.

Hedger: Which things don’t need to be shown to everyone.

Financial data like balances, positions, and transaction amounts—when confidentiality is required—should be handled at this layer. It’s not that transactions are hidden outright; it’s that sensitive information shouldn’t be exposed to everyone.

DuskDS: Who ultimately has the final say.

Transaction data and state ultimately need to settle on DuskDS, which is responsible for the underlying settlement and data availability.

Once I broke it down like this, it felt much more reasonable.

Take a financial company as an example: you wouldn’t have the front-end trading system simultaneously handle permissions, databases, clearing, and all back-office work. Users see a product; underneath, different systems each do their own jobs.

Dusk works in a similar way.

Whether applications can run is one thing; how sensitive data is handled is another; and how settlement is ultimately performed is yet another.

Of course, DuskEVM is still in the testnet stage for now, so the paper architecture makes sense—but it doesn’t necessarily mean everything will run smoothly after mainnet goes live.

Still, at least now when I see “DuskEVM + Hedger + DuskDS,” I don’t feel like I’m just stacking three technical buzzwords.

They’re actually solving three different problems.

Today I saw the market for tokenized stock in @TermMax , and my first reaction wasn’t Fixed Rate—rather:

If stock assets are already on-chain, when you need money, why do you have to sell first?

For example, you hold tokenized NVDA.

If you need a quick amount of USDT, the simplest option is of course to sell.

But once you sell, the original stock price exposure disappears as well.

TermMax’s other route is:

Use this kind of on-chain stock asset as collateral to pull out stablecoin liquidity first.

In other words, the original on-chain stock exposure remains, and the financing gets done first.

At that moment, I actually understood better why TermMax has recently been moving toward RWA.

Because for assets you’re planning to hold for months—or even longer—the question isn’t only whether you can borrow money.

The other half is:

Over the coming months, how much of that financing will be spent on borrowing costs?

Fixed Rate fits here perfectly.

Of course, what’s fixed is the borrowing cost, not the asset price.

If the stock needs to fall, it will still fall, and the collateral risk won’t disappear just because the interest rate is fixed. Using leverage amplifies risk just the same.

But I think this direction is worth continuing to watch.

Previously, when people talked about RWA, the most common question was how to move stocks and government bonds onto the chain.

Now I’m more focused on the next step:

Putting RWA on-chain is only the first step. After it can be traded, can it be financed like a real asset?

#TermMax

Assume there are two USDC loans in front of me right now:

One is a floating-rate loan at 4%.

The other is a fixed-rate loan of @TermMax at 5%.

My first reaction is definitely: Why should I pay that extra 1%?

But if you switch the scenario, it becomes clear.

If I’m planning to run a 90-day leveraged strategy, the return I calculate is 10%. My borrowing cost is 4%, leaving 6% room in between.

Then on day 20, the market suddenly rushes for liquidity. The borrowing rate jumps from 4% to 8%.

The asset didn’t drop, and the strategy is still correct—but the originally calculated profit gets eaten up by the higher funding costs.

Looking back, what exactly is that extra 1% on the 5% fixed loan?

To me, it’s more like:

Paying for “certainty” in the funding costs over the next 90 days.

This is also where I began to understand #TermMax .

What it truly sells to borrowers isn’t just a Fixed Rate—it’s the ability for you to know, at the moment you open the position, exactly how much it will cost to borrow this money until maturity.

Of course, this doesn’t mean the risk disappears.

Collateral can still fall, leverage can still be liquidated, and the strategy can still lose.

TermMax locks in the borrowing cost, not the investment outcome.

So I wouldn’t simply say that “a fixed rate is always better than a floating rate.”

The real question should be:

When the market starts to swing violently, how much are you willing to pay to exchange for certainty in future funding costs?

That price—maybe that’s the real thing the Fixed Rate market is actually trading.

#dusk $DUSK

Recently, when I saw @Dusk keep emphasizing selective disclosure, my first reaction was:

If regulators can still see it in the end, then can this still be called Privacy?

Later I thought about it—I’d actually mixed up “privacy” with “nobody can ever see it.”

Just like my bank balance isn’t posted on the bank’s front door.

Your neighbors can’t see it, other customers can’t see it, and competitors can’t see it either.

But under legal and authorized conditions, the bank, auditors, or the regulatory system may still verify relevant information.

You wouldn’t say:

“My bank account has absolutely no privacy.”

The real difference is—

who has the right to view.

That’s also the simplest way I understand Dusk’s programmable privacy now.

It doesn’t aim to permanently hide all financial activity. Instead, it pursues privacy where needed, transparency where useful, and uses selective disclosure so the authorized party can review when required.

This may sound complicated for ordinary crypto transfers, but if, in the future, regulated assets like bonds, funds, and securities are truly moved on-chain at scale, I think this is a hurdle you can’t really bypass.

Because both extremes are impractical:

If everyone can see your balance, positions, and transaction relationships, institutions may not dare to use it;

If nobody can verify anything, then regulated finance becomes hard to establish.

So now I actually feel that:

The true opposite of financial privacy isn’t necessarily “regulation.”

It might be—

people who have nothing to do with it also having the right to access your information.

If Dusk can truly build these permission boundaries into on-chain financial workflows, then programmable privacy won’t just be a nice-sounding label.

#dusk $DUSK

Look @Dusk I’ve recently been talking about Tokenization, and there’s a line that made me rethink the “liquidity” of RWA.

Let’s assume you have an asset worth $1 million.

In the past, only one person could buy it.

Now you tokenize it, splitting it into 1 million parts, with each part costing just $1.

It sounds like the threshold drops from $1 million to $1, and liquidity should take off immediately, right?

Actually, it’s completely not the case.

Fractional ownership solves the issue of “whether you can afford to buy.”

Liquidity solves the issue of “when you want to sell, is there another person willing to take it.”

If you split an asset that nobody trades into 1 million pieces, you may end up with 1 million cheaper tokens—but still no one to buy them.

That’s also why I think Dusk’s recent point is so important.

A real on-chain financial market needs more than Tokenization: eligible investors, trading venues, payment rails, price discovery, and final settlement.

Only then does it become clearer to look at Dusk, NPEX, and the roadmap for Dusk Trade—the logic is much more straightforward than simply “moving RWA on-chain.”

What NPEX brings isn’t just a logo, but a regulated market and a real investor base. And what Dusk Trade aims to solve isn’t just asset presentation, but the full path—from investor eligibility, to trading, to payment coordination, all the way to settlement.

So at this point, I don’t really believe anymore:

“Fractionalization = Liquidity.”

Lowering the barrier is definitely valuable.

But what truly determines whether an RWA can form a market is whether, after you can buy it, you can also sell it smoothly.

Tokens can be cut infinitely small.

But buyers can’t.

#dusk $DUSK

RWA has been around for quite a while now. Yesterday, I suddenly asked myself a rather awkward question:

How much on-chain RWA have I truly bought?

The answer is painfully small.

It’s not because there aren’t assets on-chain.

Over the years, I’ve looked into tons of products related to bonds, funds, and stocks—but the moment I actually consider paying money, the issues immediately pop up:

Do I have the right to buy?

Where do I buy?

After I buy, how do money and assets get settled?

What rights does this Token actually represent?

If I want to exit later, who do I sell to?

After studying Dusk Trade (@Dusk ), I realized that in the past I kept treating the simplest step of RWA as the hardest one.

Tokenizing an asset is really only the beginning.

What Dusk Trade is trying to connect is the long chain of complications afterward:

asset discovery, investor onboarding and eligibility, wallets, trading, payment coordination—right up to final settlement.

It doesn’t sound as sexy as “moving trillions of assets on-chain,” but from the perspective of a real user who’s ready to put money down, I actually think these things matter more.

Because I don’t care how many protocols are running in the background.

I just want that, once I open a single entry point, I can confirm that I’m allowed to buy, the transaction truly completes, the asset truly belongs to me, and—most importantly—it can genuinely be sold at the end.

Why do traditional brokerages work so well?

Not because stocks have been digitized.

But because ordinary users can’t feel how many systems are working behind account opening, order matching, registration, payments, and settlement.

So my biggest expectation for Dusk Trade right now isn’t “adding more RWA.”

It’s that one day, when I want to buy on-chain bonds or funds, I won’t have to first learn how to be a half-blockchain engineer.

The real large-scale adoption of RWA might happen on the day users finally don’t have to care whether it’s RWA or not.

#dusk $DUSK

I’ve been into crypto for a while, and I used to take one thing for granted:

The more transparent a blockchain is, the safer it is.

Until I recently researched @Dusk , I realized that in a real financial market, that saying may only be half right.

Suppose you’re an institution.

How much money you have in your wallet is visible to the market.

What positions you’re building is visible to the market.

Who you’re trading with is visible to the market.

Even when funds start moving, your competitors can monitor it in real time.

So is that really an “advantage of transparency”?

For ordinary transfers, maybe it is.

But for funds, market makers, and corporate treasuries, this could easily become a kind of information leakage.

But going to the other extreme isn’t an option either.

If everything is completely hidden, how can regulators, auditors, and transaction verification be done?

So lately, I’ve been increasingly able to understand what Dusk has been emphasizing: not simple privacy, but:

privacy where needed, transparency where useful.

The rules and execution outcomes that should be public remain verifiable;

For sensitive data like balances, positions, and counterparties, confidentiality is preserved;

When real regulation or auditing is required, use selective disclosure.

That distinction is something I truly hadn’t thought about seriously before.

The first stage of crypto solved:

“Don’t trust me—verify for yourself.”

But if financial markets are really going to move on-chain at scale, the next stage may need to address:

“You can verify me, but that doesn’t mean you should see everything about me.”

I think that’s where programmable privacy is truly worth discussing.

Today when I got home, I saw an old friend (@Dusk ) had started releasing content again. The first time they got onto the Creators榜, they gave them a full 2000 U. Even if you don’t make the榜, as long as you write an article, you still get 30 U. I really miss the days when the economy was booming. Today I saw it and then observed a bit: #dusk

After looking into RWA before, the one thing I cared about most was: is there actually real-world collateral/assets behind it?

But when I recently researched Dusk Trade ($DUSK ), I realized I was asking that question too early.

Let’s assume that tomorrow there really is a bond or an ETF that gets moved onto the chain. Then what?

Can I buy it?
Who will confirm that I’m eligible to buy?
After the trade, when does the asset truly become mine?
Do payment and asset settlement happen at the same time?
And if later I want to sell, where do I go to find liquidity?

Unless these issues are solved, having a Token on-chain doesn’t mean much to ordinary investors.

That’s also what I find interesting about Dusk Trade.

It’s not just building another DEX for buying RWA. Instead, it aims to put tokenized financial assets like MMFs, ETFs, and bonds into a more complete trading environment—investor access, asset trading, payment coordination, and settlement as much as possible all happening on the same underlying infrastructure.

I used to think the competition in RWA was simply about who gets assets onto the chain first.

Now I’m increasingly thinking that putting assets on-chain is only the entry ticket—the real difficulty is bringing the “market” along with them.

After all, in real finance, issuing an asset is never the endpoint.

Being able for someone to buy, for someone else to sell, for identities and eligibility to be confirmed, and for ownership to truly transfer completely after a trade—only when all these pieces connect does it count as a market.

So going forward, when I look at Dusk Trade, I won’t focus first on how many assets it can list.

What I want to see is this: once the first real users go in, from account opening, to trading, to final settlement—can it really run as a complete closed loop?

If that chain can run through successfully, I think it’s worth paying attention to more than just adding a few more kinds of RWA.

#baby $BABY Over the past couple of days I’ve continued reviewing TBV materials, and I realized I had been putting the focus in the wrong place before.

A lot of people are discussing how BitVM3 has reduced costs and made verification faster—those are obviously good things. But what I care about more is: what exactly did it replace?

Previously I always thought the most important part of decentralization is that “anyone can supervise.” Now, in order to bring the cost of controversies down, TBV’s challenge mechanism is more oriented toward using pre-assigned challengers to carry out verification. Efficiency has indeed improved, but the way supervision works has changed as well.

I’m not saying this is bad. In real life, many protocols make trade-offs between efficiency and openness. But as an ordinary user, I want to know this: if in the future the scale of funds keeps growing, will these challengers be sufficiently diversified? And when nodes go offline or during extreme market conditions, will they still be able to respond in time?

I’m increasingly feeling that when evaluating a protocol, you can’t just focus on TPS, Gas, or return rates.

What ultimately determines whether it can run for a long time are often those details that nobody talks about day to day—who is supervising, whether supervision is redundant, and whether there’s a safety net if something goes wrong.

So moving forward I’ll continue to keep an eye on @BabylonLabs_io . Not only to see the performance improvements brought by BitVM3, but also to watch the challenger ecosystem, governance transparency, and whether the safety boundaries are continuously refined.

Technical breakthroughs are worth期待, but I think whether the security model can stand up to the test of time matters more than short-term positives.

#baby $BABY

While organizing cold wallets yesterday, I came across that BTC UTXO string that hadn’t moved in years.

I’ve always thought the biggest contradiction in Bitcoin isn’t security, but rather that if you simply hold without moving, there’s no cash flow. Recently I studied Babylon’s TBV testnet and found that its redemption mechanism leaves a dedicated three-day challenge period. At first I thought it was too slow, but later I realized it’s buying time for security.

Because the entire BTC remains locked inside a Taproot script—there’s no cross-chain bridge and no wrapped assets. During redemption, a Vault Provider must submit a proof. If someone tries to forge the proof, challengers can still block the transaction within those three days. Without this window, an attacker could potentially borrow stablecoins first and then run away before the BTC is actually unlocked.

But what really makes me hesitate isn’t those three days.

Currently, the challenge process is handled by only a small subset of designated nodes. Ordinary users almost never deploy a challenge program themselves. That means that at critical moments, you still have to rely on those challengers being online and working properly. More realistically, interest on the loan won’t stop while waiting for redemption. If the market swings violently, the position might get liquidated before the BTC even comes back.

I do agree with Babylon’s direction of not bridging and not wrapping. That’s indeed more restrained than many BTCFi approaches. But once the protocol is truly deployed, I think the key to the user experience will be whether challengers can be sufficiently distributed and whether their response can be fast enough.

Higher returns can attract users. What truly keeps users is the set of details that still works properly under extreme market conditions.

@BabylonLabs_io #baby

In 2018, I researched a project with a very strong technical reputation. The team background was almost beyond reproach, yet after the mainnet went live, problems surfaced quickly. There were no vulnerabilities in the code itself; the real issue was the incentive mechanism—verification nodes couldn’t cover their operational costs with the rewards they earned, so they began to gradually exit, and the network’s security declined as well. That experience made me realize that, in many cases, protocols ultimately lose not because of technology, but because of the economic model.

Recently, as I’ve been reexamining Babylon’s TBV mechanism, I’ve kept focusing on this same point. If a node wants to participate in the challenge process, it must stay reliably online—and staying reliably online requires continuous investment in things like servers, bandwidth, operations, and monitoring. If these costs steadily approach the staking rewards, then over the long term, some nodes will naturally choose to leave.

For any PoS network, whether nodes are willing to continue operating ultimately comes down to three things: entry barriers, the risk of penalties, and return on investment. These must leave enough room for profit; otherwise, the node ecosystem will be difficult to sustain with long-term vitality. At this stage, Babylon describes the mechanism design more than it provides publicly available data on how rewards would be calculated under different market conditions, the cost model, or the node break-even points.

There’s another aspect worth monitoring continuously. If, in the future, BABY staking yields remain higher over the long run than other BTCFi reward channels, large amounts of capital may further concentrate among a few major nodes in pursuit of higher efficiency—this is a challenge many PoS networks have faced in their early stages as well.

These discussions are not meant to deny Babylon. Rather, they reflect the view that what truly determines a protocol’s long-term competitiveness is not just whether the technical方案 is advanced, but whether the economic incentives can stand up to real-market conditions. Going forward, I will focus on the number of nodes, node distribution, and changes in yield to judge whether this model truly works in practice.

@BabylonLabs_io $BABY #baby

Recently, while discussing Babylon’s BTC redemption design with friends, one question made me reread the documentation: among the three redemption methods, who really determines whether you can actually redeem?

The official options are Unbonding, Emergency Redemption, and Instant Redemption. At first glance, it looks like users have different liquidity choices. But on closer inspection, those options aren’t entirely at the users’ discretion.

Take Instant Redemption as an example: the exchange price isn’t determined solely by market execution—it’s also influenced by the protocol’s pricing mechanism. Emergency Redemption also doesn’t automatically trigger just because some objective on-chain condition is met; it’s governed by governance parameters. In other words, users have different redemption entry points, but when those entries open and what the costs are are not fully under the users’ control.

From an asset-safety perspective, BTC is still locked in Taproot scripts and UTXOs, and the custody model hasn’t changed. But from a liquidity perspective, what truly affects the experience is the mechanism responsible for interpreting state and calculating parameters.

For ordinary users, the impact might simply be paying a few extra percentage points at redemption. For institutions that manage liquidity, however, that means redemption costs and settlement times come with uncertainty, which can affect capital scheduling.

So I won’t assume the liquidity risk is solved just because there are three redemption options. I care more about several real metrics after the mainnet goes live:

* Whether Instant Redemption’s actual slippage gradually stabilizes;
* Exactly how many block confirmations Emergency Redemption requires from trigger to BTC being unlocked;
* When the community modifies key parameters, whether there is a sufficiently long period for public discussion and an opposition window.

Only after these data points are validated through a full bull-and-bear cycle will Babylon have a chance to upgrade Bitcoin Staking from “earning while long-term locked” to a foundational infrastructure that is “rule-transparent and liquidity-predictable.”

If it were you, how would you choose?

A. Accept a longer unlocking period in pursuit of higher returns.
B. Pay a certain cost for liquidity and choose instant redemption.
C. Observe the real redemption data after mainnet launch first, then decide whether to participate.

@BabylonLabs_io $BABY #BABY