#

Inside Aztec

Inside
Aztec

purple_2
Aztec Network
28 Oct
xx min read

Your Favorite DeFi Apps, Now With Privacy

How Aztec is Adding Privacy to Apps Across the Ethereum Ecosystem

Every time you swap tokens on Uniswap, deposit into a yield vault, or vote in a DAO, you're broadcasting your moves to the world. Anyone can see what you own, where you trade, how much you invest, and when you move your money.

Tracking and analysis tools like Chainalysis and TRM are already extremely advanced, and will only grow stronger with advances in AI in the coming years. The implications of this are that the ‘pseudo-anonymous’ wallets on Ethereum are quickly becoming linked to real-world identities. This is concerning for protecting your personal privacy, but it’s also a major blocker in bringing institutions on-chain with full compliance for their users. 

Until now, your only option was to abandon your favorite apps and move to specialized privacy-focused apps or chains with varying degrees of privacy. You'd lose access to the DeFi ecosystem as you know it now, the liquidity you depend on, and the community you're part of. 

What if you could keep using Uniswap, Aave, Yearn, and every other app you love, but with your identity staying private? No switching chains. Just an incognito mode for your existing on-chain life? 

If you’ve been following Aztec for a while, you would be right to think about Aztec Connect here, which was hugely popular with $17M TVL and over 100,000 active wallets, but was sunset in 2024 to focus on bringing a general-purpose privacy network to life. 

Read on to learn how you’ll be able to import privacy to any L2, using one of the many privacy-focused bridges that are already built. 

The Aztec Network  

Aztec is a fully decentralized, privacy-preserving L2 on Ethereum. You can think of Aztec as a private world computer with full end-to-end programmable privacy. A private world computer extends Ethereum to add optional privacy at every level, from identity and transactions to the smart contracts themselves. 

On Aztec, every wallet is a smart contract that gives users complete control over which aspects they want to make public or keep private. 

Aztec is currently in Testnet, but will have multiple privacy-preserving bridges live for its mainnet launch, unlocking a myriad of privacy preserving features.

Bringing Privacy to You

Now, several bridges, including Wormhole, TRAIN, and Substance, are connecting Aztec to other chains, adding a privacy layer to the L2s you already use. Think of it as a secure tunnel between you and any DeFi app on Ethereum, Arbitrum, Base, Optimism, or other major chains.

Here's what changes: You can now use any DeFi protocol without revealing your identity. Furthermore, you can also unlock brand new features that take advantage of Aztec’s private smart contracts, like private DAO voting or private compliance checks. 

Here's what you can do:

  • Use DeFi without revealing your portfolio: trade on Uniswap or deposit into Yearn without broadcasting your strategy to the world
  • Donate to causes without being tracked: support projects on Base without linking donations to your identity
  • Vote in DAOs without others seeing your choices: participate in governance on Arbitrum while keeping your votes private
  • Prove you're legitimate without doxxing yourself: pass compliance checks or prove asset ownership without revealing which specific assets you hold
  • Access exclusive perks without revealing which NFTs you own: unlock token-gated content on Optimism without showing your entire collection

The apps stay where they are. Your liquidity stays where it is. Your community stays where it is. You just get a privacy upgrade.

How It Actually Works 

Let's follow Alice through a real example.

Alice wants to invest $1,000 USDC into a yield vault on Arbitrum without revealing her identity. 

Step 1: Alice Sends Funds Through Aztec

Alice moves her funds into Aztec's privacy layer. This could be done in one click directly in the app that she’s already using if the app has integrated one of the bridges. Think of this like dropping a sealed envelope into a secure mailbox. The funds enter a private space where transactions can't be tracked back to her wallet.

Step 2: The Funds Arrive at the DeFi Vault

Aztec routes Alice's funds to the Yearn vault on Arbitrum. The vault sees a deposit and issues yield-earning tokens. But there's no way to trace those tokens back to Alice's original wallet. Others can see someone made a deposit, but they have no idea who.

Step 3: Alice Gets Her Tokens Back Privately

The yield tokens arrive in Alice's private Aztec wallet. She can hold them, trade them privately, or eventually withdraw them, without anyone connecting the dots.

Step 4: Alice Earns Yield With Complete Privacy

Alice is earning yield on Arbitrum using the exact same vault as everyone else. But while other users broadcast their entire investment strategy, Alice's moves remain private. 

The difference looks like this:

Without privacy: "Wallet 0x742d...89ab deposited $5,000 into Yearn vault at 2:47 PM"

With Aztec privacy: "Someone deposited funds into Yearn vault" (but who? from where? how much? unknowable).

In the future, we expect apps to directly integrate Aztec, making this experience seamless for you as a user. 

The Developers Behind the Bridges 

While Aztec is still in Testnet, multiple teams are already building bridges right now in preparation for the mainnet launch.

Projects like Substance Labs, Train, and Wormhole are creating connections between Aztec and major chains like Optimism, Unichain, Solana, and Aptos. This means you'll soon have private access to DeFi across nearly every major ecosystem.

Aztec has also launched a dedicated cross-chain catalyst program to support developers with grants to build additional bridges and apps. 

Unifying Liquidity Across Ethereum L2s

L2s have sometimes received criticism for fragmenting liquidity across chains. Aztec is taking a different approach. Instead, Aztec is bringing privacy to the liquidity that already exists. Your funds stay on Arbitrum, Optimism, Base, wherever the deepest pools and best apps already live. Aztec doesn't compete for liquidity, it adds privacy to existing liquidity.

You can access Uniswap's billions in trading volume. You can tap into Aave's massive lending pools. You can deposit into Yearn's established vaults, all without moving liquidity away from where it's most useful.

The Future of Private DeFi

We’re rolling out a new approach to how we think about L2s on Ethereum. Rather than forcing users to choose between privacy and access to the best DeFi applications, we’re making privacy a feature you can add to any protocol you're already using. As more bridges go live and applications integrate Aztec directly, using DeFi privately will become as simple as clicking a button—no technical knowledge required, no compromise on the apps and liquidity you depend on.

While Aztec is currently in testnet, the infrastructure is rapidly taking shape. With multiple bridge providers building connections to major chains and a dedicated catalyst program supporting developers, the path to mainnet is clear. Soon, you'll be able to protect your privacy while still participating fully in the Ethereum ecosystem. 

If you’re a developer and want a full technical breakdown, check out this post. To stay up to date with the latest updates for network operators, join the Aztec Discord and follow Aztec on X.

Most Recent
Aztec Network
22 Oct
xx min read

Bringing Private Over-The-Counter (OTC) Swaps to Crypto

Transparent OTC Trades Are Holding the Industry Back

OTC trading is fundamental to how crypto markets function. It enables better price negotiations than what you'll find on public order books and facilitates trading of illiquid assets that barely exist on exchanges. Without OTC markets, institutional crypto trading would be nearly impossible. But here's the massive problem: every single OTC transaction leaves a permanent, public trace. 

Let's say you're a fund manager who needs to sell 1,000 BTC for USDC on Base. In a traditional OTC trade, your Bitcoin leaves your wallet and becomes visible to everyone on Bitcoin's blockchain. Through cross-chain settlement, USDC then arrives in your Base wallet, which is also visible to everyone on Base's blockchain. 

