Build with Selective Privacy, Earn $AZTEC

42K+
Learn How Aztec Unites Private & Public Execution on L2
Ended
Event Period:02/23/2026 16:00:00 - 03/09/2026 16:00:00 (UTC+8)
Earn Up to 3 USDT Rewards

Learn with Aztec (AZTEC): Privacy-First Smart Contracts on Ethereum L2

Published: February 23, 2026 at 3:14 AM

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:

  1. 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

  1. 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
    • fee payment strategy (pay fees in different tokens, sponsor models, etc.)

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.
Disclaimer: The information on this page may come from third parties and does not necessarily reflect the views or opinions of KuCoin. This content is for reference only and does not constitute any form of representation or warranty, nor should it be construed as financial or investment advice. KuCoin is not responsible for any errors or omissions, or for any outcomes resulting from the use of this information. Investing in virtual assets may involve risks. Please carefully assess the product risks and your risk tolerance based on your financial situation. For more information, please refer to our Terms of Use and Risk Disclosure.