TL;DR
- Ethereum’s transparency limits private use cases like payroll, trading, and identity
- Aztec blends account-based public state with UTXO-based private state
- Private execution runs locally; public settlement anchors to Ethereum
- Notes and nullifiers enforce privacy while preventing double-spending
- “Nullify-on-read” ensures logic follows the latest private state
- Apps can mix confidential and public components without losing composability
- Supports future on-chain economies where privacy is flexible and user-controlled
Since the beginning of Ethereum, transparency has been viewed as both its superpower and its biggest roadblock. Public ledgers make it possible to verify transactions without trusting intermediaries. But the same transparency turns every financial interaction into open surveillance. Each swap, vote, and deposit reflects not just activity but identity. Wallets become profiles. Behavior becomes data trails. If blockchain is meant to support everything from personal finance to identity and institutional applications, then privacy can't remain an afterthought. It has to be a programmable option - something users can enable when activity includes sensitive data, and disable when transparency is necessary.
Aztec takes on this challenge with a simple but powerful idea: Ethereum can support both privacy and composability, as long as the underlying state architecture allows it. That means more than just hiding transactions; it requires a model where private and public data can coexist and interact without compromising security. This is where Aztec's blended state design steps in. It combines two approaches - a private state based on UTXO and a public state aligned with Ethereum's account model - to build what the team calls a publicly-verifiable private world computer.
This article takes a deep look at the architecture that makes Aztec different. How it blends Account-based public state and UTXO-based private state into a structure that supports composable privacy for Ethereum applications. And why this matters for the future of on-chain economies.
Why Ethereum's Transparency Limits Privacy
Ethereum stores data using what's known as an account-based state model. Every wallet, smart contract, or balance is a key-value pair in a global database. Updating an account means modifying its value in that database. This design ensures strong global consistency but it also exposes activity patterns. Even if values were encrypted, onlookers could still see which account was changed and when. A balance modified after a transaction reveals just enough metadata to connect event history over time.
That's the core privacy flaw: A system that updates one shared state inherently leaks information about relationships between accounts. That isn't ideal for:
- DeFi strategy protection
- Private trading
- Sensitive DAO governance
- Institution-compliant financial operations
- Personal financial privacy
Privacy isn't just about hiding a balance. It's about breaking the ability to analyze how actions map to identity. Ethereum can't simply encrypt its global ledger. Doing so would remove transparency and transparency is what makes public blockchains secure. Something different is needed.
The UTXO Model - Stronger Privacy by Default
Bitcoin uses a different model called UTXO (unspent transaction output). Rather than directly modifying an account, each action creates entirely new outputs and marks old ones as spent.
Think of it as: Instead of rewriting a page in the ledger, you replace the page with a new one and archive the old page permanently. This creates a privacy opportunity:
- Observers can't tell whether a new output belongs to the same identity as the previous one.
- Destroyed outputs are no longer tied to specific future actions.
- There's no single state pointer linking identity to history.
The result is a system where identity can remain unstated, even while balances remain verifiable. This makes UTXO an excellent foundation for private state.
Aztec's Blended State Model

