# Sidecar - Out-of-Protocol Proving

## The proving challenge

Every Aztec block must be backed by a zkp. This is what makes the rollup valid, allowing L1 contracts to verify its state transitions without re-executing transactions. But producing a proof isn’t instant. It can take minutes of heavy computation. And while sequencer selection is protocol-enforced via Fernet, proving in Aztec is intentionally not enshrined.

Instead, it uses a coordination model called **Sidecar**. This is a system where provers interact with sequencers off-chain to negotiate, commit, and guarantee proof production. The protocol provides economic hooks, but the proving process itself is out-of-band. This gives Aztec flexibility to evolve its proving markets, swap in new proving systems, or scale coordination models, all without requiring protocol upgrades.

In this walkthrough, we’ll trace how Sidecar works in practice, how commitments and slashing enforce liveness, and how it opens the door to proving specialization and out-of-protocol marketplaces.

## Overview: What is and isn't in Protocol

Sidecar is sort of a coordination layer, a minimal set of protocol rules that bind sequencers and provers together through onchain commitments, but leave the actual work of proving to **external actors**.

Here’s what **is** in protocol:

- A **commitment transaction** on L1 where the sequencer specifies a `proverAddress` and posts a **proverDeposit** (slashable bond).
- A **time window** during which a valid proof must be submitted to L1 for the corresponding block.
- A **slashing mechanism** that penalizes missed proofs by burning or redistributing the deposit.

Here’s what **is not** in protocol:
- No mechanism for matching sequencers to provers.
- No standard auction format.
- No requirement on who proves the block: it could be the sequencer, a proving service, a relayer, or a distributed network.

This separation is intentional. By moving the coordination logic **outside the core rollup contracts**, it allows Aztec to:

- Support multiple proving ecosystems (e.g., Nil, Gevulot, Kalypso),
- Let sequencers choose their own strategies (self-prove, outsource, delegate),
- Iterate on proving economics without needing contract upgrades.

In practice, Sidecar defines **three key phases** after block proposal:

1. **Prover Commitment Phase**: a prover is selected and committed to on L1.
2. **Proving Phase**: the proof is generated off-chain.
3. **Proof Submission Phase**: the proof is submitted to L1.

Failure to complete any phase has defined fallback behavior, ensuring the system continues to make progress.

## The commitment mechanism: how provers get selected

After a sequencer successfully proposes and reveals a block, the next step is to **secure a prover**. In Sidecar, this happens during the **Prover Commitment Phase**: a bounded window (e.g., 3–5 Ethereum blocks) during which the sequencer must lock in a proving strategy.

This strategy revolves around a single onchain action: the sequencer submits a transaction committing to a `proverAddress` and posting a **proverDeposit** in an ERC-20 token. This address is expected to generate and submit the zero-knowledge proof for the block before the proving window expires.

The mechanics are simple:

commitProver(proverAddress, proverDeposit)

The `proverAddress` can be:
- The sequencer itself (self-proving),
- A known proving service (e.g., nil, gevulot),
- A relayer or aggregator,
- Any externally controlled EOA or contract.

What matters is that the deposit is **slashable**. If the block is not proven in time, the proverDeposit is burned or redistributed to affected participants. This enforces **short-term liveness** and aligns the economic incentives around timely proof generation.

### **Who pays the deposit?**

By default, the sequencer does. This reflects the fact that the sequencer is in control of the block and selects the prover. However, in more advanced setups, this deposit could be forwarded from the prover off-chain. For example:
- A proving marketplace might require payment before releasing a prover address.
- A relayer might front the deposit in exchange for a reward share.
- A vertically integrated sequencer might simply post their own bond.

This flexibility allows different economic models to emerge (naive, trusted, or auction-based) without protocol changes.

### **What about multiple provers?**

Sidecar assumes one prover per block. It does not natively support distributed proving or subtree coordination. However, the `proverAddress` could itself be a smart contract that delegates or parallelizes work across multiple systems. This leaves room for future designs, like cooperative proving trees, while maintaining a simple base layer.

## Failure handling: prover timeouts, slashing, and backup modes

Sidecar is built around one key assumption (proofs must be produced **on time**). If the committed prover fails to deliver, the protocol must fall back, recover, and keep the network moving.

### **Timeouts and Slashing**

Once a prover is committed, they are given a fixed **proving window**, typically measured in Ethereum blocks (e.g., 40 blocks ≈ 8 minutes). If the proof is not submitted within this window:

- The block is **invalidated**,
- The `proverDeposit` is **slashed**,
- The chain reverts to the last finalized block,
- A new **proposal phase** begins.

The sequencer who committed the prover loses both the time and the deposit, regardless of whether they self-proved or outsourced.

This economic penalty gives sequencers a strong incentive to choose provers carefully. It also gives provers a reason to only accept jobs they can fulfill.

### **Backup Mode**

To avoid getting stuck if no prover is committed (or if the committed one fails), Sidecar includes a **backup proving mechanism**:

- If the commitment phase ends without any prover, or the proving phase ends without a valid submission,
- The block slot **reopens**,
- **Anyone** can submit a valid rollup proof for that block.

This is first-come-first-verified. The first valid proof that lands on L1 becomes canonical, and the network advances. The original proposer loses block rewards, but the chain doesn’t halt.

Backup mode ensures that **liveness is preserved**, even if all coordination mechanisms fail. It’s also a pressure valve against censorship. If a malicious sequencer commits but stalls, any party with the right data can prove the block themselves.

