For the complete documentation index, see llms.txt.
Skip to main content

Verify everything works

Time: ~2 minutes. Three checks confirm your sequencer is synced, registered, and reachable.

1. Container healthy​

docker compose ps

Expected:

NAME              IMAGE                       STATUS
aztec-sequencer   aztecprotocol/aztec:...     Up 12 minutes (healthy)

The (healthy) flag comes from the health check in your compose file. It probes the node's own API every 30 seconds and requires a proven L2 tip, so this one line covers sync progress, API readiness, and container stability.

  • (health: starting): the node is still syncing. Initial sync takes 5 to 30 minutes.
  • (unhealthy): the API stopped answering or the node lost its proven tip. Check docker compose logs -f aztec-sequencer.
  • Up with no health suffix: your compose file predates the health check. Add it from the Docker Compose step.

2. Find your sequencer on an explorer​

Paste your attester address into one of the community explorers:

  • Dashtec: validator status, queue position, attestation activity.
  • Aztec Vision: sequencer explorer with per-attester activity.

What you should see:

  • Just registered: your attester sits in the entry queue. Status stays NONE for the first 1 to 2 epochs until the queue is flushed. This is normal, not a failed deposit.
  • Active: status VALIDATING, with attestations appearing whenever your sequencer is selected for a committee.

Once attestations show up, your node has proven itself end to end: it is synced, signing, and publishing over P2P.

Community-maintained

These explorers are community projects and can lag the chain. If your network or attester is not listed, or you want an answer straight from the contracts, use the CLI check at the bottom of this page. More explorers are listed in awesome-aztec.

3. P2P port reachable​

Until your first attestations appear on an explorer, a closed P2P port is invisible. Confirm it once, from a machine outside your network:

nc -zv {{P2P_IP}} 40400

Expected output:

Connection to <P2P_IP> 40400 port [tcp/*] succeeded!

After your sequencer starts attesting, this check is redundant: attestation activity already proves connectivity.

Advanced: check contract state directly (CLI)

Explorers read the same contracts through an indexer. These checks query the contracts directly.

Quick status check. The expected status is 1 (VALIDATING). Codes: 0 NONE, 1 VALIDATING, 2 ZOMBIE, 3 EXITING. A fresh deposit sits in the entry queue until an epoch boundary passes and someone calls flushEntryQueue(uint256) on the Rollup (anyone can, including you), so 0 during the first 1 to 2 epochs does not mean the deposit failed.

Full attester report. When a status is anything other than 1 and you need to see why, download check-attester.sh. It checks one or more attesters (status, effective balance, exit state, withdrawer) and prints a labeled, color-coded report with a health verdict per attester:

curl -o check-attester.sh https://docs.aztec.network/scripts/check-attester.sh
chmod +x check-attester.sh

# Check several attesters at once: comma-separated list
ATTESTER={{ATTESTER_ADDR}} \
ROLLUP={{ROLLUP_ADDR}} \
GSE={{GSE_ADDR}} \
ETH_RPC={{ETH_RPC}} \
  ./check-attester.sh

To confirm your provider entry (admin, take rate, rewards recipient), query the Staking Registry with your provider ID:

{ read PROVIDER_ADMIN; read TAKE_RATE; read REWARDS_RECIPIENT; } < <(
  cast call {{STAKING_REGISTRY_ADDR}} \
    "providerConfigurations(uint256)(address,uint16,address)" \
    {{PROVIDER_ID}} \
    --rpc-url {{ETH_RPC}}
)
echo "providerAdmin:            $PROVIDER_ADMIN"
echo "providerTakeRate:         $TAKE_RATE"
echo "providerRewardsRecipient: $REWARDS_RECIPIENT"

Field meanings and the queue-depth check are on the register sequencer page (provider section).

You're live​

Your sequencers are registered and attesting. The nodes will be randomly selected for committees starting next epoch and earn AZTEC rewards for attesting to and proposing blocks.

One step remains: go through Updates, alerts, rewards to learn how to keep your nodes on the current version, set up monitoring alerts, manage reward distribution, and keep your provider queue stocked.

If a node is running but proposals or attestations are not landing, see Sequencer troubleshooting.