Aztec networks overview
The Aztec Protocol operates across multiple networks, each serving specific purposes and audiences. This page gives builders and node operators the technical details to connect to each network: live version, RPC and bootnode endpoints, contract addresses, and governance parameters.
Not sure which network or version to pin against? Jump to the Network selection guide. For release channels and what is coming next, see Versions and releases.
Network technical information
| Parameter | Alpha (Mainnet) | Testnet |
|---|---|---|
| Version | 6.0.0 | 6.0.0 |
| L1 Chain ID | 1 (Mainnet) | 11155111 (Sepolia) |
| Rollup Version | 2070860440 | 679261766 |
| RPC Endpoint | https://aztec-mainnet.drpc.org | https://aztec-testnet.drpc.org |
| Bootnodes | http://static.aztec.network/mainnet/bootnodes.json | http://static.aztec.network/testnet/bootnodes.json |
| Block Explorer | Aztecscan, Aztecexplorer | Aztecscan, Aztecexplorer |
| Getting Started | Run a sequencer → | Run a node → |
Testnet is your production path. It's decentralized, live, and stable: treat it as your staging environment for Alpha. If you want to deploy on Alpha, validate on Testnet first.
Versions and releases
Aztec is a monorepo. Each release publishes a single version that covers the node, Aztec.nr, and aztec.js together, so a network on 6.0.0 runs the 6.0.0 node, contracts compiled with the 6.0.0 Aztec.nr, and clients built against the 6.0.0 aztec.js. The Version row in the table above is the build a given network is currently running.
Release channels
Aztec publishes three kinds of builds, each with a different stability promise.
| Channel | Example | What it is | Recommended audience |
|---|---|---|---|
| Stable | 6.0.0, 5.2.0 | The validated, final version for a release cycle. | Builders shipping to users. Operators running Alpha or Testnet. |
| Release candidate (RC) | 5.0.0-rc.1, 5.0.0-rc.2 | Pre-release of an upcoming stable, used for internal validation and Testnet rehearsals. Additional RCs ship if issues are found. | Operators participating in pre-release rehearsals. Builders verifying compatibility ahead of a stable cut. |
| Nightly | 5.0.0-nightly.<date> | Latest in-progress work from the development branch. Experimental, less tested. | Builders previewing upcoming features. Not recommended for production. |
An RC is not newer than its matching stable: 5.0.0-rc.1 is a checkpoint on the way to 5.0.0, and 5.0.0 supersedes every 5.0.0-rc.*.
Release notes for each version are generated from the commit range since the previous release and published on the GitHub releases page. The Git history is the source of truth for what changed between two versions.
Cadence
Stable releases target roughly one per month, typically mid-month. Dates are not strictly fixed; the cadence is intended to be regular rather than ad hoc.
Contract addresses
L1 contract addresses
L2 contract addresses
| Contract Name | Alpha (Mainnet) | Testnet |
|---|---|---|
| Instance Registry | 0x0000000000000000000000000000000000000000000000000000000000000002 | 0x0000000000000000000000000000000000000000000000000000000000000002 |
| Class Registry | 0x0000000000000000000000000000000000000000000000000000000000000001 | 0x0000000000000000000000000000000000000000000000000000000000000001 |
| MultiCall Entrypoint | 0x2d464e835406c6057bf147843d1541e0b338a13f8fedd5cba697629172dd8105 | 0x2d464e835406c6057bf147843d1541e0b338a13f8fedd5cba697629172dd8105 |
| Fee Juice | 0x0000000000000000000000000000000000000000000000000000000000000003 | 0x0000000000000000000000000000000000000000000000000000000000000003 |
| SponsoredFPC | Not deployed | 0x2d8fff82a3b0c15d0a89169e7d8d043e079ab94d52031f1de1e4972ebad169d3 |
Governance parameters
| Parameter | Alpha (Mainnet) | Testnet |
|---|---|---|
| Proposer Quorum | 600/1000 | 60/100 |
| Voting Delay | 3 days | 2 minutes |
| Voting Duration | 7 days | 6 minutes |
| Execution Delay | 2 days | 2 minutes |
| Slashing Quorum | 65/128 | 65/128 |
| Slashing Round Size | 4 epochs (128 slots) | 4 epochs (128 slots) |
Network selection guide
Alpha (Mainnet)
Alpha is the Aztec mainnet in its initial operational phase, with governance, networking, and transaction processing fully active. Alpha is live but early, so bugs (including critical ones) are expected. For a full explanation of what this means, see the Alpha Network page.
Overview
Alpha is connected to Ethereum mainnet and supports user transactions. Governance and staking infrastructure are fully operational. This network requires real stakes for sequencer participation.
Target users:
- Sequencers who want to contribute to the decentralized Aztec Network
- Governance participants
- Developers deploying production applications
- Infrastructure operators
Key features:
- Governance system fully operational
- Staking required for sequencer participation
- Connected to Ethereum Mainnet
- User transactions supported
Testnet
Testnet is the production path for Aztec. It operates as a fully decentralized network with multiple sequencers and closely mirrors Alpha conditions. If you plan to deploy on Alpha, Testnet is where you validate your application. Think of it as your staging environment for the real thing.
Overview
Testnet is ideal for testing node configurations, governance proposals, and understanding network dynamics without real financial risk.
Target users:
- Future Alpha sequencer operators testing configurations
- Developers requiring production-like testing conditions
- Governance participants practicing proposal workflows
- Infrastructure operators validating monitoring setups
Key features:
- Fully decentralized sequencer set
- Connected to Ethereum Sepolia
- Transactions are proven
- Sponsored FPC available for free transactions
- Good environment for testing node operations
Choosing a version
Once you have picked a network, choose a release channel that matches your role:
- Building on Aztec. Pin Aztec.nr and aztec.js to the stable version that matches the network you are targeting (see the Version row in the Network technical information table). Validate on Testnet before deploying to Alpha. Use nightlies only when you need an unreleased feature, and expect breakage.
- Running a node or sequencer. Run the stable version listed for your network. Switch to an RC only when an upcoming-release rehearsal is announced on Testnet.
- Tracking what is coming. Watch Releases for the current stable, any RCs in flight, and nightly tags. A public release calendar is on the roadmap; until then, the releases page is the authoritative timeline.
Next steps
Based on your use case:
- Building an application? Start with Getting started.
- Running infrastructure? Review the Network operator guide.
- Joining as a sequencer? See Sequencer management.
- Tracking releases? See Versions and releases above and the GitHub releases page.