Address review feedback: align OpenVM/ZisK with PR #6157 (todo! → unimplemented!),

make send_batches_proof_to_contract private, add natspec to based contract's
verifyBatches noting it has no access control, update all L2 docs replacing
verifyBatch references with verifyBatches, move distributed_proving.md from
docs/prover/ to docs/l2/fundamentals/ since it describes the interaction between
proof coordinator, proof sender, and provers rather than prover internals, and
restructure the doc to be explanation-first with the testing guide at the end.

Author: avilagaston9

crates/l2/contracts/src/l1/based/OnChainProposer.sol

@@ -431,6 +431,8 @@ contract OnChainProposer is
     }
 
     /// @inheritdoc IOnChainProposer
+    /// @notice Callable by anyone (no access control) so that any party can
+    ///         advance verification once proofs are available.
     function verifyBatches(
         uint256 firstBatchNumber,
         bytes[] memory risc0BlockProofs,

crates/l2/prover/src/backend/openvm.rs

@@ -65,7 +65,7 @@ impl ProverBackend for OpenVmBackend {
     type SerializedInput = StdIn;
 
     fn prover_type(&self) -> ProverType {
-        todo!("No ProverType variant exists for OpenVM yet")
+        unimplemented!("OpenVM is not yet enabled as a backend for the L2")
     }
 
     fn serialize_input(&self, input: &ProgramInput) -> Result<Self::SerializedInput, BackendError> {

crates/l2/prover/src/backend/zisk.rs

@@ -114,7 +114,7 @@ impl ProverBackend for ZiskBackend {
     type SerializedInput = ();
 
     fn prover_type(&self) -> ProverType {
-        todo!("No ProverType variant exists for ZisK yet")
+        unimplemented!("ZisK is not yet enabled as a backend for the L2")
     }
 
     fn serialize_input(&self, input: &ProgramInput) -> Result<Self::SerializedInput, BackendError> {

crates/l2/sequencer/l1_proof_sender.rs

@@ -580,7 +580,7 @@ impl L1ProofSender {
     /// Sends one or more consecutive batch proofs in a single verifyBatches transaction.
     /// On revert with an invalid proof message, falls back to sending each batch
     /// individually to identify which batch has the bad proof.
-    pub async fn send_batches_proof_to_contract(
+    async fn send_batches_proof_to_contract(
         &self,
         first_batch: u64,
         batches: &[(u64, HashMap<ProverType, BatchProof>)],

docs/l2/deployment/aligned.md

@@ -355,7 +355,7 @@ INFO ethrex_l2::sequencer::l1_proof_verifier: Batches verified in OnChainPropose
 
 ### OnChainProposer
 
-- Uses `verifyBatchesAligned()` instead of `verifyBatch()` (used in standard mode).
+- Uses `verifyBatchesAligned()` instead of `verifyBatches()` (used in standard mode).
 - Receives an array of proofs to verify.
 - Delegates proof verification to the `AlignedProofAggregatorService` contract.
 

docs/l2/deployment/aligned_failure_recovery.md

@@ -250,7 +250,7 @@ ethrex l2 \
 
 1. Restart the prover(s) - they will automatically generate Groth16 proofs (since `--aligned` is not set)
 2. ProofCoordinator will request proofs starting from `lastVerifiedBatch + 1`
-3. L1ProofSender will submit directly to OnChainProposer.verifyBatch()
+3. L1ProofSender will submit directly to OnChainProposer.verifyBatches()
 
 
 ---
@@ -355,7 +355,7 @@ The response includes:
 
 | Code | Meaning | Action |
 |------|---------|--------|
-| `00h` | Use verifyBatch instead | Contract not in Aligned mode |
+| `00h` | Use verifyBatches instead | Contract not in Aligned mode |
 | `00m` | Invalid Aligned proof | Proof will be deleted and regenerated |
 | `00y` | AlignedProofAggregator call failed | Check aggregator contract address |
 | `00z` | Aligned proof verification failed | Merkle proof invalid |

docs/l2/fundamentals/README.md

@@ -30,3 +30,4 @@ For general documentation, see:
 - [Fee token](./fee_token.md)
 - [Exit window](./exit_window.md) and [Timelock](./timelock.md) for upgrade safety mechanisms.
 - [Aligned Layer Integration](./ethrex_l2_aligned_integration.md) details how ethrex L2 integrates with Aligned Layer for proof aggregation and verification.
+- [Distributed proving](./distributed_proving.md) explains how the proof coordinator, proof sender, and provers interact to enable parallel proving and multi-batch L1 verification.

docs/l2/fundamentals/based.md

@@ -78,9 +78,9 @@ The `OnChainProposer` contract, which handles batch proposals and management on
 - **Event Modification:**
   The `BatchCommitted` event has been updated to include the batch number of the committed batch. This addition enhances traceability and allows external systems to monitor batch progression more effectively.
 - **Batch Verification:**
-  The `verifyBatch` method has been made more flexible and decentralized:
-  - The `onlySequencer` modifier has been removed, allowing anyone—not just the lead Sequencer—to verify batches.
-  - The restriction preventing multiple verifications of the same batch has been lifted. While multiple verifications are now permitted, only one valid verification is required to advance the L2 state. This change improves resilience and reduces dependency on a single actor.
+  The `verifyBatches` method has been made more flexible and decentralized:
+  - The method has no access control modifier, allowing anyone—not just the lead Sequencer—to verify batches.
+  - It supports verifying one or more consecutive batches in a single transaction. Only one valid verification is required to advance the L2 state. This change improves resilience and reduces dependency on a single actor.
 
 ### SequencerRegistry (New Contract)
 

docs/l2/fundamentals/contracts.md

@@ -61,7 +61,7 @@ The `OnChainProposer` is an upgradeable smart contract that ensures the advancem
     - **`revertBatch()`**: Removes unverified batches (only callable when paused)
 
 2. **Proof Verification**
-    - **`verifyBatch()`**: Verifies a single batch using RISC0, SP1, or TDX proofs
+    - **`verifyBatches()`**: Verifies one or more consecutive batches using RISC0, SP1, or TDX proofs
     - **`verifyBatchesAligned()`**: Verifies multiple batches in sequence using aligned proofs with Merkle verification
 
 ## L2 Contracts

docs/prover/distributed_proving.md …s/l2/fundamentals/distributed_proving.mddocs/prover/distributed_proving.md renamed to docs/l2/fundamentals/distributed_proving.md docs/prover/distributed_proving.md renamed to docs/l2/fundamentals/distributed_proving.md

@@ -1,6 +1,11 @@
 # Distributed Proving
 
-Distributed proving allows running multiple prover instances in parallel, each working on different batches simultaneously. The proof coordinator assigns work to provers and collects their proofs, then the proof sender batches multiple consecutive proofs into a single L1 verification transaction.
+## Overview
+
+Distributed proving enables running multiple prover instances in parallel, each working on different batches simultaneously. It has two key aspects:
+
+1. **Parallel batch assignment**: the proof coordinator assigns different batches to different provers, so multiple provers work simultaneously.
+2. **Multi-batch verification**: the proof sender collects consecutive proven batches and submits them in a single `verifyBatches()` L1 transaction, saving gas.
 
 ## Architecture
 
@@ -28,9 +33,60 @@ Distributed proving allows running multiple prover instances in parallel, each w
               └────────────┘
 ```
 
-Multiple provers connect to the same proof coordinator. The coordinator tracks assignments per `(batch_number, prover_type)`, so:
+Multiple provers connect to the same proof coordinator over TCP. The coordinator tracks assignments per `(batch_number, prover_type)`, so:
+
 - Two `sp1` provers get assigned **different** batches.
-- An `sp1` prover and an `risc0` prover can work on the **same** batch simultaneously (they produce different proof types).
+- An `sp1` prover and a `risc0` prover can work on the **same** batch simultaneously (they produce different proof types).
+
+## Batch assignment
+
+When a prover sends a `BatchRequest`, it includes its `prover_type`. The coordinator:
+
+1. Scans batches starting from the oldest unverified one.
+2. Skips batches that already have a proof for this `prover_type`.
+3. Skips batches currently assigned to another prover of the same type (unless the assignment has timed out).
+4. Assigns the first available batch and records `(batch_number, prover_type) → Instant::now()`.
+
+The assignment map is in-memory only — it is lost on restart. On restart, the coordinator simply reassigns batches from scratch, which is safe because storing a duplicate proof is a no-op.
+
+## Prover timeout
+
+If a prover doesn't submit a proof within `prover-timeout` (default 10 minutes), its assignment expires and the batch becomes available for reassignment to another prover. This handles prover crashes, network issues, or slow provers without manual intervention.
+
+## Multi-batch verification
+
+The proof sender runs on a periodic tick (every `send-interval` ms). On each tick it:
+
+1. Queries the on-chain `lastVerifiedBatch` and `lastCommittedBatch`.
+2. Collects all **consecutive** proven batches starting from `lastVerifiedBatch + 1`, checking that every required proof type is present for each batch.
+3. Sends them in a single `verifyBatches()` call to L1.
+
+For example, if batches 5, 6, 7 are fully proven but batch 8 is missing a proof, only batches 5–7 are sent. Batch 8 waits for its proof.
+
+### Fallback to single-batch sending
+
+On **any** multi-batch error (gas limit exceeded, calldata too large, invalid proof, etc.), the proof sender falls back to sending each batch individually. Since on-chain verification is sequential (`batchNumber == lastVerifiedBatch + 1`), the fallback stops at the first failing batch — remaining batches are retried on the next tick.
+
+During single-batch fallback, if the error indicates an invalid proof (e.g. "Invalid SP1 proof"), that proof is deleted from the store so a prover can re-prove it.
+
+## Configuration reference
+
+### Proof coordinator (sequencer side)
+
+| Flag | Env Variable | Default | Description |
+|------|-------------|---------|-------------|
+| `--proof-coordinator.addr` | `ETHREX_PROOF_COORDINATOR_LISTEN_ADDRESS` | `127.0.0.1` | Listen address |
+| `--proof-coordinator.port` | `ETHREX_PROOF_COORDINATOR_LISTEN_PORT` | `3900` | Listen port |
+| `--proof-coordinator.send-interval` | `ETHREX_PROOF_COORDINATOR_SEND_INTERVAL` | `5000` | How often (ms) the proof sender collects and sends proofs to L1 |
+| `--proof-coordinator.prover-timeout` | `ETHREX_PROOF_COORDINATOR_PROVER_TIMEOUT` | `600000` | Timeout (ms) before reassigning a batch to another prover (default: 10 min) |
+
+### Prover client
+
+| Flag | Env Variable | Default | Description |
+|------|-------------|---------|-------------|
+| `--proof-coordinators` | `PROVER_CLIENT_PROOF_COORDINATOR_URL` | `tcp://127.0.0.1:3900` | Space-separated coordinator URLs |
+| `--backend` | `PROVER_CLIENT_BACKEND` | `exec` | Backend: `exec`, `sp1`, `risc0`, `zisk`, `openvm` |
+| `--proving-time` | `PROVER_CLIENT_PROVING_TIME` | `5000` | Wait time (ms) between requesting new work |
 
 ## Testing locally
 
@@ -74,47 +130,3 @@ make init-prover-exec
 ```
 
 Each prover will be assigned a different batch. When both finish, the proof sender will collect the consecutive proven batches and submit them in a single `verifyBatches` transaction on L1.
-
-## Configuration reference
-
-### Proof coordinator (L2 side)
-
-| Flag | Env Variable | Default | Description |
-|------|-------------|---------|-------------|
-| `--proof-coordinator.addr` | `ETHREX_PROOF_COORDINATOR_LISTEN_ADDRESS` | `127.0.0.1` | Listen address |
-| `--proof-coordinator.port` | `ETHREX_PROOF_COORDINATOR_LISTEN_PORT` | `3900` | Listen port |
-| `--proof-coordinator.send-interval` | `ETHREX_PROOF_COORDINATOR_SEND_INTERVAL` | `5000` | How often (ms) the proof sender batches and sends proofs to L1 |
-| `--proof-coordinator.prover-timeout` | `ETHREX_PROOF_COORDINATOR_PROVER_TIMEOUT` | `600000` | Timeout (ms) before reassigning a batch to another prover (default: 10 min) |
-
-### Prover client
-
-| Flag | Env Variable | Default | Description |
-|------|-------------|---------|-------------|
-| `--proof-coordinators` | `PROVER_CLIENT_PROOF_COORDINATOR_URL` | `tcp://127.0.0.1:3900` | Space-separated coordinator URLs |
-| `--backend` | `PROVER_CLIENT_BACKEND` | `exec` | Backend: `exec`, `sp1`, `risc0`, `zisk`, `openvm` |
-| `--proving-time` | `PROVER_CLIENT_PROVING_TIME` | `5000` | Wait time (ms) between requesting new work |
-
-## How it works
-
-### Batch assignment
-
-When a prover sends a `BatchRequest`, it includes its `prover_type`. The coordinator:
-
-1. Scans batches starting from the oldest unverified one.
-2. Skips batches that already have a proof for this `prover_type`.
-3. Skips batches currently assigned to another prover of the same type (unless the assignment timed out).
-4. Assigns the first available batch and records `(batch_number, prover_type) → Instant::now()`.
-
-### Prover timeout
-
-If a prover doesn't submit a proof within `prover-timeout` (default 10 minutes), its assignment expires and the batch becomes available for reassignment to another prover.
-
-### Multi-batch verification
-
-The proof sender periodically (every `send-interval` ms):
-
-1. Collects all **consecutive** proven batches starting from `last_verified_batch + 1`.
-2. Sends them in a single `verifyBatches()` call to L1.
-3. Falls back to per-batch verification if any batch has an invalid proof, to isolate the failure.
-
-For example, if batches 1, 2, 3 are proven but 4 is not, only batches 1-3 are sent. Batch 4 waits for its proof.