I keep returning to Hedger's most eye-catching number: "under 2 seconds."
Dusk Network says its lightweight circuits can generate client-side proofs in a browser within that time. For a confidential EVM flow, that is important. Users should not have to send private inputs to a remote prover just to move an asset.
But proof latency on one device is not market throughput.
Hedger combines homomorphic encryption with zero-knowledge proofs so encrypted balances and transfers can remain verifiable. A single proof completing quickly shows that the interaction may feel usable. It does not tell me how the system behaves across weaker laptops, mobile browsers, many assets, or a burst of simultaneous trades.
The distinction matters because Hedger is on testnet and is aimed at regulated financial applications. An institutional workflow has more than one cryptographic action. It may include eligibility checks, an order, settlement, disclosure, and reporting. Two seconds repeated across several steps can become visible friction.
I would test the claim as a distribution, not an average.
What is the median proving time? What happens at the 95th percentile? How often does memory pressure crash the browser? Can the user resume safely, or must the whole transaction be rebuilt?
Server capacity can be scaled by an operator. Client proving inherits every device a user brings. That moves performance risk from the data center to the edge.
The evidence I want from Dusk is a public benchmark matrix, followed by live testnet completion rates under concurrent demand. A fast demo on a developer machine is a useful start. A regulated market needs predictable completion across ordinary hardware.
Hedger will feel scalable when the slowest reasonable client can still complete the private workflow, not when the fastest proof makes the headline.
@Dusk_Foundation $DUSK #dusk
$ACE $CYS
Dusk Network says its lightweight circuits can generate client-side proofs in a browser within that time. For a confidential EVM flow, that is important. Users should not have to send private inputs to a remote prover just to move an asset.
But proof latency on one device is not market throughput.
Hedger combines homomorphic encryption with zero-knowledge proofs so encrypted balances and transfers can remain verifiable. A single proof completing quickly shows that the interaction may feel usable. It does not tell me how the system behaves across weaker laptops, mobile browsers, many assets, or a burst of simultaneous trades.
The distinction matters because Hedger is on testnet and is aimed at regulated financial applications. An institutional workflow has more than one cryptographic action. It may include eligibility checks, an order, settlement, disclosure, and reporting. Two seconds repeated across several steps can become visible friction.
I would test the claim as a distribution, not an average.
What is the median proving time? What happens at the 95th percentile? How often does memory pressure crash the browser? Can the user resume safely, or must the whole transaction be rebuilt?
Server capacity can be scaled by an operator. Client proving inherits every device a user brings. That moves performance risk from the data center to the edge.
The evidence I want from Dusk is a public benchmark matrix, followed by live testnet completion rates under concurrent demand. A fast demo on a developer machine is a useful start. A regulated market needs predictable completion across ordinary hardware.
Hedger will feel scalable when the slowest reasonable client can still complete the private workflow, not when the fastest proof makes the headline.
@Dusk_Foundation $DUSK #dusk
$ACE $CYS