Skip to main content
Version: dev

L1 RPC requirements

Draft page

For deep blob-storage configuration (S3, GCS, R2), see Blob retrieval in Advanced operations. This page covers what every operator needs to know about the L1 connection itself.

Every Aztec node needs two L1 endpoints: one execution client (Geth, Nethermind, etc.) and one consensus client (Lighthouse, Prysm, etc.).

TL;DR​

  • Run your own L1. Hosted RPCs at Aztec polling rates are expensive and frequently rate-limit you off the chain.
  • Your consensus client must be a supernode (Lighthouse v8.0.0+ with --super-node, Prysm v7.10+ with --super-node) or it will silently fail to reconstruct blobs older than 18 days.
  • The default archiver polling interval is 500 ms; tune only if a hosted RPC rate-limits you.

What each endpoint does​

EndpointWhat it does for Aztec
Execution client (EL)Reads Rollup-contract state, submits proposals and attestations, queries gas prices
Consensus client (CL)Retrieves blob data (KZG-committed transaction data posted to Ethereum)

Both must support high throughput and low latency. Aztec polls L1 frequently; a slow or rate-limited endpoint will cause your node to fall behind the chain tip, which is a slashable condition under the inactivity offense.

The supernode requirement​

Your consensus client must run with supernode (or semi-supernode) capability:

  • Lighthouse: version v8.0.0+ with --super-node or --semi-super-node
  • Prysm: version v7.10+ with --super-node or --semi-super-node
  • Teku: support varies; check Teku release notes for blob-archive options
  • Nimbus: support varies; check Nimbus release notes

A regular consensus node only retains blob data for ~18 days (the Ethereum protocol-level blob retention window). Aztec sometimes needs to reconstruct blob data from earlier, which requires either a supernode (which retains all blobs locally) or a fallback blob archive.

If you set up a standard beacon node without these flags, your Aztec node will silently fail to reconstruct certain blobs and you will see archiver errors. Plan for the supernode flags from the start.

Self-hosted vs hosted RPC​

Most production operators self-host their L1 endpoints because:

  • Hosted blob-supporting RPCs are expensive (often 200to200 to 600 / month at sustained Aztec polling rates).
  • Free-tier RPCs hit rate limits and cause your Aztec node to fall behind.
  • Self-hosting once gives you predictable cost and unlimited polling.

The minimum self-hosted setup is one execution client (Geth, Nethermind, Besu, or Erigon) plus one consensus client (Lighthouse or Prysm) with the supernode flag. Both can run on the same machine as the Aztec node if you have the disk for it; Ethereum's state plus beacon-chain data add several hundred GB to your Aztec footprint.

For a one-stop installer that handles Geth + Lighthouse setup with the correct flags, see the pittpv RPC setup script linked from Operator tooling.

If you do choose hosted, check that the provider advertises:

  • Beacon-API support (/eth/v1/beacon/blob_sidecars/{block_id} and related endpoints)
  • Blob data retention beyond the 18-day default

Tuning polling intervals​

The archiver polls L1 at a default of 500 ms (ARCHIVER_POLLING_INTERVAL_MS). A second viem-level polling interval defaults to 1000 ms (ARCHIVER_VIEM_POLLING_INTERVAL_MS).

The defaults are reasonable for self-hosted RPCs. On rate-limited hosted RPCs you may need to raise the archiver interval to avoid 429 errors:

ARCHIVER_POLLING_INTERVAL_MS=1000
ARCHIVER_VIEM_POLLING_INTERVAL_MS=2000

Raising the interval trades observed latency for fewer L1 calls. The maximum observed delay for new blocks is roughly ARCHIVER_VIEM_POLLING_INTERVAL_MS + ARCHIVER_POLLING_INTERVAL_MS, so doubling both pushes worst-case detection of a new L1 block to about 3 seconds, which is still well within slot timing.

If you are seeing 429s, the cheaper fix is to move to self-hosted.

The most common L1-side errors​

Error / symptomLikely cause
Error: server returned an error response: 429 Too Many RequestsRPC rate-limited; raise ARCHIVER_POLLING_INTERVAL_MS or move to self-hosted
Archiver stuck, blob reconstruction failuresConsensus client missing the supernode flag
Failed to validate blobs: 'Missing or invalid parameters.'Execution client RPC has an incompatibility with eth_sendRawTransaction for blob txs (reported with some Nethermind builds)
Publisher tx repeatedly fails with insufficient funds despite balancePublisher's gas-price estimate is too low; check the L1 client's gas-oracle behavior

See also​