一只瓢虫

Shared by the ends of the earth, this moment: Celebrating Mid-Autumn on BSC—with the world
This year marks the 4th Mid-Autumn I’ve spent with crypto. The first time I bought BNB, I thought crypto was just price movements on a screen. Later, when I entered Binance and crossed onto BSC, I realized it’s more like a network with no time zones. Mid-Autumn is about reunion, and so is life on-chain—connecting people from different continents, languages, and time zones into a single market.
In the past, trading had “time differences”: when New York closed, Tokyo hadn’t woken up, and Asian investors often had to stay up late. Now, Binance and BNB Chain make 7×24 hours more than just a slogan. At 3 a.m., I completed a transfer on BSC—paid Gas with BNB and got confirmation in seconds. At the same time, on the other side of the Earth, a partner was watching the market on Binance, joining Launchpool, and discussing the ecosystem. The moon shines on me, and on him too—blocks like relay stations under moonlight, bringing participants across regions into the same flow.
I envision the future: global markets won’t be fragmented islands anymore—stocks, gold, bonds, and RWAs can all be traded on-chain 24/7. Binance is that “global financial port” that never closes, and BSC is the bridge connecting assets and users. Trading without time zones isn’t only about candlesticks that never stop—it’s an opportunity for everyday people to participate together in global finance. No matter which time zone you’re in, open Binance and connect to BSC, and you can sync with the world.
Shared by the ends of the earth, this moment. This 4th Mid-Autumn of the year, on-chain I looked up—and what I saw wasn’t just the moon, but countless nodes shining together. May our next Mid-Autumn find us toasting again on BNB Chain, with Binance witnessing global markets pulse together.
#币安中秋故事

After bStocks collateral can be pledged, how can we better achieve “unlocking and revitalizing existing positions” while also controlling risk? For example, when using borrowed funds to allocate to other assets, are there any relatively prudent position sizing or hedging suggestions?

Wow, 333166 HYPE$HYPE

Wow, $4.5 million to buy $PONS and $CASHCAT

BTC has just fallen below $78,000, yet within the past 24 hours it's still going up—this market is truly bewildering 😂$BTC

Wow, BTC$BTC has fallen below $78,000

Wow, $1.04 million buys 20,310,000 MEME $MEME

A giant whale withdrew 1.1 million USDT from Binance, then immediately bought 9.53 million $BTC at an average price of $0.1155—does this mean they’re going to directly prop up the BTC price? $USDC

Wow, 110万枚$USDC

Wow, a hundred million dollars!$SOL

Each consensus round must add a new block. However, the whitepaper says that this round is not completed in a single pass; instead, it is carried out through multiple iterations, and each iteration is further divided into three steps. In Section 3.2, the whitepaper refers to these three steps as Proposal, Validation, and Ratification.

First step: Proposal. The DS algorithm randomly selects a provisioner as the block producer, responsible for generating candidate blocks and broadcasting them to the entire network. If no candidate block is produced or received within the specified timeout, this step outputs NIL and moves directly to the next step—but with no candidate block in hand, what is voted on afterward? The answer is: do not cast an empty vote; instead, vote NoCandidate, meaning “no candidate block is verifiable.” $DUSK

Second step: Validation. The DS algorithm randomly selects a set of voting committee members to validate the candidate block from the previous step. If the candidate block is valid, vote Valid; if invalid, vote Invalid; if there is no candidate block, vote NoCandidate. The voting committee needs an absolute majority of 2/3 to reach quorum. If quorum is not reached before the timeout, output NoQuorum. The output of this step is a ValidationResult, which includes the vote type that achieved quorum and the aggregated signature of all voters. @Dusk

Third step: Ratification. A new set of voting committee members is selected to confirm the result of the Validation. If the previous step achieves the Valid quorum, they confirm that result; if the previous step is NoQuorum or fails, they vote NoQuorum. This step ensures that the validation result is not decided by only a minority, but is recognized by a larger number of provisioners.

If the Ratification outputs Success, the candidate block is officially accepted as the new block, and the round ends. If it outputs Fail or unknown, the protocol proceeds to the next iteration: re-select the block producer and re-cast the votes. The whitepaper states that the maximum number of iterations is determined by a global parameter; the current setting is 50. If 16 consecutive iterations fail, the protocol enters emergency mode (angle 10).

