0xBac

#dusk $DUSK @Dusk I’m revisiting Dusk tokenomics because I want to understand a very simple question:

If DUSK is used to pay gas, then how exactly does real network activity affect rewards?

The answer is more interesting than I thought.

Dusk does not separate transaction fees from block rewards.

Each block receives rewards from two sources: newly issued DUSK + all transaction fees of the block. The latter portion of the rewards is then distributed according to the protocol’s mechanism.

The block generator gets 70%, plus up to an additional 10% based on credits in the certificate.

And here is the part that made me pause:

Any undistributed bonus portion will be burned.

So, seeing DUSK being burned does not necessarily mean we can conclude that the network has more economic activity.

The burn here could reflect the bonus reward portion not being fully distributed—not a direct measure of blockchain usage needs.

I think this is a fairly important distinction.

If you want to assess Dusk adoption, looking only at the burn rate could lead to a wrong conclusion.

I would want to look at all of the following at the same time:

gas usage → transaction fees → settlement activity → application activity → reward distribution → net issuance.

Especially since Dusk’s emission is designed to be cut in half every 4 years, from 250.48M DUSK in the first 4 years down to about 0.98M in years 32–36.

As the subsidy declines, the long-term question becomes clearer:

Is actual activity on-chain large enough for fees to become increasingly important in the network’s economics?

I don’t have an answer yet.

But I think this is a metric worth tracking more than simply looking at one number: “DUSK burned”.

$BTC $DEBIT

#dusk $DUSK @Dusk The more I research Dusk, the more I find an interesting paradox:

Finance needs privacy, but institutions can’t operate in a system where nobody can verify anything.

If a public blockchain exposes every account balance, transaction, and the positions of every participant, it may be too transparent for some market workflows.

But if everything is completely hidden, regulators, auditors, or issuers may lack the evidence they need.

Dusk is trying to solve the gap between these two.

Phoenix enables shielded transfers using zero-knowledge proofs without publicly revealing the amount being transferred or any information related to the note. When audits or regulatory disclosures are required, viewing keys can be used to reveal information in a controlled manner.

And Citadel goes one step further.

Instead of putting all identity information on-chain, users can prove they possess a valid credential without disclosing the exact credential or the entire personal data behind it.

I like how these two things come together.

Because regulated finance usually doesn’t ask:

“How do we make sure nobody knows anything?”

It asks:

“How do we make sure only the people who need to know know exactly what they need?”

That’s a very big difference.

If tokenized securities truly want to enter regulated markets, access control, eligibility, privacy, disclosure, and settlement must all work together. Dusk is building infrastructure in exactly that workflow direction.

I haven’t yet thought enough to conclude that Dusk will win.

But it raises an observable question:

Will privacy with control be the most appropriate form of privacy for the next generation of onchain finance?

There’s a question I find more interesting than “how fast is ZK”:

Can privacy on the blockchain truly become useful if the computational cost is still too high?

That’s why I started paying attention to the cryptography behind Dusk.

Zero-knowledge proofs are powerful because they allow a network to verify that something is true without disclosing all the original data. But that power comes with a price too: the process of generating and verifying proofs can become a significant part of the workload.

Dusk has researched this issue at the level of cryptographic primitives, including PlonKup — a work that combines Plonk with plookup to improve how checks are handled inside the proof system. PlonKup is currently listed by Dusk in its research papers group.

I like this because it shows that privacy infrastructure is not just a marketing story like “we have ZK.”

Behind a confidential transaction lies an entire cryptography stack that must be efficient enough for the blockchain to use it in real-world practice.

And this is also where I think Dusk has a tough problem.

Financial applications need privacy, but privacy can’t be traded off for an experience that’s too slow or infrastructure that’s too heavy.

On the other hand, optimizing proof generation can’t only focus on the speed of the end user; the network still has to maintain stable verification and operation.

So what I want to track at @Dusk is not just how many additional privacy features they have.

But rather:

Can they turn cryptography technologies that are inherently very complex into practical infrastructure for regulated finance?
If they can, then that’s what would be genuinely noteworthy.

#dusk $DUSK

I used to think EVM compatibility was mainly a story to attract developers.

With Solidity, familiar tooling, familiar wallets → it’s easier for developers to build.

But when I look at Dusk, I see that EVM also has another role.

Dusk is separating execution from settlement.