At this point, block explorers and analytics firms can connect these transactions through pattern analysis. As a result, your trading patterns, position sizes, and timing become public data, exposing your entire strategy.

This isn't just about privacy; transparent OTC creates serious operational and strategic risks. These same concerns have moved a significant portion of traditional markets to private off-exchange trades. 

Why Traditional Finance Moved to Private Markets

In TradFi, institutions don't execute large trades on public order books for many reasons. In fact, ~13% of all stocks in the US are now traded in dark pools, and more than 50% of trades are now off-exchange. 

They use private networks, dark pools, and OTC desks specifically because:

  • Strategy Protection: Your competitors can't front-run your moves
  • Better Execution: No market impact from revealing large positions
  • Regulatory Compliance: Meet reporting requirements without public disclosure
  • Operational Security: Protect proprietary trading algorithms and relationships

While OTC trading is already a major part of the crypto industry, without privacy, true institutional participation will never be practical. 

Now, Aztec is making this possible. 

Moving Whale-Sized Bags Privately on Aztec

We built an open-source private OTC trading system using Aztec Network's programmable privacy features. Because Aztec allows users to have private, programmable, and composable private state, users aren’t limited to only owning and transferring digital assets privately, but also programming and composing them via smart contracts.

If you’re new to Aztec, you can think of the network as a private world computer, with full end-to-end programmable privacy. A private world computer extends Ethereum to add optional privacy at every level, from identity and transactions to the smart contracts themselves. 

To build a private OTC desk, we leveraged all these tools provided by Aztec to implement a working proof of concept. Our private OTC desk is non-custodial and leverages private smart contracts and client-side proving to allow for complete privacy of the seller and buyer of the OTC.

How It Actually Works

For Sellers:

  1. Deploy a private escrow contract (only you know it exists at this stage)
  2. Initialize contract and set the terms (asset type, quantity, price)
  3. Deposit your assets into the contract
  4. After it’s been deployed, call a private API (the order book service)

For Buyers:

  1. Discover available orders through our privacy-preserving API
  2. Select trades that match your criteria
  3. Complete the seller's partial note with your payment
  4. Execute atomic swap – you get their assets, they get your payment

The Magic: Partial Notes are the technical breakthrough that make collaborative, asynchronous private transactions possible. Sellers create incomplete payment commitments that buyers can finish without revealing the seller's identity. It's like leaving a blank check that only the right person can cash, but neither party knows who the other is.

Privacy guarantees include: 

  • Complete Privacy: Neither party knows who they're trading with
  • Strategy Protection: Your trading patterns stay private
  • Market Impact Minimization: No public signals about large movements
  • Non-custodial: Direct peer-to-peer settlement, no intermediaries

Key Innovations

Private Contract Deployment: Unlike public decentralized exchanges where smart contracts are visible on the blockchain, the escrow contracts in this system are deployed privately, meaning that only the participants involved in the transaction know these contracts exist.

Partial Note Mechanism: This system uses cryptographic primitives that enable incomplete commitments to be finalized or completed by third parties, all while preventing those third parties from revealing or accessing any pre-existing information that was part of the original commitment.

Privacy-Preserving Discovery: The orderflow service maintains knowledge of aggregate trading volumes and overall market activity, but it cannot see the details of individual traders, including their specific trade parameters or personal identities.

Atomic Execution: The smart contract logic is designed to ensure that both sides of a trade occur simultaneously in a single atomic operation, meaning that if any part of the transaction fails, the entire transaction is rolled back and neither party's assets are transferred.

Build with us!

Our prototype for this is open-sourced here, and you can read about the proof of concept directly from the developer here

We're inviting teams to explore, fork, and commercialize this idea. The infrastructure for private institutional trading needs to exist, and Aztec makes it possible today. Whether you're building a private DEX, upgrading your OTC desk, or exploring new DeFi primitives, this codebase is your starting point. 

The traditional finance world conducts trillions in private OTC trades. It's time to bring that scale to crypto, privately.

To stay up to date with the latest updates for network operators, join the Aztec Discord and follow Aztec on X.

Aztec Network
15 Oct
xx min read

Your Private Money Yearns for a Private Economy

Watch this: Alice sends Zcash. Bob receives USDC on Aztec. Nobody, not even the system facilitating it, knows who Alice or Bob are.

And Bob can now do something with that money. Privately.

This is the connection between private money and a private economy where that money can actually be used.

Zcash has already achieved something monumental: truly private money. It’s the store of value that Bitcoin promised (but made transparent). Like, digital gold that actually stays hidden.

But here's the thing about gold - you don't buy coffee with gold bars. You need an economy where that value can flow, work, and grow. Privately.

Money Under the Mattress

While other projects are trying to bolt privacy onto existing chains as an afterthought, Zcash is one of the oldest privacy projects in Web3. It's achieved what dozens of projects are still chasing: a truly private store of value.

Total Shielded ZEC Value (USD): Sep 16 - Oct 14 | Source: zkp.baby/

This is critical infrastructure for freedom. The ability to store value privately is a fundamental right, a hedge against surveillance, and a given when using cash. We need a system that provides the same level of privacy guarantees as cash. Right now, there's over $1.1 billion sitting in Zcash's shielded pool, private wealth that's perfectly secure but essentially frozen.

Why frozen? Because the moment that shielded $ZEC tries to do anything beyond basic transfers: earn yield, get swapped for stablecoins, enter a liquidity pool, it must expose itself. The privacy in this format is destroyed.

This isn't Zcash's failure. They built exactly what they set out to build: the world's best private store of value. The failure is that the rest of crypto hasn't built where that value can actually work.

The Privacy Landscape Has an Imbalance

What happens when you want to do more than just send money? What happens when you want privacy after you transfer your money?

Private Digital Money (i.e., “Transfer Privacy,” largely solved by Zcash):

  • Zcash: est. 2016
  • Everyone else: building variants of digital money at the transaction or identity level
    • Monero
    • Ethereum privacy pools
    • 0xbow
    • Payy
    • Every privacy stablecoin project
    • Every confidential L2
    • Every privacy project you've ever heard of

Private World Computer (i.e., After-the-Transfer Privacy):

  • Aztec

Everyone else is competing to build better ways to hide money. Zcash has already built the private store of value, and Aztec has built the only way to use hidden money.

The Locked Liquidity Problem

Here's the trillion-dollar question: What good is private money if you can't use it?

Right now, Zcash's shielded pool contains billions in value. This is money in high-security vaults. But unlike gold in vaults that can be collateralized, borrowed against, or deployed, this private value just sits there.

Every $ZEC holder faces two impossible choices:

  1. Keep it shielded and forfeit all utility
  2. Unshield it to use it and forfeit all privacy

Our demo breaks this false sense of choice. For the first time, shielded value can move to a place where it remains private AND becomes useful.

The Private World Computer

Here's how you can identify whether you’re dealing with a private world computer, or just private digital money:

Without a private world computer (every other privacy solution):

  • Receive salary privately → Can't invest it
  • Store savings privately → Can't earn yield
  • Send money privately → Recipient can't use it privately

With a private world computer (only Aztec):

  • Receive salary privately → Invest it privately
  • Store savings privately → Earn APY privately
  • Send payment privately → Recipient spends it privately

This is basic financial common sense. Your money should grow. It should work. It should be useful.

