From de2c2764b17516d69932fa95dea0965fbd006f84 Mon Sep 17 00:00:00 2001
From: Paperclip Minimizer <minim@defi.sucks>
Date: Mon, 25 Aug 2025 14:29:58 -0300
Subject: [PATCH 01/10] docs: add consensus stuff to index and stuff

---
 .../aztec/docs/consensus-block-production/overview.md |  1 +
 .../docs/consensus-block-production/sequencing.md     |  1 +
 sites/aztec/sidebars.ts                               | 11 +++++++++++
 sites/aztec/src/pages/index.tsx                       |  2 --
 4 files changed, 13 insertions(+), 2 deletions(-)
 create mode 100644 sites/aztec/docs/consensus-block-production/sequencing.md

diff --git a/sites/aztec/docs/consensus-block-production/overview.md b/sites/aztec/docs/consensus-block-production/overview.md
index e69de29..07dd0c5 100644
--- a/sites/aztec/docs/consensus-block-production/overview.md
+++ b/sites/aztec/docs/consensus-block-production/overview.md
@@ -0,0 +1 @@
+# Overview
diff --git a/sites/aztec/docs/consensus-block-production/sequencing.md b/sites/aztec/docs/consensus-block-production/sequencing.md
new file mode 100644
index 0000000..d8ce7dd
--- /dev/null
+++ b/sites/aztec/docs/consensus-block-production/sequencing.md
@@ -0,0 +1 @@
+# Sequencing
diff --git a/sites/aztec/sidebars.ts b/sites/aztec/sidebars.ts
index e69a10a..cd137ae 100644
--- a/sites/aztec/sidebars.ts
+++ b/sites/aztec/sidebars.ts
@@ -32,6 +32,17 @@ const sidebars: SidebarsConfig = {
         'background/zk-circuits',
       ],
     },
+    {
+      type: 'category',
+      label: 'Consensus / Block Productino',
+      collapsible: false,
+      collapsed: false,
+      link: {
+        type: 'doc',
+        id: 'consensus-block-production/overview',
+      },
+      items: ['consensus-block-production/sequencing'],
+    }
   ],
 };
 
diff --git a/sites/aztec/src/pages/index.tsx b/sites/aztec/src/pages/index.tsx
index c00b9e5..79e17f5 100644
--- a/sites/aztec/src/pages/index.tsx
+++ b/sites/aztec/src/pages/index.tsx
@@ -35,8 +35,6 @@ const aztecCategories: Category[] = [
     title: "CONSENSUS",
     icon: "/img/icons/processes-icon.svg",
     href: "/docs/consensus-block-production/overview",
-    comingSoon: true,
-    comingSoonBanner: "/common/img/coming-soon-banner.png",
   },
 ];
 

From 3045ca1a84f7302d39afae62e82217d1cffaa733 Mon Sep 17 00:00:00 2001
From: Paperclip Minimizer <minim@defi.sucks>
Date: Tue, 2 Sep 2025 19:09:39 -0300
Subject: [PATCH 02/10] docs: block production overview

---
 .../consensus-block-production/overview.md    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/sites/aztec/docs/consensus-block-production/overview.md b/sites/aztec/docs/consensus-block-production/overview.md
index 07dd0c5..0941ec5 100644
--- a/sites/aztec/docs/consensus-block-production/overview.md
+++ b/sites/aztec/docs/consensus-block-production/overview.md
@@ -1 +1,25 @@
 # Overview
+
+Aztec is a Zero-Knowledge SNARK L2. This means there's an L1 *verifier contract* that keeps track
+of the current state of the blockchain and enforces proper L2 execution through ZK proofs before
+updating its known L2 state to a new one.
+
+Blocks are divided in epochs of 32 blocks each, and the L1 contract expects the proof of an entire
+epoch. Once an epoch's proof is submitted an accepted by the contract, it is considered finalized
+and no reorg can happen unless the L1 itself gets reorg'd.
+
+When a new epoch begins, a random committee is elected from the validator set to sequence the
+epoch's blocks. Each *slot* in the epoch gets assigned a random proposer from the committee to
+sequence its corresponding block, and the blocks are each produced and committed to in the L1 in
+order *without proving*.
+
+Once the epoch is fully sequenced, proving begins simultaneously to the new epoch's sequencing.
+Proving is decoupled from sequencing so that a sequencer needn't have the hardware required for
+proving. Instead, a coordination mechanism between provers and sequencers is defined, which allows
+provers to quote their price of proof and sequencers to bid for one of them.
+
+If the proof arrives to the L1 contract in time (before the next sequence finalizes), the epoch is
+finalized. Otherwise, both epochs are discarded and block production begins again from the last
+finalized epoch.
+
+There are two fallback mechanisms that enter into effect whenever the happy path is not traversed.

From 7940bb4fe7fdc9c6b8c9e44ef7283ce010f7e110 Mon Sep 17 00:00:00 2001
From: Paperclip Minimizer <minim@defi.sucks>
Date: Wed, 3 Sep 2025 11:23:29 -0300
Subject: [PATCH 03/10] docs: consensus overview

---
 .../consensus-block-production/overview.md    | 31 ++++++++++---------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/sites/aztec/docs/consensus-block-production/overview.md b/sites/aztec/docs/consensus-block-production/overview.md
index 0941ec5..e795c49 100644
--- a/sites/aztec/docs/consensus-block-production/overview.md
+++ b/sites/aztec/docs/consensus-block-production/overview.md
@@ -1,25 +1,28 @@
 # Overview
 
