I compared the privacy paths of DuskEVM and zkEVM. The former supports selective disclosure that reveals more of the nearer financial details.
This week I put DuskEVM’s Hedger+Zedger+Phoenix flow together with the “general EVM circuit + on-chain verification” privacy approach from Polygon zkEVM / Scroll. The conclusion is pretty clear: zkEVM uses ZK proofs to solve “execution correctness.” DuskEVM uses ZK to hide amounts and compliance status while still allowing selective disclosure. They target different objective functions, and in financial scenarios Dusk fits better.
zkEVM’s ZK is for proving correctness of EVM opcodes: state transitions are valid, but balances, transfer amounts, and portfolio distributions are all public—it'somorphic to Ethereum. If you want to hide amounts, you have to layer something like Aztex/Maci on top; the circuit and EVM execution are essentially two separate pieces.
DuskEVM does the opposite. Hedger pulls the @hedged variables into the Zedger note at compile time. In the Phoenix transaction model, PLONK commits the amount into the commitment. On-chain observers only see note consumption; but issuers and regulators, with view keys, can resolve “how much a given address has,” “whether it holds XSC compliant shares,” and “until which day tokens are locked.” The granularity of selective disclosure can go down to the field level.
In finance, the regulation-heavy securities category benefits most from this: bond coupon/interest distribution can’t be fully transparent (so counterparties can’t snoop), and it also can’t be fully opaque (AFM needs assurance). zkEVM’s “fully transparent + ZK correctness” doesn’t satisfy both ends, so you have to bolt on a compliance middleware. Dusk writes Citadel ZK-KYC and the view key into the transaction proof itself. When SBA produces blocks, the circuit verifies compliance internally—so compliance and hiding are part of the same proof.
I deployed an XSC dividend contract on testnet. The resolved view key shows: “alice has 1000 shares + already passed KYC + locked until 2027-03-01.” With zkEVM, you’d need to stitch together three contracts plus an off-chain KYC library to achieve the same logic.
When you build RWA, will you choose zkEVM with an external compliance module, or Dusk’s native selective disclosure?
@Dusk $DUSK #dusk
This week I put DuskEVM’s Hedger+Zedger+Phoenix flow together with the “general EVM circuit + on-chain verification” privacy approach from Polygon zkEVM / Scroll. The conclusion is pretty clear: zkEVM uses ZK proofs to solve “execution correctness.” DuskEVM uses ZK to hide amounts and compliance status while still allowing selective disclosure. They target different objective functions, and in financial scenarios Dusk fits better.
zkEVM’s ZK is for proving correctness of EVM opcodes: state transitions are valid, but balances, transfer amounts, and portfolio distributions are all public—it'somorphic to Ethereum. If you want to hide amounts, you have to layer something like Aztex/Maci on top; the circuit and EVM execution are essentially two separate pieces.
DuskEVM does the opposite. Hedger pulls the @hedged variables into the Zedger note at compile time. In the Phoenix transaction model, PLONK commits the amount into the commitment. On-chain observers only see note consumption; but issuers and regulators, with view keys, can resolve “how much a given address has,” “whether it holds XSC compliant shares,” and “until which day tokens are locked.” The granularity of selective disclosure can go down to the field level.
In finance, the regulation-heavy securities category benefits most from this: bond coupon/interest distribution can’t be fully transparent (so counterparties can’t snoop), and it also can’t be fully opaque (AFM needs assurance). zkEVM’s “fully transparent + ZK correctness” doesn’t satisfy both ends, so you have to bolt on a compliance middleware. Dusk writes Citadel ZK-KYC and the view key into the transaction proof itself. When SBA produces blocks, the circuit verifies compliance internally—so compliance and hiding are part of the same proof.
I deployed an XSC dividend contract on testnet. The resolved view key shows: “alice has 1000 shares + already passed KYC + locked until 2027-03-01.” With zkEVM, you’d need to stitch together three contracts plus an off-chain KYC library to achieve the same logic.
When you build RWA, will you choose zkEVM with an external compliance module, or Dusk’s native selective disclosure?
@Dusk $DUSK #dusk