Introduction: Aztec is a privacy-first Layer 2 that lets developers build smart contracts with both private & public state and private & public execution, enabling “selective privacy” apps that feel like normal DeFi—without exposing everything on-chain.
What Is Aztec?
Aztec is a Layer 2 network focused on privacy-by-design while still supporting public composability when needed.
The key idea is simple:
-
Private execution & private state for sensitive user actions (balances, identity, intent, strategy).
-
Public execution & public state for things that must be globally visible (public liquidity, public contract logic, shared state).
So instead of choosing “all public” or “all private,” Aztec supports hybrid apps.
How a Transaction Works on Aztec
Aztec splits execution into two separate environments:
-
Private Execution Environment (PXE) — runs on the user side
Private functions are executed client-side inside the PXE (pronounced “pixie”) to maximize privacy.
The PXE:
-
executes private functions locally
-
holds keys + notes
-
generates zero-knowledge proofs for private operations
-
is included in aztec.js (TypeScript), runnable in Node or the browser
-
Public VM (AVM) — runs on Aztec nodes
Public functions execute on the network in the Aztec Virtual Machine (AVM), conceptually similar to the EVM (so “gas-efficiency intuition” applies more like Solidity).
Directional execution rule (important)
A transaction flows private → public:
-
Private functions can enqueue public functions to run later.
-
Public functions cannot call private functions.
That separation is intentional: the public network should not be able to “reach into” private execution.
Private vs Public State: Notes, Nullifiers, and Trees
Aztec uses different state models depending on privacy:
Private state = UTXO-style “notes”
Private state is stored as notes (UTXO-like chunks of data). To keep things private:
-
Notes are appended into an append-only UTXO tree
-
When a note is “spent/deleted,” a nullifier is created
-
Nullifiers are stored in a separate nullifier tree
This allows the network to enforce “spent once” without revealing the private contents of notes.
Public state = account-like public storage
Public state behaves more like Ethereum:
-
stored in a public data tree
-
updated directly and visible on-chain
Developer takeaway:
-
Private state work = commitments + nullifiers (prove correctness without revealing data)
-
Public state work = direct updates (normal blockchain storage behavior)
Account Abstraction: Every Account Is a Smart Contract
Aztec has native account abstraction at the protocol level:
-
There are no EOAs (no simple “keypair accounts”)
-
Every account is a smart contract
-
Developers can define their own rules for:
-
authentication (signatures, multisig, passkeys, custom logic)
-
authorization policies (limits, permissions, session keys)
-
nonce / replay protection
-
Why this helps against DoS (the “validation is expensive” problem)
Aztec’s model pushes complex validation client-side:
-
The client validates and generates a ZK proof that “validation succeeded”
-
The sequencer verifies a constant-size proof
-
So validation complexity doesn’t blow up network verification cost
This enables “power-user” account logic without making the chain slow.
Keys in Aztec Accounts (Privacy-Focused)
Each Aztec account is backed by 3 key pairs:
-
Nullifier key pair: used for computing note nullifiers
-
Incoming viewing key pair: used to encrypt notes for the recipient
-
Outgoing viewing key pair: used to encrypt notes for the sender
Because accounts are smart contracts, they don’t automatically have a signing keypair—authentication is up to the account contract design.
Auth Witnesses: Safer Than “Infinite Approvals”
Aztec replaces the risky “infinite approval” pattern with Authentication Witnesses (AuthWit):
-
instead of granting unlimited permission forever,
-
users authorize specific actions with specific parameters
This is designed to reduce persistent approval risk while still enabling good UX (batching, automation).
Build on Aztec with Noir
Aztec smart contracts are written in Noir, a ZK-focused language for writing provable programs/contracts. One key warning from the docs: private functions can be written in detrimentally unoptimized ways because proving has different performance intuition than normal execution—so learning “how to write performant Noir” matters.