The core logic of the three-step design is checks and balances: the block producer can only generate candidate blocks and cannot vote; the validation committee can only validate and cannot confirm; the confirmation committee can only confirm the validation result and cannot re-verify. No single role can decide the fate of a block on its own. #dusk

When the Dusk network launches, it’s not just about the Piecrust virtual machine—it also deploys a set of genesis contracts that handle the most basic operations. Section 6.2 of the whitepaper calls them “genesis contracts”: special smart contracts deployed during network initialization, responsible for key functions such as transaction validation, the staking mechanism, and initial token allocation. The whitepaper focuses on two of them.

The first is the transfer contract (transfer contract). It manages all DUSK transfers, $DUSK and also handles the deduction of gas fees. If a transaction includes the deployment or invocation of a smart contract, the transfer contract is responsible for that as well—it verifies that the transaction conforms to the rules of Moonlight or Phoenix, and then deducts the corresponding gas fees from the sender’s balance. The whitepaper says it is the “entry point into the Dusk blockchain,” and that all transactions ultimately go through it.

The second is the stake contract (stake contract). It manages the full lifecycle of staking: verifying that the amount a user deposits meets the minimum staking threshold, locking the tokens, and registering the user as a provisioner. The more DUSK staked, the higher the probability of being selected by the DS algorithm to participate in consensus. The contract also handles unstaking requests—after the lock-up period ends, users can retrieve their tokens, while ensuring that rewards distribution and penalty deductions are executed correctly. The 1000 DUSK threshold mentioned in Angle 1, and the rewards and penalties mentioned in Angle 9, are put into practice specifically through this contract. @Dusk

Section 6.3 adds two more “other contracts.” One is the license contract (license contract), which manages the issuance and verification of licenses within the network based on the Citadel protocol; it tracks the ownership, validity, and expiration time of each license, and handles revocation or renewal. The other is the Zedger contracts, which instantiate separate smart contracts for each type of security asset instance, providing functions such as minting, burning, dividends, and forced transfer—this is the concrete implementation of the Zedger protocol mentioned in Angle 7.

The division of labor among the four contracts is clear: the transfer contract handles liquidity, the stake contract handles consensus participation, the license contract handles permissions, and the Zedger contracts handle assets. But that also means Dusk’s core functionality heavily depends on the correctness of these four contracts—if any one of them has a bug, it affects not just a single application, but the network’s fundamental operations as a whole. #dusk

In Whitepaper Section 1.1, “Related Work,” it actually only did one thing: telling readers that Dusk is not who you think.

The whitepaper categorizes existing blockchains into three types. The first type is general-purpose smart contract platforms—Ethereum and Cardano. Their problem is that transparency leaves no place to hide sensitive financial data. Even with second-layer solutions like zk-rollups, they’re only patches, not native designs. The second type is privacy chains—Zcash and Monero. They push personal privacy to the extreme, but they lack compliance frameworks, auditability, and smart contract capabilities for confidential transactions. The third type is what Dusk wants to do—neither of the first two.

What Ethereum can do, Dusk @Dusk does not—it doesn’t aim for full coverage of general DeFi. Instead, it focuses on regulated financial scenarios. What Zcash and Monero can do, Dusk can do too—it uses ZK proofs to achieve privacy, but on top of that it adds compliance interfaces and auditability. The whitepaper states clearly that Zcash and Monero “lack the necessary features for integration with the regulated financial industry,” including regulatory frameworks, auditability, and smart contract capabilities that support confidential transactions. $DUSK

This isn’t a one-liner like “Dusk is better than all of them.” It’s more like “Dusk chose a different track.” It chose a narrower path—for compliant privacy chains serving traditional financial institutions, rather than privacy chains for everyone. The path is narrower, meaning the user base is clearer; but it also means that if traditional financial institutions don’t buy in, then this positioning becomes meaningless. #dusk

When I read through Chapter 6, I noticed a key choice: Dusk’s smart contract execution environment is Piecrust, based on WebAssembly, rather than EVM compatibility. In 2024, choosing not to be EVM-compatible is a decision that needs explaining.$DUSK

The white paper says that Piecrust is a WASM virtual machine implementation written in Rust. Its core consists of two components: the piecrust crate, which is responsible for the virtual machine itself; and piecrust-uplink, a developer toolkit that provides a toolchain for compiling, deploying, and testing contracts. The white paper emphasizes that its design goals are compactness, safety, modularity, and lightweight operation.