DuskEVM provides an EVM-compatible environment for Solidity and the familiar Ethereum tools, while DuskDS handles consensus, settlement, and data availability. In parallel, DuskVM allows building Rust/WASM contracts directly on Dusk L1 when an application needs native access to transaction models, privacy, or ZK capabilities.

What’s interesting here is that developers don’t necessarily have to choose between: “EVM or blockchain native.”

They have two paths depending on the needs of the application.

If you need the ecosystem and familiar tooling → DuskEVM.

If you need deeper control at L1 → DuskVM.

And underneath, there’s still the same settlement foundation.

I think this is a noteworthy architectural direction, especially when Dusk wants to serve financial applications—where developer experience, privacy, and settlement guarantees all matter, but don’t necessarily have to be solved with the same execution environment.

Dusk doesn’t need to prove that this architecture is perfect yet.

What’s more worth watching is how real-world applications will leverage these two execution paths.

#dusk @Dusk $DUSK

#dusk @Dusk $DUSK

I used to think privacy on blockchain was simple: just don’t let other people see the transactions.

But the way Dusk designs privacy makes me think the issue is actually much more complex.

In finance, not every piece of data needs to be public.

An investor may not want their entire balance and transaction history exposed to the market. But an issuer, auditor, or regulator may still need to verify certain information.

Dusk approaches this problem by combining shielded transfers, zero-knowledge proofs, and selective disclosure.

Notably, Dusk has two transaction models:

Moonlight for public flows, where balances and transactions can be observed.

Phoenix for shielded transactions, where information about amounts and participating parties is protected, while viewing keys can be used when disclosure is needed for audit or compliance purposes.

This changed how I view privacy.

Perhaps the right question is not:

“Should blockchain be transparent or private?”
But rather:

“What information should be visible, to whom, and under what circumstances?”

Especially with regulated assets, the ability to control disclosure can be just as important as data security itself.

That is one of the angles of Dusk that I find worth following even more than the story of “fast blockchain”.

I used to think that Vaults in DeFi are simply a place to pool capital and automatically go find yield.

But when I look closely at TermMax’s Vault design, I see the story is a bit more complex.

Here, a Vault can gather capital from multiple depositors, and then the Curator is responsible for allocating that capital to suitable markets. More importantly, the Curator doesn’t have full authority to change everything instantly.

TermMax uses a timelock mechanism for many critical changes. The Guardian can intervene during this waiting period, while the market whitelist and capacity limits add further layers of control.

I quite like this approach because when you deposit into a managed Vault, the issue isn’t just “how much yield does the strategy generate.”

The more important questions are:

Who manages the capital?

Where is the capital allocated?

Can the parameters be changed easily?

And when risk changes occur, do users have time to react?

That’s also why I think TermMax’s Vault is worth studying from an infrastructure perspective, rather than just viewing it as a yield product.

#termmax @TermMax

There’s one thing I started to notice when learning about Vault @TermMax : users can see an APY, but they don’t see the full story behind that number.

Depositing into the Vault is very straightforward on the outside.

But behind the scenes, the Curator has to make a whole series of decisions: which market the capital should go into, how long the term should be, what level of risk to accept, and how to allocate liquidity.

Especially in fixed-rate lending, time also becomes part of the equation.

A market with a higher yield isn’t necessarily better if the liquidity is low or the maturity doesn’t match the need to withdraw funds.

This changed the way I think about “passive yield”.

Passive doesn’t mean there are no decisions.

It only means that most of the decisions have been moved down into another layer of management.

And that’s also where I think Vault will truly be put to the test when the market becomes volatile.

When everything is normal, almost any strategy seems reasonable.

But when liquidity tightens, maturities don’t align, and many people want to withdraw funds at the same time—that’s when you find out how well the Curator allocated the capital.

So instead of only asking:

“How much APY does this Vault have?”

I’ll ask:

“Where does that yield come from, where is the capital currently sitting, and what risks are being traded for to achieve that level of yield?”

That’s the interesting part of #TermMax .

$BNB

The RWA narrative often starts with a very attractive number:

“How much real-world value has been tokenized?”

But I've started thinking that number can be misleading.

Because a token existing onchain doesn't automatically mean the underlying financial market has moved onchain.

A tokenized fund still needs investor onboarding.

A security may have transfer restrictions.

An institution may need to verify eligibility.

A custodian needs to know where the asset is.

Cash needs to move when ownership changes.

And regulators may need access to specific information without receiving everyone's complete financial history.

This is the part of @Dusk that I find more interesting than the simple “RWA onchain” narrative.

