Wisp Messages

Wisp Message Flow

As part of their flow, the Wisp CRCmsgCRC_{msg} goes through three stages until delivered.


The first stage of the flow for a CRCmsgCRC_{msg} is the sending of the message by the user or the representing contract. Once a message is sent, the rollup saves it in its state in the COutboxC_{Outbox} contract.

On the smart contract level, this stage is marked by the emitting of the MessageSent event from the COutboxC_{Outbox} contract inside RSourceR_{Source}. This event notifies the state and message relayers to start monitoring the necessary conditions for the relay of this message and rollup state.

In Transit

The second stage of the flow for a CRCmsgCRC_{msg} is when it "enters the L1". This stage begins when the rollup anchors state that includes the message in L1. This allows the later verification of the CRCmsgCRC_{msg} inside the source rollup via the L1.

On the smart contract level, this stage is marked by the emitting an event by CSourceRollupStateC_{Source RollupState} showcasing the anchoring of RSourceR_{Source} inside L1. In the case of Optimism Bedrock this is the OutputProposed of the L2OutputOracle.

This event notifies the state relayers that aSNARKL1StateSNARK_{L1 State} can be produced and submit it inside RDestination R_{Destination} (obviously subject to their economic incentive and willingness to do so). This event also notifies the message relayers to start monitoring the CL1LightClientC_{L1 Light Client} for SNARKL1StateSNARK_{L1 State} updates refering a block which is >= than the L1 block in which the rollup state was posted that contains the CRCmsgCRC_{msg}.


The third stage of the flow for a CRCmsgCRC_{msg} is when it is getting delivered. This flow can only kick in when the state relayers have relayed an L1 block >= of the block that anchored the RSourceR_{Source} state containing the message. The beginning of this stage is marked by the HeadUpdate event inside the Wisp CL1LightClientC_{L1 Light Client}.

Once such a block is relayed, the message relayer can gather all the necessary proofs and submit them to CInboxC_{Inbox}contract on RDestination R_{Destination}. The CInboxC_{Inbox} contract will query CL1LightClientC_{L1 Light Client} and using the L1 Execution State root, verify the existance of CRCmsgCRC_{msg}. Once the message is verified , CInboxC_{Inbox} triggers the execution of the CRCmsgCRC_{msg} effectively performing the CRCDeliveryCRC_{Delivery} operation.

Further States of the CRC Flow

While the above stages conclude the life of the CRCmsgCRC_{msg} from the perspective of the end user, some post-effects of its delivery are still present and are part of the flow of the relayers.

While the user has paid its fees for delivery in the first stage of the flow, to this point the relayers have not claimed their fees. The last state of the CRC flow involves the state relayers generating the SNARKL1StateSNARK_{L1 State} that includes the state of RDestination R_{Destination} in order to prove the CRCStateRelayCRC_{State Relay} and CRCDeliveryCRC_{Delivery} inside RSourceR_{Source}. This allows them to collected the fees they are owed and creates a positive feedback loop of CRCStateRelayCRC_{State Relay}.

Properties / Format

For the alpha version of the protocol, the CRCmsgCRC_{msg} format can be found here. For future versions, the following format is considered to be used EIP-5164.

Last updated