chore: add details on migrate to native#194
Conversation
-------- Co-authored-by: Hex <165055168+hexshire@users.noreply.github.com> Co-authored-by: gotzenx <78360669+gotzenx@users.noreply.github.com>
Co-authored-by: Disco <131301107+0xDiscotech@users.noreply.github.com> Signed-off-by: Hex <165055168+hexshire@users.noreply.github.com>
| 1. Transfers the ownership of the Bridged USDC contract to the `_owner` | ||
| 2. Transfer the admin rights of the Bridged USDC proxy to the `msg.sender` (a.k.a. `roleCaller`) | ||
| - L1 Sequence (MUST wait at least 7 days to execute this sequence). | ||
| 1. Call `setBurnAmount` |
There was a problem hiding this comment.
Does setBurnAmount get invoked automatically by a message sent from the L2 > L1 bridge contract or do we need to invoke this manually after the 7 day waiting period? If it needs to be invoked manually, which address is allowed to invoke this and how is the 7 day waiting period being enforced?
There was a problem hiding this comment.
No, is not invoked automatically. Any address can invoke it since the message is generated from the L2Adapter and the L1Adapter verify its origin. The waiting period is enforced by the bridge.
I will add this to the readme as well. Thanks.
README.md
Outdated
| 1. Effects | ||
| 1. Burns the USDC locked in the adapter based on the `burnAmount` variable or the contract balance. | ||
| 2. Reset `burnAmount` and `burnCaller` variables, to avoid calling the function more than once. | ||
| 3. `receiveWithdrawLockedFundsPostMigration` is enabled, this function handles the messages that were in-flight during the migration and were sent back from L2 by transferring the locked USDC to the user. |
There was a problem hiding this comment.
How are in-flight deposits (L1 > L2 bridged USDC that hasn't been claimed on the L2) handled after the migration has been initiated? It would be nice to add another section here to describe in detail how both in-flight deposits and withdrawals are handled within this system.
There was a problem hiding this comment.
How are in-flight deposits (L1 > L2 bridged USDC that hasn't been claimed on the L2) handled after the migration has been initiated?
After the migration is started the incoming message on the L2 are sent back to the spender (the address that sent the message on L1). This is the part of the code that does it
opUSDC/src/contracts/L2OpUSDCBridgeAdapter.sol
Lines 213 to 220 in 88b2ece
There was a problem hiding this comment.
It would be nice to add another section here to describe in detail how both in-flight deposits and withdrawals are handled within this system.
Yes, what do you think about adding some flow diagrams.
There was a problem hiding this comment.
Ahh okay, makes sense! Yes, that would be great if we could add some flow diagrams.
| Enables `setBurnAmount` that is only callable by the Linked Adapter. | ||
| 3. Sends message to call `receiveMigrateToNative` on destination chain. | ||
| 3. ⚠️ Note: Once this step is executed the bridges can’t be unpaused. | ||
| 2. Call `receiveMigrateToNative` on L2 (Automatically relayed) |
There was a problem hiding this comment.
Can we add some detail or a link to OP documentation for how messaging between the contracts works?
Signed-off-by: Hex <165055168+hexshire@users.noreply.github.com>
Signed-off-by: Hex <165055168+hexshire@users.noreply.github.com>
Signed-off-by: Hex <165055168+hexshire@users.noreply.github.com>
Signed-off-by: Hex <165055168+hexshire@users.noreply.github.com>
3 participants
No description provided.