Anna-汤圆

If after financial assets are put on-chain, everyone can see them, would you still buy RWA?

After joining this Binance Creator program, I recently went back to read Dusk’s whitepaper and technical architecture seriously again—and I actually find the most interesting part is not the three words “privacy chain.”

Instead, it doesn’t understand privacy as “hiding everything.”

Dusk’s design is very realistic: Moonlight handles public trading, while Phoenix handles private trading. Phoenix uses ZK proofs to show that a transaction is valid, but it doesn’t lay out sensitive information directly to everyone—such as the amounts or the transaction counterparties. And if regulators, auditors, or specific institutions need it, selective disclosure is still possible through a viewing key.

This is actually very much like the real financial world.

Banks won’t post your account balance on the street, but they also can’t refuse to be checked by regulators.

So I think what Dusk truly wants to solve isn’t “how to make blockchains more anonymous,” but a more practical problem:

How can assets be put on-chain with both privacy and compliance?

And that’s probably the hurdle RWA can’t really bypass when it comes to being implemented.

If it were you, which would you bet on more?

#dusk $DUSK @Dusk

I recently went through Dusk’s technical documentation, and there’s a detail I can’t stop thinking about:
In Rusk’s reference implementation, why is it entirely built around Rust?
When many people see Rust, their first reaction is “high performance” and “memory safety.”
But I suspect the real priority for Dusk may not be those two words themselves.
Because Rusk isn’t just a regular application—it runs consensus, cryptography, and concurrency logic all at once.
What do these things fear the most?
Not being slow, but a basic memory error that ultimately turns into a system-wide security issue.
Rust’s Ownership and the Borrow Checker can catch a large class of memory-safety vulnerabilities at compile time.
But note this:
Memory safety ≠ cryptographic security.
Rust won’t prove your algorithms are necessarily correct, and it won’t automatically eliminate logical flaws in your cryptographic implementations.
What it truly provides is a deeper layer of safety guardrails:
at least keeping developers from falling into an entire category of pitfalls.
I find this especially interesting for Dusk.
Because what it wants to build isn’t just a chain that looks “secure,” but one tailored for financial use cases—bringing privacy, compliance, and on-chain execution together.
In that context, whether the code itself can be audited, whether dependencies can be traced, and whether the underlying implementation can be maintained long-term—all end up becoming part of the product.
So now I’m increasingly convinced that:
For Dusk, Rust isn’t just a technical aesthetic—it’s a security strategy.
Of course, Rust isn’t an invincible golden ticket.
Whether Rusk is secure is ultimately determined by the code, cryptographic design, audits, and real-world execution.
But at least from an architectural perspective, Dusk is taking a path I personally agree with:
eliminate problems as much as possible at compile time—before they ever make it to runtime.
If you’re developing a financial system, which would you care about more?
#dusk $DUSK @Dusk

I’ve been looking at TermMax V2 recently, and there’s a feeling that’s becoming more and more obvious:

It may no longer look much like a traditional Lending Protocol.
In DeFi, when I was looking for fixed-rate yields, the most annoying part wasn’t that I couldn’t borrow—it was that I had to find things myself. @TermMax
What interest rate is available in this market?
What about on another chain?
Are Curator’s order values worth it?
Do Limit Orders offer a better price?
Information is scattered across different markets, and in the end the user becomes an “artificial router.”
What TermMax V2 is doing, I think, is precisely addressing this pain point.
It unifies different orders—Curator Range Orders, Limit Orders, and so on—into the execution layer, so users don’t see a pile of orders, but a single Quote.
And it also puts multi-chain markets together for comparison.
So what does that mean?
Before, I found the liquidity myself; now the protocol helps me find it.
That’s also what I find most interesting about TermMax.
What it truly wants to do might not be to “create another lending pool,” but to move toward a Liquidity Router in the fixed-rate lane.
And its original fixed-rate and fixed-term design conveniently provides a strong foundation for this routing approach: rates can be compared directly, and funding costs can be locked in ahead of time.
When I participate in products like this, what I care about the most is never how pretty the page is—it’s whether it truly helps users take one less step. #TermMax
On this point, I think V2 has done it.

So I’d actually like to ask everyone:
If, in the future, on-chain fixed rates really turn into a “rate supermarket,” what issue would you most want the protocol to solve for you?

Dusk’s bet on secrets may not be about the word "privacy" at all

