feat: bridge recovery #1744
feat: bridge recovery #1744
Conversation
✅ Deploy Preview for docs-optimism ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
|
||
| 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 |
There was a problem hiding this comment.
A sequence diagram in mermaid could be useful here
|
|
||
| * `_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`). |
There was a problem hiding this comment.
Feels misleading since this address is "typical" only for OP Mainnet
| 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`. |
There was a problem hiding this comment.
Is LogNote just what tenderly called undecoded logs?
There was a problem hiding this comment.
This particular one, apparently. I have no idea why.
There was a problem hiding this comment.
Presumably based on this, strange though: https://github.com/dapphub/ds-note/blob/832591b2d7dfb13dd513a72d0ff5a64c23b4e327/src/note.sol#L19-L26. Perhaps related to the fact that you saw this using DAI, which probably has those LogNotes somewhere
| 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. |
There was a problem hiding this comment.
If it's not decoded how is there a field called usr?
There was a problem hiding this comment.
Yeah I have no idea, this is just how tenderly decodes it for some reason
| #### 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. |
There was a problem hiding this comment.
Should we also suggest testing with 1 token in production before using the full amount?
|
|
||
| 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. |
There was a problem hiding this comment.
Get in contact with who? Should we delete this todo?
There was a problem hiding this comment.
I feel like it'd be nice if there were some small task force of people willing to help out in these cases. I don't want to create an overwhelming responsibility here but this seems rare (only happened twice, as far as we know).
|
|
||
| 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. |
| ## 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?. |
There was a problem hiding this comment.
probably easiest to just delete this for now, there are various other pages in the docs where people may want to contact us for assistance, so people can contact us via whatever they normally do
|
|
||
| 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 |
There was a problem hiding this comment.
Thoughts on including some suggested checks people can do to prevent this mistake in the first place?
Co-authored-by: Matt Solomon <[email protected]>
Co-authored-by: Matt Solomon <[email protected]>
Description
Adds a page explaining how to recover tokens that have been sent to the Standard Bridge when they should've been sent via some other bridge.