The technical reality is that this requires private smart contracts. Aztec is building the only way to interact privately with smart contracts. These smart contracts themselves can remain completely hidden. Your private money can finally do what money is supposed to do: work for you.

What We Actually Built

Our demo proves these two worlds can connect:

  1. The Vault: Zcash
  2. The Engine: Aztec (where private money becomes useful)

We built the bridge between storing privately and doing privately.

The technical innovation - "partial notes" - are like temporary lockboxes that self-destruct after one use. Money can be put privately into these lockboxes, and a key can be privately handed to someone to unlock it. No one knows who put the money in, where the key came from, or who uses the key. You can read more about how they work here. But what matters isn't the mechanism. 

What matters is that Alice's Zcash can become Bob's working capital on Aztec without anyone knowing about either of them.

As a result, Bob receives USDC that he can:

  • Earn yield on
  • Trade with
  • Pay suppliers with
  • Build a business on
  • All privately

Why This Required Starting from Scratch (and 8 years of building)

You can't bolt privacy onto existing systems. You can't take Ethereum and make it private. You can't take a transparent smart contract platform and add privacy as a feature.

Aztec had to be built from the ground up as a private world computer because after-the-transfer privacy requires rethinking everything:

  • How state is managed
  • How contracts execute
  • How proofs are generated
  • How transactions are ordered

This is why there's only one name building fully private smart contracts. From the beginning, Aztec has been inspired by the work Zcash has done to create a private store of value. That’s what led to the vision for a private world computer.

Everyone else is iterating on the same transfer privacy problem. Aztec solves a fundamentally different problem.

The Obvious Future

Once you see it, you can't unsee it: Privacy without utility is only the first step.

Every privacy project will eventually need what Aztec built. Because their users will eventually ask: "Okay, my money is private... now what?"

  • Zcash users will want their $ZEC to earn yield
  • Privacy pool users will want to do more than just mix
  • Private stablecoin users will want to actually… use their stablecoins

This demo that connects Zcash to Aztec is the first connection between the old world (private transfers) and the new world (private everything else).

What This Means

For Zcash Holders: Your shielded $ZEC can finally do something without being exposed.

For Developers: Stop trying to build better mattresses to hide money under. Start building useful applications on the only platform that keeps them private. 

For the Industry: The privacy wars are over. There's transfer privacy (solved by Zcash) and after-the-transfer privacy (just Aztec).

What’s Next? 

This demo is live. The code is open source. The bridge between private money and useful private money exists.

But this is just the beginning. Every privacy project needs this bridge. Every private payment network needs somewhere for those payments to actually be used.

We're not competing with transfer privacy. We're continuing it.

Your private money yearns for the private economy.

Welcome to after-the-transfer privacy. Welcome to Aztec.

Aztec Network
8 Oct
xx min read

Aztec: The Private World Computer

Privacy has emerged as a major driver for the crypto industry in 2025. We’ve seen the explosion of Zcash, the Ethereum Foundation’s refocusing of PSE, and the launch of Aztec’s testnet with over 24,000 validators powering the network. Many apps have also emerged to bring private transactions to Ethereum and Solana in various ways, and exciting technologies like ZKPassport that privately bring identity on-chain using Noir have become some of the most talked about developments for ushering in the next big movements to the space. 

Underpinning all of these developments is the emerging consensus that without privacy, blockchains will struggle to gain real-world adoption. 

Without privacy, institutions can’t bring assets on-chain in a compliant way or conduct complex swaps and trades without revealing their strategies. Without privacy, DeFi remains dominated and controlled by advanced traders who can see all upcoming transactions and manipulate the market. Without privacy, regular people will not want to move their lives on-chain for the entire world to see every detail about their every move. 

While there's been lots of talk about privacy, few can define it. In this piece we’ll outline the three pillars of privacy and gives you a framework for evaluating the privacy claims of any project. 

The Three Pillars of Privacy 

True privacy rests on three essential pillars: transaction privacy, identity privacy, and computational privacy. It is only when we have all three pillars that we see the emergence of a private world computer. 

Transaction: What is being sent?

Transaction privacy means that both inputs and outputs are not viewable by anyone other than the intended participants. Inputs include any asset, value, message, or function calldata that is being sent. Outputs include any state changes or transaction effects, or any transaction metadata caused by the transaction. Transaction privacy is often primarily achieved using a UTXO model (like Zcash or Aztec’s private state tree). If a project has only the option for this pillar, it can be said to be confidential, but not private. 

Identity: Who is involved?

Identity privacy means that the identities of those involved are not viewable by anyone other than the intended participants. This includes addresses or accounts and any information about the identity of the participants, such as tx.origin, msg.sender, or linking one’s private account to public accounts. Identity privacy can be achieved in several ways, including client-side proof generation that keeps all user info on the users’ devices. If a project has only the option for this pillar, it can be said to be anonymous, but not private. 

Computation: What happened? 

Computation privacy means that any activity that happens is not viewable by anyone other than the intended participants. This includes the contract code itself, function execution, contract address, and full callstack privacy. Additionally, any metadata generated by the transaction is able to be appropriately obfuscated (such as transaction effects, events are appropriately padded, inclusion block number are in appropriate sets). Callstack privacy includes which contracts you call, what functions in those contracts you’ve called, what the results of those functions were, any subsequent functions that will be called after, and what the inputs to the function were. A project must have the option for this pillar to do anything privately other than basic transactions. 

From private money to a private world computer 

Bitcoin ushered in a new paradigm of digital money. As a permissionless, peer-to-peer currency and store of value, it changed the way value could be sent around the world and who could participate. Ethereum expanded this vision to bring us the world computer, a decentralized, general-purpose blockchain with programmable smart contracts. 

Given the limitations of running a transparent blockchain that exposes all user activity, accounts, and assets, it was clear that adding the option to preserve privacy would unlock many benefits (and more closely resemble real cash). But this was a very challenging problem. Zcash was one of the first to extend Bitcoin’s functionality with optional privacy, unlocking a new privacy-preserving UTXO model for transacting privately. As we’ll see below, many of the current privacy-focused projects are working on similar kinds of private digital money for Ethereum or other chains. 

Now, Aztec is bringing us the final missing piece: a private world computer.

A private world computer is fully decentralized, programmable, and permissionless like Ethereum and has optional privacy at every level. In other words, Aztec is extending all the functionality of Ethereum with optional transaction, identity, and computational privacy. This is the only approach that enables fully compliant, decentralized applications to be built that preserve user privacy, a new design space that we see as ushering in the next Renaissance for the space. 

Where are we now? 

Private digital money

Private digital money emerges when you have the first two privacy pillars covered - transactions and identity - but you don’t have the third - computation. Almost all projects today that claim some level of privacy are working on private digital money. This includes everything from privacy pools on Ethereum and L2s to newly emerging payment L1s like Tempo and Arc that are developing various degrees of transaction privacy 

When it comes to digital money, privacy exists on a spectrum. If your identity is hidden but your transactions are visible, that's what we call anonymous. If your transactions are hidden but your identity is known, that's confidential. And when both your identity and transactions are protected, that's true privacy. Projects are working on many different approaches to implement this, from PSE to Payy using Noir, the zkDSL built to make it intuitive to build zk applications using familiar Rust-like syntax. 

The Private World Computer 

Private digital money is designed to make payments private, but any interaction with more complex smart contracts than a straightforward payment transaction is fully exposed. 

What if we also want to build decentralized private apps using smart contracts (usually multiple that talk to each other)? For this, you need all three privacy pillars: transaction, identity, and compute. 

If you have these three pillars covered and you have decentralization, you have built a private world computer. Without decentralization, you are vulnerable to censorship, privileged backdoors and inevitable centralized control that can compromise privacy guarantees. 

Aztec: the Private World Computer 

What exactly is a private world computer? A private world computer extends all the functionality of Ethereum with optional privacy at every level, so developers can easily control which aspects they want public or private and users can selectively disclose information. With Aztec, developers can build apps with optional transaction, identity, and compute privacy on a fully decentralized network. Below, we’ll break down the main components of a private world computer.

Private Smart Contracts 

A private world computer is powered by private smart contracts. Private smart contracts have fully optional privacy and also enable seamless public and private function interaction. 

Private smart contracts simply extend the functionality of regular smart contracts with added privacy. 

As a developer, you can easily designate which functions you want to keep private and which you want to make public. For example, a voting app might allow users to privately cast votes and publicly display the result. Private smart contracts can also interact privately with other smart contracts, without needing to make it public which contracts have interacted. 

Aztec’s Three Pillars of Privacy

Transaction: Aztec supports the optionality for fully private inputs, including messages, state, and function calldata. Private state is updated via a private UTXO state tree.

Identity: Using client-side proofs and function execution, Aztec can optionally keep all user info private, including tx.origin and msg.sender for transactions. 

Computation: The contract code itself, function execution, and call stack can all be kept private. This includes which contracts you call, what functions in those contracts you’ve called, what the results of those functions were, and what the inputs to the function were. 

Decentralization

A decentralized network must be made up of a permissionless network of operators who run the network and decide on upgrades. Aztec is run by a decentralized network of node operators who propose and attest to transactions. Rollup proofs on Aztec are also run by a decentralized prover network that can permissionlessly submit proofs and participate in block rewards. Finally, the Aztec network is governed by the sequencers, who propose, signal, vote, and execute network upgrades.

What Can You Build with a Private World Computer?

Private DeFi

A private world computer enables the creation of DeFi applications where accounts, transactions, order books, and swaps remain private. Users can protect their trading strategies and positions from public view, preventing front-running and maintaining competitive advantages. Additionally, users can bridge privately into cross-chain DeFi applications, allowing them to participate in DeFi across multiple blockchains while keeping their identity private despite being on an existing transparent blockchain.

Private Dark Pools

This technology makes it possible to bring institutional trading activity on-chain while maintaining the privacy that traditional finance requires. Institutions can privately trade with other institutions globally, without having to touch public markets, enjoying the benefits of blockchain technology such as fast settlement and reduced counterparty risk, without exposing their trading intentions or volumes to the broader market.

Private RWAs & Stablecoins

Organizations can bring client accounts and assets on-chain while maintaining full compliance. This infrastructure protects on-chain asset trading and settlement strategies, ensuring that sophisticated financial operations remain private. A private world computer also supports private stablecoin issuance and redemption, allowing financial institutions to manage digital currency operations without revealing sensitive business information.

Compliant Apps

Users have granular control over their privacy settings, allowing them to fine-tune privacy levels for their on-chain identity according to their specific needs. The system enables selective disclosure of on-chain activity, meaning users can choose to reveal certain transactions or holdings to regulators, auditors, or business partners while keeping other information private, meeting compliance requirements.

Let’s build

The shift from transparent blockchains to privacy-preserving infrastructure is the foundation for bringing the next billion users on-chain. Whether you're a developer building the future of private DeFi, an institution exploring compliant on-chain solutions, or simply someone who believes privacy is a fundamental right, now is the time to get involved.

Follow Aztec on X to stay updated on the latest developments in private smart contracts and decentralized privacy technology. Ready to contribute to the network? Run a node and help power the private world computer. 

The next Renaissance is here, and it’s being powered by the private world computer.

Aztec Network
24 Sep
xx min read

Testnet Retro - 2.0.3 Network Upgrade

Special thanks to Santiago Palladino, Phil Windle, Alex Gherghisan, and Mitch Tracy for technical updates and review.

On September 17th, 2025, a new network upgrade was deployed, making Aztec more secure and flexible for home stakers. This upgrade, shipped with all the features needed for a fully decentralized network launch, includes a completely redesigned slashing system that allows inactive or malicious operators to be removed, and does not penalize home stakers for short outages. 

With over 23,000 operators running validators across 6 continents (in a variety of conditions), it is critical not to penalize nodes that temporarily drop due to internet connectivity issues. This is because users of the network are also found across the globe, some of whom might have older phones. A significant effort was put into shipping a low-memory proving mode that allows older mobile devices to send transactions and use privacy-preserving apps. 

The network was successfully deployed, and all active validators on the old testnet were added to the queue of the new testnet. This manual migration was only necessary because major upgrades to the governance contracts had gone in since the last testnet was deployed. The new testnet started producing blocks after the queue started to be “flushed,” moving validators into the rollup. Because the network is fully decentralized, the initial flush could have been called by anyone. The network produced ~2k blocks before an invalid block made it to the chain and temporarily stalled block production. Block production is now restored and the network is healthy. This post explains what caused the issue and provides an update on the current status of the network. 

Note: if you are a network operator, you must upgrade to version 2.0.3 and restart your node to participate in the latest testnet. If you want to run a node, it’s easy to get started.

What’s included in the upgrade? 

This upgrade was a team-wide effort that optimized performance and implemented all the mechanisms needed to launch Aztec as a fully decentralized network from day 1. 

Feature highlights include: 

  • Improved node stability: The Aztec node software is now far more stable. Users will see far fewer crashes and increased performance in terms of attestations and blocks produced. This translates into a far better experience using testnet, as transactions get included much faster.
  • Boneh–Lynn–Shacham (BLS) keys: When a validator registers on the rollup, they also provide keys that allow BLS signature aggregation. This unlocks future optimizations where signatures can be combined via p2p communication, then verified on Ethereum, while proving that the signatures come from block proposers.
  • Low-memory proving mode: The client-side proving requirements have dropped dramatically from 3.7GB to 1.3GB through a new low-memory proving mode, enabling older mobile devices to send Aztec transactions and use apps like zkPassport. 
  • AVM performance: The Aztec Virtual Machine (AVM) performance has seen major improvements with constraint coverage jumping from 0% to approximately 90-95%, providing far more secure AVM proving and more realistic proving performance numbers from provers. 
  • Flexible key management: The system now supports flexible key management through keystores, multi-EOA support, and remote signers, eliminating the need to pass private keys through environment variables and representing a significant step toward institutional readiness. 
  • Redesigned slashing: Slashing has been redesigned to provide much better consensus guarantees. Further, the new configuration allows nodes not to penalize home stakers for short outages, such as 20-minute interruptions. 
  • Slashing Vetoer: The Slasher contract now has an explicit vetoer: an address that can prevent slashing. At Mainnet, the initial vetoer will be operated by an independent group of security researchers who will also provide security assessments on upgrades. This acts as a failsafe in the event that nodes are erroneously trying to slash other nodes due to a bug.

With these updates in place, we’re ready to test a feature-complete network. 