Dusk Trade is being designed around the broader lifecycle of tokenized financial assets rather than treating the token itself as the finished product.

And programmable privacy adds another layer to the problem.

Traditional finance doesn't require everything to be public.

It requires the right information to be available to the right participant.

That distinction matters.

An investor might want privacy.

A regulated venue needs verification.

An auditor may need evidence.

A regulator may need selective access.

These requirements sound contradictory until privacy becomes something that can be programmed into the workflow.

That's why I'm starting to view Dusk less as another chain trying to tokenize assets and more as an experiment in rebuilding parts of regulated financial infrastructure onchain.

Whether institutions will actually find the resulting system simple enough to use is still an open question.

And honestly, that's probably the most important question left.

#dusk $DUSK

There’s one thing I’ve always checked before choosing a Merchant on P2P, but I almost used to ignore it: the recent feedback.

I used to have a habit of looking very quickly:

Good price ✅
High Completion Rate ✅
Merchant badge ✅

→ Place the order.

Only later did I realize that a great-looking profile doesn’t necessarily tell the full story.

If a Merchant has thousands of transactions, but in the recent feedback the same issue keeps showing up—e.g., slow handling, poor responses, or taking a long time to complete the transaction—then I’ll spend a few more minutes reviewing.

This doesn’t mean I conclude that Merchant has a problem.

A single piece of feedback could come from a special situation.

But if the same kind of complaint repeats many times, that’s information I don’t want to overlook.

Now, before placing a large order, I usually look at:

🔎 Completion Rate
📊 Number of transactions
⭐️ Recent feedback
📋 Promotional terms
⚠️ Issues that many people mention

Especially, I no longer have the mindset:

“Looks like a great rate—let’s try once and it’ll probably be fine.”

There are many ads to choose from in P2P.

If a Merchant makes me think too much before I click “Order,” I’d rather choose another option with clearer terms.

A good price is only worth it when the entire trading experience matches too.

For me, a few minutes reading feedback before transacting is still much cheaper than spending a few hours dealing with an order that doesn’t go as expected.

#binancep2pantoan @Binance Vietnam $BTC

The “1 billion TMX” headline sounds simple.

But the number I keep looking at is much smaller: the initial circulating supply.

According to TermMax’s token documentation, $TMX has a fixed maximum supply of 1 billion tokens, while the initial circulation is planned at around 200 million.

That changes the way I think about the tokenomics.

Maximum supply tells you how large the pie can eventually become.

Float tells you how much of that pie can actually interact with the market today.

Then comes the harder question: how quickly does that float expand?

Investors, team members and other long-term allocations unlock over time. None of that automatically means selling pressure — vesting is normal for crypto projects.

But it creates a simple equation I want to watch after TGE:

Does real protocol growth absorb new circulating supply faster than tokens become liquid?

If TermMax keeps growing its lending markets, Vault activity and user base, increasing supply can potentially be absorbed by genuine demand.

If demand doesn't grow fast enough, the same unlock schedule tells a very different story.

That's why I don't judge $TMX by “1B supply”.

I care much more about:

→ Initial float
→ Unlock velocity
→ Actual protocol usage
→ Staking/governance demand
→ And how much liquidity the market can realistically absorb

The headline is 1 billion.

The real story is what becomes liquid, when it becomes liquid, and who actually wants to buy it.

#termmax @TermMax

I went down another RWA rabbit hole last night and ended up somewhere I didn't expect.

Everyone talks about tokenization like the difficult part is creating the token.

Put a bond onchain.

Put an ETF onchain.

Put a money market fund onchain.

Done.

But then I started following what happens after the token exists.

Who is actually allowed to buy it?

How does the platform know?

What happens when the asset changes hands?

Who settles the payment?

Can it move between applications?

And what happens when a regulator asks to see evidence of a particular transaction six months later?

Suddenly, “put it onchain” doesn't sound quite so simple.

This is where @Dusk started making more sense to me.

Dusk Trade isn't being positioned as just another place to swap tokens. The idea is much closer to building an application layer for regulated financial assets, with things like investor eligibility, trading and settlement becoming part of the workflow.

And then there's NPEX.

That's the detail I keep coming back to.

Instead of assuming traditional financial infrastructure disappears the moment blockchain arrives, Dusk is working around an existing regulated market framework.

That feels much more realistic to me.

TradFi probably isn't going to wake up one morning and say:

“Great, let's throw away every compliance process we've built.”

The more likely future is a hybrid one.

Blockchain handles settlement, programmability and composability.

