> ## Documentation Index
> Fetch the complete documentation index at: https://docs.base.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Proof System

> Specification of the Azul multi-proof system, replacing the single output proposer with an AggregateVerifier contract for L2 checkpoint security.

Azul introduces a multi-proof system for the L2 checkpoints that secure withdrawals to L1. A
checkpoint is a fixed interval of L2 blocks summarized by an output root. Each proposal about that
checkpoint is submitted to `AggregateVerifier`, an L1 dispute game that can verify one or two
proofs for the same proposal before withdrawals rely on it.

In the common path, a TEE prover creates the initial proposal proof. A permissionless ZK prover can
later back the same proposal or dispute an invalid one. `AggregateVerifier` delegates proof checks
to dedicated verifier contracts, while a prover registrar keeps the onchain registry of accepted
TEE signer identities up to date.

## Why Change the Proof System

Base's current fault-proof system is optimistic and interactive: a proposal resolves unless someone
challenges it. That model has two limits.

* Withdrawals take at least 7 days because every proposal inherits the full challenge window.
* Every bad proposal must be actively challenged. That creates an economic attack surface: if
  challengers cannot fund every dispute, an incorrect state can finalize. Centralized guardrails
  reduce that risk today, but that is not a long-term model for Stage 2 decentralization.

Azul replaces that model with a multi-proof design built around TEE and ZK provers. TEE proofs
support the common path, ZK proofs provide a permissionless backstop, and the architecture leaves
room to adopt stronger proving systems over time.

## Finality Model

The Azul design supports three settlement paths for a proposal on Ethereum:

| Proofs present | Settlement path | Target window | What it means                            |
| -------------- | --------------- | ------------- | ---------------------------------------- |
| TEE only       | Long window     | 7 days        | Common path, still overridable by ZK     |
| ZK only        | Long window     | 7 days        | Permissionless path without TEE reliance |
| TEE + ZK       | Short window    | 1 day         | Faster finality when both systems agree  |

The long window gives independent provers time to verify a claim and dispute it if needed. The
short window is available only when both proof systems back the same proposal. A ZK prover can also
dispute an invalid TEE-backed claim and claim the TEE prover's bond as a reward. In Azul, that delay
lives in `AggregateVerifier` itself. `OptimismPortal2` and `AnchorStateRegistry` no longer add a
separate 3.5 day delay, because keeping either legacy delay would eliminate the fast-finality path
even when both proofs are present.

## Security and Decentralization

* The TEE path is permissioned and optimized for the common case.
* The ZK path is permissionless and can override an invalid TEE-backed claim.
* The proof layer remains modular and can evolve toward stronger TEE implementations, different ZK
  systems, or multi-ZK designs.

## Overview

### New/Changed Onchain Components

* `AggregateVerifier`: Azul's dispute-game contract for checkpoint proposals. Each proposal is
  initialized with one proof, a second proof can be added later for the same claimed root, and the
  contract calls proof-specific verifier contracts and aggregates their results to determine how the
  proposal resolves. This is also where the Azul finality delay now lives.
* `TEEVerifier` and `ZKVerifier`: proof-specific verifier contracts called by `AggregateVerifier`.
  Their addresses are immutable on the `AggregateVerifier` implementation, so each deployment has
  an explicit verifier set.
* `DelayedWETH`: still escrows the proposal bond for each game, but Azul reduces its withdrawal delay
  to 1 day. That is sufficient here because the only bonds at stake are proposer bonds.
* `OptimismPortal2`: no longer adds the separate 3.5 day proof-maturity delay for these proposals.
  That timing moves into `AggregateVerifier`, which keeps the 1 day path reachable instead of
  forcing every proposal to inherit at least 3.5 days of extra delay.
* `AnchorStateRegistry`: Similar to `OptimismPortal2`, this no longer has a 3.5 day finalization
  delay for proposals, allowing fast finality.

### Proof Flow

The proof flow for Azul is:

1. The proposer identifies the next canonical checkpoint range and requests a TEE proof.
2. The TEE prover re-executes that L2 block range inside an AWS Nitro Enclave and signs the
   resulting output root.
3. The proposer verifies the result against canonical Base L2 state and submits a new
   `AggregateVerifier` game to L1.
4. A challenger can independently recompute the same checkpoint roots and, if it finds an invalid
   claim, sources the ZK proof needed to dispute it.

This architecture keeps the normal path simple, preserves a permissionless dispute path, and
supports faster settlement when both proof systems are available.

## Proof Roles

* The proposer turns canonical L2 checkpoints into new `AggregateVerifier` games on L1.
* A challenger checks in-progress games against canonical L2 state and disputes incorrect claims.
* TEE provers power the common proposal path.
* ZK provers provide the permissionless verification and override path.
* The registrar maintains the onchain registry of accepted TEE signer identities.
* `AggregateVerifier` and its verifier contracts verify claims before withdrawals on L1 can rely on
  them.

## Proposer

The proposer turns safe or finalized Base L2 checkpoints into L1 `AggregateVerifier` games. It
finds the latest canonical parent state, requests a TEE proof for the next checkpoint interval,
verifies the returned output root against canonical L2 state, and submits the next proposal with
the required bond.

## Challenger

Anyone can run a challenger. A challenger independently recomputes checkpoint output roots for
in-progress games, identifies the first invalid claim, and submits the required dispute
transaction. The permissionless dispute path is a ZK proof challenge. Base will run a challenger as
a security backstop, and Base's challenger also has access to a TEE nullification path for invalid
TEE-backed proposals.

## TEE Provers

TEE provers are AWS Nitro Enclave-backed services used in the common proposal path. The host gathers
witness data from RPCs, the enclave re-executes the requested L2 block range in isolation, and the
enclave signs the resulting checkpoint outputs with a key that never leaves the enclave.

## ZK Provers

ZK provers are the permissionless proving backend in Azul. They are used when a dispute requires a
ZK proof, especially to challenge an invalid TEE-backed proposal or to invalidate a bad ZK claim.
In normal operation, the proposer does not depend on ZK provers to create new games. In the
future, the proposer may integrate ZK provers directly so new roots can carry both proof paths from
the start, unlocking faster finality for all roots.

## Prover Registrar

The prover registrar keeps the onchain `TEEProverRegistry` in sync with the live set of Nitro prover
signers. It discovers active provers, attests their signer identities onchain, and removes orphaned
signers with safeguards against transient outages.