Aztec matters because it does not bolt privacy onto Ethereum-style contracts. Aztec changes the execution model itself: private functions run on the user side inside the Private Execution Environment, public functions run on the Aztec Virtual Machine, and the resulting state transition is proven and settled to Ethereum. That gives developers real private state instead of mere obfuscation, but it also means deploying on Aztec is not a straight Solidity port.
As of March 10, 2026, Aztec is in a transitional but important phase. The public testnet has been open to developers since May 1, 2025, the decentralized Ignition Chain went live in November 2025 to prove the consensus and governance layer, and the Alpha upgrade that adds the first canonical programmable privacy execution environment was announced as ready for governance proposal on March 3, 2026. In other words, Aztec is already buildable, but the long-lived production shape of the smart contract network is still being finalized by governance rather than settled by time.
Aztec is a privacy-first rollup, not an EVM L2 with encryption cosmetics
Aztec is best understood as a hybrid public-private zkRollup on Ethereum. Its core design lets developers choose which parts of state are public and which are private, then pair that state with public or private execution paths. Public state is transparent and updated by sequencers, while private state is handled through notes, commitments, and client-side proving.
That design decision has a direct consequence for developers: Aztec is not EVM-compatible. Public execution uses the Aztec Virtual Machine rather than the EVM, and private functions compile into circuits rather than normal chain-executed bytecode. The development model is therefore closer to building an application across two execution domains than deploying a standard Solidity contract to another rollup.
The authorizing account model is also different. Aztec has native account abstraction at the protocol level, so every account is a smart contract rather than an EOA. That gives teams control over authentication, fee payment, nonce logic, and authorization patterns, but it also pushes more design responsibility onto application teams.
Technical history: Aztec has already pivoted once to get closer to programmable privacy
Aztec’s history is a sequence of increasingly ambitious attempts to make privacy usable on Ethereum. The project’s 2022 Aztec Connect launch brought private DeFi interactions to mainnet Ethereum, but on March 13, 2023 Aztec announced that Aztec Connect would be sunset so resources could be focused on Noir and a general-purpose encrypted zkRollup, with the final sequencer-run sunset date set for March 31, 2024. That history matters because it shows a team willing to abandon an intermediate architecture if it blocks the end-state network.
The current Aztec stack grew out of that reset. Aztec’s Sandbox introduced a local developer environment for private smart contract experimentation, the public testnet opened on May 1, 2025 for fully private applications, the Adversarial Testnet added slashing and decentralized governance testing in July 2025, and Ignition launched in November 2025 as the decentralized backbone before Alpha execution ships. The March 2026 roadmap update and Alpha proposal make clear that the execution environment is no longer conceptual. It is now a governance-mediated rollout.
What deploying a smart contract on Aztec actually involves
| Dimension | What it means for deployment |
|---|---|
| Language | Contracts are written in Noir via Aztec.nr, not Solidity. |
| Execution split | Private functions execute client-side in PXE with proofs, while public functions execute on the sequencer-side AVM. |
| State model | Contracts can hold both public and private state in the same application architecture. |
| Deployment flow | Deployment means publishing the contract class and creating a contract instance, with the address deterministically derived from class, constructor args, salt, and deployer. |
| Public bytecode | If the contract has public functions, its class must be registered so the public bytecode is available on-network. |
| Private bytecode | Private function bytecode is not published to the network, so integrators need the contract artifact offchain to call those functions. |
| Accounts and fees | Accounts are smart contracts, and Aztec supports fee abstraction, including sponsored fee-payment contracts on testnet. |
| Governance exposure | Protocol upgrades are sequencer-signaled and token-voted on L1, and current operator docs describe a 3-day voting delay, 7-day voting period, and 7-day execution delay. |
| Current network reality | You can build now on sandbox, devnet, and public testnet, but the Alpha execution network was still at the governance-proposal stage on March 3, 2026. |
The biggest mental shift is that Aztec contracts are intentionally two-sided. A single application may need private note handling, public state transitions, offchain artifact distribution, wallet-side PXE coordination, and explicit thinking about what gets revealed when private flows cross into public functions or L1 messages. If your engineering team still thinks in terms of “deploy bytecode and call methods,” you are not ready yet.
Pros of deploying smart contracts on Aztec
- Aztec gives you real private state, not merely private front ends. Developers can combine public and private state inside the same application and route logic between private and public execution contexts. That makes Aztec structurally suited to use cases like hidden-order trading, confidential identity checks, sealed-bid logic, private payroll, private social graphs, and games with hidden information.
- Aztec’s account model is stronger than the average L2 wallet model. Because every account is a smart contract, teams can build custom authorization and recovery flows instead of inheriting EOA limitations. For user-facing apps, that is not a cosmetic improvement. It is part of the product architecture. Sponsored fees and fee-payment contracts also help reduce onboarding friction during testing and early adoption.
- Aztec constrains governance more than many “upgradable” chains do. The March 2026 Alpha proposal states that each Aztec version is a set of immutable, non-upgradable smart contracts, and that governance can modify fee-market parameters and choose the canonical rollup instance rather than arbitrarily rewriting deployed state. That is a meaningful protection against governance abuse. It reduces the blast radius of political capture.
- Developer tooling has crossed the threshold from research project to usable stack. Aztec provides aztec.js, codegen, sandbox, Playground, testnet docs, fee tooling, and contract tutorials. The public testnet launch also showed that apps were not hypothetical: more than 20,000 users visited the Playground in the first 24 hours and 10 apps launched live on day one.
- Aztec’s governance and settlement model is visible onchain rather than hidden behind a multisig fiction. Signaling and voting happen on Ethereum, upgrades follow a public lifecycle, and the registry model keeps historical rollups accessible rather than pretending the past never existed. That does not eliminate power concentration, but it does make the control surface legible.
Cons of deploying smart contracts on Aztec
- Aztec is a rewrite, not a redeploy. Aztec is not EVM-compatible, public functions compile to AVM bytecode, and private functions compile to standalone circuits. A Solidity protocol cannot simply bridge liquidity and keep the code. It must redesign execution, data flow, audits, and usually user interaction.
- Privacy on Aztec is easy to damage through bad application design. The docs are explicit that private data can leak when a private function calls a public function, reveals arguments, emits unencrypted events, or sends L2-to-L1 messages. The PXE docs also note that querying a node for world state can leak what data a user is interested in unless the user runs their own node. Privacy exists here, but it is not automatic.
- The network is still explicitly experimental for smart-contract use. The Alpha proposal says the upcoming Alpha network should be treated as experimental technology and that users should only transact with funds they are willing to lose. Aztec’s own privacy guidance also warns that real-world, meaningful, valuable secrets should not yet be entrusted to the system. For production-critical applications, that warning matters more than the marketing.
- Governance power is constrained, but agenda-setting is still concentrated. Only the designated block proposer can signal support for a payload during a slot, and current docs show that staked voting power is automatically delegated to the rollup contract, which votes “yea” on proposals that passed sequencer signaling unless holders proactively redelegate their power elsewhere. In practice, that means passive capital follows a sequencer-led agenda by default.
- There is counterweight to that concentration, but it is expensive to use. Aztec includes an escape hatch called proposeWithLock() that can bypass sequencer signaling, yet the docs say it requires a large amount of voting power to be locked with a long withdrawal delay. So the system is not dictator-proof through pure egalitarianism. It is dictator-resistant through capital and process friction.
- Versioned immutability reduces governance abuse, but it also raises migration costs. Aztec’s upgrade model keeps every historical rollup accessible and expects migration toward a new canonical instance rather than mutating the old one in place. The March 2026 Alpha proposal also says to expect multiple Alpha versions. That is a healthy constraint on governance power, but it means application teams should assume state migration, not seamless invisible upgrades.
- The current ecosystem is still early enough that standards and integrations are being actively formed. Aztec’s March 2026 roadmap update says contract standards for tokens and NFTs are underway for Alpha rather than long-settled. That means less inherited composability than a mature EVM network and a higher chance that your team becomes part of the standards-discovery process.
The most visible projects on Aztec today are infrastructure-heavy for a reason
The official Aztec ecosystem page is dominated by foundational products, not finished blue-chip application layers. The most recognizable names include Azguard and Obsidion on wallets, Aztec Explorer and somethinghappened.wtf on block explorers, Raven House on NFTs, Nemi on privacy-preserving exchange infrastructure, human.tech and Substance Labs on bridging, ZKPassport on privacy-preserving identity, Shade on money markets, Taurus on confidential token logic, and Wonderland on smart-contract standards.
That project mix tells you where Aztec really is. The ecosystem is already beyond pure demos, but it is still building the rails: wallets, explorers, bridges, identity, standards, and early privacy-native apps. That is exactly what you would expect from a network whose core value proposition is a new execution model rather than another venue for copy-pasted EVM DeFi.
Who should deploy on Aztec, and who should wait
Aztec is a strong choice when privacy is the application, not just an extra feature. If the product breaks without hidden balances, hidden identity attributes, hidden game state, hidden bids, or protected transaction intent, Aztec’s architecture is aligned with the job. If the product mainly needs cheap execution, standard EVM tooling, and immediate liquidity composability, Aztec imposes too much overhead today.
From FinDaS Tokenomics, the decisive issue is power distribution as much as technical capability. Aztec’s design deliberately limits governance’s ability to rewrite history, but it still gives sequencers disproportionate control over what reaches the ballot and relies on users to actively reclaim voting power if they do not want the default rollup vote. That trade-off may be acceptable for teams that need credible privacy and can tolerate versioned upgrades, experimental infrastructure, and a new audit surface. It is not acceptable for teams that want the comfort of mature standards and the illusion that governance does not matter.
The short version is simple. Deploy on Aztec if private state is core to your product and you are willing to build for a different machine, a different trust model, and a still-maturing network. Do not deploy on Aztec if what you really want is another general-purpose L2 with a privacy narrative wrapped around it.
This article is part of our Choosing The Right Blockchain series.