Regulated institutions handle the parts that still need legal and market oversight.

Privacy sits between them so sensitive information doesn't become public by default.

That's a much less flashy story than “RWA revolution.”

But honestly, I think it's the more interesting one.

Because if tokenized assets ever become a serious financial market, the infrastructure underneath them has to work when the hype disappears.

That's the test I'm watching with Dusk.

#dusk $DUSK $BTW

If you make a mistake, redo it—don’t stubbornly try to fix the wrong and keep DCA like this. When the capital runs out, you’ll get burned.

Sell USDT on P2P, but when the buyer asks for “additional verification” using unrelated information—I stop right away.

Once, when I was selling crypto, the buyer messaged me asking me to provide some extra personal information to “verify.”

They explained it pretty reasonably, and even said that if I sent it quickly, the Order would be processed faster.

If someone’s new, I think it’s very easy to be swayed by emotion:
“Just send it—it's only a few bits of information.”

But I don’t do that.

I go back to check the Order and wonder:

Is this information truly necessary to complete the transaction?

If a new request appears but has nothing to do with the Order’s actual conditions, I don’t want to provide more personal data just because the other party asks.

I keep the entire exchange on Binance P2P, and if the two sides can’t continue under the agreed transaction terms, I let the platform handle it instead of settling privately.

Binance says P2P users must complete identity verification before trading, and the platform also has an Appeal mechanism when disputes arise.

For me, what matters is distinguishing:

Identity verification according to the platform’s process
and
a stranger asking me to send additional personal data through chat.

Those are completely different things.

From then on, I added another rule for running P2P:

🔴 Don’t provide unnecessary personal data just because a counterparty requests it.

🟡 If the transaction conditions change unexpectedly → stop and check.

🟢 If it can’t be resolved → keep the Order, keep the chat, and use the Appeal process.

Don’t trade personal data for something that only takes a few minutes to deal with on an Order—it could matter for years.

#binancep2pantoan @Binance Vietnam $BNB

Most people look at a DeFi lending protocol and immediately ask one question:

“What APY can I get?”

I think that's often the wrong starting point.

With @TermMax , the more interesting question is how the market itself is constructed.

TermMax doesn't treat fixed-rate liquidity as a simple pool where capital sits and waits. Its Range Order AMM allows curators and order makers to define pricing curves and target rate ranges, effectively making liquidity more intentional.

That matters because fixed-rate markets have a different problem from ordinary AMMs.

You don't just need liquidity.

You need liquidity at the right maturity, the right rate and the right point on the pricing curve.

Capital sitting somewhere in the protocol doesn't automatically mean it's useful capital.

TermMax's approach tries to make that liquidity more efficient through mechanisms such as Range Orders, Atomic Orders and idle-fund deployment into other lending protocols.

But there's an important trade-off.

More sophisticated liquidity management also means more parameters, more assumptions and more things users need to understand.

So when I look at a TermMax market, I don't just look at the headline APY anymore.

I want to know:

Who is providing the liquidity?
Where is the pricing curve?
What happens if I need to exit early?
And who absorbs the risk when market conditions change?

That's where fixed-rate DeFi becomes much more interesting than simply “earning a fixed yield.”

#termmax $CYS $ACE

I used to think the biggest challenge for RWAs was simply getting traditional assets onto a blockchain.

Then I started thinking about what happens once the asset is there.

A tokenized security still needs reliable market data.

It may need to interact with applications on other networks.

It needs controlled transfers, compliance checks and eventually a functioning secondary market.

So putting an asset onchain is really only the beginning.

This is one Lation alone.

I don't think partnerships automatically prove adoption will if RWAs are eventually going to become a real part of onchain markets, interoperability, data, compliance and privacy will all have to work together.
That's the experiment I'm watching with Dusk.

#dusk $DUSK @Dusk $VELVET $BEAT

There’s something I started paying more attention to after trading P2P with a large amount: the counterparty’s processing ability.

Previously, I would usually sort ads by price and then choose the most suitable option.

But when the amount increased, I realized that price is only part of the equation.

A good order must also have:

🔎 A clearly defined trading history of the counterparty
📊 A stable completion rate
⏱️ Appropriate response capability
💰 Order limits that sufficiently meet your needs

For example, I needed to sell a large amount, but the advertisement had a low limit. Instead of trying to “work around” the limit or make a separate private arrangement, I split my needs into multiple orders that fit the conditions available.

This also helps me manage cash flow more proactively.

I’m no longer thinking:

