## Summary An off-by-one error in the `SequencerLedgerOps::get_pending_commitments` function causes the last pending commitment in a consecutive sequence to be omitted from retrieval, potentially leading to a complete halt of the L2 commitment pipeline. ## Finding Description The [get_pending_commitments](https://cantina.xyz/code/49b9e08d-4f8f-4103-b6e5-f5f43cf9faa1/crates/sovereign-sdk/full-node/db/sov-db/src/ledger_db/mod.rs?lines=706,706) function in `SequencerLedgerOps` contains a critical off-by-one error when retrieving pending sequencer commitments: ```rust fn get_pending_commitments(&self) -> anyhow::Result> { let commitment_indexes = self.db.get::(&())?; match commitment_indexes { Some(mut commitment_indexes) => { if commitment_indexes.is_empty() { return Ok(vec![]); } commitment_indexes.sort_unstable(); let start = commitment_indexes[0]; let end = commitment_indexes[commitment_indexes.len() - 1]; // @audit BUG: Exclusive range self.get_data_range::(&(start..end)) } None => Ok(vec![]), } } ``` The implementation of [get_data_range](https://cantina.xyz/code/49b9e08d-4f8f-4103-b6e5-f5f43cf9faa1/crates/sovereign-sdk/full-node/db/sov-db/src/ledger_db/mod.rs?lines=120,120) is as follows: ```rust fn get_data_range(&self, range: &std::ops::Range) -> Result, anyhow::Error> where T: Schema, K: Into + Copy + SeekKeyEncoder, { let mut raw_iter = self.db.iter()?; // @audit max_items will be one-too-small because of the incorrect range provided let max_items = (range.end.into() - range.start.into()) as usize; raw_iter.seek(&range.start)?; let iter = raw_iter.take(max_items); let mut out = Vec::with_capacity(max_items); for res in iter { let batch = res?.value; out.push(batch) } Ok(out) } ``` The bug occurs because Rust ranges `(start..end)` (provided by `get_pending_commitments` to `get_data_range`) are exclusive of the end value. When consecutive pending commitments exist (e.g., [5, 6, 7]), the function retrieves commitments 5 and 6 (because `max_items` is calculated to be 2, when it should have been 3), missing commitment 7. Exact same bug gets triggered also in a more likely case where there is a single pending commitment. Let's assume sequencer creates new pending commitment with index 7 and immediately crashes before submitting the Bitcoin TX. When `get_pending_commitments` is called by sequencer after it is restarted, it will return empty list when it should return list with a single element `[7]`. This breaks the commitment chain's integrity in two critical ways: 1. During sequencer restart: the [resubmit_pending_commitment](https://cantina.xyz/code/49b9e08d-4f8f-4103-b6e5-f5f43cf9faa1/crates/sequencer/src/commitment/service.rs?lines=272,272) function uses this buggy method, causing the last pending commitment to remain unprocessed and not submitted to Bitcoin DA. 2. During commitment controller initialization: the [load_next_commitment_index_and_start_height](https://cantina.xyz/code/49b9e08d-4f8f-4103-b6e5-f5f43cf9faa1/crates/sequencer/src/commitment/helpers.rs?lines=17,17) function also uses this method, potentially causing the sequencer to create duplicate commitment indices with different content. When a commitment is indefinitely lost (ie. pending sequencer commitment 7 does not get submitted by sequencer due to the bug): - Full node cannot finalize future commitments (each requires its predecessor to be finalized) - The commitment chain halts at the missing commitment - L2 blocks after this point remain uncommitted - No new proofs can be generated (they require committed commitments) ## Impact Explanation High - can cause a complete halt of the L2 commitment and proof pipeline. Security guarantees of the rollup are compromised as L2 state transitions are no longer verifiable on L1 ## Likelihood Explanation Medium - the bug triggers when one or more consecutive commitments accumulate as pending, which occurs when sequencer crashes or restarts, or when DA service issues cause delays in Bitcoin transaction submission ## Proof of Concept Here's a simple POC - in `CommitmentService`'s [commit](https://cantina.xyz/code/49b9e08d-4f8f-4103-b6e5-f5f43cf9faa1/crates/sequencer/src/commitment/service.rs?lines=190,190) we add debug logs immediately after sequencer creates new `PendingSequencerCommitment` using `put_pending_commitment`: ```diff ledger_db.put_pending_commitment(&commitment).map_err(|_| { anyhow!("Sequencer: Failed to store sequencer commitment in pending commitments") })?; + debug!("debug-pending: Pending commitment stored: {:?}", commitment.index); + debug!("debug-pending: get_pending_commitments: {:?}", ledger_db.get_pending_commitments()); ``` Now re-build the project, run the bitcoin chain: ```bash ❯ bitcoind -regtest -txindex=1 -addresstype=bech32m -fallbackfee=0.0001 -rpcport=18443 -rpcuser=citrea -rpcpassword=citrea ❯ bitcoin-cli -regtest -rpcuser=citrea -rpcpassword=citrea loadwallet citreatesting ❯ bitcoin-cli -regtest -rpcuser=citrea -rpcpassword=citrea -generate 201 ``` Start sequencer: ```bash CITREA_VERBOSITY=1 ./target/debug/citrea --dev --da-layer bitcoin --rollup-config-path resources/configs/bitcoin-regtest/sequencer_rollup_config.toml --sequencer resources/configs/bitcoin-regtest/sequencer_config.toml --genesis-paths resources/genesis/bitcoin-regtest ``` Now, the expectation is that debug statements will show the pending commitment which was just created. However, due to the bug `get_pending_commitments` returns empty list instead of the list with a single element: ```bash ❯ cat logs/sequencer.log| grep "debug-pending" 2025-08-09T13:47:09.707901Z DEBUG CommitmentService: citrea_sequencer::commitment::service: debug-pending: Pending commitment stored: 1 2025-08-09T13:47:09.707992Z DEBUG CommitmentService: citrea_sequencer::commitment::service: debug-pending: get_pending_commitments: Ok([]) 2025-08-09T13:48:49.707621Z DEBUG CommitmentService: citrea_sequencer::commitment::service: debug-pending: Pending commitment stored: 2 2025-08-09T13:48:49.707696Z DEBUG CommitmentService: citrea_sequencer::commitment::service: debug-pending: get_pending_commitments: Ok([]) 2025-08-09T13:50:29.708950Z DEBUG CommitmentService: citrea_sequencer::commitment::service: debug-pending: Pending commitment stored: 3 2025-08-09T13:50:29.709185Z DEBUG CommitmentService: citrea_sequencer::commitment::service: debug-pending: get_pending_commitments: Ok([]) ``` ## Recommendation Fix the off-by-one error: ```diff fn get_pending_commitments(&self) -> anyhow::Result> { let commitment_indexes = self.db.get::(&())?; match commitment_indexes { Some(mut commitment_indexes) => { if commitment_indexes.is_empty() { return Ok(vec![]); } commitment_indexes.sort_unstable(); let start = commitment_indexes[0]; - let end = commitment_indexes[commitment_indexes.len() - 1]; + let end = commitment_indexes[commitment_indexes.len() - 1] + 1; self.get_data_range::(&(start..end)) } None => Ok(vec![]), } } ```

Goran

Public reviews