What happened after deployment? 

As mentioned above, block production started when someone called the flush function and a minimum number of operators from the queue were let into the validator set. 

Shortly thereafter, while testing the network, a member of the Aztec Labs team spun up a “bad” sequencer that produced an invalid block proposal. Specifically, one of the state trees in the proposal was tampered with. 

Initial block production 

The expectation was that this would be detected immediately and the block rejected. Instead, a bug was discovered in the validator code where the invalid block proposal wasn't checked thoroughly enough. In effect, the proposal got enough attestations, so it was posted to the rollup. Due to extra checks in the nodes, when the nodes pulled the invalid block from Ethereum, they detected the tampered tree and refused to sync it. This is a good outcome as it prevented the attack. Additionally, prover nodes refused to prove the epoch containing the invalid block. This allowed the rollup to prune the entire bad epoch away. After the prune, the invalid state was reset to the last known good block.

Block production stalled

The prune revealed another, smaller bug, where, after a failed block sync, a prune does not get processed correctly, requiring a node restart to clear up. This led to a 90-minute outage from the moment the block proposal was posted until the testnet recovered. The time was equally split between waiting for pruning to happen and for the nodes to restart in order to process the prune.

The Fix

Validators were correctly re-executing all transactions in the block proposals and verifying that the world state root matched the one in the block proposal, but they failed to check that intermediate tree roots, which are included in the proposal and posted to the rollup contract on L1, were also correct. The attack tweaked one of these intermediate roots while proposing a correct world state root, so it went unnoticed by the attestors. 

As mentioned above, even though the block made it through the initial attestation and was posted to L1, the invalid block was caught by the validators, and the entire epoch was never proven as provers refused to generate a proof for the inconsistent state. 

A fix was pushed that resolved this issue and ensured that invalid block proposals would be caught and rejected. A second fix was pushed that ensures inconsistent state is removed from the uncommitted cache of the world state.

Block production restored

What’s Next

Block production is currently running smoothly, and the network health has been restored. 

Operators who had previously upgraded to version 2.0.3 will need to restart their nodes. Any operator who has not upgraded to 2.0.3 should do so immediately. 

Attestation and Block Production rate on the new rollup

Slashing has also been functioning as expected. Below you can see the slashing signals for each round. A single signal can contain votes for multiple validators, but a validator's attester needs to receive 65 votes to be slashed.

Votes on slashing signals

Join us this Thursday, September 25, 2025, at 4 PM CET on the Discord Town Hall to hear more about the 2.0.3 upgrade. To stay up to date with the latest updates for network operators, join the Aztec Discord and follow Aztec on X.

Explore by Topic
Noir
Noir
24 Jun
xx min read

Announcing the Noir awardees of the inaugural EF ZK Grants Wave

Aztec Labs is committed to enabling developers to build with ZK and unlock the full potential of this transformative technology. To that end, we built Noir, an open source Domain Specific Language for safe and seamless construction of privacy-preserving ZK proofs. We fund tooling, libraries, and applications that make Noir more accessible and enjoyable for developers.

Earlier this year, the Ethereum Foundation announced the first ZK Grants Round, a cofunded proactive grants round to encourage research and development for Zero-Knowledge proofs and standards for ZK L2s. Aztec Labs contributed US$150,000 to the US$900,000 prize pool alongside other projects such as Polygon, Scroll, Taiko, and zkSync. We sponsored this initiativeas a part of our commitment to support builders who are advancing ZK across dimensions including research, performance, tooling, and applications.

We were thrilled to see submissions to the ZK Grants Round from both new and existing Noir contributors. In this post, we want to highlight the ZK Grants Wave awardees for the Noir ecosystem to showcase what the community is working on and provide inspiration for how you could contribute.

Plonky2 backend for ACIR

Team: @eryxcoop, @manastech

Noir is back-end agnostic and its Arithmetic Circuit Intermediate Representation (ACIR) can be integrated with different proving backends. This project will enable Noir users to prove and verify their programs with Plonky2 technology, unlocking more possibilities to develop blockchain and ZK infrastructure with Noir. Meanwhile, it will also allow Plonky2 users to benefit from Noir’s developer-friendly abstractions, tooling, and growing sets of libraries, lowering the barrier of entry to the proving technology.

Detecting Private Information Leakage in Zero-Knowledge Applications

Team: @schaliasosvons, @theosotir

Noir abstracts away underlying cryptography so it’s accessible to a broader developer base. However, one risk of these abstractions is unintentionally leaking private variable information. This tool will apply static analysis, taint tracking, input generation, and SMT solving to detect privacy leaks in Noir program designs. Noir users can leverage this easy to use framework and debugging tool to identify, analyze and amend such leakages in their projects.

ZK Benchmarks

Team: @wz__ht

Performance benchmarking varies across different languages and proving systems. This project aims to produce benchmarking suites, articles, and a website that compares and informs developers about characteristics, performance, and tradeoffs between Noir-compatible and other proving backends in the ZK ecosystem.

ZK Treesitter

Team: @wz__ht

Noir reduces barriers for developers to use ZK with its simple and familiar Rust-like syntax. But a solid developer experience is more than just language design. It also depends on a strong ecosystem of developer tooling. This project will offer treesitter grammars that unlock features like syntax highlighting and code formatting for the language in more development environments like Helix and Neovim – providing Noir developers with more flexibility and choice.

Onboard users to verifiable KYC

Team: Neoxham, Lakonema2000, @0x18a6

Noir tooling and libraries are created to support and enable application developers who solve problems using ZK. This team will leverage Noir to create an educational end-to-end example of verifiable Know Your Customer (KYC) with compliance checks, and provide onboarding guides to increase adoption of the application.

We are grateful to the Ethereum Foundation for coordinating the ZK Grants Round and to the teams who submitted proposals. We look forward to seeing how the Noir community leverages these tools and resources to build the next wave of ZK powered applications.

If you’d like to learn more about Noir, read our docs and follow @NoirLang for more contribution opportunities coming soon.

Aztec Network
Aztec Network
11 Mar
xx min read

Client-side Proof Generation

TL;DR

The proof generation for a privacy-preserving zk-rollup differs a lot from that of a general-purpose zk-rollup. The reason for this is that there is specific data in a given transaction (processed by private functions) that we want to stay completely private. In this article, we explore the client-side proof generation used for proving private functions’ correct execution and explain how it differs from proof generation in general-purpose rollups.

Contents

  • What proofs are and how they work in general-purpose zk-rollups
  • How proofs work in Aztec
  • Proving functions’ correct execution
  • For public functions: rollup-side proof generation
  • For private functions: client-side proof generation
  • An example proof
  • How client-side proof generation decreases memory requirements
  • Appendix: other details of client-side proof generation.
  • Summary

What proofs are and how they work in general-purpose zk-rollups

Disclaimer: If you’re closely familiar with how zk-rollups work, feel free to skip this section.

Before we dive into proofs on Aztec, specifically the privacy-first nature of Aztec’s zk-rollup, let’s recap how proofs work on general-purpose zk-rollups.

When a stateful blockchain executes transactions, it conducts a state transition. If the state of the network was originally A, then a set of transactions (a block) is executed on the network, the state of the network is now B.

