Binance Square
Salar_Ghazi
5.1k Publications

Salar_Ghazi

395 Suivis
19.4K+ Abonnés
4.2K+ J’aime
Publications
PINNED
·
--
Haussier
#dusk @Dusk_Foundation Something I kept circling back to while looking at $DUSK architecture is the XSC standard and why it exists as a separate contract layer at all. Most blockchains let you issue tokens. XSC Confidential Security Contract is designed for something narrower regulated securities. Not generic tokens. Stocks, bonds, tokenized financial instruments that legally require investor eligibility checks, transfer restrictions, and audit trails. What makes it structurally different from something like an ERC-20 is where compliance logic sits. On a standard chain, compliance is enforced off-chain someone manually checks a whitelist before approving a transfer. On Dusk, XSC embeds that logic directly into the contract. Eligibility, transfer restrictions, disclosure rules all enforced at execution, not after the fact. The privacy piece is where it gets unusual. XSC transactions use the Phoenix model underneath amounts and counterparty details stay shielded from public view. But the issuer retains selective disclosure capability. A regulator can be granted visibility into specific transaction data without that data becoming publicly visible on-chain. That's the design intent private to the market, auditable to authority. What I genuinely can't confirm right now how many XSC-based securities are actually live and trading on mainnet today. The standard exists. The infrastructure is built. But public data on active XSC deployments is thin. A compliance-first token standard with no publicly visible live issuances is that a timing problem or an adoption problem? $ONG {future}(ONGUSDT) $BMT {future}(BMTUSDT) XSC on Dusk: timing or adoption?
#dusk @Dusk Something I kept circling back to while looking at $DUSK architecture is the XSC standard and why it exists as a separate contract layer at all.

Most blockchains let you issue tokens. XSC Confidential Security Contract is designed for something narrower regulated securities. Not generic tokens. Stocks, bonds, tokenized financial instruments that legally require investor eligibility checks, transfer restrictions, and audit trails.

What makes it structurally different from something like an ERC-20 is where compliance logic sits. On a standard chain, compliance is enforced off-chain someone manually checks a whitelist before approving a transfer. On Dusk, XSC embeds that logic directly into the contract. Eligibility, transfer restrictions, disclosure rules all enforced at execution, not after the fact.

The privacy piece is where it gets unusual. XSC transactions use the Phoenix model underneath amounts and counterparty details stay shielded from public view. But the issuer retains selective disclosure capability. A regulator can be granted visibility into specific transaction data without that data becoming publicly visible on-chain. That's the design intent private to the market, auditable to authority.

What I genuinely can't confirm right now how many XSC-based securities are actually live and trading on mainnet today. The standard exists. The infrastructure is built. But public data on active XSC deployments is thin.

A compliance-first token standard with no publicly visible live issuances is that a timing problem or an adoption problem?
$ONG
$BMT

XSC on Dusk: timing or adoption?
Timing
Adoption
Both
Too early
3 heure(s) restante(s)
PINNED
·
--
Haussier
#dusk $DUSK @Dusk_Foundation for a few hours and the thing that keeps pulling my attention isn't the ZK architecture or the RWA narrative it's what the August 16th bridge incident actually revealed about how the network is being used. Monitoring flagged suspicious behavior on a team-managed wallet tied to bridge operations. The team paused bridge services, recycled the affected addresses, and coordinated with Binance after identifying that part of the flow touched their platform. What struck me isn't the incident itself bridge ops getting flagged is almost routine in 2026 it's what it implies about the current architecture. The team was quick to clarify this was not a protocol-level issue on DuskDS, and that mainnet continued operating normally. Meaning the network held, but the operational layer the bridge wallet was the weak point. That's a meaningful distinction. My small surprise Dusk markets itself heavily on institutional-grade compliance and privacy, yet the bridge is still relying on team-managed wallets for operational flow. That feels like a temporary design choice they haven't fully replaced yet. Bridge services remain temporarily paused while a broader hardening pass is completed. I don't know the full scope of what that means whether it's a quick patch or a structural redesign. Which raises the question I can't answer: how much of Dusk's cross-chain volume was flowing through this single bridge operational wallet, and what does that concentration say about how decentralized the infrastructure actually is right now? $PROM $ONG Team-managed bridge wallets acceptable for an "institutional-grade" project?
#dusk $DUSK @Dusk for a few hours and the thing that keeps pulling my attention isn't the ZK architecture or the RWA narrative it's what the August 16th bridge incident actually revealed about how the network is being used.

