From b9453daf2e11bf5863298953d573b843fa9b1f4e Mon Sep 17 00:00:00 2001 From: Kelvin Fichter Date: Mon, 15 Sep 2025 12:33:48 -0400 Subject: [PATCH 1/5] feat: bridge recovery --- pages/stack/smart-contracts/_meta.json | 5 +- .../stack/smart-contracts/bridge-recovery.mdx | 254 ++++++++++++++++++ 2 files changed, 257 insertions(+), 2 deletions(-) create mode 100644 pages/stack/smart-contracts/bridge-recovery.mdx diff --git a/pages/stack/smart-contracts/_meta.json b/pages/stack/smart-contracts/_meta.json index 3446960d9..fa0019ab4 100644 --- a/pages/stack/smart-contracts/_meta.json +++ b/pages/stack/smart-contracts/_meta.json @@ -2,5 +2,6 @@ "smart-contracts": "Smart Contracts", "superchain-ops-guide": "Upgrade using superchain-ops", "op-deployer-upgrade": "Upgrade L1 contracts using op-deployer", - "upgrade-op-contracts-1-3-1-8": "Upgrading Smart Contracts from v1.3.0 to v1.8.0" -} \ No newline at end of file + "upgrade-op-contracts-1-3-1-8": "Upgrading Smart Contracts from v1.3.0 to v1.8.0", + "bridge-recovery": "Recovering tokens sent via the wrong bridge" +} diff --git a/pages/stack/smart-contracts/bridge-recovery.mdx b/pages/stack/smart-contracts/bridge-recovery.mdx new file mode 100644 index 000000000..3195f9a9b --- /dev/null +++ b/pages/stack/smart-contracts/bridge-recovery.mdx @@ -0,0 +1,254 @@ +--- +title: Recovering tokens sent via the wrong bridge +description: Learn how to recover certain tokens that were sent via the wrong bridge +lang: en-US +content_type: guide +topic: bridge-recovery +personas: + - protocol-developer + - chain-operator +categories: + - protocol + - l1-contracts +is_imported_content: 'false' +--- + +import { Steps, Callout } from 'nextra/components' + +# Recovering tokens sent via the wrong bridge + + + This is a guide for recovering certain types of tokens that were sent to the Standard Bridge when they should have been sent to some other bridge instead. This guide will NOT always work and requires certain conditions to be met. You should always run all of the simulations described in this guide before attempting any recovery, and you should reach out for assistance if you are unsure of what you're doing. + + +## Introduction + +This guide explains how certain types of tokens can be recovered from the Standard Bridge when they were meant to be sent to some other bridge instead. For instance, DAI does NOT use the Standard Bridge and instead utilizes a custom DAI bridge. Users who attempt to withdraw DAI via the Standard Bridge will see those tokens stuck in the Standard Bridge and would normally not be able to complete the withdrawal process. + +Under certain conditions, it can still be possible to complete the withdrawal process (or deposit process, depending on the bridging action that was attempted) succesfully. This guide will walk you through the steps necessary to attempt a recovery. + +## Recovery principle + +The fundamental principle that enables this type of recovery is that the Standard Bridge can facilitate the execution of a deposit or withdrawal as long as there is sufficient liquidity of the "remote" token on the opposite chain. We can take advantage of this knowledge to force the withdrawal to execute by creating the necessary liquidity on the opposite chain. We do this by depositing or withdrawing the "remote" token as needed. + +### Typical failure mode + +Most bridging operations take place between a native token on one chain and a bridged representation of that token on the opposite chain. For example, when withdrawing AAVE from Ethereum to OP Mainnet, the "local" token on Ethereum is the native representation while the "remote" token on OP Mainnet is a bridged representation. This bridged representation officially recognizes the Standard Bridge and will dynamically mint (on deposit) or burn (on withdrawal) whenever it detects a bridging operation through the Standard Bridge. + +The typical failure mode that leads to "stuck" tokens is when the "remote" token does not officially recognize the Standard Bridge and therefore does not dynamically mint or burn any tokens. + +For example, suppose that a user deposits DAI via the Standard Bridge. DAI does NOT recognize the Standard Bridge. On L1, the user will successfully deposit the DAI into the Standard Bridge without any issues. However, on L2, the user's deposit will fail because the DAI token will not dynamically mint L2 DAI tokens and, as a result, there is insufficient liquidity to complete the deposit. + +### Generating liquidity + +We can generate the liquidity necessary to complete a failed deposit/withdrawal of this type by depositing or withdrawing an equal amount of tokens on the opposite chain. For example, if a user deposits DAI from Ethereum to OP Mainnet via the Standard Bridge (the incorrect bridge for DAI), we can generate the liquidity necessary to complete the deposit by withdrawing DAI from OP Mainnet to Ethereum. + +The withdrawal will utilize the liquidity that was placed into the Standard Bridge on L1, and the original deposit can then be completed by utilizing the liquidity that was generated by the withdrawal. The net result is that the bridge has no more balance and the users receive their tokens on each end. + +### When this works + +This type of recovery works when the "remote" token is a real ERC-20 token that exists on the opposite chain. For example, if the "remote" token specified for a DAI deposit is the actual L2 DAI address on OP Mainnet (`0xDA10009cBd5D07dd0CeCc66161FC93D7c9000da1`), this recovery would be possible. However, if there was a user error and the "remote" token was set to the wrong address (like the zero address), this recovery would not be possible. Recovery *may* be possible if the "remote" token was set to an incorrect address that also happens to be some other valid token on the opposite chain, but this is a rare case and should be treated with caution. + +## Recovery conditions + +Before attempting to recover a token, you must verify that the conditions for recovery are met. + +### You deposited or withdrew with the correct token pair + +When you deposited or withdrew your tokens, the "local" and "remote" token addresses were provided correctly. Even though these tokens may not have been intended to be bridged via the Standard Bridge, it is often possible to recover the tokens if the token pair is correct. Use block explorers like Etherscan to verify that the token pair was identified correctly. If the "remote" pair was set incorrectly (e.g., the zero address), recovery is likely not possible. + +### You have sufficient liquidity on the opposite chain + +You will need access to an amount of the "remote" token on the opposite chain equal to the amount of the "local" token that you deposited or withdrew. For example, if you deposited 100 DAI from Ethereum to OP Mainnet via the Standard Bridge, you will need to have 100 DAI on OP Mainnet to complete the recovery. + +## Recovery process + +The basic process for recovering these stuck tokens is to deposit or withdraw the "remote" token on the chain opposite to the original bridging action. For example, if you deposited 100 DAI from Ethereum to OP Mainnet via the Standard Bridge, you will need to have 100 DAI on OP Mainnet to complete the recovery. You can do this by withdrawing 100 DAI from OP Mainnet to Ethereum. + +### Example recovery + +1. User deposits 100 DAI from Ethereum to OP Mainnet via the Standard Bridge. This causes the Standard Bridge to pull 100 DAI tokens into its account on L1. The Standard Bridge now has a balance of 100 DAI tokens on L1. +1. At this point, the Standard Bridge has 0 DAI tokens in its account. DAI does not officially recognize the Standard Bridge and therefore does not dynamically mint the liquidity on L2 required to execute the deposit. User never receives the deposit on L2 and the deposit is "stuck" waiting for this liquidity. +1. User collects 100 DAI on OP Mainnet. +1. User withdraws 100 DAI from OP Mainnet to Ethereum via the Standard Bridge. This causes the Standard Bridge to pull 100 DAI tokens into its account on L2. The Standard Bridge now has a balance of 100 DAI tokens on L2. +1. User can now "replay" the original deposit on L2. The deposit will now succeed because the Standard Bridge has sufficient liquidity (100 DAI) to complete the deposit. User receives 100 DAI on L2 and the Standard Bridge again has a balance of 0 DAI tokens on L2. +1. After the 7 day withdrawal period, user finalizes their withdrawal of 100 DAI. The user can successfully finalize this withdrawal because the Standard Bridge has a 100 DAI balance on L1 from the original deposit. User is able to retrieve all of the DAI from the bridge on both ends. + +Note that this recovery process is the same in both directions. Failed withdrawals are resolved by depositing an equal amount of the L1 token into the Standard Bridge on L1. Failed deposits are resolved by withdrawing an equal amount of the L2 token from the Standard Bridge on L2. + +## Simulating the recovery + +Always begin by simulating the recovery process to verify that it will succeed. This will help you understand the process, identify any potential issues, and validate that the recovery will be successful. + +### Creating the simulation networks + +Currently, the best way to simulate this recovery is to use [Tenderly](tenderly.co). You will need to create two Virtual TestNets, one for the L1 chain and one for the L2 chain. Make sure that the parent chain for each network is correct before continuing. These networks will act as forks of the actual L1 and L2 chains and will allow you to fully simulate the recovery process. + +### Withdrawal recovery + +The exact simulation process required depends on the type of recovery that you are attempting. In this section, we describe the process for simulating the recovery of a failed withdrawal. We assume that you have already created a withdrawal on the L2 network and that you unsuccessfully attempted to finalize the withdrawal on the L1 network. + +#### Find the failed withdrawal finalization transaction + +First, before you continue, find the transaction where you called `finalizeWithdrawalTransaction` on the `OptimismPortal` contract on L1. If you have not yet attempted to finalize the withdrawal, do so now. This will not have any negative effects on the recovery process, but it will simplify the rest of the recovery process. If you have already created a simulation network, you will need to create a new L1 Virtual TestNet after you attempt to finalize the withdrawal. + +From the failed withdrawal finalization transaction, you will need to extract the following parameters. Be certain that you are copying these parameters **EXACTLY** as they appear in your original call to `finalizeWithdrawalTransaction`. + +* `_nonce` - the unique identifier for your withdrawal. +* `_sender` - the address that initiated the withdrawal on L2 (typically `0x4200000000000000000000000000000000000010`). +* `_target` - the address on L1 being targeted (typically `0x99C9fc46f92E8a1c0deC1b1747d010903E884bE1`). +* `_value` - the amount of ETH in the withdrawal (usually zero for token withdrawals). +* `_minGasLimit` - the minimum amount of gas to provide to the transaction. +* `_message` - the data for the withdrawal transaction. + +#### Get access to the token on L1 + +You will need to get access to an amount of the token on the L1 equal to the amount that you withdrew on L2. For instance, if you withdrew 100 DAI from OP Mainnet to Ethereum, you will need to get access to 100 DAI on Ethereum. You can typically simulate this by finding an account with a large balance of that token on L1 and creating an impersonated transaction in the Virtual TestNet that causes the account to send you the required balance. In the real recovery, you will need to find another way to get this token (like swapping). + +#### Deposit the token on L1 + +Submit a deposit transaction to the Standard Bridge on L1. You will first need to approve the Standard Bridge to spend the token on L1. Create a simulated transaction in the Virtual TestNet that calls the `approval` transaction on the L1 token, approving the Standard Bridge to spend the required amount of tokens. Once the approval is submitted, create a simulated transaction that calls the Standard Bridge's `bridgeERC20To` function using the following parameters: + +* `_localToken` - The address of the token on L1. +* `_remoteToken` - The address of the token on L2. +* `_to` - The address of the recipient of the tokens (usually your own address). +* `_amount` - The amount of tokens to deposit. +* `_minGasLimit` - The minimum amount of gas to provide to the transaction (use 500000). +* `_extraData` - The data for the withdrawal transaction (leave empty, 0x). + +Confirm that the simulated deposit transaction was successful by looking at the `Events` tab in Tenderly and verifying that you see a `Transfer` event for the token on L1 and a `ERC20DepositInitiated` event in the `L1StandardBridge` contract. + +#### Extract the deposit transaction data + +Once you've submitted the deposit, you'll need to extract some important information from the deposit transaction so that you can later simulate the deposit on the L2 network. We won't use this immediately, but this is the right time to extract it. + +1. Open the `Events` tab in the simulated deposit transaction. +1. Look for the `TransactionDeposited` event. Sometimes, Tenderly does not properly decode this event, in which case you will instead see a `LogNote` event with a signature of `0xb3813568`. +1. If the event is decoded properly, look for the `opaqueData` field. If the event is not properly decoded, look for the `data` field. Inside of these fields, look for the four byte string `d764ad0b`. Copy this string and everything that comes after it. The total string you copied should be about 968 characters or 484 bytes (give or take, gas limits may vary and add or remove a few bytes). Store this data in a notepad for later. +1. If the event is decoded properly, look for the `from` field. If the event is not properly decoded, look for the field called `usr`. Copy this address and store it in a notepad for later. + +#### Simulate the withdrawal finalization + +Now that you've deposited on the L1 side, you've created the liquidity necessary to finalize your original withdrawal. Using the data you extracted from your failed finalization transaction, you can now replay the withdrawal transaction and complete it. + +Use the Virtual TestNet to create a simulated transaction that calls the `relayMessage` function on the `L1CrossDomainMessenger` contract on L1. This function has the following signature: + +```solidity +function relayMessage( + uint256 _nonce, + address _sender, + address _target, + uint256 _value, + uint256 _minGasLimit, + bytes calldata _message +) +``` + +When you call this function, provide the parameters **EXACTLY** as you found them when you [extracted them previously](#find-the-failed-withdrawal-finalization-transaction). Note that these parameters line up exactly with the `relayMessage` parameters. It is **IMPORTANT** that you provide sufficient gas to the transaction to ensure that it will execute properly. We recommend a minimum of 1 million gas. This is DIFFERENT than the `_minGasLimit` parameter, keep the `_minGasLimit` parameter exactly as you found it. + +Once you execute this simulated transaction, confirm that the withdrawal executed successfully by looking at the `Events` tab in Tenderly and verifying that you see a `Transfer` event in the token contract and an `ERC20WithdrawalFinalized` event in the `L1StandardBridge` contract. + +#### Simulate the deposit on L2 + +If you were able to see all of the above, you have successfully simulated the L1 side of the withdrawal recovery process. You now need to simulate the deposit on the L2 side to confirm that you receive the L2 tokens correctly. Note that this step is not necessary during a real recovery as this transaction would be automatically generated by the L2 network. + +Switch over to the L2 Virtual TestNet. Create a new simulated transaction. Set the `from` address to be the "from" or "usr" address [that you extracted previously](#extract-the-deposit-transaction-data). Set the `to` address to be the `L2CrossDomainMessenger` contract address (`0x4200000000000000000000000000000000000007`). Set the `data` to be the portion of the "opaqueData" or "data" field [that you extracted previously](#extract-the-deposit-transaction-data). Set the `gasLimit` to 1 million. + +Execute this simulated transaction. Confirm that the deposit executed successfully by looking at the `Events` tab in Tenderly and verifying that you see a `Transfer` event in the token contract and a `ERC20BridgeFinalized` event in the `L2StandardBridge` contract. + +#### Confirm the recovery + +If you were able to complete all of the above steps and see all of the relevant transactions, you have successfully simulated the recovery process. If anything did not execute correctly, there may be issues in your parameters, you may have made a mistake in the process, or it may not be possible to recover the tokens. + +TODO: Generally figure out how people should get in contact if this happens. + +#### Executing the recovery + +Once you are entirely confident that the recovery is possible, you may consider executing the recovery on the actual network. The recovery process is almost identical to the simulated process above, except that the L2 deposit transaction is automatically generated by the network. + +### Deposit recovery + +Deposit recovery is very similar to withdrawal recovery, although the steps and ordering differ slightly. Like with the withdrawal recovery simulation, you will need to create a virtual testnet for both the L1 and L2 chains. + +#### Find the original deposit tranasction on L1 + +First, find the transaction where you deposited the token on L1. This transaction will have emitted a `ERC20DepositInitiated` event in the `L1StandardBridge` contract as well as a `SentMessage` event in the `L1CrossDomainMessenger` contract. From the `SentMessage` event, extract the following parameters: + +* `_nonce` - the unique identifier for your deposit. +* `_sender` - the address that initiated the deposit (usually the `L1StandardBridge` contract address). +* `_target` - the address on L2 being targeted (usually `0x4200000000000000000000000000000000000010`). +* `_value` - the amount of ETH in the deposit (usually zero for token deposits). +* `_minGasLimit` - the minimum amount of gas to provide to the transaction. +* `_message` - the data for the deposit transaction. + +#### Get access to the token on L2 + +You will need to get access to an amount of the token on the L2 equal to the amount that you deposited on L1. For instance, if you deposited 100 DAI from Ethereum to OP Mainnet, you will need to get access to 100 DAI on OP Mainnet. You can typically simulate this by finding an account with a large balance of that token on L2 and creating an impersonated transaction in the Virtual TestNet that causes the account to send you the required balance. In the real recovery, you will need to find another way to get this token (like swapping). + +#### Withdraw the token on L2 + +Submit a withdrawal transaction to the Standard Bridge on L2. You will first need to approve the Standard Bridge to spend the token on L2. Create a simulated transaction in the Virtual TestNet that calls the `approval` transaction on the L2 token, approving the Standard Bridge to spend the required amount of tokens. Once the approval is submitted, create a simulated transaction that calls the Standard Bridge's `bridgeERC20To` function using the following parameters: + +* `_localToken` - The address of the token on L2. +* `_remoteToken` - The address of the token on L1. +* `_to` - The address of the recipient of the tokens (usually your own address). +* `_amount` - The amount of tokens to withdraw. +* `_minGasLimit` - The minimum amount of gas to provide to the transaction (use 500000). +* `_extraData` - The data for the withdrawal transaction (leave empty, 0x). + +Confirm that the simulated withdrawal transaction was successful by looking at the `Events` tab in Tenderly and verifying that you see a `Transfer` event for the token on L2 and an `ERC20WithdrawalInitiated` event in the `L2StandardBridge` contract. + +Search for the `SentMessage` event emitted by the `L2CrossDomainMessenger` contract. This event will contain the parameters that you need to finalize the withdrawal on L1. Record the `target`, `sender`, `message`, `messageNonce`, and `gasLimit` parameters from this event. + +#### Replay the deposit on L2 + +Now that you've withdrawn on the L2 side, you've created the liquidity necessary to replay your original deposit. Using the data you extracted from your failed deposit transaction, you can now replay the deposit transaction and complete it. + +Use the Virtual TestNet to create a simulated transaction that calls the `relayMessage` function on the `L2CrossDomainMessenger` contract on L2. This function has the following signature: + +```solidity +function relayMessage( + uint256 _nonce, + address _sender, + address _target, + uint256 _value, + uint256 _minGasLimit, + bytes calldata _message +) +``` + +When you call this function, provide the parameters **EXACTLY** as you found them when you [extracted them previously](#find-the-original-deposit-transaction-on-l1). Note that these parameters line up exactly with the `relayMessage` parameters. It is **IMPORTANT** that you provide sufficient gas to the transaction to ensure that it will execute properly. We recommend a minimum of 1 million gas. This is DIFFERENT than the `_minGasLimit` parameter, keep the `_minGasLimit` parameter exactly as you found it. + +Once you execute this simulated transaction, confirm that the deposit executed successfully by looking at the `Events` tab in Tenderly and verifying that you see a `Transfer` event in the token contract and a `ERC20BridgeFinalized` event in the `L2StandardBridge` contract. + +#### Finalize the withdrawal on L1 + +At this point, you will have successfully completed the original deposit. You now need to finalize the withdrawal to be able to unlock the DAI that was locked by the original deposit transaction. Note that to unlock this DAI in the real network, you must prove your withdrawal to the `OptimismPortal` contract, wait one week, and then finalize the withdrawal. You can use the [Superbridge UI](https://superbridge.app/) to carry out this step when you are ready to execute the recovery in a real environment. + +For now, we will skip past the proving step while simulating to avoid additional complexity. Although this step will not exactly mirror the real recovery process, it provides us with all of the information necessary to determine if the recovery will work or not. Again, in the real environment, you can complete the withdrawal process directly via the Superbridge UI instead. + +Click on "Simulator" in the left-hand sidebar, then start by populating a transaction to the `relayMessage` function on the `L1CrossDomainMessenger` contract. Fill in the parameters **EXACTLY** as you found them when you extracted them after you [withdrew the token on L2](#replay-the-deposit-on-l2). Set the `value` field to zero. This transaction should be sent FROM the `OptimismPortal` contract address. + +BEFORE you execute this transaction, click on the "State Overrides" section to add an override. + + + If you do not see the "State Overrides" section, make sure you have clicked on the "Simulator" tab. The "State Overrides" section does not appear when you use the "Send" button in the Tenderly UI. + + +Add an override for the `OptimismPortal` contract. Set the `l2Sender` field to be equal to the address of the `L2CrossDomainMessenger` contract (`0x4200000000000000000000000000000000000007`). + +Now simulate this transaction. You should see a `Transfer` event in the token contract and a `ERC20WithdrawalFinalized` event in the `L1StandardBridge` contract. + +#### Confirm the recovery + +If you were able to complete all of the above steps and see all of the relevant transactions, you have successfully simulated the recovery process. If anything did not execute correctly, there may be issues in your parameters, you may have made a mistake in the process, or it may not be possible to recover the tokens. + +TODO: Generally figure out how people should get in contact if this happens. + +#### Executing the recovery + +Once you are entirely confident that the recovery is possible, you may consider executing the recovery on the actual network. Again, the process is mostly identical to the simulated process above, except that the actual withdrawal process should be executed directly via the Superbridge UI. + +## Requesting assistance + +Please simulate the recovery process above before requesting assistance. If you are unable to simulate the recovery process and need additional support, please contact TODO: WHO?. From 5de2b5632302d7cb899eb694caadf002a7152aa1 Mon Sep 17 00:00:00 2001 From: Kelvin Fichter Date: Mon, 15 Sep 2025 12:43:37 -0400 Subject: [PATCH 2/5] fix: linting errors --- pages/stack/smart-contracts.mdx | 1 + pages/stack/smart-contracts/bridge-recovery.mdx | 6 +++--- words.txt | 2 ++ 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/pages/stack/smart-contracts.mdx b/pages/stack/smart-contracts.mdx index 0b511b1a6..5d2fd6727 100644 --- a/pages/stack/smart-contracts.mdx +++ b/pages/stack/smart-contracts.mdx @@ -15,4 +15,5 @@ Documentation covering smart contracts overviews, upgrades using superchain-ops + diff --git a/pages/stack/smart-contracts/bridge-recovery.mdx b/pages/stack/smart-contracts/bridge-recovery.mdx index 3195f9a9b..3599e10ba 100644 --- a/pages/stack/smart-contracts/bridge-recovery.mdx +++ b/pages/stack/smart-contracts/bridge-recovery.mdx @@ -25,7 +25,7 @@ import { Steps, Callout } from 'nextra/components' This guide explains how certain types of tokens can be recovered from the Standard Bridge when they were meant to be sent to some other bridge instead. For instance, DAI does NOT use the Standard Bridge and instead utilizes a custom DAI bridge. Users who attempt to withdraw DAI via the Standard Bridge will see those tokens stuck in the Standard Bridge and would normally not be able to complete the withdrawal process. -Under certain conditions, it can still be possible to complete the withdrawal process (or deposit process, depending on the bridging action that was attempted) succesfully. This guide will walk you through the steps necessary to attempt a recovery. +Under certain conditions, it can still be possible to complete the withdrawal process (or deposit process, depending on the bridging action that was attempted) successfully. This guide will walk you through the steps necessary to attempt a recovery. ## Recovery principle @@ -82,7 +82,7 @@ Always begin by simulating the recovery process to verify that it will succeed. ### Creating the simulation networks -Currently, the best way to simulate this recovery is to use [Tenderly](tenderly.co). You will need to create two Virtual TestNets, one for the L1 chain and one for the L2 chain. Make sure that the parent chain for each network is correct before continuing. These networks will act as forks of the actual L1 and L2 chains and will allow you to fully simulate the recovery process. +Currently, the best way to simulate this recovery is to use [Tenderly](https://tenderly.co). You will need to create two Virtual TestNets, one for the L1 chain and one for the L2 chain. Make sure that the parent chain for each network is correct before continuing. These networks will act as forks of the actual L1 and L2 chains and will allow you to fully simulate the recovery process. ### Withdrawal recovery @@ -170,7 +170,7 @@ Once you are entirely confident that the recovery is possible, you may consider Deposit recovery is very similar to withdrawal recovery, although the steps and ordering differ slightly. Like with the withdrawal recovery simulation, you will need to create a virtual testnet for both the L1 and L2 chains. -#### Find the original deposit tranasction on L1 +#### Find the original deposit transaction on L1 First, find the transaction where you deposited the token on L1. This transaction will have emitted a `ERC20DepositInitiated` event in the `L1StandardBridge` contract as well as a `SentMessage` event in the `L1CrossDomainMessenger` contract. From the `SentMessage` event, extract the following parameters: diff --git a/words.txt b/words.txt index 55af6d53a..3de46722c 100644 --- a/words.txt +++ b/words.txt @@ -2,6 +2,7 @@ accountqueue ACCOUNTQUEUE accountslots ACCOUNTSLOTS +AAVE ACDC ADDI ADDIU @@ -401,6 +402,7 @@ subheaders subsecond SUBU Sunnyside +Superbridge superchain Superchain SUPERCHAIN From 1a2d174529b8fbffdd51d78844187e91e90582e6 Mon Sep 17 00:00:00 2001 From: Kelvin Fichter Date: Mon, 15 Sep 2025 12:43:58 -0400 Subject: [PATCH 3/5] Auto-fix: Update breadcrumbs, spelling dictionary and other automated fixes --- words.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/words.txt b/words.txt index 3de46722c..3eebefffc 100644 --- a/words.txt +++ b/words.txt @@ -1,8 +1,8 @@ +AAVE accountqueue ACCOUNTQUEUE accountslots ACCOUNTSLOTS -AAVE ACDC ADDI ADDIU @@ -406,8 +406,8 @@ Superbridge superchain Superchain SUPERCHAIN -superchainerc Superchain's +superchainerc Superlend Superloans Superscan From 7cc3f1b9bbfd6f1987f939d9254b9eb7d226ac9b Mon Sep 17 00:00:00 2001 From: smartcontracts Date: Mon, 15 Sep 2025 13:45:21 -0400 Subject: [PATCH 4/5] Update pages/stack/smart-contracts/bridge-recovery.mdx Co-authored-by: Matt Solomon --- pages/stack/smart-contracts/bridge-recovery.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/smart-contracts/bridge-recovery.mdx b/pages/stack/smart-contracts/bridge-recovery.mdx index 3599e10ba..01d3c6fcf 100644 --- a/pages/stack/smart-contracts/bridge-recovery.mdx +++ b/pages/stack/smart-contracts/bridge-recovery.mdx @@ -68,7 +68,7 @@ The basic process for recovering these stuck tokens is to deposit or withdraw th ### Example recovery 1. User deposits 100 DAI from Ethereum to OP Mainnet via the Standard Bridge. This causes the Standard Bridge to pull 100 DAI tokens into its account on L1. The Standard Bridge now has a balance of 100 DAI tokens on L1. -1. At this point, the Standard Bridge has 0 DAI tokens in its account. DAI does not officially recognize the Standard Bridge and therefore does not dynamically mint the liquidity on L2 required to execute the deposit. User never receives the deposit on L2 and the deposit is "stuck" waiting for this liquidity. +1. At this point, the Standard Bridge on L2 has 0 DAI tokens in its account. DAI does not officially recognize the Standard Bridge and therefore does not dynamically mint the liquidity on L2 required to execute the deposit. User never receives the deposit on L2 and the deposit is "stuck" waiting for this liquidity. 1. User collects 100 DAI on OP Mainnet. 1. User withdraws 100 DAI from OP Mainnet to Ethereum via the Standard Bridge. This causes the Standard Bridge to pull 100 DAI tokens into its account on L2. The Standard Bridge now has a balance of 100 DAI tokens on L2. 1. User can now "replay" the original deposit on L2. The deposit will now succeed because the Standard Bridge has sufficient liquidity (100 DAI) to complete the deposit. User receives 100 DAI on L2 and the Standard Bridge again has a balance of 0 DAI tokens on L2. From de6357b6892f85c41870f9ba25cada35ac36d620 Mon Sep 17 00:00:00 2001 From: smartcontracts Date: Mon, 15 Sep 2025 13:45:30 -0400 Subject: [PATCH 5/5] Update pages/stack/smart-contracts/bridge-recovery.mdx Co-authored-by: Matt Solomon --- pages/stack/smart-contracts/bridge-recovery.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/smart-contracts/bridge-recovery.mdx b/pages/stack/smart-contracts/bridge-recovery.mdx index 01d3c6fcf..04a63d7d4 100644 --- a/pages/stack/smart-contracts/bridge-recovery.mdx +++ b/pages/stack/smart-contracts/bridge-recovery.mdx @@ -71,7 +71,7 @@ The basic process for recovering these stuck tokens is to deposit or withdraw th 1. At this point, the Standard Bridge on L2 has 0 DAI tokens in its account. DAI does not officially recognize the Standard Bridge and therefore does not dynamically mint the liquidity on L2 required to execute the deposit. User never receives the deposit on L2 and the deposit is "stuck" waiting for this liquidity. 1. User collects 100 DAI on OP Mainnet. 1. User withdraws 100 DAI from OP Mainnet to Ethereum via the Standard Bridge. This causes the Standard Bridge to pull 100 DAI tokens into its account on L2. The Standard Bridge now has a balance of 100 DAI tokens on L2. -1. User can now "replay" the original deposit on L2. The deposit will now succeed because the Standard Bridge has sufficient liquidity (100 DAI) to complete the deposit. User receives 100 DAI on L2 and the Standard Bridge again has a balance of 0 DAI tokens on L2. +1. User can now "replay" the original deposit on L2. The deposit will now succeed because the L2 Standard Bridge has sufficient liquidity (100 DAI) to complete the deposit. User receives 100 DAI on L2 and the Standard Bridge again has a balance of 0 DAI tokens on L2. 1. After the 7 day withdrawal period, user finalizes their withdrawal of 100 DAI. The user can successfully finalize this withdrawal because the Standard Bridge has a 100 DAI balance on L1 from the original deposit. User is able to retrieve all of the DAI from the bridge on both ends. Note that this recovery process is the same in both directions. Failed withdrawals are resolved by depositing an equal amount of the L1 token into the Standard Bridge on L1. Failed deposits are resolved by withdrawing an equal amount of the L2 token from the Standard Bridge on L2.