### **Slashing Redistribution (TBD)**

In future versions, slashed prover deposits may be redistributed:
- To backup provers who rescued the block,
- To other sequencers affected by the delay (uncle rewards),
- Or partially burned to reduce token supply.

This remains an open area for refinement but reinforces the idea that slashing is both a penalty and a funding mechanism for fallback scenarios.

## Design commentary: modularity, flexibility, tradeoffs

Sidecar is optimized for flexibility. So, by decoupling proof generation from the protocol, it allows Aztec to remain agile. But this modularity also introduces new coordination challenges and risk surfaces.

### **Why not enshrine provers?**

The decision to keep proving out-of-protocol follows the same logic as Ethereum’s **Proposer-Builder Separation (PBS)**:
- Provers and sequencers serve distinct roles.
- Decoupling them enables specialization.
- Market-based selection can evolve faster than protocol upgrades.

This means Aztec can integrate proving services, new zkVMs, or parallel proof networks **without forking the protocol**. As long as a `proverAddress` can submit a valid proof on time, the system remains coherent.

Sidecar is the minimum viable glue to connect these parts.

### **Coordination is pushed to the edge**

All the complexity (auctions, trust assumptions, relayer protocols) lives **outside the protocol**. This creates room for experimentation, but it also shifts risk to operators:

- Sequencers must build or integrate negotiation infrastructure (e.g., proof-boost).
- Provers must track revealed blocks and compete for proving rights quickly.
- Coordination failures result in slashing, not just lost opportunities.

This is acceptable for high-skill actors, but may exclude smaller or casual participants unless middleware emerges.

### **Timeliness vs Throughput**

Sidecar currently defines fixed proving windows and single prover commitments. This simplifies finality, but limits throughput scalability:
- Large blocks require fast provers or vertical integration.
- Shared proving pools or subtree splitting are not yet supported.
- Dynamic batching must be handled carefully to avoid extended reorg risks.

In time, Sidecar could evolve to support cooperative proving models (covered in a future article), but for now, it trades **parallelism** for **predictability**.

### **Slashing as a guarantee, not a punishment**

Slashing in Sidecar is designed to **guarantee liveness**, not to punish malicious behavior. There is no censorship detection, no equivocation rule, no in-protocol fraud logic. The only thing that matters is: was a valid proof submitted in time?

This reflects a bias toward **incentive alignment**, not enforcement.

## What this enables: Proof-Boost, Marketplaces, and Specialization

Because Sidecar does not prescribe how provers are selected, it creates space for an entire **prover economy** to emerge around Aztec. This mirrors the evolution of **block builders and relayers** in Ethereum's PBS stack, but tailored to the demands of zero-knowledge rollups.

### **Proof-Boost: PBS for ZK**

In analogy to mev-boost, **proof-boost** is a proposed middleware layer that lets sequencers outsource proof selection to external networks. A proof-boost relay could:
- Aggregate bids from multiple prover services,
- Run a sealed-bid auction or a simple RFQ (request for quote),
- Return the winning `proverAddress` and deposit details,
- Let the sequencer commit this on-chain before the timeout.

This lets sequencers earn block rewards without running proving infrastructure and allows provers to monetize capacity in an open, permissionless way.

Early prototypes of proof-boost may rely on trusted relays, but longer term, this layer could be decentralized and permissionless, just like the proving systems themselves.

### **Vertically integrated sequencers**

Sidecar also enables **vertical integration**. A sequencer with sufficient hardware may choose to:
- Self-prove every block,
- Avoid negotiation or relay dependency,
- Capture the full block reward and MEV path.

This reduces coordination risk and slashing exposure, at the cost of higher operational complexity. It also aligns well with specialized operators or teams that want tight control over uptime and performance.

### **Specialized provers and market differentiation**

Because the only requirement is proof validity and timeliness, provers can differentiate along multiple axes:

- Proof latency (faster = more valuable),
- Proof cost (cheaper bids = more competitive),
- Supported proving systems (Plonk, Goblin, STARKs),
- Custom optimization (e.g., handling large blocks, supporting batching).

This creates room for new infrastructure providers to enter the ecosystem and build services optimized for specific parts of the rollup lifecycle.

In time, this could resemble a **ZK builder market**, where performance and cost efficiency determine who gets to prove each block.

## Where this could evolve

It represents a pragmatic starting point: a coordination layer that does just enough to bind sequencers and provers economically, without locking the protocol into a specific architecture. It gives Aztec a way to move fast while still anchoring critical guarantees, like proof availability and liveness, on Ethereum.

But the proving ecosystem around Aztec is just beginning to take shape. Open questions remain:

- Should Sidecar evolve to support **cooperative proving**, where multiple provers work on a single proof tree?
- Could the prover commitment phase be merged into the proposal phase, reducing L1 gas cost and timing complexity?
- Is it worth **enshrining** proving eventually, once a dominant architecture emerges?
- How should **slashed deposits** be redistributed to reward honest actors and incentivize backup proving?

These questions are active areas of research and debate. I guess they will be shaped not only by protocol design, but also by the needs of app developers, relayers, and the operators running the infrastructure.

For now, Sidecar is an experiment in minimalism. A set of hooks, and a bet that the proving market will evolve faster than the protocol itself. Whether that bet pays off will depend on what the community builds next.