“How to sell everything as fast as possible?”

Instead I focus on:

“How to complete this conversion in the most controllable way?”

That’s a pretty big difference after using P2P for a while.

When the amount goes up, speed is no longer the only criterion.

The ability to control each order, each payment, and each step in the process is what I care about more.

#binancep2pantoan @Binance Vietnam #creatorpad $PRL $BTC

What if the next stage of DeFi isn't about creating more ways to trade, but about making capital more predictable?

That question is what makes @TermMax interesting to me.

A large part of DeFi today is built around floating rates, perpetual positions and constantly changing market conditions. That's powerful, but it can also make capital planning difficult. TermMax is taking a different route by building markets around defined terms and fixed rates, while connecting lending, borrowing, vaults and structured products within the same ecosystem.

The interesting part is how broad that infrastructure becomes: Term Markets for fixed-rate lending, ERC-4626 vaults for managed liquidity, one-click leverage, and Alpha products such as Long/Short and Dual Investment.

Even more interesting is the direction toward RWA collateral and multi-chain liquidity.

If DeFi wants to attract more sophisticated capital, predictability may become just as important as yield.

That's the part of #TermMax I'm watching closely.

One thing I keep coming back to when researching @Dusk is that regulated finance doesn't necessarily need more transparency.
It needs better-controlled transparency.
Imagine a tokenized bond being traded onchain.

The transaction may need to be verified, settlement needs to be deterministic, and regulators may need access to specific information.

But does every market participant need to see the investor's entire position, trading history or sensitive financial details?

That is where Dusk's programmable privacy approach makes sense to me.

Instead of choosing between “everything public” and “everything private,” the goal is to make information available according to who is authorized to see it.

This becomes especially relevant for Dusk Trade and its focus on tokenized financial assets such as bonds, ETFs and MMFs.

The interesting challenge isn't just putting these assets onchain.

It is creating an environment where institutions can actually use them without turning every financial activity into public information.

I think that distinction could become increasingly important as RWAs move from experiments toward real financial infrastructure.

#dusk $DUSK @Dusk $ACE $BTC

There was a time when I used P2P like a “swap crypto for cash” button whenever I needed cash. Later on, I realized that I was trading purely based on emotion.

When the market fluctuates → sell.

When the USDT price looks good → buy.

When I need money urgently → open P2P right away.

Every decision was made based on whatever I needed in the next few minutes.

Later, I started separating the two things:

My financial needs, and my P2P trading decisions.

If I need VND, I determine in advance how much I truly need instead of selling more than necessary just because the price seems stable.

If I need to buy crypto, I also don’t try to buy everything just because the market had a single bout of volatility.

This helps me avoid getting into situations like:
“Instead of just selling 300 USDT, I ended up selling 1,000 USDT.”

P2P can make asset conversion very convenient, but that convenience sometimes makes me forget that every time I press Buy/Sell, it’s still a financial decision.

After some time, I developed a fairly simple rule:
Determine the amount I need to trade first, then open P2P to find a suitable Order.

Don’t let the price chart decide how much I will trade.

For me, good P2P trading isn’t only about trading safely.

It’s also trading in such a way that after everything is completed, I still feel my decision was reasonable.

#binancep2pantoan @Binance Vietnam #creatorpad $BNB $PORTAL

I used to think the biggest advantage of bringing financial applications to an EVM-compatible chain was simply developer familiarity.

Solidity, existing tooling, familiar infrastructure — remove as much friction as possible and developers can start building.

Then I looked deeper into DuskEVM and Hedger.

What caught my attention is that privacy isn't being treated as a separate feature added on top. Hedger is designed around homomorphic encryption and zero-knowledge proofs to support confidential EVM workflows.

That creates a much more interesting question.

How do you keep financial data private while still allowing the right people to verify what happened?

For a normal application, hiding data might be enough.

For regulated finance, it isn't.

An institution may need to prove that a transaction satisfied certain conditions without exposing every piece of information behind that transaction.

A regulator may need to review specific facts without gaining unrestricted access to an entire financial history.

That is where selective disclosure becomes important.

So I don't see DuskEVM simply as “another EVM chain.”

The more interesting experiment is whether an EVM environment can support financial workflows where privacy, verification and compliance are designed to coexist.

The architecture sounds compelling on paper.

But the real test will be when DuskEVM and Hedger have to handle actual applications, real users and real financial activity.

That is the part I'm most curious to see.

#dusk $DUSK @Dusk $AKE #creatorpad