Over the past few days, I spread out all the technical pieces of Dusk and looked at them again. Suddenly, I realized I had been misunderstanding its positioning @Dusk
//
At first, I thought Dusk was just another privacy coin—hiding balances, hiding addresses, hiding transaction counterparts. It seemed to follow a logic similar to Monero. But once I put the puzzle pieces together—like XSC, CITP—I realized it’s actually building a full execution chain for tokenized securities/RWA—from asset on-chain, to compliant disclosures, to trade execution. Each step is moving toward the direction of “being acceptable to regulation,” not toward “pushing for absolute anonymity” #
//
What I find most interesting is the concept of “confidential interoperability.” Privacy isn’t an isolated island. The data hidden on-chain has to be able to communicate with external traditional finance systems and other chains—and yet not leak the secret during that communication. That’s far harder than simply “hiding.” Hiding is easy. The real skill is hiding in a way that can be verified and still integrated with external systems
//
From my own thinking, what Dusk lacks for truly large-scale institutional adoption isn’t the privacy technology itself. It’s the surrounding ecosystem—the reliable oracle layer, toolchains that can pass audits, and interfaces that can plug into traditional finance standards. These are the “last mile” for whether compliance-minded institutions can actually use it #dusk
//
Once I figured that out, my understanding of Dusk completely changed. It isn’t betting on “privacy” itself. It’s betting on “privacy as an entry ticket for putting regulated assets on-chain”—which is a completely different game from traditional privacy coins. One wants to make you disappear entirely; the other wants you to retain privacy while still being under regulation
//
Let me ask: what is Dusk’s core positioning closer to? $DUSK

I dug out where I hid TermMax V2’s “smart” @TermMax

Over the past couple of days, I went through the TermMax V2 app from top to bottom. To be honest, at first I didn’t think it was that special—until I realized I had missed something I used to do every time I took out or provided a loan: price comparison.
//
In the past, when I used DeFi lending, there was always a string in my head: “Is this order’s interest rate worth it? Would that neighboring pool be better?” I’d keep switching back and forth, and somehow I ended up acting like a human matching engine. This time, V2 directly removes that layer of hassle. Those order types that were clearly separated before—Curator Range Orders, Limit Orders, and the like—have been stuffed into the same execution layer. I open the app and what I see is basically a Quote. Behind it, the whole bundle of price-comparison logic has already been handled for me.
//
The part I feel most strongly about is cross-chain. In the past, if I wanted to compare interest-rate opportunities across different networks, I had to open multiple pages and switch between them. Now, what the official message is saying—“one app, every chain, every order”—means markets across multiple chains are shown together. The protocol can even combine orders from different sources into a single transaction, helping me find the best path. I don’t have to assemble it order by order myself.
//
I thought about it, and in this upgrade, what’s truly valuable isn’t whether the interface looks better or not—it’s that the protocol has lifted the two headaches from me: “spending time to search for information” and “executing price comparisons myself.” This is less like a traditional lending pool now. It’s more like an on-chain interest-rate router—what you want isn’t a particular pool, but the best price and the smoothest execution.
Fixed-rate Liquidity Router. I think that description fits what it looks like now better than “Lending Protocol.” #TermMax
//
One question: what cost does TermMax V2 really save?

Over the past couple of days, I opened and played around with the TermMax V2 app. The more I use it, the more I feel that many people misunderstood what this upgrade is really focused on @TermMax
//
Most people might think V2 is just about the interface looking nicer and adding a few more order types. But after digging around, I found that the real changes are hidden in places you can’t see—it's taking order types that were previously scattered, like Curator Range Orders and Limit Orders, and putting them all into the same execution layer. Before, you had to figure out which order type fits the current situation yourself; now those differences are absorbed by the protocol, and what you see in front of you is only one unified execution entry
//
The most worth mentioning, in my opinion, is the design of “Best Execution.” Previously, in DeFi lending, you had to compare order books one by one, calculate which interest rate is actually more favorable—basically, you were acting as the matchmaker. With V2, that step is removed entirely. When you open the app, what you see is a Quote, and the protocol has already compared everything in the background. This sounds simple, but in reality it shifts the “information search cost” from the user to the protocol layer
//
Looking further down, the cross-chain market comparison part is also pretty interesting. What the official is saying now is “one app, every chain, every order”—markets across multiple chains are shown together, so you don’t have to open multiple pages and jump back and forth comparing rate opportunities on different chains. The protocol also combines orders from different sources into a single transaction, helping you find the optimal liquidity path instead of making you assemble it order by order
//
In my own understanding, once you put all this together, TermMax is becoming less like a traditional “lending pool” and more like an on-chain interest-rate router. What users want was never “which pool”—it’s “which price is best, and which execution is the smoothest.” This upgrade in V2 feels like it’s moving in exactly that direction #TermMax
Fixed-rate Liquidity Router—this positioning might be more accurate than calling it a Lending Protocol.