But what really interests me is the design of host functions. Dusk@Dusk moves computationally heavy tasks—such as ZK proof verification, signature verification, and hash computation—from inside the virtual machine to the host environment. The white paper lists specific host functions: the hash function supports two hash algorithms, Blake2b and Poseidon; verify_plonk and verify_groth16_bn254 verify two kinds of ZK proofs—PlonK and Groth16, respectively; verify_schnorr and verify_bls verify signatures, supporting both single signatures and multi-signatures. These operations run natively, not inside the WASM sandbox.#dusk

Why do this? The white paper cites research data showing that running complex applications in WASM is 45% to 255% slower than running them in native code. For a chain that heavily uses ZK proofs, this performance gap is critical. If every transaction must verify a PlonK proof within the WASM environment, the overhead alone would make transaction latency unacceptable. Moving verification to the host environment is essentially bypassing the bottleneck.

However, there’s also a cost to Dusk’s approach. Not being EVM-compatible means existing smart contracts on Ethereum can’t be directly migrated to Dusk, and developers need to relearn the development toolchain for WASM. EVM compatibility is a safety net in the industry because there are already many developers, tools, and codebases built around it. Dusk giving up that safety net suggests it has a clear focus on its intended user base—enterprise developers building for securities and real-world assets.

The toolchain provided by Piecrust-uplink—including compiling contracts into WASM modules, executing them in a controlled environment, and verifying correctness and security—seems like it’s trying to address a shortfall in developer experience. But whether the toolkit is actually convenient or not isn’t something the white paper can answer; developers will have to use it in practice to judge.

When I read Chapter 5, I found that Dusk had done a lot of work on energy efficiency, and they provided specific data. That made me feel they really considered this issue seriously.

First, at the consensus layer. The whitepaper cites data after Ethereum switched from mining to PoS, claiming energy consumption drops by 99.95% or more. But SA consensus isn’t just PoS—it’s PoS with a committee-based design. The whitepaper says that deterministic assignment means block production and validation don’t require intensive computation, because who does the work is selected in advance rather than determined by a competition of computing power. The committee consists only of the chosen provisioner group, not the entire network validating together—so the overall computational load is smaller. $DUSK

At the network layer, the Kadcast data is more interesting. The whitepaper says that compared with the Gossip protocol, Kadcast can reduce bandwidth consumption by 25% to 50%. This isn’t speculation—it cites research data. Moreover, Kadcast can also reduce the orphan block rate by 10% to 30%—those blocks that get broadcast but ultimately aren’t accepted. In PoS networks, fewer orphan blocks means fewer rounds of wasted voting and validation work.

At the cryptographic operations layer, Dusk moves heavy tasks—ZK proof verification, signature verification, and hash computation—from the WASM virtual machine to the host environment, running them with host functions. The whitepaper cites research data saying that executing complex applications in WASM is 45% to 255% slower than native code. By eliminating that extra overhead, for a chain that heavily uses ZK proofs, the saved computation is quite substantial. #dusk

However, the whitepaper is also honest that these specific numbers for energy savings haven’t yet been quantified. The Kadcast bandwidth-saving data comes from other networks, not from Dusk’s own mainnet measurements. That makes me think that when they wrote the whitepaper, the attitude was rigorous, not padding the numbers just to make things look better.

But on the flip side, if Dusk@Dusk ’s SA consensus truly reduces the number of validators to a very small scale, then energy consumption could indeed be even lower than Ethereum’s PoS. Ethereum PoS doesn’t mine anymore, but there are still hundreds of thousands of validators worldwide, and each one has to run full node validation. If Dusk’s validation work is done by a small committee, then the energy cost per validation would be much lower. This logic holds theoretically, but the real-world impact still has to wait until after mainnet launch and we can get data to back it up.

When I read the Zedger protocol in the whitepaper, I felt a kind of “finally, it’s here.” After all the groundwork—everything from privacy to compliance to the dual-transaction model—Zedger is the culmination of all these technical ideas. $DUSK

The whitepaper says that Zedger is a protocol for managing securities and real-world assets. It supports minting, burning, corporate actions like dividend distribution, and even supports forced transfers. Just looking at these functions, you can tell its target users aren’t retail investors, but institutions that issue securities.

