Update fp-changes.mdx #689
Conversation
✅ Deploy Preview for docs-optimism ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
…ridge warnings, and withdrawal time changes
…sm/docs into fp-notice-update
WalkthroughThe updates in the Changes
Possibly related issues
Recent Review DetailsConfiguration used: .coderabbit.yaml Files selected for processing (2)
Additional Context UsedLanguageTool (91)
Path-based Instructions (1)
Additional comments not posted (5)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Out of diff range and nitpick comments (2)
pages/builders/notices/fp-changes.mdx (2)
Line range hint
45-45: Add a determiner before "Most notable change" to improve readability.- Most notable change for developers is that withdrawals will have to be proven against the `rootClaim` of some dispute game rather than referencing an output in the `L2OutputOracle` contract. + The most notable change for developers is that withdrawals will have to be proven against the `rootClaim` of some dispute game rather than referencing an output in the `L2OutputOracle` contract.
Line range hint
46-46: Consider adding a comma after "game" for better readability.- ...rootClaim` of some dispute game rather than referencing an output in the `L2OutputOracle` contract. + ...rootClaim` of some dispute game, rather than referencing an output in the `L2OutputOracle` contract.
| **ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reproven after the upgrade is complete. | ||
|
|
||
| * Reproving simply requires that you execute the [withdrawal proving flow](https://docs.optimism.io/stack/protocol/rollup/withdrawal-flow) again. | ||
| * Withdrawals prior to the Fault Proofs upgrade must wait a 7-day challenge period before finalization. As a result, any withdrawal initiated less than 7 days before the upgrade cannot be finalized before the upgrade is executed. You may want to consider waiting until after the upgrade is complete to begin a withdrawal during this 7-day window. | ||
| </Callout> |
There was a problem hiding this comment.
The notice about re-proving withdrawals is crucial and well-highlighted. However, consider simplifying "Withdrawals prior to the Fault Proofs upgrade" to "Withdrawals before the upgrade" for conciseness.
- Withdrawals prior to the Fault Proofs upgrade must wait a 7-day challenge period before finalization.
+ Withdrawals before the upgrade must wait a 7-day challenge period before finalization.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| **ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reproven after the upgrade is complete. | |
| * Reproving simply requires that you execute the [withdrawal proving flow](https://docs.optimism.io/stack/protocol/rollup/withdrawal-flow) again. | |
| * Withdrawals prior to the Fault Proofs upgrade must wait a 7-day challenge period before finalization. As a result, any withdrawal initiated less than 7 days before the upgrade cannot be finalized before the upgrade is executed. You may want to consider waiting until after the upgrade is complete to begin a withdrawal during this 7-day window. | |
| </Callout> | |
| **ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reproven after the upgrade is complete. | |
| * Reproving simply requires that you execute the [withdrawal proving flow](https://docs.optimism.io/stack/protocol/rollup/withdrawal-flow) again. | |
| * Withdrawals before the upgrade must wait a 7-day challenge period before finalization. As a result, any withdrawal initiated less than 7 days before the upgrade cannot be finalized before the upgrade is executed. You may want to consider waiting until after the upgrade is complete to begin a withdrawal during this 7-day window. | |
| </Callout> |
| @@ -50,7 +74,7 @@ | |||
|
|
|||
| * **Option 1: Optimism SDK Update.** If you use OptimismSDK for bridging, simply update to version 3.2.0 or higher. | |||
| The Optimism SDK changes do not break the API and require no changes other than updating to the correct software version to support the new `OptimismPortal` logic. The Optimism SDK will automatically begin to use the new logic once it detects that the FPM update has gone live. | |||
| * **Option 2: Viem Update.** Viem changes will break the API and require both updating to latest version and replacing use of the currently used decorator with the `experimental` decorator that supports fault proofs. When fault proofs are on Mainnet in the future, `publicActionsL2` will be updated to support fault proofs by default, and it will be recommended that developers switch to the stable API. | |||
| * **Option 2: Viem Update.** Viem changes will break the API and require both updating to latest version and replacing use of the currently used decorator with the `experimental` decorator that supports fault proofs. When Fault Proofs are on OP Mainnet, `publicActionsL2` will be updated to support fault proofs by default, and it will be recommended that developers switch to the stable API. | |||
There was a problem hiding this comment.
Include "the" before "latest version" to correct the grammar.
- ...updating to latest version and replacing use of the currently used decorator...
+ ...updating to the latest version and replacing use of the currently used decorator...Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| * **Option 2: Viem Update.** Viem changes will break the API and require both updating to latest version and replacing use of the currently used decorator with the `experimental` decorator that supports fault proofs. When Fault Proofs are on OP Mainnet, `publicActionsL2` will be updated to support fault proofs by default, and it will be recommended that developers switch to the stable API. | |
| * **Option 2: Viem Update.** Viem changes will break the API and require both updating to the latest version and replacing use of the currently used decorator with the `experimental` decorator that supports fault proofs. When Fault Proofs are on OP Mainnet, `publicActionsL2` will be updated to support fault proofs by default, and it will be recommended that developers switch to the stable API. |
updates per issue #687