What are the core changes in TermMax V2?

Over the past couple of days, I’ve been looking into Dusk’s invisible address design, and I realized my earlier understanding was way too simplistic—just hiding the amount isn’t enough. What really gets analyzed on-chain is the address linkage. The same address can receive repeatedly and reappear over and over, and they can still piece together your funding profile.

//
First, let me talk about what I understand: how this one-time address is created.
Dusk uses an ECDH-style key agreement. My understanding is that the payer takes the recipient’s publicly known address information, combines it with a random number, and then, using elliptic curve operations, derives a brand-new one-time receiving address for each payment. So every transaction looks different.
The recipient’s “main address” never directly appears on-chain from start to finish. As an outsider, what I ever see is just a bunch of addresses that seem totally unrelated—so you can’t reconstruct that all those addresses actually belong to the same person.

//
Then my first reaction was: how does the recipient get the money back?
That depends on the view key, or the viewing (view) key. The recipient uses this key to scan all outputs on-chain and uses key-based identification to determine which notes were derived for them. I, as an outsider, can’t do that because I don’t have the corresponding private key material, but the recipient can compute it themselves.
One clever aspect of this design is that the view key can also be separately authorized to a third party (for example, an auditor) to do read-only scanning—without handing over spending permissions that can actually move the funds.

//
I compared this setup with the classic stealth address scheme (like CryptoNote’s), and I found that Dusk’s approach isn’t isolated. It’s meant to fit together with the entire zk ledger. After the one-time address is derived, the corresponding assets are packaged into a note. That note includes a value commitment. When spending, you also have to generate the corresponding nullifier to prevent double-spending.
My understanding is: address hiding solves “you can’t tell where the money went.” Commitments and nullifiers solve “you can’t tell how much there is or whether it was spent.” Only when all three layers align and lock together is the privacy complete—if any one piece is missing, the game is up.

@Dusk #dusk $DUSK @Dusk
What is the purpose of the view key?

🌙 Qixi Special Event | Tangyuan Invites You to Celebrate Qixi Together

The 27th round of the “Scheri” game is about to begin! 🔥

📅 Officially starts on August 19 at 12:00
💰 The community has injected 100,000 Scheri into the prize pool
🎁 Addresses that participate in this round can additionally receive airdrop benefits of 20 Scheri
⏰ Claim deadline: by 22:00 on August 20

We’ll be live tonight—Tangyuan will keep you company for a different kind of Qixi ❤️

This live stream centers on the Qixi Festival × Scheri game. We’ll cover how to play the game, how to get the rewards,

and there will be continuous airdrop perks throughout the live chat!

Whether you’re an old friend or a new friend who just came to the plaza, everyone is welcome to join and play together.

Tonight, see you in livestream @Anna-汤圆 !
🎁 Airdrops keep coming
🔥 Games keep going
🌙 Let’s play Qixi together!

Game entrance: 105906.xyz

#舍利子 #MEME #空投

If you treat FT, XT, and GT under @TermMax as three separate tokens, I think it’s easy to get more and more confused the more you read.
Instead, I’d suggest flipping the question around:
In a DeFi loan, what does it actually include?
In practice, it boils down to a few things: how much you will have to repay in the future, the interest-value component contained in the loan, what collateral the borrower puts up, and how much risk the entire position carries.
What TermMax does is to break these components apart.
First, let’s look at FT.
In essence, FT is very similar to a zero-coupon bond: bought at a discount, redeemed at maturity for its face value. For example, if you pay 90 USDC to buy an FT that can be redeemed for 100 USDC at maturity, what you’re really buying is a future, certain stream of cash flows.
Next, XT.
It’s not simply an “points token”; it’s the interest-value component within the lending structure. In TermMax’s mechanism, FT and XT together form the value relationship of a debt token. The core relationship can be understood as:
1 FT + 1 XT = 1 debt token
Finally, GT.
GT is even more interesting: it’s not a standard ERC-20 token, but an ERC-721 NFT.
You can think of it as a “position container,” which records the collateral and the debt, and corresponds to the state of the entire leveraged position. In the past, managing a complex leveraged position might require handling lots of information—now you can pack the whole position into an NFT.
So when you look at the three things together, it becomes much clearer:
FT answers “how much needs to be paid in the future.”
XT carries “the interest value inside this loan.”
GT answers “how the collateral and the overall lending position are managed.”
This is also the part I think makes TermMax particularly worth studying.
It may not just be about fixed interest rates; it may further split a traditional loan into tokenized cash flows, interest value, and an NFT position that can be managed and transferred.
In short, it’s about “looking at a loan in pieces.”
But the problem is:
After the tokens are broken down so finely, who will price FT, XT, and GT?
How should tokens with different maturities, different interest rates, and different risks form reasonable prices?
That question might actually be more worth researching than “how to split the tokens.”
#termMax
What is TermMax’s FT essentially more like?