Aztec's approach starts from a simple belief: privacy shouldn't require leaving Ethereum behind. Instead of forcing every application to be either fully public or fully private, Aztec combines the strengths of two different systems in one network. Public state uses the familiar account-based structure that Ethereum already understands, where shared information like token supply or AMM pricing can remain visible to everyone. Meanwhile, private state uses a UTXO-style design, allowing people to hold balances and interact with smart contracts without exposing their identities or activity patterns.
Both of these states work inside a single execution environment. When someone sends a transaction, all private logic runs first on the user's device, updating encrypted notes that only they can view. Once that private portion is complete, the public functions take over, modifying shared state on-chain in a way that other smart contracts and dApps can respond to. The two layers complement each other rather than compete, letting privacy stay flexible instead of absolute. Builders can choose transaction by transaction what deserves confidentiality and what should remain open to the ecosystem.
This blended model gives Ethereum something new: privacy without isolation. Users protect what matters. Apps remain composable. And the network continues to function like Ethereum - only with room for more personal space.
Notes and Nullifiers - The Core of Private State
In Aztec's system, all private values are stored as notes - encrypted records only the owner can read. Notes aren't updated in place. When state changes, notes are:
- Consumed (destroyed privately)
- Replaced with new notes representing the updated state
To prevent double-use of old notes, Aztec uses nullifiers. A nullifier is essentially a private receipt proving a note has been spent once. Importantly, it does not reveal which note it came from. This protects privacy while securing consumption rules.
Example:
-
Emmy holds a note worth 100 tokens. She wants to send 30 to Bob.
What happens:
- Emmy consumes the 100-value note → nullifier created
- A new note for Bob worth 30 is issued
- A new note for Alice worth 70 replaces the old note
Observers only see that:
- A nullifier was submitted
- Two new private commitments entered the system
They cannot tell:
- Who sent what
- What value was transferred
- Whether the notes relate to previous state
That is the privacy promise of UTXO inside Aztec.
Keeping Data Fresh: The Nullify-on-Read Rule
Private data in Aztec can't remain static forever. If a user could rely on an outdated piece of information - like an old balance or a permission that expired long ago - it would break trust in the system. That's why Aztec uses a concept called nullify-on-read, a rule that forces private data to stay up to date. Whenever a private note is accessed during a transaction, the system treats it as "consumed," even if the value hasn't changed. The note is replaced with a new one that reflects the current state. This approach ensures that no one can rewind time to a version of the state that benefits them unfairly.
Imagine someone has a permission that's only valid while a counter remains under ten. Without nullify-on-read, they could search for an older version of the state where their counter was still low and continue using that permission. Aztec prevents this by making every interaction count. Opening a private note leaves a trace - the old version becomes invalid, and the network recognizes only the new one. The owner of the note keeps their privacy intact because nullifiers reveal nothing about the content or who created them.
The rule might sound like a small detail, but it's crucial for preserving both privacy and correctness. It ensures all private logic progresses fairly, while still allowing users to encrypt everything about their financial and identity-linked data. In simple terms: Aztec keeps privacy modern, synchronized, and honest without slowing down what makes Ethereum dynamic.
Public State: Transparency Where It Matters
Some application logic needs to be visible. Examples include:
- Global supply records
- Protocol-wide configuration
- Shared counters and governance settings
- Liquidity pools and pricing parameters
These are stored in a public account-based state, similar to Ethereum. Aztec allows developers to choose what must stay public for composability and what can remain private for confidentiality. This is what makes Aztec programmable privacy rather than total opacity.
Different dApps can express nuanced privacy rules:
- Private transfers but public supply
- Private holdings but public governance votes
- Public access control with private user attributes
It's not just hiding - it's selective visibility.
How Both States Work Together
Aztec's design lets private and public states operate side-by-side without breaking the rules of Ethereum. When someone interacts with a smart contract, the private parts of the transaction execute first on the user's own device. That means the sensitive data - balances, identity-linked information, or anything else that shouldn't be public - stays local and encrypted. Once that private update is settled, the transaction continues to the public layer, where only the necessary details are recorded. The result is a single action that touches two worlds: one completely private to the user, and another fully visible to everyone.
It's this blending that enables zero-knowledge execution to feel like regular Ethereum. Developers don't have to choose between building a private app and a public one. Instead, they can keep trust-critical elements out in the open while protecting parts that reveal too much. A lending protocol can show its global liquidity while hiding each borrower's debt profile. A game can reveal the winner without exposing every internal move. Every contract can decide what belongs on which side of the line.
The flow is simple in experience but complex under the hood. Private changes create new encrypted notes and nullifiers that are later recognized by the network, proving that the transaction followed the rules. Public changes update shared state, so applications stay composable with the rest of Ethereum. Through this layered execution, Aztec gives users control of what they reveal while developers keep the functionality and network effects that make Ethereum powerful. Privacy becomes part of the architecture - not a trade-off.
Developer Experience: Privacy without Isolation
A major challenge for early privacy chains was isolation. Building for them meant:
- Different programming models
- Separate liquidity
- Less composability
- Small or immature developer communities
Aztec avoids this fragmentation. Its smart contract language Noir allows builders to reuse Ethereum-style patterns while adding privacy controls where needed.
Developers can:
- Mix public and private functions inside a single contract
- Allow contracts to interact through both states
- Enable familiar asset models and DeFi patterns
Privacy becomes a feature of existing Ethereum-style development, not a replacement for it.
Interoperability with Ethereum
Aztec doesn't try to steal users or liquidity from L1 or other Layer 2 chains. Instead, the architecture is designed so value stays in established ecosystems.
Users can:
- Earn yield on Arbitrum
- Trade on DeFi pools on mainnet
- Participate in governance on Base
...while interaction flows through Aztec to shield identities and strategies. Composability remains intact. Privacy becomes optional. Ethereum remains the settlement layer.
Why Aztec's Model Matters

A privacy-capable Ethereum unlocks practical adoption in ways that transparent chains alone cannot. Individuals gain meaningful protection against behavioral tracking. Institutions gain an environment for compliance-alignable private operations.
Potential beneficiaries include:
- Funds executing trading strategies
- Enterprises running payroll and settlement flows
- DAOs protecting sensitive votes
- Apps that require personal data - without revealing it
- Users wanting to separate financial activity from identity
The future isn't a choice between private or public systems. It's a world where both can operate together. Aztec is one of the first architectures built specifically to make that possible.
Challenges Ahead
Programmable privacy isn't simple. There are real hurdles:
- Zero-knowledge proving remains computationally demanding
- Developer onboarding requires learning new mental models
- Regulators still debate how privacy tech fits into policy
- Security assumptions must withstand years of scrutiny
These challenges are not unique to Aztec. But solving them in a way that preserves trust while protecting user autonomy is critical to the evolution of public blockchains. Adoption will depend on delivering privacy that is:
- Easy to use
- Practical at scale
- Legally compatible
- Secure under open verification
Progress continues, but this is still early infrastructure.
Looking Forward
Aztec is building toward an Ethereum where private and public systems work seamlessly inside one network. Transparent security remains where it's needed. Personal data stays personal. Applications retain composability and liquidity access. This is not privacy as a separate chain. It is privacy woven into Ethereum's design. The blended state model - private UTXO with public account-based logic - is the foundation. Notes, nullifiers, client-side execution, and selective visibility all combine to make privacy a programmable primitive.
The goal is simple: Users shouldn't have to choose between confidentiality and participation in the Ethereum economy. If Aztec succeeds, the next phase of Web3 innovation will feel a lot more natural - and a lot more private.