Summary
MessagingConfig.confirmation_depth defaults to 0, i.e. the collector gathers right up to the settlement chain's latest block with no reorg buffer. If a settlement block that was already gathered reorgs away (or shifts position), the message sequence desyncs.
Where
crates/messaging/src/lib.rs (MessagingConfig, confirmation_depth default 0, documented as dev/test only).crates/messaging/src/stream/mod.rs — safe_head = latest_block - confirmation_depth.
Impact
For non-dev Starknet settlement this leaves no protection against settlement-chain reorgs, which can drop or reorder L1-handler messages. For reference, the official Apollo sequencer uses a scrape cooldown (new_l1_handler_tx_cooldown_secs) for the same purpose.
Fix idea
Default confirmation_depth to a safer value for non-dev Starknet settlement (and/or document the recommended value clearly), keeping 0 only for dev.
Follow-up split from the L1-handler nonce-gate fix (case B3c in the investigation).
Summary
MessagingConfig.confirmation_depthdefaults to0, i.e. the collector gathers right up to the settlement chain's latest block with no reorg buffer. If a settlement block that was already gathered reorgs away (or shifts position), the message sequence desyncs.Where
crates/messaging/src/lib.rs(MessagingConfig,confirmation_depthdefault0, documented as dev/test only).crates/messaging/src/stream/mod.rs—safe_head = latest_block - confirmation_depth.Impact
For non-dev Starknet settlement this leaves no protection against settlement-chain reorgs, which can drop or reorder L1-handler messages. For reference, the official Apollo sequencer uses a scrape cooldown (
new_l1_handler_tx_cooldown_secs) for the same purpose.Fix idea
Default
confirmation_depthto a safer value for non-dev Starknet settlement (and/or document the recommended value clearly), keeping0only for dev.Follow-up split from the L1-handler nonce-gate fix (case B3c in the investigation).