I re-analyzed Phoenix’s transaction structure again these past couple of days. This time, I even split one transaction up to see exactly which parts can be seen on-chain and which parts cannot.
━━━━━━━━━━━━━━
▎What’s hidden inside the note
Phoenix uses the UTXO model, where each unit of asset on-chain is called a note. Each note packages three things: a commitment to the amount (not the plaintext number, but an encrypted commitment value), a blinding factor (basically a random salt added to the commitment to prevent someone from guessing the amount via collisions), and a one-time random value that ensures every note is unique and will not collide with any other note.
Together, these three items mean that what you see on-chain is just a bunch of encrypted data—specifically, no one can tell how much was transferred or what a particular note is worth. But the network can still verify that the commitments add up correctly for balance, without decrypting any specific number.
━━━━━━━━━━━━━━
▎Preventing double-spending with a nullifier
One clever aspect of this design is that it doesn’t prevent duplicate spending by “deleting old notes.” Instead, it relies on publishing a consumption credential that cannot be linked back to the original note.
When you spend a note, the system generates a corresponding nullifier. This value is computed deterministically, but an external observer can’t reverse-engineer which note it corresponds to. The network only needs to monitor whether “this nullifier has appeared before.” If it has, it proves that the corresponding note has already been spent. If someone tries to spend the same note a second time, it will generate the same nullifier, which will immediately collide with the existing record, and the system will reject it.
In the whole process, nothing reveals “who spent what.” Collision detection alone handles it.
━━━━━━━━━━━━━━
▎Poseidon hashes—the foundation that supports the entire privacy state
Because the privacy state must be stored in a Merkle tree, it’s used to create membership proofs (proving that “this note really exists in the state tree”).
If you put a regular hash function into a zk circuit to compute it, the cost is enormous. Poseidon is a hash algorithm designed specifically to be zk-friendly. Its structure matches the proving system more closely, which greatly reduces the cost of hash computations inside the circuit. Without a zk-friendly hash like this, generating proofs for the privacy state tree would be so slow that it would be unusable.
@Dusk $DUSK #dusk
In a Phoenix transaction, what mechanism prevents hidden assets from being double-spent?

A DeFi issue that’s easy to overlook: floating interest rates are also a risk
Recently, while looking at @TermMax , I suddenly thought of an interesting question.
When we borrow USDC or ETH on Aave or Morpho, our first instinct is usually to check the collateral ratio, LTV, and liquidation line.
But there’s something that has always been changing—borrow interest rates.
When you borrow money today, you might feel that a 4% rate is comfortable. But what about 30 days from now? If the market shifts and rates jump to 7% or 8%, the room for profit you calculated originally might disappear overnight.
Especially for strategies like leverage and arbitrage, this is really something to worry about.
Because how much you earn is one thing, but how much you have to pay back on the borrowed funds is another.
So I’ve increasingly come to feel that the meaning of fixed interest rates isn’t simply that “the rate is always lower,” but at least that it lets me know:
When this money is borrowed for how long, how much I will have to pay in total.
This is where TermMax is particularly interesting.
It doesn’t just convert floating interest rates into fixed rates—it also puts Maturity (time to maturity) into the market. By using Debt Tokens, Collateral Tokens, and Maturity, it creates a term-based market.
In plain terms, it adds a previously often-ignored element to DeFi lending and borrowing:
time.
Previously, everyone was more accustomed to “borrow and repay as needed, with interest rates floating all the time.” TermMax is trying to turn borrowing into a piece of financing with a clear term and a clear cost.
I think this approach is quite interesting.
Because in DeFi, we’ve always been discussing yield rates, liquidation, and leverage, but we rarely seriously discuss:
“Can I actually know in advance how much this liability will cost me if I need to repay earlier?”
That might be where fixed interest rates truly have value.
#TermMax
What is the biggest value of TermMax fixed interest rates?

