## **Coordinating Aztec: Sequencers, Provers, and Governance in a Modular Rollup**

> _A walkthrough series on how Aztec is building its infrastructure for decentralized block production, zkp coordination, and fork-aware upgrades._

Aztec is building a new kind of L2: one where functions, variables, smart contracts and even bytecode can be private, and users can interact with the chain through encrypted state. This makes standard rollup assumptions harder to apply. There’s **no shared mempool**, **no transparent builder market**, and **no easy way to coordinate** who does what and when.

To make the network work, Aztec needs to answer three fundamental questions:

1. **Who gets to propose the next block?**
2. **Who proves that block is valid?**
3. **How does the network evolve, and who gets to decide?**

Over the past few months, the community and protocol designers have proposed answers to these questions. They are not finalized. But they reflect a coherent philosophy: **decentralize authority, enforce what matters, and leave the rest to modular coordination**.

This series of articles try to document that philosophy (across sequencing, proving, and governance) based on a collection of request-for-comments (RFCs), forum posts, protocol sketches, and coordination design proposals.

### **Part 1: Fernet - Randomized Sequencer Selection**

> _How Aztec selects block proposers using verifiable randomness, enforced commitments, and no L2 consensus._

In Aztec, sequencing is **open**. Anyone [can register to become a sequencer](https://tally.so/r/n0k0oN). Every few minutes, a new leader is selected using a verifiable random function (VRF), based on **RANDAO** and public inputs. This protocol, called **Fernet**, ensures fairness, censorship resistance, and compatibility with private mempools.

In the following article we walk through how Fernet works, how blocks are proposed and revealed, and what happens when things go wrong.

**Read: [Fernet - Aztec’s Random Leader Election for Sequencers](https://hackmd.io/@HSdqwwPmQB-GAaSnAFcwUQ/aztec-fernet-randomized-sequencer-selector)**

### **Part 2: Sidecar - Out-of-Protocol Proving**

> _A look into the proving coordination layer, where sequencers negotiate proof generation using external relays and economic guarantees._

Sidecar is the current default for coordinating provers. It does not define how proofs are built, only how sequencers commit to someone doing the work. This includes a `proverAddress`, a slashable bond, and a proving deadline. The actual negotiation happens offchain, allowing for unconstrained markets.

We explore how this works in practice, what fallback mechanisms exist, and how this enables proof-boost, relayer markets, and vertical integration.

**Read: [Sidecar - Proving Goes Off-Road](https://hackmd.io/@HSdqwwPmQB-GAaSnAFcwUQ/aztec-sidecar-out-of-protocol)**

### **Part 3: Cooperative Proving - Enshrined Coordination Across a Proof Tree**

> _A proposed alternative to Sidecar that brings prover selection into the protocol using VRF scores, reward sharing, and parallel proof trees._

Instead of outsourcing coordination, this model builds it directly into the protocol. Staked provers are ranked per proof node using VRF + burn-adjusted scores. Rewards are split across a shared tree, with provers incentivized to include redundant sub-proofs. The winning tree is the one with the highest cumulative score.

We walk through how this system works, why it improves liveness and parallelism, and what it costs in terms of protocol complexity.

**Read: [Cooperative Proving - Enshrined Coordination Across a Proof Tree](https://hackmd.io/@HSdqwwPmQB-GAaSnAFcwUQ/aztec-cooperative-proving)**

### **Part 4: The Republic - Fork-Aware, Non-Coercive Governance**

> _A design for protocol upgrades that avoids forced migrations and empowers users, portals, and infrastructure to choose their own path._

Aztec treats governance as coordination: not control. Instead of relying on a single upgrade path, it introduces **portals** (self-governed bridges), a **Senate** (elected proposal body), and a **registry** (version tracker). Users can reject upgrades without losing funds. Portals can refuse to follow. And pending messages are version-aware to keep forks clean.

This article walks through the full governance lifecycle, from AZIPs to forced exits, and compares Aztec’s model with fully governed and immutable systems.

**Read: [The Republic - Fork-Aware Governance for a Modular Aztec](https://hackmd.io/@HSdqwwPmQB-GAaSnAFcwUQ/the-republic)**

### **Why This Matters**

As rollups scale and decentralize, coordination becomes the problem. Aztec is tackling this head-on by creating protocol rules where trust is unavoidable, and markets where flexibility is needed. Sequencing, proving, and upgrading are treated as separable concerns, each with its own guarantees, risks, and escape hatches.

This series is a snapshot of how the protocol is being designed in the open.

# References
[Request for Comments: Aztec Sequencer Selection and Prover Coordination Protocols](https://forum.aztec.network/t/request-for-comments-aztec-sequencer-selection-and-prover-coordination-protocols/3038
)

[The Republic: A Flexible, Optional Governance Proposal with Self-Governed Portals](https://forum.aztec.network/t/the-republic-a-flexible-optional-governance-proposal-with-self-governed-portals/609)

[[Proposal] Prover Coordination: Sidecar](https://forum.aztec.network/t/proposal-prover-coordination-sidecar/2428)

[[Proposal] Cooperative proving network for Fernet](https://forum.aztec.network/t/proposal-cooperative-proving-network-for-fernet/2400)

[[Proposal] Provers: Bonded Prover Auction](https://forum.aztec.network/t/proposal-provers-bonded-prover-auction/2401)

[Fernet](https://hackmd.io/@aztec-network/fernet)