Went back to that same group chat today that I've been avoiding because someone pushed back saying: "okay, Moonlight and Phoenix are neat, but that's all base-layer stuff. So I have a question now like that person. What happens when an actual dev wants to build something on it?" Fair pushback, and I didn't have a great answer last time. Turns out that's exactly the gap DuskEVM is for. It's the EVM-compatible application layer sitting on top of the base chain — meaning a Solidity dev doesn't have to learn a whole new language or toolchain to build here, they get a familiar entry point into a chain that already handles the privacy/compliance split natively underneath. The part I hadn't clocked: EVM environments are usually transparent by default, that's just how the tooling works. So plugging a "reviewable privacy" chain into an EVM-compatible layer isn't free, someone has to actually solve that seam. That's what Hedger is — Dusk's privacy module built specifically for confidential EVM workflows, using homomorphic encryption and ZK proofs so contract execution can stay private but still be disclosed to whoever's actually authorized to check it. So, the stack is starting to make more sense as layers, not just one feature. Moonlight/Phoenix handles the transaction-level privacy choice, DuskEVM provides a normal path in, and Hedger is the piece ensuring that path doesn't just inherit theEVM's "everything's public" default by accident.
Caveat, same as last time: DuskEVM mainnet isn't live yet, it's coming. Hedger's "reviewable, not just hidden" claim is a design goal until real contracts are running through it and someone's actually pulled the disclosure lever on a live workflow.
Genuinely curious what people think though: If you were building on a chain like this, what would worry you most? 🔧 Tooling maturity 🔍 How disclosure actually works ⏱️ Mainnet timeline 🤝 Whether devs will actually show up
#dusk $DUSK @Dusk Went back to that same group chat today because someone pushed back: "okay, Moonlight and Phoenix are neat, but that's all base-layer stuff. What happens when an actual dev wants to build something on it?"😅 Fair pushback, and I didn't have a great answer last time. Turns out that's exactly the gap DuskEVM is for. It's the EVM-compatible application layer sitting on top of the base chain — meaning a Solidity dev doesn't have to learn a whole new language or toolchain to build here, they get a familiar entry point into a chain that already handles the privacy/compliance split natively underneath.
The part I hadn't clocked: EVM environments are usually transparent by default, that's just how the tooling works. So plugging a "reviewable privacy" chain into an EVM-compatible layer isn't free, someone has to actually solve that seam.
That's what Hedger is — Dusk's privacy module built specifically for confidential EVM workflows, using homomorphic encryption and ZK proofs so contract execution can stay private but still be disclosed to whoever's actually authorized to check it.
So the stack is starting to make more sense as layers, not one feature: Moonlight/Phoenix handle the transaction-level privacy choice, DuskEVM gives builders a normal path in, and Hedger is the piece making sure that path doesn't just inherit EVM's "everything's public" default by accident.
Caveat, same as last time: DuskEVM mainnet isn't live yet, it's coming. Hedger's "reviewable, not just hidden" claim is a design goal until real contracts are running through it and someone's actually pulled the disclosure lever on a live workflow.
Genuinely curious what people think though: If you were building on a chain like this, what would worry you most?
Someone in a group chat said "on-chain, you're either fully public or you go full privacy-coin, there's no in-between" and I almost just agreed because that's the default assumption😅. Except that's not actually true, it's just true for most chains, which isn't the same thing.
Dusk runs two separate transaction models side by side😁, not privacy as a bolt-on setting. One's called Moonlight🌕 — it's transparent and account-based, basically the normal Ethereum-style model where balances are public and a signature proves you own the funds. The other's Phoenix🔥 — UTXO-based, and instead of the network checking your balance directly, you submit a zero-knowledge proof that the transaction is valid (right amount in, right amount out, funds not double-spent) without revealing what those amounts actually are. Both run through the same transfer contract. Same rules underneath — no double-spending, no forging transactions, no tampering after the fact — just proven two different ways. Moonlight proves it in the open. Phoenix proves it privately. That's the actual point most "privacy chain" pitches skip: privacy isn't one global switch. It's a choice per transaction, and the guarantees underneath don't get weaker in either mode, they just get proven differently. Where this actually matters is a regulated trade doesn't get to pick "public forever" or "hidden forever" — sometimes it needs to be invisible to competitors and fully visible to one specific auditor. That's the harder design problem, and it's the one @Dusk built its base layer around instead of retrofitting later. Caveat: this is the base-chain design, live today. The newer app-layer stuff (DuskEVM, Hedger's disclosure tooling) sits on top of this and I'm not folding claims about that into what I just described.
Curious where people land on this: Which would you actually want per-transaction control over? 👁️ Who sees my balance 🧾 Who sees the counterparty 💵 Who sees the amount 🔓 None of it, full transparency's fine #dusk $DUSK