PLONK：How computation on-chain can be made "verifiable" instead of "reproducible"
Over the past few days, I’ve been studying the PLONK proving system. The more I look, the more it feels like blockchain verification has been rewritten at the level of logic.
First, a simple question: how does the chain confirm that an on-chain computation is correct?
The most direct method is to "recompute it once"—every node runs the exact same computation, and if the results match, it counts. This approach is dumb but works. The problem is that the cost grows linearly with the amount of computation: the more complex the computation, the greater the overhead the entire network repeats for verification.
What PLONK does is replace "recomputing everything" with "producing a proof of constant size." No matter how complex the computation is, the proof size that the verifier needs to check is basically constant. The overhead barely grows with the scale of computation. This isn’t just optimization—it fundamentally changes the cost structure from the ground up.
━━━━━━━━━━━━━━
Behind this is KZG polynomial commitments
PLONK folds the constraint conditions of the entire circuit into several polynomials. The prover doesn’t need to lay out the computation details for you. It only needs to prove that "the evaluations of these polynomials at certain points are correct." The verifier receives just a few group operations, which are extremely lightweight to compute. A huge stack of execution traces gets compressed into several concise algebraic checks.
There’s also a key design: preprocessing.
The parts of the circuit that are public and fixed can be computed ahead of time offline, so they don’t have to be redone for every verification. When verifying on-chain, you only handle the lightweight portion related to the specific proof. This is also why PLONK can achieve "universal and updatable"—the same framework can serve circuits of different sizes without having to redo the trusted setup every time you change the circuit.
━━━━━━━━━━━━━━
Bringing it to Dusk: this proving system is called directly by the CVM
After the privacy-contract execution finishes, it doesn’t just throw the result out for everyone else to rerun verification. Instead, it outputs a proof directly. The execution itself is the proof generation process.
This is the most essential difference between "verifiable" and "reproducible": one relies on everyone being willing to recompute it, while the other relies on mathematics so you don’t have to compute to trust.
@Dusk $DUSK #dusk

翻Dusk的密码学选型这两天，发现一个很容易被忽略的决定——换一条椭圆曲线这事，大部分人觉得无所谓，其实牵一发动全身

//
先说为啥不能直接拿比特币以太坊那套用
secp256k1是矿机钱包世界最流行的曲线，但它压根不是为zk证明设计的。证明系统（比如Plonk背后靠的BN254、BLS12-381这类曲线）所有运算都被限制在一个特定标量域里，电路里的加法乘法都得在这个域里做。secp256k1的域跟这些证明系统的域根本对不上，硬要在电路里验证一个secp256k1签名，得靠"非原生运算"去模拟，成本是原生运算的成百上千倍——不是不能做，是贵得离谱

//
JubJub这条曲线，就是专门冲着解决这个不兼容来的
它是一条twisted Edwards曲线，关键在于它的域刚好嵌在BLS12-381的标量域里，也就是说在Plonk电路内部做JubJub上的点运算，走的是原生运算，代价一下降下来了。拿它处理密钥生成、签名、加密这些操作，跟证明系统天然贴合，不用绕弯子

//
再说说群抽象这层要解决的事
Edwards形式的曲线普遍有cofactor不是1的问题，说白了就是同一个"逻辑上的点"，在曲线上可能对应好几种不同的字节表示。这种表示歧义历史上确实出过漏洞——攻击者能利用cofactor相关的小子群，构造出一些边界情况绕过验证。业内常见的解法，是在曲线上面再包一层群抽象，把这些表示歧义抹平，保证一个点只有一种规范写法，从根上堵住这类攻击

//
拿这套选型跟矿机世界最流行的secp256k1比一下就清楚了：一个是为签名验证效率和生态兼容服务的曲线，一个是为证明系统内部运算成本和安全边界服务的曲线，压根不是奔着同一个目标去的。换曲线这个决定听着挺技术、挺细，但直接决定了后面整条zk管线是便宜还是昂贵、是干净还是留了隐患

@Dusk $DUSK #dusk

Why can the JubJub curve align well with Dusk’s proving system?