Rollups are stateful blockchains as well. They use proofs to ensure that the state transition was executed correctly. The proof is generated and verified for every block. All proofs are posted on L1, and anyone can re-verify them to ensure that the state transition was done correctly.

For a general-purpose zk-rollup, proof generation is very straightforward, as all data is public. Both the sequencer and the prover see all the transaction data, public states are public, and the data necessary to reconstruct each state transition is posted on L1.

How proofs work in Aztec

Aztec’s zk-rollups are a different story. As we mentioned in the previous article, in the Aztec network, there are two types of state: public and private.

Aztec smart contracts (written in Noir) are composed of two types of functions: private and public.

  • Private functions – user-owned state, client-side proof generation
  • Public functions – global/public state, rollup-side proof generation

For both of these, we need proof of correct execution. However, as the anatomy of private and public functions is pretty different, their proof generation is pretty different too.

As a brief overview of how Aztec smart contracts are executed: first, all private functions are executed and then all public functions are executed.

However, diving into the anatomy of Aztec smart contracts is outside the scope of this piece. To learn more about it, check the previous article.

Here, we will focus on the correct proof generation execution of private functions and why it is a crucial element of a privacy-first zk-rollup.

The concepts of private state and private functions in blockchain might seem a little unusual. The following map describes the path of this article, where we will shed some light on the difference between how proofs work for private and public states respectively.

Proving functions’ correct execution

For public functions: rollup-side proof generation

Let’s start by looking at public function execution, as it is more similar to other general-purpose zk-rollups.

Public state is the global state available to everyone. The sequencer executes public functions, while the prover generates the correct execution proof. In particular, the last step means that the function (written in Noir) is compiled in a specific type of program representation, which is then evaluated by a virtual machine (VM) circuit. Evaluated means that it will execute the set of instructions one by one, resulting in either a proof of correct execution or failure. The rollup-side prover can handle heavy computation as it is run on powerful hardware (i.e. not a smartphone or a computer browser as in the client-side case).

For private functions: client-side proof generation

Private state on the other hand is owned by users. When generating proof of a private transaction's correct execution, we want all data to stay private. It means we can’t have a third-party prover (as in the case of public state) because data would be subsequently exposed to the prover and thus no longer be private.

In the case of a private transaction, the transaction owner (the only one who is aware of the transaction data) should generate the proof on their own. That is, the proof of a private transaction's correct execution has to be generated client-side.

That means that every Aztec network user should be able to generate a proof on their smartphone or laptop browser. Furthermore, as an Aztec smart contract might be composed of a number of private functions, every Aztec network user should be able to generate a number of proofs (one proof for each private function).

On the rollup side, block proofs are generated using ZK-VM (ZK virtual machine). On the private side, there is no VM.

Instead, each private function is compiled into a static circuit on its own.

When we say “a circuit”, we’re referring to a table with some precomputed values filled in. This table describes the sequence of instructions (like MUL and ADD) to be executed during a particular run of the code.

There are a bunch of predefined relations between the rows and columns of the table, for example, copy constraints that state that the values of a number of wires are expected to be the same.

Let’s take a look at a quick example:

In the diagram above, we have two gates, Gate 1 (+) and Gate 2 (x). As we can see, z is both the output of Gate 1 (denoted as w3, wire 3) and the left input to Gate 2 (denoted as w4, wire 4). So, we need to ensure that the value of the output of Gate 1 is the same as the value of the left input of Gate 2. That is, that w3 = w4. That’s exactly what we call “checking copy constraints”.

When we say that the verifier verifies the circuit, we mean it checks that these predefined relations hold for all rows and columns.

An example proof

Disclaimer: the following example reflects the general logic in a simplified way. The real functions are much more complex.

Assume we have a function a2+b2=c2. The goal is to prove that equality holds for specific inputs and outputs. Assume a = 3, b = 4, c = 5.

As a piece of code, we can represent the function as the following:

When the function is executed, the result of each step is written down in a table. When this table is filled with the results of the specific function execution on specific values, it’s called an execution trace.

This is just a fragment of the table, with values and opcode names. However, to instruct the computer about which operation should be executed in which specific row, the opcode name is not enough; we need selectors.

Selectors are gates that refer to toggling operations (like an on/off switch). In our example, we will use a simplified Plonk equation with two selectors: qADD for the addition gate and qMUL for the multiplication gate. The simplified Plonk equation is: qMUL(a*b)+qADD(a+b)-c=0.

Turning them on and off, that is, assigning values 1 and 0, the equation will transform into different operations. For example, to perform the addition of a and b, we put qADD= 1, qMUL=0, so the equation is a+b-c =0.

So, for each performed operation, we also store in the table its selectors:

How client-side proof generation decrease memory requirements

In the case of private functions, as each function is compiled into a static circuit, all the required selectors are put into the table in advance. In particular, when the smart contract function is compiled, it outputs a verification key containing a set of selectors.

In the case of a smart contract, the circuit is orders of magnitude larger as it contains more columns with selectors for public function execution. Furthermore, there are more relation checks to be done. For example, one needs to check that the smart contract bytecode really does what it is expected to do (that is, that the turned selectors are turned according to the provided bytecode commitment).

As a mental model, you can think about a smart contract circuit as a table where 50 out of 70 columns are reserved for the selectors' lookup table. Storing the entire table requires a lot of memory.

Now you see the difference between circuit size for client-side and rollup-side proof generation: on the client-side, circuits are much smaller with lower memory and compute requirements. This is one of the key reasons why the proofs of private functions' correct execution can be generated on users’ devices.

Appendix: other details of client-side proof generation

  • To further decrease memory and computation requirements for the prover, we use a specific proving system, Honk, which is a highly optimized Plonk developed by Aztec Labs. Honk is a combination of Plonk-ish arithmetization, the sum-check protocol (which has some nice memory tricks), and a multilinear polynomial commitment scheme.
  • Some gadgets that may be added to Honk to make it even more efficiet include Goblin Plonk, a specific type of recursion developed by Aztec Labs, and ProtoGalaxy, developed by Liam Eagen and Ariel Gabizon.
  • Goblin Plonk allows a resource-constrained prover to construct a zk-snark with multiple layers of recursion. That perfectly fits the case of client-side proof generation, where a proof of each private function in a smart contract is an additional layer of the recursion. The trick is that expensive operations (such as Elliptic Curve operations) at each recursion layer are postponed to the last step instead of being executed at each. The recursion ends in one single proof for all the private functions in a smart contract.
  • This proof is then verified by the rollup circuit. The recursive verification of this proof is pretty resource intensive. However, as it is performed rollup-side, it has enough computation and memory resources.
  • ProtoGalaxy is a folding scheme that optimizes the recursive verifier work. It allows for folding multiple instances in one step, decreasing the verifier’s work in each folding step to a constant.
  • Diving into Honk and its optimizations is outside the scope of this article, but we promise to cover it soon in upcoming pieces.

Summary

Client-side proof generation is a pretty novel approach for the blockchain domain. However, for privacy-preserving solutions, it is an absolute must-have. Aztec Labs has spent years developing the protocol and cryptography architecture that make client-side proof generation performance feasible for the production stage.

You can help build it further.

Vision
Vision
7 Mar
xx min read

Regeneration: a Manifesto for an Autonomous Future

The following is written by Zac Williamson, with inspiration and advice from Arnaud Schenk.