Monitoring flagged suspicious behavior on a team-managed wallet tied to bridge operations. The team paused bridge services, recycled the affected addresses, and coordinated with Binance after identifying that part of the flow touched their platform.

What struck me isn't the incident itself bridge ops getting flagged is almost routine in 2026 it's what it implies about the current architecture. The team was quick to clarify this was not a protocol-level issue on DuskDS, and that mainnet continued operating normally. Meaning the network held, but the operational layer the bridge wallet was the weak point. That's a meaningful distinction.

My small surprise Dusk markets itself heavily on institutional-grade compliance and privacy, yet the bridge is still relying on team-managed wallets for operational flow. That feels like a temporary design choice they haven't fully replaced yet.
Bridge services remain temporarily paused while a broader hardening pass is completed. I don't know the full scope of what that means whether it's a quick patch or a structural redesign.

Which raises the question I can't answer: how much of Dusk's cross-chain volume was flowing through this single bridge operational wallet, and what does that concentration say about how decentralized the infrastructure actually is right now?
$PROM
$ONG

Team-managed bridge wallets acceptable for an "institutional-grade" project?
Yes, it's transitional
100%
No, it's a red flag
0%
Depends on timeline
0%
Neutral
0%
1 Votes • Vote fermé
·
--
Haussier
$BTC is flashing a setup traders won’t want to ignore the next move could come fast. $BTC is showing strong bullish momentum, with the structure building up nicely. Long Watch — Market Context Entry: $80,500–$80,700 Target 1: $81,000 Target 2: $81,270 Target 3: $81,600 Target 4: $82,000 Stop Loss: $80,100 $BTC has bounced strongly from the $80.1K area and is reclaiming the $80.5K zone. If buyers push through $81.27K, the upside structure could accelerate. #Write2Earn {future}(BTCUSDT)
$BTC is flashing a setup traders won’t want to ignore the next move could come fast.

$BTC is showing strong bullish momentum, with the structure building up nicely.

Long Watch — Market Context

Entry: $80,500–$80,700
Target 1: $81,000
Target 2: $81,270
Target 3: $81,600
Target 4: $82,000
Stop Loss: $80,100

$BTC has bounced strongly from the $80.1K area and is reclaiming the $80.5K zone. If buyers push through $81.27K, the upside structure could accelerate.
#Write2Earn
#dusk $DUSK @Dusk_Foundation the actual node client behind Dusk, not the marketing page version. Back in May, a Rusk release quietly shipped something called http.policy ACL rules, endpoint-class rate limits, a whole framework for the node to deny or throttle specific traffic at the protocol level. Read as a spec line, it looked like boring ops hygiene. Then on August 16, Dusk's team flagged suspicious activity on a bridge linked wallet and, within hours, spun up a Web Wallet recipient blocklist to stop transfers to flagged addresses same mechanism, live, under pressure.That's the part that stuck. $DUSK gets marketed as "privacy + compliance," future tense, coming soon. But the actual first real-world use of that enforcement layer wasn't a user-facing privacy feature it was the team protecting the bridge. Infrastructure built for regulators ended up serving as an incident response tool before it ever touched an end user's shielded transaction. Not a complaint, just noticing the order things unlock in. I went in expecting Rusk to be "the VM," came out thinking of it more as a policy engine that happens to also run consensus.who else gets access to that blocklist logic before it's ever documented publicly.
#dusk $DUSK @Dusk the actual node client behind Dusk, not the marketing page version.

Back in May, a Rusk release quietly shipped something called http.policy ACL rules, endpoint-class rate limits, a whole framework for the node to deny or throttle specific traffic at the protocol level. Read as a spec line, it looked like boring ops hygiene.

Then on August 16, Dusk's team flagged suspicious activity on a bridge linked wallet and, within hours, spun up a Web Wallet recipient blocklist to stop transfers to flagged addresses same mechanism, live, under pressure.That's the part that stuck. $DUSK gets marketed as "privacy + compliance," future tense, coming soon. But the actual first real-world use of that enforcement layer wasn't a user-facing privacy feature it was the team protecting the bridge.

Infrastructure built for regulators ended up serving as an incident response tool before it ever touched an end user's shielded transaction.

