老李说财经

#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.”

#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.

#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.

#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.

#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

Someone once asked me why I keep holding BTC and don’t participate in DeFi. My answer is simple: it’s not that I don’t want to—it’s that I’m not comfortable.

Many proposals require cross-chain transfers, wrapping, or handing custody over to a third party. The returns might indeed be higher, but the more steps there are, the more I worry.

Recently I looked into Babylon’s Trustless Bitcoin Vault (TBV), and it made me feel like it addresses a more realistic question: can we add as little new trust as possible?

The official position has consistently emphasized No Bridge, No Wrapped BTC, and No Custodian—not because these solutions have zero value, but because they want BTC to be able to participate in applications like lending while preserving its native security properties. (Babylon Labs documentation)

I think this mindset matches the habits of many Bitcoin holders.

What people truly care about isn’t just the return rate, but whether their assets can still be protected in the ways they’re familiar with.

If, in the future, BTCFi can get more people to join because it feels “safer,” rather than only because “the returns are higher,” then I believe that would be real progress.

@BabylonLabs_io $BABY #baby

I used to think that people don’t put BTC into DeFi because everyone is too conservative.

Later I realized that many long-term Bitcoin holders actually aren’t unwilling to participate; they just aren’t willing to hand their assets over to someone else in order to do so.

So when I saw Babylon continuously emphasizing Trustless Bitcoin Vaults, my first reaction wasn’t “yet another new product,” but rather that finally someone has started discussing the real issues Bitcoin users truly care about.

Returns can be higher or lower, but peace of mind can’t be built with rewards.

If, in the future, we want to attract more BTC holders into BTCFi, I think the most important thing isn’t launching more game mechanics—it’s reducing the places where users are forced to trust third parties as much as possible.

Whether TBV can become the final answer still needs to be proven over time, but at least it’s discussing principles that the Bitcoin community has always cared about a great deal.

A truly long-term ecosystem shouldn’t be built on “trusting others,” but on “needing to trust others as little as possible.”

@BabylonLabs_io #baby $BABY

People have always said that BTC is the largest on-chain asset, but the proportion of users truly participating in DeFi has remained low. I used to think it was because users were too conservative, but more and more I feel the problem may lie in the tools themselves.

Many solutions require cross-chain transfers, wrapping, or handing BTC over to third parties for management. For those who hold BTC long term, this step is actually hard to take—not because of lack of potential returns, but because the biggest concern is security.

Recently, after learning about Babylon’s Trustless Bitcoin Vaults (TBV), I feel it points to a direction worth paying attention to: minimizing reliance on third parties, allowing BTC to participate in more applications while preserving the original security principles.

Of course, whether TBV can become the key infrastructure for future BTCFi still needs to be validated over time. But at least it addresses real industry problems, rather than simply adding a new gimmick.

What I’d rather see in the future is that more and more users choose to use TBV because of security, not just because of high returns for a brief period. The ecosystems that can truly last must be built on long-term trust.

@BabylonLabs_io $BABY #baby

Recently, many friends have asked me: what is your biggest expectation for $BABY ?

My answer is not short-term price growth, but whether it can truly connect the BTCFi ecosystem.

Many projects can run campaigns and give out rewards, but what can truly retain users are still those that create long-term demand—foundational infrastructure.

If, in the future, more and more network choices rely on the Bitcoin Security provided by Babylon, then BTC will no longer be just an asset to hold—it will become an important part of the entire ecosystem.

I think this is also the biggest difference between Babylon and many other projects. It aims to build long-term capability, not short-term hype.

Market sentiment will change, but real demand won’t.

So rather than watching the price every day, I’d rather continue to observe Babylon’s ecosystem building and progress in real-world applications.

@BabylonLabs_io $BABY #Baby

I’ve found that when many people look at a project, their first reaction is: “How high are the returns?”

But for Babylon, I think what’s more worth considering is: if there weren’t huge incentives, would people still keep using it?

Truly excellent infrastructure doesn’t constantly rely on subsidies—it exists because it solves real problems.

If developers need Bitcoin’s security capabilities, and users need a more reliable BTCFi experience, then Babylon’s value comes from genuine demand, not short-term campaigns.

So I’m not just fixated on APR, and I’m not watching the coin price every day.

What I care about more is whether the ecosystem has gained new partnerships, whether new applications have been integrated, and whether more developers are willing to build products around Babylon.

In the long run, demand matters more than returns, and usage matters more than hype.

@BabylonLabs_io #BABY $BABY