My fellow companions, my decentralized brothers and sisters. I wish to tell you a story, about complicated people and their struggles to resolve the wreckage of their contradictions. It is a story of humanity.

We are at a unique point in history and stand at the threshold of two worlds. One world is a propagation of our present, a status quo antebellum with all of its associated joys and sorrows.

There is another door, one hidden from view except for those with the sight to see it. You and I are here because we see a unique vision of the future, one of high technology and high ideals, that advance human beings from their status as a commodity resource in a globalized world, to free actors imbued with autonomy and purpose, who bow to no one.

I want to articulate this vision and examine the forces that drive us. Despite our successes and dedication it is clear that our current achievements fall short of our aspirations. We must reconcile this.

Bitcoin is not yet a credible threat to traditional currencies. Paying for goods and services with cryptocurrency is a niche luxury for the technologically well-connected. Decentralized autonomous organizations (DAOs) are yet to govern anything that is not a cryptocurrency project. A notable exception was ConstitutionDAO, which immediately failed in its goals due to the intrinsic limitations of trustless blockchain networks.

There are missing pieces in the technological armaments we have fashioned. I want to show you the missing pieces. I want to go back to the roots: what are the systems and frameworks we want to disrupt? Which properties do blockchain networks need for us to forge a conspiracy against the present, and fight for our vision of the future?

Control Factions

Reaching back into prehistory, humanity has been waging a war against itself – a war that pits the freedom and autonomy of individuals against the safety and control of institutions.

We want to be free. We want to be safe. This is the eternal contradiction.

To acquire safety we bind ourselves to institutions. Within these institutions, control factions form. They metastasize and act to entrench their power and influence by monopolizing human agency. This triggers inevitable conflict and revolt, which acts to reset the equilibrium.

How best we can resolve the contradiction between freedom and safety is a function of social organization, the quality of which is gated behind technological innovation.

Blockchain is one such technology. To identify what we need, we must identify the weaknesses of the institutions we seek to undermine, and tailor our strengths against them.

The competency crisis

Control factions have a fatal weakness: they reject competence.

Competent people threaten individuals within entrenched power structures. A competent subordinate is a threat to your power and privileges. This is the so-called “dictator trap”, but the mechanics at play extend to all power structures, from the boards of mega-corporations to the local residents association. But it’s not a dictator trap, it is an institution trap.

Power craves legibility and predictability and will act on these desires by exerting control – limiting agency and freedom of action.

Re-distributing institutional control

We want to undermine institutional control, and redistribute control down to smaller units of organization.

Blockchain technology enables such radical new forms of social organization that fall outside the frameworks of traditional institutions.

We possess a keystone technology that enables mass peer-to-peer coordination, initially of cryptocurrency assets but this can be generalized to anything with perceived value that can be given a digital fingerprint.

Blockchain networks have radically different incentive mechanisms to traditional modes of social organization.

Because blockchains are coordination engines. They enable individuals to coordinate on how to deploy their collective resources. This type of mass-coordination of personal resources is unique and will subtly act to profoundly re-distribute the existing power structures of the present.

Why? Blockchains weaken the fundamental value propositions of vertically integrated companies that extract a profit from information asymmetries. Individuals whose skills serve large institutions can more easily decide for themselves how best to apply their skills, without the need for the institution’s support frameworks. As a coordination engine, blockchain networks can efficiently combine the skills and capital required to execute grand ideas, as well as provide a digital market for resulting products.

A global marketplace of programmable money is one with profound information transparency. The ability of independent groups to analyze the market enables great efficiency and reduces information asymmetries. Though, does not delete them entirely.

In short, blockchain networks are pro-competency. They allow individuals to decide for themselves how their skills can best be utilized and deployed, instead of having that decided for them by a control faction. Competent people add value to the network and in doing so, provide another composable brick that others can use in their constructions. The raw incentives create a positive-sum game.

Missing pieces

What are the missing pieces?

The great difficulty in realizing our vision is the limited ability of current blockchains to reach into the real world.

We are not our online avatars. We exist in a physical space and we have physical needs that must be satisfied. We are bound to networks of obligation and responsibility that societies depend upon to maintain social order. We cannot live in an NFT.

The real world matters. Without a way of linking real-world identities to blockchains, the grand cypherpunk vision for blockchain can never be fully realized – only a neutered form of primitive electronic sovereignty.

The new information networks: composable privacy

The new information networks we are building lack a key ingredient: composable privacy.

By using novel cryptography, we can turn blockchains into encrypted ledgers where transactions hide their execution from observers. Identities can be encrypted, but still used to prove statements about the user, and without involving an additional institutional third party. e.g. “I have a U.S. passport”, “I have a digital driving license”, “I have a Twitter account with over 1,000 followers”, “I signed in with a Google account”.

The effect of this is to build trust infrastructure that allows human beings to iteratively build trust between themselves and to do so rapidly and at scale.

Programmable private blockchains stand to usher in a revolution in how distributed systems can be used. Without strong identity guarantees, the only workable governance mechanisms for distributed on-chain organizations are autocracy and plutocracy.

However, if past actions can be uniquely tied to a cryptocurrency account, it is possible to identify key stakeholders and to give them an accelerated role in governance. That enables a much more democratic architecture of governance systems.

Privacy technology is required to turn blockchains into the coordination engines they were always destined to be.

The future we are building does not outright destroy existing systems of control – it breaks them apart and replicates these systems on a smaller scale. Lower barriers to entry lead to greater competition and market fragmentation and act to limit the ability of distributed organizations to consolidate power.

Because coordination engines are pro-competency.

Privacy for the user, transparency for the protocol

There is a phrase I think we will hear much of over the coming years: privacy for the user, transparency for the protocol.

The capabilities of private programmable blockchains and the outcomes they enable are not commonly understood. A private blockchain is not one where all information and data are intrinsically hidden. They are hybrid systems where public and private data coexist. Application designers and users can choose which data is hidden.  

Efficient markets require data transparency. Data relating to identity requires data confidentiality. The solution is applications where information that relates to assets is public, and information relating to users (e.g. who owns said assets) is private.

To create a privacy-preserving ecosystem it must be possible for confidential, transparent, and hybrid applications to directly interact with one another. Privacy is not an aftermarket add-on to be bolted onto a few select applications. Full composability is essential to develop a rich ecosystem.

Composability enables trust-building networks by allowing individuals to put core aspects of themselves on-chain, disclosing it only selectively and enabling distributed protocols to use these capabilities in a composable permissionless manner, without leaking information. Who are you? What have you done? What do you want to do? With privacy, we can disclose this information to smart contracts and hide it from people. These will form core primitives of our new information networks.

I have spent the last 6 years building exactly this, through building Aztec. Crafting the missing ingredient, privacy, via cutting-edge cryptography, zero-knowledge proofs, and raw engineering.  

Values of the new information networks

Networks have values that are independent of their creators. Networks live or die on the quality of their network effects. This incentive gives network participants a shared motivation to expand the network. The more nodes that exist, the greater the value individual nodes can extract from the network. The manner in which the network changes itself to act on these motivations defines its intrinsic values.

What are the intrinsic values of permissionless programmable privacy networks like Aztec? We can derive these from the fundamental value proposition – to expose a rich ecosystem of composable, confidential applications, and to do this as a permissionless, decentralized network. This enables individuals and small groups to compete in industries dominated by large players leveraging large information asymmetries.

