Skip to content

feat: resolve rollup address from Aztec Registry, drop static config#59

Merged
koenmtb1 merged 1 commit intomainfrom
feat/resolve-rollup-from-registry
Apr 21, 2026
Merged

feat: resolve rollup address from Aztec Registry, drop static config#59
koenmtb1 merged 1 commit intomainfrom
feat/resolve-rollup-from-registry

Conversation

@koenmtb1
Copy link
Copy Markdown
Contributor

Summary

  • Indexer: indexes Aztec Registry CanonicalRollupUpdated events into a new rollup_version table, and uses Ponder's factory pattern on the same event to auto-index every canonical rollup, historical, current, and future upgrades without a config change.
  • New endpoint: GET /api/rollups returns current canonical + full history ([{version, address, blockNumber, timestamp}, ...]). Source of truth is the indexed table; served by a trivial select.
  • API handlers: getCanonicalRollupAddress now reads the DB table first and only falls back to live Registry RPC during the brief pre-sync window.
  • Frontend: resolves the rollup via fetch(${VITE_API_HOST}/api/rollups) at boot, no viem, no RPC dependency, no Registry ABI. Caches the full version list in getRollupVersions().
  • Config: replaces ROLLUP_ADDRESS with REGISTRY_ADDRESS + REGISTRY_START_BLOCK on the indexer; drops VITE_ROLLUP_ADDRESS entirely on the frontend

Why

Rollup cutovers (Registry.addRollup()) change the canonical rollup's address. Previously that address was baked into env vars / CI secrets / Terraform, so every upgrade required a coordinated redeploy of both services. The Aztec Registry already exposes this via getCanonicalRollup() and emits CanonicalRollupUpdated on every upgrade.

After this change: upgrades are picked up automatically. The indexer keeps indexing events from every historical rollup forever (claims / withdrawal finalizations on old rollups continue flowing through existing handlers), and the frontend reads the current rollup on every page load.

Scope note

This PR makes the dashboard upgrade-aware for normal operation against the current canonical rollup. It does not yet let users claim rewards or finalize withdrawals against old rollups — the event data is preserved (rollupAddress is on every event in the schema), but the UI still issues claim/finalize transactions against the current canonical rollup only. This will follow in a follow-up PR.

Mainnet config values

  • Registry address: 0x35b22e09Ee0390539439E24f06Da43D83f90e298
  • Registry deployment block: 23786827
  • Current canonical rollup (verified): 0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962
  • numberOfVersions(): 2, factory backfill will replay both

Deploy checklist

  • Add REGISTRY_ADDRESS + REGISTRY_DEPLOYMENT_BLOCK as GitHub environment vars for testnet and prod (both indexer + dashboard environments).
  • After merge, ROLLUP_ADDRESS GH env var can be removed.
  • Indexer re-sync required: the Rollup contract changed from a static address to factory-sourced, which invalidates the Ponder schema hash. Re-syncs from REGISTRY_START_BLOCK (~ATP factory deployment).
  • Any contract_addresses.json files held outside the repo need registryAddress + registryDeploymentBlock added and rollupAddress removed.

@koenmtb1 koenmtb1 requested a review from a team April 20, 2026 11:27
@koenmtb1 koenmtb1 requested a review from a team as a code owner April 20, 2026 11:27
@koenmtb1 koenmtb1 merged commit 161fde5 into main Apr 21, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant