Merge pull request #689 from ethereum-optimism/fp-notice-update

Update fp-changes.mdx

Author: OPMattie

pages/builders/notices/fp-changes.mdx

@@ -1,23 +1,42 @@
 ---
-title: Preparing for Fault Proofs Breaking Changes
+title: Preparing for Fault Proofs Changes
 lang: en-US
-description: Learn how to prepare for Fault Proofs breaking changes.
+description: Learn how to prepare for Fault Proofs changes.
 ---
 
 import { Steps, Callout } from 'nextra/components'
 
-# Preparing for Fault Proofs Breaking Changes
+# Preparing for Fault Proofs Changes
 
-This page outlines breaking changes related to Fault Proof upgrade for bridges, centralized exchanges, and custom solutions that use withdrawals. This page outlines changes for OP Mainnet and OP Sepolia only, and details for other OP Chains are forthcoming.
-If you experience difficulty at any stage of this process, please reach out to [developer support](https://github.com/ethereum-optimism/developers/discussions).
+OP Labs has submitted a [proposal to governance](https://gov.optimism.io/t/upgrade-proposal-fault-proofs/8161) to upgrade OP Mainnet to support Fault Proofs. If this proposal passes, fault proofs would launch on OP Mainnet approximately June 2024. This document details changes that apply to users, bridges, and centralized exchanges, as well as any custom solutions that use withdrawals. This page outlines changes for OP Mainnet and OP Sepolia only. Details for other OP Chains are forthcoming.
+
+If you experience difficulty at any stage of this process, please reach out to [OP Labs Developer Support](https://github.com/ethereum-optimism/developers/discussions).
+
+<Callout type="error">
+ **IMPORTANT NOTICE FOR BRIDGES AND USERS**
+
+**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>
 
 <Callout type="warning">
-  *   Fault Proofs are scheduled to launch on testnet on **Tuesday, March 19, 2024**.
-  *   Withdrawals between OP Sepolia and Sepolia will no longer be instant, since they are using the Fault Proofs mechanism.
+  **IMPORTANT NOTICE FOR BRIDGES AND USERS**
+  
+  Maximum withdrawal delay times are increasing with the Fault Proofs upgrade.
+  *   Withdrawals will generally take 7 days to finalize (unchanged from before Fault Proofs).
+  *   Withdrawals that are proven against an output proposal that receives a validity challenge are delayed by an additional 3.5 days. Valid proposals that are challenged maliciously can be delayed by up to an additional 9 days at a very high cost to the malicious actor. Additional delays of this type are expected to be infrequent.
+</Callout>
+
+<Callout type="warning">
+  As of the Fault Proofs update to OP Sepolia in March 2024, **OP Sepolia withdrawals are no longer instant.** This is because the Fault Proof mechanism now applies to OP Sepolia transactions.
 </Callout>
 
 ## Overview of Changes
 
+If you are operating a custom bridge, review this section for changes you need to make. If you are using Optimism SDK or Viem for your bridging, you can [skip to the next section](#for-bridges-and-centralized-exchanges).
+
 The `L2OutputOracle` is being entirely removed and replaced by the `OptimismPortal` and `DisputeGameFactory`. The `L2OutputOracle` smart contract is currently used by the trusted Proposer role to store L2 state output proposals.
 Presently, developers use these outputs to prove that their withdrawals actually happened on L2. But with fault proofs, developers will have to change how their client software proves withdrawals in the first step of the two-step withdrawal process.
 
@@ -39,7 +58,12 @@ Developers should then verify this proposal locally as the default game type wil
 
 ## For Bridges and Centralized Exchanges
 
-The proposed Fault Proof upgrade requires developers to enable Fault Proof changes before the Sepolia release. This impacts bridges, centralized exchanges, and custom solutions that use withdrawals.
+The proposed Fault Proof upgrade requires developers to enable Fault Proof changes before the Op Mainnet release. This impacts bridges, centralized exchanges, and custom solutions that use withdrawals.
+
+<Callout type="error">
+  Withdrawals that haven't finalized before the upgrade occurs will be unable to be finalized post-upgrade without resubmitting. This means these withdrawals will need to go through a new 7-day period. The time accrued before the upgrade will not count.
+  This means the withdrawal time could be as long as 13-14 days during the upgrade window. (If you submit it \~6 days before the upgrade, then must re-submit after the upgrade, you will have to wait a new seven days.)
+</Callout>
 
 <Steps>
   ### Update Logic to Support Fault Proofs
@@ -50,7 +74,7 @@ The proposed Fault Proof upgrade requires developers to enable Fault Proof chang
 
   *   **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.
 
   ### Update Withdrawal Monitor
 

words.txt

@@ -134,6 +134,7 @@ journalremotes
 JSPATH
 jspath
 jwtsecret
+leadup
 leveldb
 lightkdf
 logfile
@@ -251,6 +252,7 @@ rejournal
 REMOTEDB
 remotedb
 replayability
+reproven
 REQUIREDBLOCKS
 requiredblocks
 Rollups