feat: add resend msg feature changes on fmas (#12)

security/fma-message-passing-contracts.md

@@ -63,17 +63,22 @@ Below are references for this project:
 - **Detection:** Monitoring tools should track every validated message to ensure it was observed and validated at the origin chain.
 - **Recovery Path(s):** The chain will eventually resolve the issue as the dependency graph advances, but the resolution could be slow, especially if the sequencer is down or equivocating, or if chains in the dependency graph stop batching. Investigate the causes of such incidents.
 
-### FM3: Valid message is initiated but never relayed in destination although is safe to include
+### FM3: Valid message is initiated but never relayed in destination although it is safe to include
 
 - **Description:** A user (or contract) may send a valid cross-chain message, but the final relay step—`relayMessage` or `validateMessage`—never occurs (or is dropped before to gain a safe status) even when the initiated message is included in a finalized block on the origin chain.
+
+  Some consequences of this issue are:
+
+  - Inability to `relayETH` in `SuperchainETHBridge`
+  - Inability to `relayERC20` in `SuperchainTokenBridge` to mint `SuperchainERC20`
+  - Any other contract awaiting a time-sensitive `relayMessage`.
+
 - **Risk Assessment:** High.
-  - Potential Impact: Critical. Several scenarios could lead to severe consequences, including:
-    - Inability to `relayETH` in `SuperchainWETH`
-    - Inability to `relayERC20` in `SuperchainTokenBridge` to mint `SuperchainERC20`
-    - Any other contract awaiting a time-sensitive `relayMessage`.
-      If the message is not included within the expiration window, both the message and the underlying action could be considered lost.
-  - Likelihood: Medium. Block builders/sequencers are generally controlled by a single entity per chain.
-- **Mitigations:** From a smart contract perspective, little can be done except allowing calls to `validateMessage` within a deposit context to improve censorship resistance. This is currently under discussion [here](https://github.com/ethereum-optimism/specs/issues/520).
+  - Potential Impact: High. If the message failure is not related to a time-sensitive operation but is due to the message being incorrect, it could be considered lost.
+  - Likelihood: Medium. Block builders/sequencers are generally controlled by a single entity per chain. Additionally, if the relay failed on destination due to an incorrect state and after some time it is safe to be relayed again, you can do it even if it expired by call `resendMessage` on origin chain.
+- **Mitigations:**
+  - If the problem is that the message is expired, calling `resendMessage` on origin chain to make it available again to be relayed.
+  - From a smart contract perspective, allowing calls to `validateMessage` within a deposit context to improve censorship resistance. This is currently under discussion [here](https://github.com/ethereum-optimism/specs/issues/520).
 - **Detection:** Monitoring tools should track whether every initiated message has been validated at the destination by checking identifiers. Support tickets filed by users reporting the issue sustain the severity of the case in some situations.
 - **Recovery Path(s):** Depends on sequencer/chain governor policy operations.
 

security/fma-superchainerc20.md

@@ -3,15 +3,16 @@
 
 ## **Table of Contents** _generated with [DocToc](https://github.com/thlorenz/doctoc)_
 
+- [**Table of Contents** _generated with DocToc_](#table-of-contents-generated-with-doctoc)
 - [**SuperchainERC20 standard-only FMA (Failure Modes and Recovery Path Analysis)**](#superchainerc20-standard-only-fma-failure-modes-and-recovery-path-analysis)
 - [Introduction](#introduction)
   - [Audit Requirements](#audit-requirements)
   - [Security Considerations](#security-considerations)
 - [Failure Modes and Recovery Paths](#failure-modes-and-recovery-paths)
-  - [FM1: Unauthorized Access to `crosschainMint` & `crosschainBurn` Functions](#fm1-unauthorized-access-to-crosschainmint--crosschainburn-functions)
-  - [FM2: Token Contract Missing in Destination Chain — Relay Fails Until Deployed (But Deployment Is Permissionless)](#fm2-token-contract-missing-in-destination-chain--relay-fails-until-deployed-but-deployment-is-permissionless)
-  - [FM3: Token Contract Missing in Destination Chain — Relay Fails Until Deployed (But Deployment Is Permissioned)](#fm3-token-contract-missing-in-destination-chain--relay-fails-until-deployed-but-deployment-is-permissioned)
-  - [FM4: Token Contract Missing in Destination Chain — Token Deployer Is Lost or Unable to Deploy to Expected Address](#fm4-token-contract-missing-in-destination-chain--token-deployer-is-lost-or-unable-to-deploy-to-expected-address)
+  - [FM1: Unauthorized Access to `crosschainMint` \& `crosschainBurn` Functions](#fm1-unauthorized-access-to-crosschainmint--crosschainburn-functions)
+  - [FM2: Token Contract Missing in Destination Chain: Relay Fails Until Deployed (But Deployment Is Permissioned)](#fm2-token-contract-missing-in-destination-chain-relay-fails-until-deployed-but-deployment-is-permissioned)
+  - [FM3: Token Contract Missing in Destination Chain: Relay Fails Until Deployed (But Deployment Is Permissionless)](#fm3-token-contract-missing-in-destination-chain-relay-fails-until-deployed-but-deployment-is-permissionless)
+  - [FM4: Token Contract Missing in Destination Chain: Token Deployer is Lost, or Unable to Deploy to Expected Address](#fm4-token-contract-missing-in-destination-chain-token-deployer-is-lost-or-unable-to-deploy-to-expected-address)
   - [FM5: Compromised Deployment Method](#fm5-compromised-deployment-method)
 - [Action Items](#action-items)
 - [Warning for Integrators](#warning-for-integrators)
@@ -62,10 +63,8 @@ Similar to ERC20, SuperchainERC20 implementations should be considered untrusted
 ### FM2: Token Contract Missing in Destination Chain: Relay Fails Until Deployed (But Deployment Is Permissioned)
 
 - **Description**: The token on the destination chain is not yet deployed, which prevents the cross-chain transfer from finalizing (`relayERC20` fails). However, the token's deployment is permissioned, meaning it is solely up to the deployer to make the token available on the destination chain
-- **Risk Assessment**: High.
-  - Potential impact: High. Users may lose access to their tokens temporarily or permanently. Two specific scenarios can arise:
-    1. Funds are stuck but can eventually be relayed if the deployment occurs before the message expiration window ends.
-    2. Funds are stuck and potentially lost if the deployment occurs after the message expiration time ends or never occurs.
+- **Risk Assessment**: Medium.
+  - Potential impact: Medium. Users may lose access to their tokens temporarily, until the token is deployed.
   - Likelihood: Medium. A deployer may choose not to deploy the token on all chains.
 - **Mitigation**: Trusted bridge frontends should prevent users from sending tokens to a chain where the token doesn’t exist. Double-check other trusted sources (such as Superchain Token List) for greater confidence.
 - **Detection**: Support tickets filed by users reporting the issue.

security/fma-superchainethbridge.md

@@ -39,11 +39,11 @@ Below are references for this project:
 
 - **Description:** If `ETHLiquidity` lacks sufficient ETH, mint calls will revert when the contract attempts to forward funds using `SafeSend`. This breaks bridging flows dependent on `relayETH`.
 - **Risk Assessment:** Medium.
-  - Potential Impact: High. Not having enough ETH balance in `ETHLiquidity` prevents relaying ETH, which would greatly degrade the user experience, as they would be temporarily stuck. The situation becomes even more serious if the affected cross-chain messages expire before the issue can be resolved, making it impossible to retry the relay and get the funds in destination chain.
+  - Potential Impact: High. Not having enough ETH balance in `ETHLiquidity` prevents relaying ETH, which would greatly degrade the user experience, as they would be temporarily stuck.
   - Likelihood: Very low. `ETHLiquidity` starts with a maximum balance (`type(uint248).max`).
 - **Mitigations:** Our current codebase includes tests to check if the `mint` request exceeds the contract’s balance ([test](https://github.com/ethereum-optimism/optimism/blob/dd37e6192c37ed4c5b18df0269f065f378c495cc/packages/contracts-bedrock/test/L2/ETHLiquidity.t.sol#L103)). Initial ETH supply in `ETHLiquidity` is `type(uint248).max` ([test](https://github.com/ethereum-optimism/optimism/blob/dd37e6192c37ed4c5b18df0269f065f378c495cc/packages/contracts-bedrock/test/L2/ETHLiquidity.t.sol#L29)) and equally set in all chains.
 - **Detection:** Perform checks on the `ETHLiquidity` balance as a preventive monitoring measure. User-filed support tickets may flag this issue in case of failure.
-- **Recovery Path(s):** Coordinate an L2 hard fork to replenish the `ETHLiquidity` contract. Investigate the causes of the depletion to determine if other factors are involved. Messages will need to be retried for relaying; otherwise, use the `expireMessage` feature if it is available and integrated into `SuperchainETHBridge`.
+- **Recovery Path(s):** Coordinate an L2 hard fork to replenish the `ETHLiquidity` contract. Investigate the causes of the depletion to determine if other factors are involved. Messages will need to be retried for relaying, leveraging the `resendMessage` feature if needed.
 
 ### FM2: Overflow during `burn` in `ETHLiquidity` due to max Balance