Not a complaint, just noticing the order things unlock in. I went in expecting Rusk to be "the VM," came out thinking of it more as a policy engine that happens to also run consensus.who else gets access to that blocklist logic before it's ever documented publicly.
·
--
Haussier
Guys, $XRP is setting up for a move don’t ignore this zone. $XRP is showing strong bullish momentum, with the structure building up nicely. Entry: $1.47–$1.49 Target 1: $1.52 Target 2: $1.55 Target 3: $1.60 Target 4: $1.65 Stop Loss: $1.43 XRP is holding above the $1.45 area after a strong consolidation phase, while buyers are starting to push back toward the $1.50 resistance. A clean break above $1.50 could open the way toward the higher targets. #Write2Earn {future}(XRPUSDT) {future}(PORTALUSDT)
Guys, $XRP is setting up for a move don’t ignore this zone.

$XRP is showing strong bullish momentum, with the structure building up nicely.

Entry: $1.47–$1.49
Target 1: $1.52
Target 2: $1.55
Target 3: $1.60
Target 4: $1.65
Stop Loss: $1.43

XRP is holding above the $1.45 area after a strong consolidation phase, while buyers are starting to push back toward the $1.50 resistance. A clean break above $1.50 could open the way toward the higher targets.
#Write2Earn

·
--
Haussier
$BNB Long Watch Entry: $692–696 Target 1: $705 Target 2: $715 Stop Loss: $686 $BNB is holding above the $690 support zone after a strong recovery from the $680s. Price is consolidating near $696, while the recent rejection around $705 remains the key resistance. A clean hold above $692–696 could set up another push toward $705 and potentially $715. Losing $690 would weaken the bullish structure. $SPK {future}(SPKUSDT) {future}(PORTALUSDT) {future}(BNBUSDT)
$BNB Long Watch
Entry: $692–696
Target 1: $705
Target 2: $715
Stop Loss: $686

$BNB is holding above the $690 support zone after a strong recovery from the $680s. Price is consolidating near $696, while the recent rejection around $705 remains the key resistance.

A clean hold above $692–696 could set up another push toward $705 and potentially $715. Losing $690 would weaken the bullish structure.
$SPK

·
--
Haussier
$ETH is holding the recovery structure on the 4H chart. Price bounced strongly from the $2,360–$2,400 zone and is now consolidating around $2,438 after rejection near $2,470. Key levels: Entry: $2,420–$2,440 Target 1: $2,480 Target 2: $2,520 Stop Loss: Below $2,390 A clean 4H breakout above $2,480 could open the way toward $2,520. Losing $2,400 would weaken the bullish setup. #Write2Earn $PORTAL {future}(PORTALUSDT) $SPK {future}(SPKUSDT)
$ETH is holding the recovery structure on the 4H chart.

Price bounced strongly from the $2,360–$2,400 zone and is now consolidating around $2,438 after rejection near $2,470.

Key levels:
Entry: $2,420–$2,440
Target 1: $2,480
Target 2: $2,520
Stop Loss: Below $2,390

A clean 4H breakout above $2,480 could open the way toward $2,520. Losing $2,400 would weaken the bullish setup.
#Write2Earn
$PORTAL
$SPK
·
--
Haussier
#dusk @Dusk_Foundation $DUSK dev docs this week after the DuskEVM testnet went live on August 10. What caught my attention isn't the launch itself it's the fork in the road it creates for developers. DuskEVM runs on OP Stack settles to DuskDS and lets you deploy Solidity with Hardhat Foundry standard EVM wallets all the familiar tooling. DuskVM meanwhile builds directly on Dusk's own execution model Rust/WASM contracts, native transaction models protocol-level assets, and ZK capabilities. Same underlying chain, two completely different development philosophies. What surprised me: the docs are unusually honest about when not to use DuskEVM. They explicitly say use native Dusk when you need privacy, ZK smart contracts, confidential assets, or custom execution. Most L2s don't volunteer their own limitations that clearly. The testnet went live mid-August you can verify early contract deployments on Blockscout (DuskEVM's explorer). I haven't confirmed how many independent devs have actually deployed vs. the team's own test contracts. That distinction matters and I can't say for certain yet. TVL sits below $1M and the DApp ecosystem is thin.The real question does DuskEVM pull in Solidity devs who'd never touch Rust, or does Dusk's privacy story only attract builders willing to go native?
#dusk @Dusk $DUSK dev docs this week after the DuskEVM testnet went live on August 10. What caught my attention isn't the launch itself it's the fork in the road it creates for developers.