-Aztec is a Zero-Knowledge SNARK L2. This means there's an L1 *verifier contract* that keeps track
-of the current state of the blockchain and enforces proper L2 execution through ZK proofs before
-updating its known L2 state to a new one.
+Aztec is a Zero-Knowledge SNARK L2. This means there's an L1 *verifier contract* (a.k.a. *rollup
+contract*) that keeps track of the current state of the blockchain and verifies proper L2 execution
+through ZK proofs before updating its known L2 state to a new one.
 
-Blocks are divided in epochs of 32 blocks each, and the L1 contract expects the proof of an entire
-epoch. Once an epoch's proof is submitted an accepted by the contract, it is considered finalized
-and no reorg can happen unless the L1 itself gets reorg'd.
+Blocks are divided in epochs of 32 blocks each, and the rollup contract expects the proof of an
+entire epoch. Once an epoch's proof is submitted and accepted by the contract, it is considered
+finalized and no reorg can happen unless the L1 itself gets reorg'd.
 
 When a new epoch begins, a random committee is elected from the validator set to sequence the
 epoch's blocks. Each *slot* in the epoch gets assigned a random proposer from the committee to
-sequence its corresponding block, and the blocks are each produced and committed to in the L1 in
-order *without proving*.
+sequence its block, and the blocks are each produced and committed to in the L1 in order *without
+proving*.
 
-Once the epoch is fully sequenced, proving begins simultaneously to the new epoch's sequencing.
+Once the epoch is fully sequenced, proving begins in simultaneou to the new epoch's sequencing.
 Proving is decoupled from sequencing so that a sequencer needn't have the hardware required for
 proving. Instead, a coordination mechanism between provers and sequencers is defined, which allows
-provers to quote their price of proof and sequencers to bid for one of them.
+provers to quote their price for proving, and sequencers to bid for one of them.
 
-If the proof arrives to the L1 contract in time (before the next sequence finalizes), the epoch is
-finalized. Otherwise, both epochs are discarded and block production begins again from the last
-finalized epoch.
+If the proof arrives to the L1 contract in time (before the next epoch's sequencing is done), the
+epoch is finalized. Otherwise, both epochs are discarded and block production begins again from the
+last finalized epoch.
 
-There are two fallback mechanisms that enter into effect whenever the happy path is not traversed.
+There are two fallback mechanisms that enter into effect whenever the happy path is not traversed,
+in order to ensure liveliness and finality:
+- Based fallback
+- Forced inclussion queue

From 8a278d17e834d5eaf10289facd8b9cbbc6ac6ae6 Mon Sep 17 00:00:00 2001
From: Paperclip Minimizer <minim@defi.sucks>
Date: Wed, 3 Sep 2025 11:24:11 -0300
Subject: [PATCH 04/10] docs: allow mermaid

---
 sites/aztec/docusaurus.config.ts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/sites/aztec/docusaurus.config.ts b/sites/aztec/docusaurus.config.ts
index 2510c67..eeae52b 100644
--- a/sites/aztec/docusaurus.config.ts
+++ b/sites/aztec/docusaurus.config.ts
@@ -21,6 +21,11 @@ const localConfig: Config = {
   organizationName: "defi-wonderland",
   projectName: "aztec-handbook",
 
+  markdown: {
+      mermaid: true,
+  },
+  themes: ["@docusaurus/theme-mermaid"],
+
   presets: [
     [
       "classic",

From 272e5b7107c7f70059d5b6bd000ab9065bb416a9 Mon Sep 17 00:00:00 2001
From: Paperclip Minimizer <minim@defi.sucks>
Date: Thu, 4 Sep 2025 23:00:29 -0300
Subject: [PATCH 05/10] docs: consensus overview and almost sequencing

---
 .../fallback-mechanisms.md                    |  1 +
 .../consensus-block-production/overview.md    | 66 ++++++++++----
 .../consensus-block-production/proving.md     |  1 +
 .../consensus-block-production/sequencing.md  | 85 +++++++++++++++++++
 4 files changed, 138 insertions(+), 15 deletions(-)
 create mode 100644 sites/aztec/docs/consensus-block-production/fallback-mechanisms.md
 create mode 100644 sites/aztec/docs/consensus-block-production/proving.md

diff --git a/sites/aztec/docs/consensus-block-production/fallback-mechanisms.md b/sites/aztec/docs/consensus-block-production/fallback-mechanisms.md
new file mode 100644
index 0000000..73670e4
--- /dev/null
+++ b/sites/aztec/docs/consensus-block-production/fallback-mechanisms.md
@@ -0,0 +1 @@
+# Fallback mechanisms
diff --git a/sites/aztec/docs/consensus-block-production/overview.md b/sites/aztec/docs/consensus-block-production/overview.md
index e795c49..329ad6c 100644
--- a/sites/aztec/docs/consensus-block-production/overview.md
+++ b/sites/aztec/docs/consensus-block-production/overview.md
@@ -1,19 +1,43 @@
 # Overview
 
-Aztec is a Zero-Knowledge SNARK L2. This means there's an L1 *verifier contract* (a.k.a. *rollup
-contract*) that keeps track of the current state of the blockchain and verifies proper L2 execution
-through ZK proofs before updating its known L2 state to a new one.
+Aztec is a Zero-Knowledge SNARK L2. The blockchain state is committed to in an L1 contract known as
+the *rollup contract*. In order to advance the contract from the current state to the next state,
+the rollup contract expects a valid ZK proof of transition.
 
-Blocks are divided in epochs of 32 blocks each, and the rollup contract expects the proof of an
-entire epoch. Once an epoch's proof is submitted and accepted by the contract, it is considered
-finalized and no reorg can happen unless the L1 itself gets reorg'd.
+Blocks are grouped in epochs of 32 blocks each, and the rollup contract expects the proof of an
+entire epoch. Once an epoch's proof is submitted and accepted by the contract, the epoch is
+considered finalized and no Aztec reorg can happen unless the L1 itself reorgs.
 
-When a new epoch begins, a random committee is elected from the validator set to sequence the
-epoch's blocks. Each *slot* in the epoch gets assigned a random proposer from the committee to
-sequence its block, and the blocks are each produced and committed to in the L1 in order *without
-proving*.
+Aztec consensus and block production can be divided into four parts:
+1) Transaction propagation
+2) Sequencing
+3) Proving
+4) Fallback mechanisms
 
