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

Updates, alerts, rewards

Time: ~5 minutes. Your sequencers are running. Set up four things before you call it done: version upgrades, monitoring alerts, reward distribution, and queue monitoring. The rest of this page is reference material to keep handy.

1. Stay current on upgrades​

When a new version is released:

# Pull new image and restart
docker compose pull && docker compose up -d

# Verify version
docker compose logs aztec-sequencer | head -20
Watch for upgrade announcements

Some upgrades require action within a specific timeframe; a node left on an old version eventually stops attesting. Watch the channels in Where to stay informed below, especially Discord, where time-sensitive upgrade notices are posted first.

2. Set up monitoring and alerts​

Aztec exports metrics via OpenTelemetry. The full monitoring stack:

  • OpenTelemetry Collector receives metrics from the node via OTLP.
  • Prometheus stores time-series metrics.
  • Grafana renders dashboards and alerts.

Key metrics to watch:

  • Attestation rate (target: 99%+)
  • Block proposals
  • Committee participation
  • Peer count
  • Disk usage
Lightweight alternative

Don't want to set up the full OTEL stack? pittpv/aztec-monitoring-script is a community tool that monitors your node and sends alerts to Telegram.

See the full monitoring setup guide when you're ready for the proper stack.

3. Claim rewards​

Two paths:

  • Aztec staking dashboard — aggregates pending rewards across every sequencer you operate, claims in one wallet flow. Easiest for most operators.
  • CLI claim — see the Claiming Rewards guide for the full reference (pending-rewards check, claimSequencerRewards cast send, keystore-file and hardware-wallet variants, gas-limit troubleshooting).

In the default flow, your coinbase for each delegated attester is the per-delegation Split contract (set in Configure environment). Each delegation's Split is a Splits-V2 pull split, so getting rewards out to the final addresses is two steps. First, anyone calls distribute() on the Split contract, which moves the accumulated balance into the shared Splits warehouse and credits each recipient by their share. Second, each recipient calls withdraw() on the warehouse to move their credited balance to their own address: your commission share to the rewards-recipient address you set at registration, and the delegator's share to their vault. Both steps are permissionless and need no manual settlement script; just monitor that delegations are being distributed and withdrawn.

Alternative: EOA coinbase with the payout script

The Split flow is the default, not the only option. A provider can set the coinbase to an address they control and run the payout script to calculate and distribute delegator rewards at a published commission and cadence. See the configuration step and the forum announcement.

4. Keep your provider queue stocked​

Every delegation pulls one keystore off your queue. Empty queue = no new delegations can activate. Check queue length:

cast call {{STAKING_REGISTRY_ADDR}} \
  "getProviderQueueLength(uint256)(uint256)" \
  {{PROVIDER_ID}} \
  --rpc-url {{ETH_RPC}}

For a cron-driven alert that pings you below a threshold, see the Monitoring Keystore Availability section — copy that script verbatim, edit the placeholders, schedule with crontab -e.

When you need to add more keystores, follow the same flow you used in register as staking provider (Step 2).

For per-delegation Split-coinbase updates, provider config changes, queue recovery (dripProviderQueue), and admin rotation, see the dedicated provider operations page.

Slashing awareness​

Slashing is tiered. Inactivity (failing to attest or propose when assigned) is slashed 2,000 AZTEC, and so is submitting a proposal with invalid attestations. Duplicate proposals and duplicate attestations are slashed 5,000 AZTEC. There is a 190,000 AZTEC ejection threshold below which the sequencer is ejected. See Slashing for the full offense set and thresholds.

Where to stay informed​

  • Discord — upgrade announcements and operator discussion. This is where version updates and time-sensitive notices are posted first.
  • Forum — longer-form proposals, governance, and operator announcements.
  • GitHub — source, issues, and releases.
  • Changelog — per-version operator-facing changes and migration notes.

You finished the guide​

Your sequencers are live. Focus on keeping the publisher funded, the L1 endpoints reliable, keeping your nodes on the latest recommended version, and keeping the queue stocked.