I paid particular attention to the “forced transfer” feature. On Ethereum, your assets are yours—no one can move them. But in real-world financial markets, courts can freeze assets, liquidators can forcibly transfer them, and regulators can require recoveries. Zedger builds this capability in, which shows that its understanding of regulatory and compliance needs goes beyond slogans—it’s truly designed for institutions’ requirements. @Dusk

But there’s a very subtle balance here. If the forced-transfer function is abused, then it’s not compliance—it’s centralization. The whitepaper says that Zedger uses ZK proofs and auditing capabilities to ensure legality, while also protecting user privacy. What I understand is that every forced transfer must come with an encrypted compliance proof proving that the action is legitimate, but without exposing the transaction details.

However, the whitepaper’s description of Zedger is still rather high-level. It doesn’t go into detail about who has the authority to execute forced transfers, how that authority is distributed, or how it prevents abuse. If the authority is held unilaterally by the issuer, then at its core, the system is centralized. If the authority must be triggered through on-chain governance or multisig, then the security and degree of decentralization would be much higher.

I tend to believe that Zedger’s design philosophy is right—providing a clear technical framework for RWA and securities. But the actual level of decentralization depends on the specific implementation of permission control. The whitepaper leaves room here for questions worth digging into. #dusk

When I read the section about SA consensus, my first reaction was to look for its finality time parameter. The whitepaper says “finality achieved within a few seconds,” but it doesn’t specify exactly how many seconds. This ambiguity made me a bit uneasy, but it also pushed me to understand the logic behind it.

First, let’s compare. Bitcoin’s finality for $DUSK relies on probability: with about 6 block confirmations, it takes roughly 1 hour. The longer you wait, the more confident you are that the transaction won’t be rolled back. Ethereum’s PoS finality relies on the Casper protocol: it needs two epochs, about 12.8 minutes. Dusk claims it only takes a few seconds—why is that?

The key lies in its deterministic assignment mechanism. The whitepaper states that before each round begins, the DS algorithm has already pre-selected who will be the block producer and who will be the voting committee. This “pre-knowing” means that voters are already ready before the block is generated; there’s no need to temporarily recruit participants or broadcast across the whole network to find consensus. Communication costs are greatly reduced.

I broke down its process. Each round contains multiple iterations, and each iteration has three stages: proposal, voting, and confirmation. The voting committee involves only the group of validators that has been selected, not everyone across the network. The number of nodes participating in voting is constrained within a relatively small range, so the communication volume during voting is small. The exchange of information can be completed in just a few @Dusk .

But there’s one part I couldn’t quite figure out. The whitepaper mentions the term “rolling finality,” but it doesn’t elaborate on the specific mechanism. My understanding is that it might mean finality is not locked all at once; instead, as new blocks keep being generated, the finality probability of the previous block gradually increases. If that’s the case, then “a few seconds” might refer to the first layer of confirmation, not final irreversible finality. #dusk

Also, I noticed the whitepaper doesn’t provide a precise number of seconds. “3 seconds” and “9 seconds” are both called “a few seconds,” but they mean completely different things in financial scenarios. For now, I can’t find the answer from the whitepaper; I may need to wait for the real test data after the mainnet goes live.

When I was reading the whitepaper, this question kept spinning in my head. Dusk’s biggest narrative is “we can have both privacy and compliance,” but historical experience tells me that such promises usually please neither side. #dusk

Let’s look at the counterexamples first. Zcash and Monero pushed privacy to the extreme, but regulators didn’t accept it—exchanges delisted them, and liquidity shrank. Ethereum and Bitcoin are fine on compliance, but transactions are fully transparent; when institutions make a large trade, the counterparties can see everything clearly. Dusk says it has found a third path, and I was skeptical at first. @Dusk

The solution outlined in the whitepaper is a dual-transaction model plus the Zedger protocol. Moonlight is used for compliance scenarios, Phoenix for privacy scenarios, and Zedger ensures that smart contracts execute in confidential states while preserving auditability. In theory, this architecture could indeed work.

But after reading it, I found a critical gap. The whitepaper says regulators can access the necessary data—but it never explains how they access it, what authorization mechanism is used, who holds and manages the keys, or how access can be revoked. In an auditable privacy system, the hardest part isn’t getting regulators to see the data—it’s ensuring the data is only visible to the people who are supposed to see it, and only during the authorized time window.

