Add message expiration doc

pages/interop/_meta.json

@@ -12,6 +12,7 @@
     "explainer": "Superchain interop explainer",
     "predeploy": "Superchain interop predeploys",
     "message-passing": "Superchain interop message passing",
+    "message-expiration": "Message expiration",
     "reading-logs": "Reading logs",
     "op-supervisor": "OP Supervisor",
     "superchain-eth-bridge": "Superchain ETH bridge",

pages/interop/message-expiration.mdx

@@ -0,0 +1,53 @@
+---
+title: Message expiration
+description: What message expiration is, why it exists, and how to reemit a previously sent message if it has expired and was never relayed.
+lang: en-US
+content_type: guide
+topic: message-expiration
+personas:
+  - protocol-developer
+  - chain-operator
+  - app-developer
+categories:
+  - protocol
+  - interoperability
+  - cross-chain-messaging
+  - security
+  - block-safety
+  - message-passing
+  - reorgs
+  - superchain
+is_imported_content: 'false'
+---
+
+# Message expiration
+
+[Messages](/interop/message-passing) referenced between OP Stack chains have a limited validity period called the expiry window. Once this window elapses, the referenced message becomes invalid and can no longer be referenced.
+
+For messages using [`L2ToL2CrossDomainMessenger`](/interop/message-passing), if a message expires before being referenced, developers can reemit the message on the source chain. This triggers a fresh `SentMessage` event, enabling the message to be relayed.
+
+## The expiry window
+
+The expiry window is an offchain constant, defined by [OP-Supervisor](/interop/op-supervisor), that defines how long a cross-chain message or event emitted remains valid. For any chain in the [Superchain interop cluster](/interop/explainer#superchain-interop-cluster), messages must be referenced within 7 days (604,800 seconds) of the log being created.
+
+After this period, a message can no longer be referenced unless the event is remitted.
+
+## Reemitting an expired message
+
+The `resendMessage` function on the [`L2ToL2CrossDomainMessenger`](/interop/message-passing) contract allows developers to reemit a message that was sent but not yet relayed.
+
+This emits a new `SentMessage` log with the same content as the original message, enabling offchain relayers to pick it up again.
+
+The process to reemit an expired message:
+
+1.  Call [`resendMessage`](https://github.com/ethereum-optimism/optimism/blob/a979a9444dbb482843f2a42f437ced54a8ac1053/packages/contracts-bedrock/interfaces/L2/IL2ToL2CrossDomainMessenger.sol#L110-L128) on the origin chain to reemit the message event. The contract verifies the message hash was originally sent. The call requires   [every parameter](https://github.com/ethereum-optimism/optimism/blob/a979a9444dbb482843f2a42f437ced54a8ac1053/packages/contracts-bedrock/interfaces/L2/IL2ToL2CrossDomainMessenger.sol#L110-L128) to rebuild the original message.
+
+2.  [Relay the new message](/interop/message-passing#executing-message) as normal.
+
+Note: Re-emitting an already relayed message will have no effect on the destination chain since the re-emitted event won't be logged by OP-Supervisor. 
+
+## Next steps
+
+*   [Build a revolutionary app](/app-developers/get-started) that uses multiple blockchains within the Superchain
+*   Learn how to [pass messages between blockchains](/interop/tutorials/message-passing)
+*   Deploy a [SuperchainERC20](/interop/tutorials/deploy-superchain-erc20) to the Superchain

pages/interop/message-passing.mdx

@@ -101,7 +101,7 @@ sequenceDiagram
     dstXdom->>dstContract: 5. Call with provided calldata
 ```
 
-1.  Before the executing message is processed, the log event of the initiating message has to get to `op-supervisor` on the destination chain.
+1.  Before the executing message is processed, the log event of the initiating message has to get to `op-supervisor` on the destination chain before the [expiry window](/interop/message-expiration) of 7 days. 
 
 2.  The autorelayer, the application, or a contract calling on the application's behalf calls [`L2ToL2CrossDomainMessenger.relayMessage`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/L2ToL2CrossDomainMessenger.sol#L150-L203).
     This call includes the message that was sent (`_sentMessage`), as well as the [fields required to find that message (`_id`)](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/interfaces/L2/ICrossL2Inbox.sol#L4-L10).
@@ -110,12 +110,12 @@ sequenceDiagram
 
 4.  `L2ToL2CrossDomainMessenger` on the destination chain verifies the message is legitimate:
 
-    *   The origin (of the log entry) is `L2ToL2CrossDomainMessenger` on the other side.
-    *   The destination chain ID is correct.
-    *   The target is neither `CrossL2Inbox` nor `L2ToL2CrossDomainMessenger`.
-    *   This message has not been relayed before.
-
-    This is the reason we need the nonce value, to enable us to send multiple messages that would be otherwise identical.
+    *   `_destination`: Chain ID of the destination chain.
+    *   `_nonce`: Nonce of the message sent
+    *   `_sender`: Address that sent the message
+    *   `_target`: Target contract or wallet address.
+    *   `message`: Message payload to call target with.
+
 
 5.  If everything checks out, `L2ToL2CrossDomainMessenger` calls the destination contract with the calldata provided in the message.
 

pages/interop/reading-logs.mdx

@@ -27,6 +27,10 @@ This enables developers to:
 *   Build cross-chain applications that react to events happening across the Superchain.
 *   Create novel applications that leverage data from multiple chains.
 
+<Callout>
+When reading logs, you must reference logs created within the [expiry window of 7 days](/interop/message-expiration).
+</Callout>
+
 ## Why use `CrossL2Inbox`?
 
 *   **Reference existing logs**: Allows contracts to verify and use logs that were already emitted, without requiring those logs to have been sent as cross-chain messages.