-Once the epoch is fully sequenced, proving begins in simultaneou to the new epoch's sequencing.
+### Transaction propagation
+
+Users' PXEs produce and gossip `Tx` objects. Amongst other information, these contain:
+- Transaction hash
+- Transaction effects (nullifiers, logs, etc)
+- The ZK proof for the private execution
+- The enqueued public calls
+
+These are gossiped to at least one node. Uppon receival of a `Tx` object, a node checks its validity
+and then forwards it to its known pairs. This defines a mempool of transactions that are pending
+execution.
+
+### Sequencing
+
+Roughly, when a new epoch begins
+
+1) A random committee is elected from the validator set
+2) Proposers are sampled from the committee for each of the epoch's slot
+3) Each proposer produces a block and, uppon collecting enough attestations, publishes to the rollup
+   contract *without proving*
+
+### Proving
+
+Once an epoch is fully sequenced, proving begins in simultaneous to the new epoch's sequencing.
 Proving is decoupled from sequencing so that a sequencer needn't have the hardware required for
 proving. Instead, a coordination mechanism between provers and sequencers is defined, which allows
 provers to quote their price for proving, and sequencers to bid for one of them.
@@ -22,7 +46,19 @@ If the proof arrives to the L1 contract in time (before the next epoch's sequenc
 epoch is finalized. Otherwise, both epochs are discarded and block production begins again from the
 last finalized epoch.
 
-There are two fallback mechanisms that enter into effect whenever the happy path is not traversed,
-in order to ensure liveliness and finality:
-- Based fallback
-- Forced inclussion queue
+### Fallback mechanisms
+
+There are two fallback mechanisms that enter into effect whenever the happy path is not traversed:
+- Based fallback: ensures liveliness
+- Forced inclussion queue: ensures finality
+
+## Up next
+
+The following pages explain the later three points in more detail.
+
+## References
+
+- [Aztec's Block Production System](https://forum.aztec.network/t/request-for-comments-aztecs-block-production-system/6155)
+
+### Source code
+- [Tx object](https://github.com/AztecProtocol/aztec-packages/blob/286fbfae25b173d372164eedd7b22926eac32b2a/yarn-project/stdlib/src/tx/tx.ts#L27)
diff --git a/sites/aztec/docs/consensus-block-production/proving.md b/sites/aztec/docs/consensus-block-production/proving.md
new file mode 100644
index 0000000..5cb41e5
--- /dev/null
+++ b/sites/aztec/docs/consensus-block-production/proving.md
@@ -0,0 +1 @@
+# Proving
diff --git a/sites/aztec/docs/consensus-block-production/sequencing.md b/sites/aztec/docs/consensus-block-production/sequencing.md
index d8ce7dd..73572df 100644
--- a/sites/aztec/docs/consensus-block-production/sequencing.md
+++ b/sites/aztec/docs/consensus-block-production/sequencing.md
@@ -1 +1,86 @@
 # Sequencing
+
+The sequencing of an epoch can be summarized in the following steps
+
+```mermaid
+sequenceDiagram
+    Validator set-->>Committee: Sample without replacement
+    Committee-->>Proposers: Sample with replacement
+    loop each proposer
+        Note over Proposers: Construct block
+        Proposers->>Committee: Send block proposal
+        loop each committee member
+            alt block proposal is valid
+                Committee->>Proposers: Send attestation
+            end
+        end
+        alt quorum of attestations
+            Proposers->>Rollup contract: Block commitment
+            Proposers->>Rollup contract: Post TxEffects to blob DA
+        end
+    end
+```
+
+Each proposer must catch up to the previous proposer before they start constructing their own
+blocks.
+
+## Epoch initialization
+
+At the start of an epoch, a committee is ellected pseudorandomly, along with the set of committee
+members that will act as proposers. Randomness is sampled from randao at a previous epoch and a
+random seed derived from it:
+
+```solidity
+seed = uint256(keccak256(abi.encode(epoch, randao[epoch-2])))
+```
+
+The sampling occurs as follows:
+- **Committee**: Draw `TARGET_COMMITTEE_SIZE` indices pseudorandomly *without replacement*. At the
+  time of writing this is done with a Fisher-Yates shuffle algorithm.
+- **Proposers**: Draw 32 indices from the committee *with replacement*.
+
+### Validator lookahead
+
+The validator set used to compute the committee at epoch $$N$$ is taken from a snapshot of the
+validator set at 1 second before the start of epoch $$N-1$$. Since the randao value used for seed
+generation is that of epoch $$N-2$$, this means the committee and proposers are known one full epoch
+in advance.
+
+## Block building and proposal atestation
+
+The proposer collects enough `Tx` objects from their view of the mempool and sequences a valid
+block. After this, they construct a `BlockProposal`, constituting of:
+- `blockNumber`: the block number
+- `payload`: what the signature is over, consisting of block header, archive root after block, and
+  state after block
+- `signature`: the proposal's signature by the proposer
+- `txHashes`: TX hashes
+- `txs`: (optional) the block's complete transaction data
+
+:::note
+The archive tree is a tree whose leaves are the previous blocks' headers
+:::
+
+The proposer then forwards the proposal to the committee in order to collect atestations. When a
+commitee member receives a block proposal, they can send a signature for the proposal back to the
+proposer.
+
+A lawful commitee member will check for correctness before signing: the changes in state must
+correspond to the `txHashes` in the proposals.
+
+## On-chain block commitment
+
+After reciving the quorum of attestations, the block producer will:
+- Post the TX effects to blob DA
+- Post the attestment signatures, block header, and state root to the L1 rollup contract
+
+The rollup contract in turn will perform checks
+TODO
+
+## References
+
+### Source code
+
+- [Committee computation](https://github.com/AztecProtocol/aztec-packages/blob/286fbfae25b173d372164eedd7b22926eac32b2a/l1-contracts/src/core/libraries/crypto/SampleLib.sol#L33)
+- [Proposer sampling](https://github.com/AztecProtocol/aztec-packages/blob/286fbfae25b173d372164eedd7b22926eac32b2a/l1-contracts/src/core/libraries/rollup/ValidatorSelectionLib.sol#L381)
+- [Block proposal](https://github.com/AztecProtocol/aztec-packages/blob/286fbfae25b173d372164eedd7b22926eac32b2a/yarn-project/stdlib/src/p2p/block_proposal.ts#L37)

From 67b22166ac4d6eb2d82864f8982057d5f1550aa7 Mon Sep 17 00:00:00 2001
From: Paperclip Minimizer <minim@defi.sucks>
Date: Tue, 16 Sep 2025 13:28:09 -0300
Subject: [PATCH 06/10] docs: minor fixes, add block propagation and
 attestation

---
 .../fallback-mechanisms.md                    |  2 +
 .../consensus-block-production/overview.md    | 23 ++---
 .../consensus-block-production/sequencing.md  | 94 +++++++++++++++----
 3 files changed, 88 insertions(+), 31 deletions(-)

diff --git a/sites/aztec/docs/consensus-block-production/fallback-mechanisms.md b/sites/aztec/docs/consensus-block-production/fallback-mechanisms.md
index 73670e4..099d872 100644
--- a/sites/aztec/docs/consensus-block-production/fallback-mechanisms.md
+++ b/sites/aztec/docs/consensus-block-production/fallback-mechanisms.md
@@ -1 +1,3 @@
 # Fallback mechanisms
+
+TODO: ensure whether they are implemented or not
diff --git a/sites/aztec/docs/consensus-block-production/overview.md b/sites/aztec/docs/consensus-block-production/overview.md
index 329ad6c..9298074 100644
--- a/sites/aztec/docs/consensus-block-production/overview.md
+++ b/sites/aztec/docs/consensus-block-production/overview.md
@@ -1,14 +1,14 @@
 # Overview
 
-Aztec is a Zero-Knowledge SNARK L2. The blockchain state is committed to in an L1 contract known as
-the *rollup contract*. In order to advance the contract from the current state to the next state,
+Aztec is a Zero-Knowledge SNARK L2. The blockchain's state is committed to in an L1 contract known
+as the *rollup contract*. In order to advance the contract from the current state to the next state,
 the rollup contract expects a valid ZK proof of transition.
 
-Blocks are grouped in epochs of 32 blocks each, and the rollup contract expects the proof of an
-entire epoch. Once an epoch's proof is submitted and accepted by the contract, the epoch is
-considered finalized and no Aztec reorg can happen unless the L1 itself reorgs.
+Aztec blocks are grouped in epochs of 32 blocks each, and the rollup contract expects the proof of
+an entire epoch. Once an epoch's proof is submitted and accepted by the contract, the epoch is
+finalized and no Aztec reorg can happen unless the L1 itself reorgs.
 
-Aztec consensus and block production can be divided into four parts:
+Aztec block production can be divided into four parts:
 1) Transaction propagation
 2) Sequencing
 3) Proving
@@ -24,7 +24,8 @@ Users' PXEs produce and gossip `Tx` objects. Amongst other information, these co
 
 These are gossiped to at least one node. Uppon receival of a `Tx` object, a node checks its validity
 and then forwards it to its known pairs. This defines a mempool of transactions that are pending
-execution.
+execution. The TX validity check ensures the ZK proof for private execution is valid and that fees
+will be paid correctly.
 
 ### Sequencing
 
@@ -32,12 +33,12 @@ Roughly, when a new epoch begins
 
 1) A random committee is elected from the validator set
 2) Proposers are sampled from the committee for each of the epoch's slot
-3) Each proposer produces a block and, uppon collecting enough attestations, publishes to the rollup
-   contract *without proving*
+3) Each proposer produces a block. They then broadcast it to the committee for attestations and,
+   uppon collecting enough attestations, publishes to the rollup contract *without proving*
 
 ### Proving
 