DuskEVM runs on OP Stack settles to DuskDS and lets you deploy Solidity with Hardhat Foundry standard EVM wallets all the familiar tooling. DuskVM meanwhile builds directly on Dusk's own execution model Rust/WASM contracts, native transaction models protocol-level assets, and ZK capabilities. Same underlying chain, two completely different development philosophies.

What surprised me: the docs are unusually honest about when not to use DuskEVM. They explicitly say use native Dusk when you need privacy, ZK smart contracts, confidential assets, or custom execution. Most L2s don't volunteer their own limitations that clearly.

The testnet went live mid-August you can verify early contract deployments on Blockscout (DuskEVM's explorer). I haven't confirmed how many independent devs have actually deployed vs. the team's own test contracts. That distinction matters and I can't say for certain yet.

TVL sits below $1M and the DApp ecosystem is thin.The real question does DuskEVM pull in Solidity devs who'd never touch Rust, or does Dusk's privacy story only attract builders willing to go native?
·
--
Haussier
#dusk @Dusk_Foundation $DUSK architecture specifically how confidential smart contracts work under the XSC standard and one detail keeps pulling my attention back. Dusk positions itself as the first blockchain with native confidential smart contracts meaning execution logic counterparties and amounts are hidden by default. Not wrapped in a privacy layer on top built into the base execution environment. That's the architectural claim at least. What made me stop and actually think about this on August 16, the Dusk team detected suspicious activity tied to a team-managed bridge wallet paused bridge services disabled related addresses and coordinated with Binance after part of the flow touched their platform. No user funds impacted they say. But read it carefully this wasn't a protocol flaw. It was off-chain bridge infrastructure. The L1 itself stayed clean. And that's the interesting tension. The team explicitly confirmed the incident was not a protocol-level problem on DuskDS the native chain. Which means the confidential execution layer did what it was supposed to do. The vulnerability lived exactly where it always does the bridge not the chain. I honestly didn't expect them to contain it that fast. Surprised me a bit. What I can't confirm: how many transactions actually went through during the incident window and whether any shielded contract interactions were affected on the native side. That data isn't easily readable which is kind of the point of confidential contracts, but also makes independent verification harder. The bridge stays closed pending a full security review. Meanwhile DuskEVM is still incoming. How those two timelines interact is worth watching closely...
#dusk @Dusk $DUSK architecture specifically how confidential smart contracts work under the XSC standard and one detail keeps pulling my attention back.

Dusk positions itself as the first blockchain with native confidential smart contracts meaning execution logic counterparties and amounts are hidden by default. Not wrapped in a privacy layer on top built into the base execution environment. That's the architectural claim at least.

What made me stop and actually think about this on August 16, the Dusk team detected suspicious activity tied to a team-managed bridge wallet paused bridge services disabled related addresses and coordinated with Binance after part of the flow touched their platform. No user funds impacted they say. But read it carefully this wasn't a protocol flaw. It was off-chain bridge infrastructure. The L1 itself stayed clean.

And that's the interesting tension. The team explicitly confirmed the incident was not a protocol-level problem on DuskDS the native chain. Which means the confidential execution layer did what it was supposed to do. The vulnerability lived exactly where it always does the bridge not the chain.
I honestly didn't expect them to contain it that fast. Surprised me a bit.

What I can't confirm: how many transactions actually went through during the incident window and whether any shielded contract interactions were affected on the native side. That data isn't easily readable which is kind of the point of confidential contracts, but also makes independent verification harder.

The bridge stays closed pending a full security review. Meanwhile DuskEVM is still incoming. How those two timelines interact is worth watching closely...
·
--
Haussier
#dusk @Dusk_Foundation $DUSK transaction data on duskexplorer.com today. One number stopped me cold. Out of 252 transactions recorded in the last 24 hours only 21 were Phoenix the shielded ZK-proof model that's supposed to be the actual privacy layer of this network. The other 231 ran through Moonlight, the fully public account-based model. That's roughly 9% Phoenix adoption on a chain built around privacy. Phoenix is a UTXO-based zero-knowledge transaction model that hides amounts sender-receiver links, and balance changes through cryptographic commitments and nullifiers. Phoenix 2.0 even went a step further enabling compliant privacy where sender identity is provable to the receiver without exposing anything to the public which is supposedly the institutional differentiator. So what explains the gap? My honest read: Phoenix is heavier. Every Phoenix transaction carries a PLONK proof while Moonlight just uses a BLS signature check less compute, faster, cheaper. Most current users are probably just staking, converting tokens, or doing routine transfers. Privacy has a cost, and not everyone's paying it yet. What I can't tell from the explorer whether the Phoenix transactions we do see represent actual privacy-seeking users or just wallet mechanics routing funds through the shielded pool for other reasons. If Phoenix usage stays this low as institutional partners come onboard does the privacy pitch hold up or does it quietly become optional?
#dusk @Dusk $DUSK transaction data on duskexplorer.com today. One number stopped me cold.

Out of 252 transactions recorded in the last 24 hours only 21 were Phoenix the shielded ZK-proof model that's supposed to be the actual privacy layer of this network. The other 231 ran through Moonlight, the fully public account-based model.

That's roughly 9% Phoenix adoption on a chain built around privacy.
Phoenix is a UTXO-based zero-knowledge transaction model that hides amounts sender-receiver links, and balance changes through cryptographic commitments and nullifiers. Phoenix 2.0 even went a step further enabling compliant privacy where sender identity is provable to the receiver without exposing anything to the public which is supposedly the institutional differentiator.

So what explains the gap? My honest read: Phoenix is heavier. Every Phoenix transaction carries a PLONK proof while Moonlight just uses a BLS signature check less compute, faster, cheaper. Most current users are probably just staking, converting tokens, or doing routine transfers. Privacy has a cost, and not everyone's paying it yet.

What I can't tell from the explorer whether the Phoenix transactions we do see represent actual privacy-seeking users or just wallet mechanics routing funds through the shielded pool for other reasons.
If Phoenix usage stays this low as institutional partners come onboard does the privacy pitch hold up or does it quietly become optional?
·
--
Haussier
#dusk @Dusk_Foundation $DUSK explorer for a while and one number stuck with me in the last 24 hours out of 252 total transactions on the network 231 were Moonlight and only 21 were Phoenix that's roughly 92% public, 8% shielded. You can verify this yourself at duskexplorer.com right now. That ratio surprised me a little. The whole design premise of $DUSK is that Phoenix handles confidential financial activity private settlements hidden balances ZK proofs. Moonlight was added later, partly to satisfy exchange compliance requirements. But on-chain, actual users are overwhelmingly choosing the public path. Could be that Phoenix's UX overhead (UTXO notes, proof generation) is still friction enough to push casual users toward Moonlight. Could also be staking-related flows Moonlight supports the Stake contract and most delegation activity is public by nature. I'm honestly not sure which use case is dominating. What I can't confirm is whether that 21 Phoenix count reflects real privacy demand or just power users testing the model. There's no way to see who's behind those shielded notes which is kind of the point. The question I'm sitting with: if privacy is the core value proposition why is it the minority behavior at this stage?
#dusk @Dusk $DUSK explorer for a while and one number stuck with me in the last 24 hours out of 252 total transactions on the network 231 were Moonlight and only 21 were Phoenix that's roughly 92% public, 8% shielded. You can verify this yourself at duskexplorer.com right now.

That ratio surprised me a little. The whole design premise of $DUSK is that Phoenix handles confidential financial activity private settlements hidden balances ZK proofs. Moonlight was added later, partly to satisfy exchange compliance requirements. But on-chain, actual users are overwhelmingly choosing the public path.

Could be that Phoenix's UX overhead (UTXO notes, proof generation) is still friction enough to push casual users toward Moonlight. Could also be staking-related flows Moonlight supports the Stake contract and most delegation activity is public by nature. I'm honestly not sure which use case is dominating.

What I can't confirm is whether that 21 Phoenix count reflects real privacy demand or just power users testing the model. There's no way to see who's behind those shielded notes which is kind of the point.
The question I'm sitting with: if privacy is the core value proposition why is it the minority behavior at this stage?
·
--
Haussier
#dusk $DUSK @Dusk_Foundation after the DuskEVM testnet went live on August 10. The headline is EVM compatibility Solidity, Hardhat, familiar tooling. Fine. But what actually caught my attention is buried a layer deeper Hedger. Hedger is Dusk's privacy engine sitting inside DuskEVM. It pairs ElGamal homomorphic encryption with ZK proofs to shield transaction amounts and counterparties all while still letting the network verify correctness. In-browser proving clocks in at under 2 seconds. That's not a whitepaper claim at this point; the testnet is live and that functionality is accessible to anyone deploying on it. What this suggests is that Dusk isn't just building an EVM chain with a privacy label slapped on it. The ZK proving is happening at the transaction execution layer, not as an optional wrapper. That's a meaningful architectural choice. Here's my honest hesitation though: testnet activity is developer-driven. I haven't seen public data on how many contracts have actually been deployed since August 10, or whether any of the ZK-shielded transactions are coming from external teams versus internal testing. So the real question are builders actually using Hedger, or is it sitting there waiting? There's a difference between a feature being live and a feature being used. $ACE
#dusk $DUSK @Dusk after the DuskEVM testnet went live on August 10. The headline is EVM compatibility Solidity, Hardhat, familiar tooling. Fine. But what actually caught my attention is buried a layer deeper Hedger.

Hedger is Dusk's privacy engine sitting inside DuskEVM. It pairs ElGamal homomorphic encryption with ZK proofs to shield transaction amounts and counterparties all while still letting the network verify correctness. In-browser proving clocks in at under 2 seconds. That's not a whitepaper claim at this point; the testnet is live and that functionality is accessible to anyone deploying on it.
What this suggests is that Dusk isn't just building an EVM chain with a privacy label slapped on it. The ZK proving is happening at the transaction execution layer, not as an optional wrapper. That's a meaningful architectural choice.

Here's my honest hesitation though: testnet activity is developer-driven. I haven't seen public data on how many contracts have actually been deployed since August 10, or whether any of the ZK-shielded transactions are coming from external teams versus internal testing.

So the real question are builders actually using Hedger, or is it sitting there waiting? There's a difference between a feature being live and a feature being used.
$ACE
·
--
Haussier
Partiellement vrai
$DUSK docs and their Aug 15 piece on SME tokenization and one thing keeps nagging at me. The dual transaction model Moonlight (public, account-based) and Phoenix (shielded UTXO + ZK proofs) is core to the whole pitch. Privacy is opt-in not default. That's actually the interesting part. Moonlight exposes balances and transaction details openly, suited for compliance reporting and exchange integrations. Phoenix hides amounts, sender-receiver links, and balance changes behind cryptographic commitments and nullifiers. But here's what I noticed digging through their Aug 15 post on private market workflows: the entire NPEX use case the €200M+ SME securities pipeline relies on selective disclosure for regulatory and servicing needs, not blanket privacy. Meaning the actual "privacy" in production is tightly scoped, regulator-permissioned visibility, not what most crypto users picture when they hear "zero-knowledge." What genuinely surprised me: 210M+ @Dusk_Foundation is staked securing the network (dusk) , yet DuskEVM and Hedger (the confidential EVM layer) are still on testnet. That's a large staking base propping up infrastructure that hasn't seen real institutional transaction volume yet. I can't confirm what share of actual mainnet transactions are Phoenix vs. Moonlight right now the explorer shows tx types but not a clean breakdown I could pull quickly. Makes me wonder: is privacy here really a feature for end users, or mostly compliance plumbing for the institutions? And does that distinction matter for where the network goes? #dusk @Dusk_Foundation $ACE $TUT
$DUSK docs and their Aug 15 piece on SME tokenization and one thing keeps nagging at me.

The dual transaction model Moonlight (public, account-based) and Phoenix (shielded UTXO + ZK proofs) is core to the whole pitch. Privacy is opt-in not default. That's actually the interesting part.

Moonlight exposes balances and transaction details openly, suited for compliance reporting and exchange integrations. Phoenix hides amounts, sender-receiver links, and balance changes behind cryptographic commitments and nullifiers.

But here's what I noticed digging through their Aug 15 post on private market workflows: the entire NPEX use case the €200M+ SME securities pipeline relies on selective disclosure for regulatory and servicing needs, not blanket privacy.

Meaning the actual "privacy" in production is tightly scoped, regulator-permissioned visibility, not what most crypto users picture when they hear "zero-knowledge."
What genuinely surprised me: 210M+ @Dusk is staked securing the network (dusk) , yet DuskEVM and Hedger (the confidential EVM layer) are still on testnet. That's a large staking base propping up infrastructure that hasn't seen real institutional transaction volume yet.

I can't confirm what share of actual mainnet transactions are Phoenix vs. Moonlight right now the explorer shows tx types but not a clean breakdown I could pull quickly.
Makes me wonder: is privacy here really a feature for end users, or mostly compliance plumbing for the institutions? And does that distinction matter for where the network goes?
#dusk @Dusk
$ACE
$TUT
·
--
Haussier
#dusk $DUSK @Dusk_Foundation explorer data today and one number stopped me cold. Right now, on-chain 252 transactions in the last 24 hours. 231 of those are Moonlight fully public. Only 21 are Phoenix shielded. That's roughly a 91/9 split. The thing that hit me is the irony of it. @Dusk_Foundation entire pitch is privacy-first finance. Moonlight is the account-based, fully transparent model. Phoenix uses ZK proofs and UTXO commitments to hide amounts, sender-receiver links, and balance changes. Two models designed to coexist but users are overwhelmingly choosing the public one. Now I don't know why that is. Could be tooling Phoenix is more friction to use. Could be that the current user base is mostly stakers and provisioners running operational transactions that don't need privacy. Could be something else entirely. I genuinely can't confirm the reason from the explorer alone. What I can say is: if this ratio persists when regulated securities start moving through the network, it would say something interesting about what "compliance-ready privacy" actually means in practice institutions may still default to transparency when a regulator is watching. The compliance layer and the privacy layer are built to work together. But right now users are using one and barely touching the other. Is that a UX problem, a maturity problem, or just... normal for this stage? $PORTAL $GPS
#dusk $DUSK @Dusk explorer data today and one number stopped me cold.

Right now, on-chain 252 transactions in the last 24 hours. 231 of those are Moonlight fully public. Only 21 are Phoenix shielded. That's roughly a 91/9 split.

The thing that hit me is the irony of it. @Dusk entire pitch is privacy-first finance. Moonlight is the account-based, fully transparent model. Phoenix uses ZK proofs and UTXO commitments to hide amounts, sender-receiver links, and balance changes. Two models designed to coexist but users are overwhelmingly choosing the public one.

Now I don't know why that is. Could be tooling Phoenix is more friction to use. Could be that the current user base is mostly stakers and provisioners running operational transactions that don't need privacy. Could be something else entirely. I genuinely can't confirm the reason from the explorer alone.

What I can say is: if this ratio persists when regulated securities start moving through the network, it would say something interesting about what "compliance-ready privacy" actually means in practice institutions may still default to transparency when a regulator is watching.

The compliance layer and the privacy layer are built to work together. But right now users are using one and barely touching the other. Is that a UX problem, a maturity problem, or just... normal for this stage?
$PORTAL
$GPS
·
--
Haussier
$HOLO Market Direction Bearish sharp rally rejected near $0.10 with strong selling pressure. Entry Zone: $0.0890–$0.0940 Stop Loss: $0.1025 Take Profit: TP1: $0.0820 TP2: $0.0760 TP3: $0.0700 Price is showing a clear rejection from the $0.10 area. A failed recovery into the entry zone would favor a short continuation toward the previous breakout levels. Invalidation above $0.1025. #Write2Earn {future}(HOLOUSDT) $PROM {future}(PROMUSDT) $BABY {future}(BABYUSDT)
$HOLO Market Direction Bearish sharp rally rejected near $0.10 with strong selling pressure.

Entry Zone: $0.0890–$0.0940
Stop Loss: $0.1025

Take Profit:
TP1: $0.0820
TP2: $0.0760
TP3: $0.0700

Price is showing a clear rejection from the $0.10 area. A failed recovery into the entry zone would favor a short continuation toward the previous breakout levels.

Invalidation above $0.1025.
#Write2Earn

$PROM
$BABY
·
--
Haussier
$SOL /USDT Short Setup Market Direction: Short bias below 77.00 resistance Entry Zone: 76.40–76.90 Stop Loss: 78.05 Take Profit 1: 75.20 Take Profit 2: 73.80 Take Profit 3: 72.30 Price is consolidating near resistance after a strong move up. A rejection from the 76.50–77.00 area could trigger a pullback toward the lower support zones. Invalidation is a clean break and hold above 78.00. {future}(SOLUSDT) $HOLO {future}(HOLOUSDT) $PROM {future}(PROMUSDT)
$SOL /USDT Short Setup

Market Direction: Short bias below 77.00 resistance

Entry Zone: 76.40–76.90
Stop Loss: 78.05

Take Profit 1: 75.20
Take Profit 2: 73.80
Take Profit 3: 72.30

Price is consolidating near resistance after a strong move up. A rejection from the 76.50–77.00 area could trigger a pullback toward the lower support zones. Invalidation is a clean break and hold above 78.00.
$HOLO
$PROM
·
--
Haussier
$PROM Short Setup Market Direction: Bearish after a sharp rejection from the 3.50 area. Entry Zone: 2.65–2.85 Stop Loss: 3.10 Target 1: 2.35 Target 2: 2.05 Target 3: 1.85 Price has shown strong rejection after the spike toward 3.50. A failure to reclaim 2.85–3.00 could open the way for a deeper pullback toward the previous consolidation zones. Wait for confirmation before entering; volatility is extremely high. {future}(PROMUSDT) $HOLO {future}(HOLOUSDT)
$PROM Short Setup

Market Direction: Bearish after a sharp rejection from the 3.50 area.

Entry Zone: 2.65–2.85
Stop Loss: 3.10
Target 1: 2.35
Target 2: 2.05
Target 3: 1.85

Price has shown strong rejection after the spike toward 3.50. A failure to reclaim 2.85–3.00 could open the way for a deeper pullback toward the previous consolidation zones.

Wait for confirmation before entering; volatility is extremely high.
$HOLO
·
--
Haussier
$ETH Short Setup Market Direction: Bearish price rejected the 1,900–1,920 resistance zone and is showing weakness. Entry Zone: 1,865–1,885 Stop Loss: 1,925 Target 1: 1,840 Target 2: 1,810 Target 3: 1,780 Wait for a retest and rejection around the entry zone rather than chasing the current candle. $BANANA {future}(BANANAUSDT) {future}(ETHUSDT) #Write2Earn
$ETH Short Setup
Market Direction: Bearish price rejected the 1,900–1,920 resistance zone and is showing weakness.
Entry Zone: 1,865–1,885
Stop Loss: 1,925
Target 1: 1,840
Target 2: 1,810
Target 3: 1,780
Wait for a retest and rejection around the entry zone rather than chasing the current candle.
$BANANA


#Write2Earn
$BNB /USDT — Long Setup Entry: 607.0–609.0 Target 1: 612.0 Target 2: 615.0 Stop Loss: 604.5 Price has reclaimed the 608 area with strong momentum after holding the 600–602 zone. A clean hold above 607 keeps the short-term structure bullish. If 612 breaks with strength, 615 becomes the next upside level. {future}(BNBUSDT) $DOGE {future}(DOGEUSDT) #Write2Earn
$BNB /USDT — Long Setup
Entry: 607.0–609.0
Target 1: 612.0
Target 2: 615.0
Stop Loss: 604.5
Price has reclaimed the 608 area with strong momentum after holding the 600–602 zone. A clean hold above 607 keeps the short-term structure bullish. If 612 breaks with strength, 615 becomes the next upside level.
$DOGE

#Write2Earn
·
--
Haussier
$BTC /USDT — LONG SETUP Market Direction: Bullish Entry Zone: $65,120–$65,220 Target 1: $65,300 Target 2: $65,420 Target 3: $65,470 Stop Loss: $65,040 $BTC is holding a strong short-term upward structure on the 15m chart, with higher highs and higher lows forming. A clean hold above $65,100 keeps the bullish setup valid. The key trigger is a break and retest of $65,300; above that level, the 24H high around $65,474 becomes the next major target. Invalidation: 15m close below $65,040. #Write2Earn!
$BTC /USDT — LONG SETUP
Market Direction: Bullish
Entry Zone: $65,120–$65,220
Target 1: $65,300
Target 2: $65,420
Target 3: $65,470
Stop Loss: $65,040

$BTC is holding a strong short-term upward structure on the 15m chart, with higher highs and higher lows forming.
A clean hold above $65,100 keeps the bullish setup valid. The key trigger is a break and retest of $65,300; above that level, the 24H high around $65,474 becomes the next major target.

Invalidation: 15m close below $65,040.
#Write2Earn!
Connectez-vous pour découvrir plus de contenu
Rejoignez la communauté mondiale des adeptes de cryptomonnaies sur Binance Square
⚡️ Suviez les dernières informations importantes sur les cryptomonnaies.
💬 Jugé digne de confiance par la plus grande plateforme d’échange de cryptomonnaies au monde.
👍 Découvrez les connaissances que partagent les créateurs vérifiés.
Adresse e-mail/Nº de téléphone
Plan du site
Préférences de cookies
CGU de la plateforme