M-03 Inconsistent Proved Event Payload Creates Data Availability Gap for Aggregated Transitions

[ggonzalez94]

The InboxOptimized1 contract aggregates multiple consecutive transitions into a single TransitionRecord when span > 1. In this case, _setTransitionRecordHashAndDeadline emits a Proved event containing:

• transition: the transition data for the first proposal in the aggregated span, including its full Checkpoint (block hash and state root).
• transitionRecord: the aggregated record for the last proposal in the span, including only the checkpointHash of its Checkpoint.

However, the event never exposes the full Checkpoint preimage for the end of the span, only its hash.

The off-chain indexer (shasta_indexer) that consumes this Proved event mirrors the event payload as-is. It does not derive or fetch the missing end-of-span Checkpoint preimage needed for finalization.

This design conflicts with the intended usage of the event stream as a self-sufficient data source for constructing ProposeInput. The propose function expects a ProposeInput.checkpoint whose hash matches record.checkpointHash for the last finalized transition. Any Proposer relying solely on this event-driven indexer cannot construct a valid ProposeInput for aggregated proofs without additional L2 queries.

Even if this behavior is intentional from a protocol design perspective, it introduces a data availability gap for L1 operations:

• The L1 Proved event stream is no longer sufficient to drive finalization for aggregated transitions.
• If the L2 RPC is unavailable, out-of-sync, or restricted, finalization of aggregated spans can stall despite valid proofs being present on L1.
• This harms liveness and undermines the robustness and decentralization benefits of using L1 events as the primary source of truth.

To preserve the self-sufficiency of the L1 event stream and avoid this gap, consider extending the Proved event to include the full Checkpoint for the end of the span (in addition to or instead of the start), so off-chain components can reconstruct ProposeInput directly from logs. Alternatively, emit an additional event containing the end-of-span Checkpoint whenever an aggregated TransitionRecord is created.

[dantaik]

@ggonzalez94 this doesn't appear addressed as written — but it may have been handled by a different design. The Proved event (IInbox.sol:183) carries firstProposalId / firstNewProposalId / lastProposalId / actualProver only — no Checkpoint preimage. The end-of-span checkpoint is instead persisted via a separate _signalService.saveCheckpoint(...) (Inbox.sol:301), which emits its own CheckpointSaved event.

So an indexer can still get the end-of-span checkpoint, just from a second event rather than from Proved directly. Was M-03 intentionally resolved via CheckpointSaved (→ close), or do you still want the Proved event extended to carry the end-of-span Checkpoint?