Such networks are, at their very core, pro-competency. If you have something useful to add to the network, you can. If you want to use existing network components in your product, go right ahead. No need to ask for permission from the network.

From this starting point we can anticipate the cycles of action and reaction that will drive networks like Aztec to adopt the following values over their lives:

  • They are pro-emergence and pluralistic.
  • They strongly desire individual autonomy and freedom of action.
  • They are fiercely anti-elite, but not necessarily anti-elitism.
  • Finally, they seek to undermine traditional frameworks of control and subjugation used to promote institutional stability.

Blockchain networks grow by harnessing the industry and enterprise of as many human souls as they can get their hands on.  

Without mechanisms of coercion to fall back on, the network must ensure a positive-sum game for network participants who add value. These also happen to be values that I believe I strongly hold. This is not a coincidence. I started in web3 seven years ago building a marketplace for corporate debt on Ethereum and by degrees ended up building a distributed programmable privacy network on Ethereum. This was not due to some grand design but, I think, the cumulative effects of seven years of following my impulses. To find a place of belonging.

This feeling is something you may share – that the frameworks and systems produced by our societies offer none of us a true sense of belonging and purpose. But here, amongst our companions, we have found belonging through building a shared vision of a radical new world.

The road ahead

There is a long road to walk to realize the ambitions of the new information networks. The technology is barely capable and challenging to build. The architecture is novel and challenging to design. Convincing people to build on radical foundations to bootstrap a market is challenging. Building competitive infrastructure and tooling is challenging.

The challenge is irrelevant. We cannot become a generation scorned by our descendants for squandering the opportunity of a lifetime.

We will build and deploy the new information networks and by degrees will learn how to use them to chip away at the inequities of the status quo, and the social order that upholds it.

Equipped with such armaments and driven by our ideals, we will pull our ideas into reality. Together, we will forge our digital Eden.

Noir
Noir
3 Jan
xx min read

Interview with Kev Wedderburn, Father of Noir

Kev Wedderburn is the father, architect, and team lead of Noir, a universal zero knowledge circuit writing language funded by Aztec Labs.

We're excited to bring you this interview and profile of the man and mystery behind the DSL creating a step-function change in the accessibility of ZK programs.

Alyssa: Hey Kev! Thanks so much for your time, I’d love to give readers a snapshot of your journey into web3 and Aztec Labs, as well as your focus on the Noir team.

Kev: Sure! Let’s jump in.

Alyssa: Can you start by sharing your web2 background?

Kev: Yes. I started out as a front-end developer, then moved into app development.

I built a social media site for books. Then, a janky music-sharing app that would check your playlist, then check my playlist, then if our playlists overlapped enough, it would recommend each of us songs on each other's playlist (this was before Spotify became Spotify I think).

Alyssa: How’d app development lead you to going full-time web3?

Kev: While transitioning to crypto, I made a tax app that scanned your bitcoin QR code and told you how much tax you owed.

From there, I started doing tutorial videos focused on smart contracts. I wanted to do one for a particular blockchain, and it turned out that they didn’t have a well-functioning wallet. So that’s actually what led to my entry into the web3 space. I didn’t end up finishing that tutorial, I just went on to build the wallet myself.

Alyssa: And this work led to your first formal web3 role?

Kev: Eventually, yes. While I was working on an improved wallet, I noticed the node that the original wallet was interacting with wasn’t that great either. So once the new wallet was finished, I moved on to creating a node in Golang (the wallet was also originally built in Golang).

After I finished the node, I got recruited by a privacy-focused project. And they asked me to build a node for their privacy network.

Once I dug deeper, it turned out they didn’t have a proving system. So then I started learning cryptography to implement a type of ZK proof called bulletproofs — state of the art at the time.

Alyssa: And you’ve primarily worked on privacy within web3 ever since, is that right?

Kev: Yes, I worked for several other privacy blockchains prior to Aztec, such as Monero. At Monero, I pivoted from implementing Bulletproofs to Plonk for increased proving speed, but noticed it was very challenging to program on top of Plonk.

The Plonk constraint system and proving system both have nice properties, but the UX was really bad. So Kobi Gurkan from Geometry Research, and Barry Whitehat from the Ethereum Foundation asked if I wanted to make a compiler — I guess they saw that I was pretty active within Plonk and cryptography in general.

Alyssa: Had you built one before?

Kev: At the time, I didn’t know much about compilers at all, so it was exciting to figure out what the compiler I’d build would look like, what other compilers were doing, and how to make a compiler with the safety guarantees needed for zero knowledge proofs.

That was the beginning of what we now call Noir, and I’ve been at Aztec since.

Alyssa: Wow, okay, so you’ve been with the Noir project since the beginning of Noir’s existence?

Kev: Yeah, exactly.

Alyssa: Amazing, congrats on all the progress you and the team have made. And what about getting into web3 in the first place? Was it through engineering, or your own interest in cryptocurrency? How did that look?

Kev: I first looked at Bitcoin in university, but was deterred by the codebase being challenging to read. But I wanted to learn Bitcoin and teach people about it. Back then, everything was a bit scammy. I even created a Bitcoin book…

Alyssa: Going back to Noir, how do you feel about the experience of learning the language you helped build? Is it intuitive for developers?

Kev: I can tend to over-criticize the things I do. But Noir’s in a solid place. There’s not much to really compare it to….there are other zkDSLs, but they give different guarantees for the most part. For example, Noir provides devs with a high-level language that aims not to sacrifice performance and safety, while Circom gives devs very little safety but allows them to do anything. There are pros and cons to both of these approaches.

The more control you give to a developer, the more powerful things they can do, but they can also easily make mistakes because the compiler is no longer holding your hand or stopping you from doing something potentially dangerous.

But yes, Noir is in a good place for developers to use. There’s still a lot we want to put into the language to make it comparable to common programming languages in terms of UX. But we’re well on our way.

Alyssa: And what about just being on the Aztec Labs team in general, and maybe even the Noir team within Aztec Labs? What’s that like? What do you enjoy about it?

Kev: The Aztec team is cross-functional and fluid, meaning that even though you’re on the Noir team, or the tooling team, or the engineering team, you can touch other parts of the stack. So that’s great about being at Aztec.

The fun thing about the Noir team in particular is that there are so many challenges we have yet to solve. We’ve solved quite a lot of them, but there’s still a lot we’re excited to work on like continuing to improve the UX, as I mentioned.

Alyssa: Love that answer as I know there’s a job opening on the Noir team, so someone joining can have exposure beyond understanding their specific role.

Kev: In fact, we encourage that, if you’re on tooling and you want to create something and the compiler just doesn’t seem to be fit to do what you want, feel free to start some print or tasks to modify the compiler. We’re always open to new ideas.

Alyssa: Really cool, that’s great. And what about beyond web3, any general interests or hobbies?

Kev: Generally speaking, I really like maths. I also used to sing and play guitar for quite a while, and I exercise a lot these days.

Alyssa: Thanks again for the chat, great learning a bit more about your work, Kev!

Kev: Thank you!

Get started with Noir

We think Noir has the best syntax, most modularity, and best ecosystem of any ZK language. But don't take our word for it.

Get started with Noir at noir-lang.org.