-Once an epoch is fully sequenced, proving begins in simultaneous to the new epoch's sequencing.
+Once an epoch is fully sequenced, proving begins in simultaneous to the next epoch's sequencing.
 Proving is decoupled from sequencing so that a sequencer needn't have the hardware required for
 proving. Instead, a coordination mechanism between provers and sequencers is defined, which allows
 provers to quote their price for proving, and sequencers to bid for one of them.
@@ -54,7 +55,7 @@ There are two fallback mechanisms that enter into effect whenever the happy path
 
 ## Up next
 
-The following pages explain the later three points in more detail.
+The following pages explain sequencing, proving, and fallback mechanisms in more detail.
 
 ## References
 
diff --git a/sites/aztec/docs/consensus-block-production/sequencing.md b/sites/aztec/docs/consensus-block-production/sequencing.md
index 73572df..adfeaf3 100644
--- a/sites/aztec/docs/consensus-block-production/sequencing.md
+++ b/sites/aztec/docs/consensus-block-production/sequencing.md
@@ -1,5 +1,9 @@
 # Sequencing
 
+Each epoch is sequenced *without proving* until it is complete. Such chain of unproven blocks is
+called the *pending chain*, which is dispatched for proving only after it's been completely
+sequenced.
+
 The sequencing of an epoch can be summarized in the following steps
 
 ```mermaid
@@ -26,7 +30,7 @@ blocks.
 
 ## Epoch initialization
 
-At the start of an epoch, a committee is ellected pseudorandomly, along with the set of committee
+At the start of an epoch, a committee is elected pseudorandomly, along with the set of committee
 members that will act as proposers. Randomness is sampled from randao at a previous epoch and a
 random seed derived from it:
 
@@ -36,7 +40,7 @@ seed = uint256(keccak256(abi.encode(epoch, randao[epoch-2])))
 
 The sampling occurs as follows:
 - **Committee**: Draw `TARGET_COMMITTEE_SIZE` indices pseudorandomly *without replacement*. At the
-  time of writing this is done with a Fisher-Yates shuffle algorithm.
+  time of writing, this is done with a Fisher-Yates shuffle algorithm.
 - **Proposers**: Draw 32 indices from the committee *with replacement*.
 
 ### Validator lookahead
@@ -46,14 +50,22 @@ validator set at 1 second before the start of epoch $$N-1$$. Since the randao va
 generation is that of epoch $$N-2$$, this means the committee and proposers are known one full epoch
 in advance.
 
-## Block building and proposal atestation
+## Block building
+
+Inside an epoch, slots are filled in sequence. Each slot's assigned proposer waits for all previous
+blocks to be committed to in the rollup contract. They'll then catch their state up with the latest
+committed state and begin their own block construction and proposal.
 
-The proposer collects enough `Tx` objects from their view of the mempool and sequences a valid
-block. After this, they construct a `BlockProposal`, constituting of:
+The proposer collects enough `Tx` objects from their view of the mempool to sequence a valid block.
+For any TX ordering, the proposer can simulate their execution *without proving* to know what state
+changes are introduced by the resulting block. After settling for one specific list of TXs, the
+proposer uses the simulation's results to construct a `BlockProposal`, consisting of:
 - `blockNumber`: the block number
-- `payload`: what the signature is over, consisting of block header, archive root after block, and
-  state after block
 - `signature`: the proposal's signature by the proposer
+- `payload`: what the signature is over
+  - block header, including the archive root after this block is added
+  - archive root after block
+  - state after block
 - `txHashes`: TX hashes
 - `txs`: (optional) the block's complete transaction data
 
@@ -61,26 +73,68 @@ block. After this, they construct a `BlockProposal`, constituting of:
 The archive tree is a tree whose leaves are the previous blocks' headers
 :::
 
-The proposer then forwards the proposal to the committee in order to collect atestations. When a
-commitee member receives a block proposal, they can send a signature for the proposal back to the
-proposer.
+The proposer then forwards the proposal to the committee in order to collect attestations.
+
+## Block propagation
+
+Just like with transactions, all nodes re-broadcast block proposals to their known peers after a
+basic *P2P validity check*.
+
+This check currently ensures:
+- A committee has been defined in the rollup contract for the slot the proposal belongs to
+- The proposal is for either the current or the next slot
+- The proposer is the correct one for the slot
+
+## Proposal attestation
+
+When a commitee member receives a block proposal, they should verify the proposal and send a
+`BlockAttestation` back to the proposer. This verification includes the P2P validity check, as well
+as checks that the proposal is consistent with the previous known state, and the proposed block
+executes correctly.
+
+In detail, the consistency checks are:
+- The block previous to the proposal is known
+- The proposal's *previous* archive root matches the previous block's archive root
+- The L1->L2 messages in the proposal match the ones in the rollup contract
 
-A lawful commitee member will check for correctness before signing: the changes in state must
-correspond to the `txHashes` in the proposals.
+:::note
+As commented in the code, some of the attestation checks may be promoted to P2P validity checks,
+tightening the gossip checks.
+:::
+
+If all check pass, the attester sends the proposer a `BlockAttestation`, consisting of the same
+`blockNumber` and `payload` as the proposal, as well as the attester's `signature`.
 
 ## On-chain block commitment
 
-After reciving the quorum of attestations, the block producer will:
-- Post the TX effects to blob DA
-- Post the attestment signatures, block header, and state root to the L1 rollup contract
+After reciving the quorum of attestations, the block producer will submit their block proposal to
+the L1 contract by calling `RollupCore::propose` with:
+- `ProposeArgs` object that includes the proposed block's header
+- The committee attestations
+- Data for blob DA
+
+At this point, the rollup contract will prune any epochs that failed to prove. It will then validate
+the proposal in order to add it to the pending chain.
+
+
+
+## Catching-up with the latest block
+
+## TODOs
 
-The rollup contract in turn will perform checks
-TODO
+- [ ] On-chain block commitment: what's in `_blobsInput`?
+- [ ] On-chain block commitment: What will the proposer publish?
+- [ ] On-chain block commitment: What checks does the contract perform?
+- [ ] Catching-up with the latest block
+- [ ] Check whether the contract checks `proposer = proposers[slot]`
 
 ## References
 
 ### Source code
 
-- [Committee computation](https://github.com/AztecProtocol/aztec-packages/blob/286fbfae25b173d372164eedd7b22926eac32b2a/l1-contracts/src/core/libraries/crypto/SampleLib.sol#L33)
-- [Proposer sampling](https://github.com/AztecProtocol/aztec-packages/blob/286fbfae25b173d372164eedd7b22926eac32b2a/l1-contracts/src/core/libraries/rollup/ValidatorSelectionLib.sol#L381)
-- [Block proposal](https://github.com/AztecProtocol/aztec-packages/blob/286fbfae25b173d372164eedd7b22926eac32b2a/yarn-project/stdlib/src/p2p/block_proposal.ts#L37)
+- [Committee computation](https://github.com/AztecProtocol/aztec-packages/blob/v2.0.0-nightly.20250820/l1-contracts/src/core/libraries/crypto/SampleLib.sol#L33)
+- [Proposer sampling](https://github.com/AztecProtocol/aztec-packages/blob/v2.0.0-nightly.20250820/l1-contracts/src/core/libraries/rollup/ValidatorSelectionLib.sol#L381)
+- [Block proposal](https://github.com/AztecProtocol/aztec-packages/blob/v2.0.0-nightly.20250820/yarn-project/stdlib/src/p2p/block_proposal.ts#L37)
+- [P2P validity check](https://github.com/AztecProtocol/aztec-packages/blob/v2.0.0-nightly.20250820/yarn-project/p2p/src/msg_validators/block_proposal_validator/block_proposal_validator.ts#L15)
+- [Attesting function](https://github.com/AztecProtocol/aztec-packages/blob/v2.0.0-nightly.20250820/yarn-project/validator-client/src/validator.ts#L251)
+- [Rollup core](https://github.com/AztecProtocol/aztec-packages/blob/v2.0.0-nightly.20250820/l1-contracts/src/core/RollupCore.sol)

From e2c5379d7e1ce87a3dd43aff17cd1a3f62268144 Mon Sep 17 00:00:00 2001
From: Paperclip Minimizer <minim@defi.sucks>
Date: Tue, 16 Sep 2025 13:31:17 -0300
Subject: [PATCH 07/10] docs: rename section to just 'block production'

---
 .../fallback-mechanisms.md                             |  0
 .../overview.md                                        |  0
 .../proving.md                                         |  0
 .../sequencing.md                                      |  0
 sites/aztec/docs/intro/welcome.md                      |  4 ++--
 sites/aztec/sidebars.ts                                | 10 +++++-----
 sites/aztec/src/pages/index.tsx                        |  4 ++--
 7 files changed, 9 insertions(+), 9 deletions(-)
 rename sites/aztec/docs/{consensus-block-production => block-production}/fallback-mechanisms.md (100%)
 rename sites/aztec/docs/{consensus-block-production => block-production}/overview.md (100%)
 rename sites/aztec/docs/{consensus-block-production => block-production}/proving.md (100%)
 rename sites/aztec/docs/{consensus-block-production => block-production}/sequencing.md (100%)

diff --git a/sites/aztec/docs/consensus-block-production/fallback-mechanisms.md b/sites/aztec/docs/block-production/fallback-mechanisms.md
similarity index 100%
rename from sites/aztec/docs/consensus-block-production/fallback-mechanisms.md
rename to sites/aztec/docs/block-production/fallback-mechanisms.md
diff --git a/sites/aztec/docs/consensus-block-production/overview.md b/sites/aztec/docs/block-production/overview.md
similarity index 100%
rename from sites/aztec/docs/consensus-block-production/overview.md
rename to sites/aztec/docs/block-production/overview.md
diff --git a/sites/aztec/docs/consensus-block-production/proving.md b/sites/aztec/docs/block-production/proving.md
similarity index 100%
rename from sites/aztec/docs/consensus-block-production/proving.md
rename to sites/aztec/docs/block-production/proving.md
diff --git a/sites/aztec/docs/consensus-block-production/sequencing.md b/sites/aztec/docs/block-production/sequencing.md
similarity index 100%
rename from sites/aztec/docs/consensus-block-production/sequencing.md
rename to sites/aztec/docs/block-production/sequencing.md
diff --git a/sites/aztec/docs/intro/welcome.md b/sites/aztec/docs/intro/welcome.md
index 7392360..88b818d 100644
--- a/sites/aztec/docs/intro/welcome.md
+++ b/sites/aztec/docs/intro/welcome.md
@@ -32,8 +32,8 @@ You'll explore:
 - **Background**: The core ideas that power Aztec: an introduction to UTXOs, nullifiers, and zero-knowledge proofs, explained in plain language (or at least we tried to)
 - **Stack** (WIP): How all the pieces fit together, from the virtual machine that runs your code to the prover that generates proofs
 - **Transactions & Messaging** (WIP): How private and public executions work, how they talk to each other, and how the whole system communicates with Ethereum
-- **Consensus** (WIP): How the network agrees on what happened without seeing what happened
+- **Block production** (WIP): How the network agrees on what happened without seeing what happened
 
 There are more sections coming soon, from standards to the governance system. Aztec is in the early stages, so this handbook will evolve with the network and with every developer who joins the mission. Feel free to contribute! We're building the infrastructure for a world where privacy is the default, not the exception.
 
-Ready to help build it? Let's go 🛠️
\ No newline at end of file
+Ready to help build it? Let's go 🛠️
diff --git a/sites/aztec/sidebars.ts b/sites/aztec/sidebars.ts
index 6b43105..8665f83 100644
--- a/sites/aztec/sidebars.ts
+++ b/sites/aztec/sidebars.ts
@@ -60,17 +60,17 @@ const sidebars: SidebarsConfig = {
     },
     {
       type: 'category',
-      label: 'Consensus / Block Productino',
+      label: 'Block Production',
       collapsible: false,
       collapsed: false,
       link: {
         type: 'doc',
-        id: 'consensus-block-production/overview',
+        id: 'block-production/overview',
       },
       items: [
-        'consensus-block-production/sequencing',
-        'consensus-block-production/proving',
-        'consensus-block-production/fallback-mechanisms',
+        'block-production/sequencing',
+        'block-production/proving',
+        'block-production/fallback-mechanisms',
       ],
     },
   ],
diff --git a/sites/aztec/src/pages/index.tsx b/sites/aztec/src/pages/index.tsx
index f75f8b1..9790e74 100644
--- a/sites/aztec/src/pages/index.tsx
+++ b/sites/aztec/src/pages/index.tsx
@@ -30,9 +30,9 @@ const aztecCategories: Category[] = [
     comingSoonBanner: "/common/img/coming-soon-banner.png",
   },
   {
-    title: "CONSENSUS",
+    title: "BLOCK PRODUCTION",
     icon: "/img/icons/processes-icon.svg",
-    href: "/docs/consensus-block-production/overview",
+    href: "/docs/block-production/overview",
   },
 ];
 

From 05f6f166b21ab9ce06d42bbc8fcfd7ba111a0a9c Mon Sep 17 00:00:00 2001
From: Paperclip Minimizer <minim@defi.sucks>
Date: Thu, 18 Sep 2025 15:22:42 -0300
Subject: [PATCH 08/10] docs: sequencing: proposa, updating pending chain,
 handling messages

---
 .../aztec/docs/block-production/sequencing.md | 58 +++++++++++++++----
 1 file changed, 47 insertions(+), 11 deletions(-)

diff --git a/sites/aztec/docs/block-production/sequencing.md b/sites/aztec/docs/block-production/sequencing.md
index adfeaf3..920d756 100644
--- a/sites/aztec/docs/block-production/sequencing.md
+++ b/sites/aztec/docs/block-production/sequencing.md
@@ -113,20 +113,56 @@ the L1 contract by calling `RollupCore::propose` with:
 - The committee attestations
 - Data for blob DA
 
-At this point, the rollup contract will prune any epochs that failed to prove. It will then validate
-the proposal in order to add it to the pending chain.
-
-
+At this point, the rollup contract will prune any epochs that failed to prove. It will then
+- Validate the proposal, abort if it fails
+- Add it to the pending chain
+- Handle L1-L2 messages
+
+### Validating the proposal
+
+The following elements are validated:
+- Blob data: checks that the data in the blobs is the same as the data provided for the proofs.
+- Header data: does some sanity checks (e.g. the last archive root in the header must be the last
+  root's archive root, timestamp must be the one corresponding to the slot) as well as checking for
+  data availability.
+- Proposer: checks that the proposer corresponding to the block has properly signed the block.
+
+Attestations aren't validated eagerly during the `propose` call but rather assumed correct
+optimistically. Sequencers validate attestations off-chain during catch-up and, if a mistake is
+found, will invoke the L1 contract's `invalidateBadAttestation` or
+`invalidateInsufficientAttestations` function, in accordance to whether an invalid signature or an
+invalid amount of attestation has been found in an L1 proposed block.
+
+### Updating the pending chain
+
+The L1 contract's storage keeps track of both historical data and temporary data.
+
+The following historical data is updated:
+- Number of pending blocks
+- The archive tree root for this slot
+
+The following data for this block is stored temporarily in a circular storage buffer:
+- Header hash
+- Blob commitments hash
+- Payload digest
+- Slot number
+- Fee header:
+  - Excess mana
+  - Mana used
+  - Fee asset price
+  - Congestion cost
+  - Prover cost
+
+### Handling L1-L2 messages
+
+This consists of consuming the pending L1->L2 messages up to this block's start and inserting the
+L2->L1 messages into the outbox. The later can only be consumed after the epoch is confirmed.
 
 ## Catching-up with the latest block
 
-## TODOs
-
-- [ ] On-chain block commitment: what's in `_blobsInput`?
-- [ ] On-chain block commitment: What will the proposer publish?
-- [ ] On-chain block commitment: What checks does the contract perform?
-- [ ] Catching-up with the latest block
-- [ ] Check whether the contract checks `proposer = proposers[slot]`
+Once a block is persisted in the L1 contract, all sequencers must catch up to it by re-executing the
+transactions in order to have the latest view of the blockchain. At this stage, sequencers will
+ensure the block has the correct amount of attestations.
 
 ## References
 

From bdd4a06d47468abe884c063544fbcc95f8ac99cb Mon Sep 17 00:00:00 2001
From: Paperclip Minimizer <minim@defi.sucks>
Date: Wed, 1 Oct 2025 14:16:39 -0300
Subject: [PATCH 09/10] docs: fix typos in block production

---
 sites/aztec/docs/block-production/overview.md   | 16 ++++++++--------
 sites/aztec/docs/block-production/sequencing.md |  4 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/sites/aztec/docs/block-production/overview.md b/sites/aztec/docs/block-production/overview.md
index 9298074..6869021 100644
--- a/sites/aztec/docs/block-production/overview.md
+++ b/sites/aztec/docs/block-production/overview.md
@@ -22,36 +22,36 @@ Users' PXEs produce and gossip `Tx` objects. Amongst other information, these co
 - The ZK proof for the private execution
 - The enqueued public calls
 
-These are gossiped to at least one node. Uppon receival of a `Tx` object, a node checks its validity
-and then forwards it to its known pairs. This defines a mempool of transactions that are pending
+These are gossiped to at least one node. Upon receival of a `Tx` object, a node checks its validity
+and then forwards it to its known peers. This defines a mempool of transactions that are pending
 execution. The TX validity check ensures the ZK proof for private execution is valid and that fees
 will be paid correctly.
 
 ### Sequencing
 
-Roughly, when a new epoch begins
+Roughly, when a new epoch begins:
 
 1) A random committee is elected from the validator set
 2) Proposers are sampled from the committee for each of the epoch's slot
 3) Each proposer produces a block. They then broadcast it to the committee for attestations and,
-   uppon collecting enough attestations, publishes to the rollup contract *without proving*
+   upon collecting enough attestations, publishes to the rollup contract *without proving*
 
 ### Proving
 
-Once an epoch is fully sequenced, proving begins in simultaneous to the next epoch's sequencing.
+Once an epoch is fully sequenced, proving happens simultaneously to the next epoch's sequencing.
 Proving is decoupled from sequencing so that a sequencer needn't have the hardware required for
 proving. Instead, a coordination mechanism between provers and sequencers is defined, which allows
 provers to quote their price for proving, and sequencers to bid for one of them.
 
-If the proof arrives to the L1 contract in time (before the next epoch's sequencing is done), the
+If the proof arrives at the L1 contract in time (before the next epoch's sequencing is done), the
 epoch is finalized. Otherwise, both epochs are discarded and block production begins again from the
 last finalized epoch.
 
 ### Fallback mechanisms
 
 There are two fallback mechanisms that enter into effect whenever the happy path is not traversed:
-- Based fallback: ensures liveliness
-- Forced inclussion queue: ensures finality
+- Based fallback: ensures liveness
+- Forced inclusion queue: ensures finality
 
 ## Up next
 
diff --git a/sites/aztec/docs/block-production/sequencing.md b/sites/aztec/docs/block-production/sequencing.md
index 920d756..ad21165 100644
--- a/sites/aztec/docs/block-production/sequencing.md
+++ b/sites/aztec/docs/block-production/sequencing.md
@@ -107,7 +107,7 @@ If all check pass, the attester sends the proposer a `BlockAttestation`, consist
 
 ## On-chain block commitment
 
-After reciving the quorum of attestations, the block producer will submit their block proposal to
+After receiving the quorum of attestations, the block producer will submit their block proposal to
 the L1 contract by calling `RollupCore::propose` with:
 - `ProposeArgs` object that includes the proposed block's header
 - The committee attestations
@@ -156,7 +156,7 @@ The following data for this block is stored temporarily in a circular storage bu
 ### Handling L1-L2 messages
 
 This consists of consuming the pending L1->L2 messages up to this block's start and inserting the
-L2->L1 messages into the outbox. The later can only be consumed after the epoch is confirmed.
+L2->L1 messages into the outbox. The latter can only be consumed after the epoch is confirmed.
 
 ## Catching-up with the latest block
 

From 024ae92807375c7a09b070827d7bcbb70d863c17 Mon Sep 17 00:00:00 2001
From: Paperclip Minimizer <minim@defi.sucks>
Date: Wed, 1 Oct 2025 14:20:56 -0300
Subject: [PATCH 10/10] docs: copy line spacing from other commit

---
 .../src/components/CategoryCards/styles.module.css              | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/packages/common-config/src/components/CategoryCards/styles.module.css b/packages/common-config/src/components/CategoryCards/styles.module.css
index 1c98093..aa7fa97 100644
--- a/packages/common-config/src/components/CategoryCards/styles.module.css
+++ b/packages/common-config/src/components/CategoryCards/styles.module.css
@@ -85,7 +85,7 @@
     sans-serif;
   font-weight: 500;
   font-size: 1rem;
-  line-height: 0.7;
+  line-height: 1.2;
   padding-top: 0.15em;
   color: var(--wonderland-gray-100);
   margin: 0;