I tried to reason it through from this angle. If Dusk adopts a proof system similar to zk-SNARKs, and regulators hold a specific audit key, $DUSK could verify transaction compliance without exposing user privacy—then the plan would hold. But if regulatory authority is abused or the key leaks, then the “privacy protection building” collapses.

So my conclusion is: having privacy and compliance coexist is theoretically possible, and it may even be achievable in engineering. However, the real-world outcome completely depends on the design details of the permission control mechanisms. Since the whitepaper doesn’t provide these details yet, I can only wait for more technical documentation before judging. The answer to this question isn’t in the whitepaper—it’s in the mainnet code.

When I read this part about Kadcast, my mind kept comparing it to Ethereum’s gossip protocol. Gossip logic is very simple: when you receive a message, you forward it to all the neighbors you know; then your neighbors forward it to their neighbors, and so on until the whole network receives it. But there’s a problem—when the number of nodes grows, the amount of repeated forwarding increases exponentially.

Kadcast does it differently. It’s based on Kademlia’s DHT and organizes nodes into layers by XOR distance. Instead of forwarding to all neighbors, each node forwards only to a selected set of nodes at increasing XOR distances. I had to read this mechanism twice to understand its cleverness—it creates a cascading effect rather than flooding.

For example, when node A sends a message, it forwards it only to a few of the closest nodes. Those nodes then forward it to nodes that are farther away. The number of target nodes per layer is controlled, not an unlimited spread. The whitepaper says this significantly reduces the total number of transmissions required for network propagation.

So what does this design have to do with financial scenario $DUSK ? My understanding is that financial scenarios are especially sensitive to two things: latency and bandwidth. If a transaction broadcast takes more than ten seconds—or even dozens of seconds—for it to reach the entire network, then second-level finality doesn’t really matter. Kadcast uses a tree-like structure so the message reaches all nodes with the minimum number of relays, compressing propagation time to the extreme.

There’s another point I didn’t notice at first. The whitepaper mentions that Kadcast naturally obfuscates the origin of messages. Since nodes communicate only with selected peers rather than broadcasting to the whole network, it’s difficult for an attacker to track which node a particular transaction originated from. This is an additional bonus for Dusk@Dusk ’s privacy narrative.

However, I still have a question. The whitepaper compares gossip and Kadcast, but it only provides qualitative descriptions and no specific data on bandwidth savings. How much is saved—30% or 90%? Without that data, it’s hard for me to judge how large the efficiency advantage really is. Maybe this magnitude can only be answered by using real network data after it goes live on the mainnet. #dusk

My first reaction to reading the SA consensus was: how on earth did it come up with the number 1000 DUSK? The whitepaper only gave the result, not the derivation process. So I traced backward from its parameters.

It sets an epoch of 2,160 blocks. Given Dusk’s current block production speed, that’s roughly 6 hours per epoch. Then it provides a maturation period formula: M = 2 × epoch - (height mod epoch). In other words, if you stake a batch of DUSK, you have to wait from roughly the second half of an epoch up to a full epoch before you can truly start doing work.

The interesting part of this design is that it aligns the activation time of all newly staked funds to the epoch boundary. It doesn’t take effect immediately upon staking; instead, everyone activates at the same starting point. My guess is that the goal is to give the DS algorithm’s deterministic selection (the verifiable randomness/lottery) a stable snapshot of the staking pool. If anyone could stake at any moment and become active right away, then the candidate provisioner set would change every block, making deterministic assignment harder to do. $DUSK

But what about the number 1000 DUSK itself? I did some calculations: if the threshold were set to 100, the number of provisioners would skyrocket. With 64 slots competing within each epoch, the competition would be much fiercer, but the stake held by any single node would be too low—so network security could end up being diluted. @Dusk

If the threshold were set to 10,000, then retail users basically couldn’t participate. Provisioners would become a game dominated by a small number of large nodes, and decentralization would take a hit.

So 1000 sits in the middle. I looked up parameters from a few other PoS chains: Dusk’s threshold isn’t particularly low, but it’s not high either. It’s like saying, “I don’t want you to be able to spin up a node with just some spare change, but I also don’t want you to have to be a whale to participate.”

However, I still have one question I haven’t fully figured out. The whitepaper doesn’t give the target interval for the total number of provisioners, nor does it explain what ratio of slot-competition intensity is optimal. Without those data, I really can’t tell whether 1000 is “right.” Maybe its reasonableness can only be validated after the mainnet goes live using real-world data. #dusk