feat: add resend msg feature changes on fmas #12
Conversation
| - **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. | ||
| - **Risk Assessment:** Low. | ||
| - Potential Impact: Low. The message will need to be re-sent, using the `resendMessage` feature. |
There was a problem hiding this comment.
I suggest not deleting the scenario where for some reason you couldn't relay the msg. It is ok to remove the expired logs one but the FM still there in case something goes wrong while relaying
There was a problem hiding this comment.
Hmm ok, I wanted to do that, but I removed these items:
including:
- Inability to `relayETH` in `SuperchainWETH`
- Inability to `relayERC20` in `SuperchainTokenBridge` to mint `SuperchainERC20`
- Any other contract awaiting a time-sensitive `relayMessage`.
I will add them back, but using medium as risk since they can be re-sent, if that's ok for you.
There was a problem hiding this comment.
The only problem is that the risk is not low if funds are stuck for another reason
| - **Recovery Path(s):** Depends on sequencer/chain governor policy operations. | ||
| - **Recovery Path(s):** | ||
| - If not expired, re-relaying the message on destination. | ||
| - If expired, calling `resendMessage` on origin chain to make it available again to be relayed. |
There was a problem hiding this comment.
Don't feel that this change is worth it. The resendMessage is more like a mitigation than a recovery path. The recovery path is for cases where the resend is not helping
|
|
||
| Some consequences of this issue are: | ||
|
|
||
| - Inability to `relayETH` in `SuperchainWETH` |
| - **Risk Assessment:** Medium. | ||
| - **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:** Low. 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 calling `resendMessage` on origin chain. |
There was a problem hiding this comment.
Potential Impact and Likelihood should be indented below risk
No description provided.