Feature Request: Prover for Unfinalized State in OP Stack Chains

[jackchuma]

Context

When sending a 7755 request, a user must first decide which outbox on source chain to use. Currently, this selection is determined solely by the destination chain, as each supported chain requires its own specialized Prover implementation due to differences in their L1 state posting mechanisms and data models.

Prerequisites
This issue assumes familiarity with:

• Optimistic Rollups
• OP Stack Architecture
• Fault Proof Systems

Protocol Flow

The RRC-7755 protocol operates in four key steps:

1. Request Initiation: User submits a cross-chain call request to the source chain with a reward bounty
2. Fulfillment: An offchain fulfiller forwards the request to the destination chain's Inbox contract, providing necessary execution funds
3. Receipt Generation: The Inbox contract records an execution receipt in its storage
4. Proof Submission: After a delay, the fulfiller proves the receipt's existence to the source chain's Outbox contract to claim their reward

Current Limitations

The current design has a notable constraint: fulfillers must lock their funds during the delay period before proof submission. Our OP Stack Prover implementation requires waiting for the complete challenge period to ensure finalized state. While this approach provides maximum security, it creates significant opportunity costs for fulfillers who must wait to claim their rewards.

Proposed Enhancement

We propose developing an alternative OP Stack Prover implementation that operates on unfinalized state. This implementation would verify against state claims that have remained unchallenged for a configurable threshold period, rather than waiting for full finalization. Requesters could specify this threshold using the existing finalityDelaySeconds parameter in the delay attribute.