Aztec shipped Alpha V5 this week after a token-holder governance vote executed onchain, and the headline change is architectural rather than cosmetic: zero-knowledge proofs for private transactions are now generated on the user's own phone or laptop instead of in a remote proving service. Proving a private token transfer natively takes about 2.5 seconds on a consumer laptop, down from 5.2 seconds on V4, and about 6.8 seconds in a browser, down from 12.5. Fully private transaction costs dropped roughly 50%. The speed matters, but the reason to care is that nothing sensitive leaves the device to get the proof made.

  • Client-side proving is the whole point. Most ZK systems generate proofs in centralized data centers, which means handing the prover your inputs. Aztec V5 keeps them local and ships only the proof.
  • Private transfers are now roughly 2x faster and about half the cost. 5.2 seconds to 2.5 natively, 12.5 to 6.8 in a browser.
  • Hybrid contracts are the developer-facing feature. A single contract can hold some state public and some encrypted, so an app does not have to be all-private or all-transparent.
  • This is an alpha, and the governance path was onchain. The upgrade was approved by token holders and executed onchain rather than pushed by the core team.
Remote proving compared with client-side proving In the remote model a user sends private inputs to a centralized prover in a data center which returns a proof. In the client-side model the proof is generated on the user's own device and only the proof is published to the network. WHERE THE PROOF IS MADE A. REMOTE PROVING, THE COMMON DESIGN User device holds the secret private inputs Prover service sees the secret proof Network verifies B. CLIENT-SIDE PROVING, AZTEC ALPHA V5 User device holds the secret and builds the proof 2.5s native, 6.8s in a browser proof only Network verifies without ever seeing inputs genztech.blog
Fig 1 The privacy difference is not cryptographic, it is operational. In design A the prover is a party you must trust with your inputs. In design B there is no such party.

What actually shipped in Alpha V5?

Three things. First, client-side proving: end-to-end private transactions can be generated on consumer hardware, phones included, without a remote proving service in the loop. Second, a full private execution environment on the L2, which is what lets contracts run logic over encrypted state rather than just moving shielded balances around. Third, hybrid public and private smart contracts, so a developer can keep some contract state transparent and some encrypted inside a single application.

RelatedSolana's Alpenglow Kills Proof of History for 150ms Finality

The upgrade was passed by token-holder governance and executed onchain, which is a detail worth noting on its own. Plenty of L2s describe themselves as decentralized while retaining a team-controlled upgrade key. Routing an execution-layer change through an onchain vote is a harder path and a more credible one.

Private token transfer proving time, Aztec V4 compared with Alpha V5 Bar chart of proving times in seconds. Native on a consumer laptop falls from 5.2 seconds on V4 to 2.5 seconds on V5. In a browser it falls from 12.5 seconds on V4 to 6.8 seconds on V5. PROVING A PRIVATE TRANSFER Seconds on a consumer laptop, lower is better Native, V4 5.2s Native, V5 2.5s Browser, V4 12.5s Browser, V5 6.8s Roughly 2x faster in both environments, with fully private transaction costs down about 50%. genztech.blog
Fig 2 · benchmark Figures published by Aztec for a private token transfer. The browser number is the one that decides adoption, because that is where most users will actually meet the network.

Why does it matter where the proof is generated?

A zero-knowledge proof lets you convince a verifier that a statement is true without revealing why it is true. That property holds regardless of who runs the prover. The catch is that to build the proof, the prover needs the witness, which is the private data itself. So if a service generates your proof, that service sees your balances, counterparties and amounts, and the network-level privacy guarantee sits on top of a party that knows everything.

This is the gap between "the chain cannot see your data" and "nobody can see your data." Most ZK rollups optimise for throughput and put proving in a data center, which is a reasonable trade for scaling but does not deliver privacy in any meaningful sense. Aztec's design puts the prover where the secret already lives. That removes a trusted party, and it also removes a subpoena target, a breach target and a censorship chokepoint.

Why is it still seconds rather than milliseconds?

Because proof generation is genuinely expensive computation, and consumer hardware is the constraint. Building a proof for a private transfer means executing the transaction inside a circuit and running a large number of field operations and polynomial commitments over the resulting trace. Data-center provers throw many cores and often GPUs at that. A laptop has neither, and a browser adds a WebAssembly sandbox and limited threading on top, which is exactly why the browser figure sits at 6.8 seconds against 2.5 natively.

Halving both numbers in one release is a meaningful engineering result, and the direction of travel is the point: the same class of optimisation applied again brings a browser transfer under 4 seconds, which is roughly where users stop noticing.

 Aztec Alpha V5Typical ZK rollupShielded pool app
Where proofs are madeOn the user's deviceCentralized prover networkUsually on device
Who sees your inputsOnly youThe prover operatorOnly you
What is privateContract execution and stateNothing, ZK is used for scalingTransfers within one pool
ProgrammabilityHybrid public and private contractsFull, but fully transparentLimited to the pool's rules
Cost of a private transferRoughly half of V4Not applicableVaries by pool
Main trade-offSeconds of local computeNo privacyNarrow use case
  1. V4Private transfer proves in 5.2s natively and 12.5s in a browser the baseline this release halves
  2. Jul 2026Token-holder governance approves the V5 upgrade executed onchain, not by the core team
  3. This weekAlpha V5 goes live with client-side proving and hybrid contracts 2.5s native, 6.8s browser, costs down about 50%
  4. NextApplications built on hybrid public and private state the alpha label comes off when real apps run on it

Who does this actually affect?

Three groups, in decreasing order of immediacy. Developers building anything where the state itself is sensitive, which includes payroll, private order books, sealed-bid auctions, credit scoring and identity attestations, now have a programmable environment rather than a fixed shielded pool. Regulated institutions that have wanted onchain settlement without publishing their positions get an architecture where the confidential part never leaves their own infrastructure. And ordinary users get the least glamorous but most important benefit: the privacy claim no longer depends on trusting an operator.

RelatedLayer 2 rollups: how blockchains finally scaled

The obvious caveat is the word alpha. This is a live execution layer running new cryptography under new governance, and the sensible posture is to build against it rather than to move significant value through it.

What to watch · next two quarters
  • Browser proving under 4 seconds. That is the threshold where a private transaction feels like a normal one. V5 got halfway there.
  • Mobile numbers, published. Phones are the hardest target and Aztec has claimed them. Independent measurements on mid-range Android hardware would settle it.
  • Real hybrid contracts in production. The feature only matters if applications ship that mix public and encrypted state, rather than demos.
  • Whether other L2s follow. If client-side proving becomes an expectation rather than a differentiator, the centralized-prover design gets harder to defend.

Our take

The performance numbers will get the attention and they are the less interesting half. A 2x speedup is an engineering milestone that any competent team can eventually match. What is hard to copy is the architectural commitment: once you decide the prover runs on the user's device, you inherit a permanent performance handicap against anyone proving in a data center, and you have to close it with cryptography and compiler work rather than with hardware. Most teams take the easier path and describe the result as privacy anyway.

Aztec took the harder one, and the result is that its privacy claim survives the question that breaks most of them: what happens if the operator is compromised or compelled? Here the answer is that there is no operator holding anything. That is worth more than two seconds.

What we would temper is the timeline. Alpha means alpha, hybrid contracts are a new programming model that developers have to learn, and the network's usefulness now depends on applications that do not exist yet. Judge this in six months by what got built on it, not by the proving benchmark.

Primary sources

Original analysis by GenZTech, built from Aztec's Alpha V5 release figures and the public design documentation for client-side proving. Story confirmed against The Block's report and crypto.news. Nothing here is investment advice.