From 4bde6ceb701d4b8401f8da7390c5149759b49ef3 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Wed, 22 Jan 2025 16:53:45 -0600 Subject: [PATCH 1/7] Update the `SuperchainERC20` page --- pages/stack/interop/superchain-erc20.mdx | 136 ++++++++++++++--------- words.txt | 3 +- 2 files changed, 84 insertions(+), 55 deletions(-) diff --git a/pages/stack/interop/superchain-erc20.mdx b/pages/stack/interop/superchain-erc20.mdx index 2e2f652e4..3762762f4 100644 --- a/pages/stack/interop/superchain-erc20.mdx +++ b/pages/stack/interop/superchain-erc20.mdx @@ -6,94 +6,124 @@ description: Learn about the basic details of the SuperchainERC20 implementation import { Callout } from 'nextra/components' -# SuperchainERC20 +import { InteropCallout } from '@/components/WipCallout' - - Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information. - + + +# SuperchainERC20 -`SuperchainERC20` is an implementation of [ERC-7802](https://ethereum-magicians.org/t/erc-7802-crosschain-token-interface/21508) designed to enable asset interoperability in the Superchain. -Asset interoperability allows for tokens to securely move across chains without asset wrapping or liquidity pools for maximal capital efficiency, thus unifying liquidity and simplifying the user experience. +[`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) is an implementation of [ERC-7802](https://ethereum-magicians.org/t/erc-7802-crosschain-token-interface/21508) designed to enable asset interoperability in the Superchain. +Asset interoperability allows for tokens to securely move across chains without asset wrapping or liquidity pools for maximum capital efficiency, thus unifying liquidity and simplifying the user experience. Additional features: -* **Simplified deployments**: 0-infrastructure cost to make your token cross-chain. Provides a consistent, unified implementation for tokens across all Superchain-compatible networks and a common cross-chain interface for the EVM ecosystem at large. -* **Permissionless propagation**: Easily clone an existing token contract to a new OP Stack chain using `create2` without requiring the original owner, which enables movement of assets to the new chain once Interop goes live. Importantly, permissionless propagation retains the integrity of the original owner on the contract and preserves security but proliferates the contract's availability to new chains. +* **Simplified deployments**: Zero infrastructure cost to make your token cross-chain. + Provides a consistent, unified implementation for tokens across all Superchain-compatible networks and a common cross-chain interface for the EVM ecosystem at large. * **Common standard**: Implements ERC-7802, a unified interface that can be used across all of Ethereum to enable cross-chain mint/burn functionality. ## How it works -`SuperchainERC20` facilitates secure token transfers between chains in the Superchain networks via native burning and minting. +[`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) and [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) work together to allow ERC-20 tokens to be transferred from one chain to the other. -* **Token Burning**: Initiating message where token is **burned** on the source chain. A user initiates a transfer of token from one blockchain to another and specifies the recipient wallet address on the destination chain. A specified amount of token is burned on the source chain. -* **Token Minting**: Executing message where token is **minted** on the destination chain. The specified amount of token is minted on the destination chain directly to the recipient wallet address. - -An important thing to note is using `crosschainBurn` and `crosschainMint` on the `SuperchainERC20` to move your asset across the Superchain only affects which chain your asset is located on and does not change the overall supply of the token. This keeps the token's total amount the same across all networks, ensuring its value stays stable during the move and that the `SuperchainERC20` retains a unified, global supply count. +The initiating message burns tokens on the source chain. +The executing message then mints them on the destination chain. ```mermaid sequenceDiagram - box rgba(255, 4, 32, 0.1) ChainA - participant User-chainA - participant SuperchainERC20-chainA - participant SuperchainERC20Bridge-chainA - end - box rgba(248, 61, 213, 0.1) ChainB - participant SuperchainERC20Bridge-chainB - participant SuperchainERC20-chainB - participant User-chainB - end - - - User-chainA->>SuperchainERC20-chainA: Initiate token transfer - SuperchainERC20-chainA->>SuperchainERC20Bridge-chainA: Bridge to chainB - SuperchainERC20Bridge-chainA->>SuperchainERC20-chainA: Burn tokens - SuperchainERC20Bridge-chainA-->>SuperchainERC20Bridge-chainA: Emit cross-chain event - SuperchainERC20Bridge-chainB-->>SuperchainERC20Bridge-chainB: Validates message - SuperchainERC20Bridge-chainB-->>SuperchainERC20-chainB: Mint tokens - SuperchainERC20-chainB->>User-chainB: User receives tokens + box rgba(0,0,0,0.1) Source Chain + participant src-erc20 as ERC201 + participant src-bridge as Bridge + end + actor user as User + box rgba(0,0,0,0.1) Destination Chain + participant dst-l2Xl2 as L2ToL2 + participant dst-bridge as Bridge + participant dst-erc20 as ERC20 + end + rect rgba(0,0,0,0.1) + note over src-erc20, dst-l2Xl2: Initiating Message + user->>src-bridge: 1. Move n tokens + src-bridge->>src-erc20: 2. Burn n tokens + src-bridge->>dst-l2Xl2: 3. Relay n tokens to user + end + rect rgba(0,0,0,0.1) + note over user,dst-erc20: Executing message + user->>dst-l2Xl2: 4. Relay the message + dst-l2Xl2->>dst-bridge: 4. Relay the message + dst-bridge->>dst-erc20: 5. Mint n tokens to user + end ``` -This diagram illustrates the process where tokens are burned on the source chain and minted on the destination chain, enabling seamless cross-chain transfers without the need for asset wrapping or liquidity pools. +#### Initiating message -## Major components +1. The user (or a contract) calls [`SuperchainTokenBridge.sendERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol#L52-L78). -* **Token Contract**: implements `SuperchainERC20` with bridging functionality. -* **Bridging Functions**: using methods like `sendERC20` and `relayERC20` for cross-chain transfers. +2. The token bridge calls [`SuperchainERC20.crosschainBurn`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol#L37-L46) to burn those tokens on the source chain. -## Comparison to other token implementations +3. The source token bridge calls [`SuperchainTokenBridge.relayERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol#L80-L97) on the destination token bridge. + This call is relayed using [`L2ToL2CrossDomainMessenger`](./message-passing). -`SuperchainERC20` differs from other token implementations in its focus and implementation: +#### Executing message -* `SuperchainERC20` implements ERC-7802, which provides a minimal crosschain mint/burn interface designed to be a common pattern for the EVM ecosystem. -* `SuperchainERC20` shares trust assumptions across all chains in the Superchain, such that custom assumptions around security and latency are not required to account for when executing transfers. +4. The user sends an executing message to [`L2ToL2CrossDomainMessenger`](./message-passing) to relay the message. - - Projects moving from other token implementations may need to adapt to the `SuperchainERC20` specification. - +5. The destination token bridge calls [`SuperchainERC20.crosschainMint`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol#L26-L35) to mint tokens for the user/contract that called `SuperchainTokenBridge.sendERC20` originally. -## Consistent addresses across chains +## Requirements -It is best to use predefined addresses: Assign and verify the same address for each `SuperchainERC20` instance on every chain. Predefined addresses reduce deployment conflicts and ensure tokens are accurately recognized across chains. Otherwise, the `SuperchainERC20Bridge` would need a way to verify if the tokens they mint on destination, correspond to the tokens that were burned on source. +Application developers must do two things to make their tokens `SuperchainERC20` compatible. +Doing this setup now ensures that tokens benefit from interop (once it is available). -Consider using `Create2Deployer` or one of our [predeploys](https://specs.optimism.io/interop/predeploys.html) to ensure this. +* Grant permission to `SuperchainTokenBridge` (address `0x4200000000000000000000000000000000000028`) to call `crosschainMint` and `crosschainBurn`. + [`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) already does this for you. -## Implementation details +* Deploy the ERC-20 contract at the same address on every chain in the Superchain. + This is easiest when using [`create2`](https://book.getfoundry.sh/tutorials/create2-tutorial). -Application developers must do two things to make their tokens `SuperchainERC20` compatible. Doing this setup now ensures that tokens can benefit from Interop once the Interop upgrade happens. + + To do this securely you must either write the deployer in such a way that only a specific trusted ERC-20 contract, such as `SuperchainERC20`, can be deployed through it, + or call the contract with `CREATE2` directly from an EOA you control. + This is critical because if somebody can deploy a different ERC-20 contract at the same address, on any superchain network, they can mint themselves as many tokens as they'd like and then bridge them to the network where the original ERC-20 contract is located. + -1. Permission only `SuperchainERC20Bridge` to call `crosschainMint` and `crosschainBurn`. -2. Deployment at same address on every chain in the Superchain using `create2` function. +{/* -For now, application developers should view `SuperchainERC20`as ERC20 tokens with additional built-in functions that allow cross-chain asset movement that will be enabled once Interop goes live. +Add this after the tutorial is written For step-by-step information on implementing SuperchainERC20, see [Deploy assets using SuperchainERC20](/stack/interop/assets/deploy-superchain-erc20) - - To enable asset interoperability, `SuperchainERC20` must give access to the address where the future `SuperchainERC20Bridge` will live. +*/} + +## Comparison to other token implementations + +`SuperchainERC20` differs from other token implementations in its focus and implementation: + +* `SuperchainERC20` implements ERC-7802, which provides a minimal crosschain mint/burn interface designed to be a common pattern for the EVM ecosystem. +* `SuperchainERC20` uses the shared trust assumptions of the Superchain. + Traffic originating in *any* chain is trusted, because they are all managed by The Optimism Foundation. + + + Projects moving from other token implementations may need to adapt to the `SuperchainERC20` specification. +## FAQ + +### What happens if I bridge to a chain that does not have the ERC-20 contract? + +The initiating message will successfully burn the tokens on the source chain. +However, the executing message will try to call `crosschainMint` on a non-existent contract and fail. +Once a `SuperchainERC20` contract is properly deployed at the destination chain, you can attempt the executing message again and get your tokens. + ## Next steps + * Watch the [ERC20 to SuperchainERC20 video walkthrough](https://www.youtube.com/watch?v=Gb8glkyBdBA) to learn how to modify an existing ERC20 contract to make it interoperable within the Superchain. * Explore the [SuperchainERC20 specifications](https://specs.optimism.io/interop/token-bridging.html) for in-depth implementation details. * Check out the [SuperchainERC20 starter kit](https://github.com/ethereum-optimism/superchainerc20-starter) to get started with implementation. + +{/* + +Add this back when the tutorial is written. + * Review the [Deploy SuperchainERC20 tutorial](../assets/deploy-superchain-erc20) to learn how to deploy a SuperchainERC20. + +*/} diff --git a/words.txt b/words.txt index fc73c26e8..68e21d58b 100644 --- a/words.txt +++ b/words.txt @@ -154,7 +154,6 @@ Inator inator INFLUXDBV influxdbv -interchain IPCDISABLE ipcdisable ipcfile @@ -289,6 +288,7 @@ pricelimit productionize productionized Protip +providng Proxied Proxyd proxyd @@ -360,7 +360,6 @@ Superchain superchain Superchain's Superchainerc -superchainerc Superchains Superscan Supersim From fbdaea02af5113c00f1e3a2f91b82a3258c5f0f5 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Thu, 23 Jan 2025 08:02:30 -0600 Subject: [PATCH 2/7] Most @zainbacchus comments --- pages/stack/interop/superchain-erc20.mdx | 25 ++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/pages/stack/interop/superchain-erc20.mdx b/pages/stack/interop/superchain-erc20.mdx index 3762762f4..65d6c399e 100644 --- a/pages/stack/interop/superchain-erc20.mdx +++ b/pages/stack/interop/superchain-erc20.mdx @@ -29,16 +29,25 @@ The initiating message burns tokens on the source chain. The executing message then mints them on the destination chain. ```mermaid + +%%{ + init: { + "sequence": { + "wrap": true + } + } +}%% + sequenceDiagram box rgba(0,0,0,0.1) Source Chain - participant src-erc20 as ERC201 - participant src-bridge as Bridge + participant src-erc20 as SuperchainERC20 + participant src-bridge as SuperchainTokenBridge end actor user as User box rgba(0,0,0,0.1) Destination Chain - participant dst-l2Xl2 as L2ToL2 - participant dst-bridge as Bridge - participant dst-erc20 as ERC20 + participant dst-l2Xl2 as L2ToL2CrossDomainMessenger + participant dst-bridge as SuperchainTokenBridge + participant dst-erc20 as SuperchainERC20 end rect rgba(0,0,0,0.1) note over src-erc20, dst-l2Xl2: Initiating Message @@ -54,7 +63,7 @@ sequenceDiagram end ``` -#### Initiating message +#### Initiating message (source chain) 1. The user (or a contract) calls [`SuperchainTokenBridge.sendERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol#L52-L78). @@ -63,9 +72,9 @@ sequenceDiagram 3. The source token bridge calls [`SuperchainTokenBridge.relayERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol#L80-L97) on the destination token bridge. This call is relayed using [`L2ToL2CrossDomainMessenger`](./message-passing). -#### Executing message +#### Executing message (destination chain) -4. The user sends an executing message to [`L2ToL2CrossDomainMessenger`](./message-passing) to relay the message. +4. The user, or a relayer, sends an executing message to [`L2ToL2CrossDomainMessenger`](./message-passing) to relay the message. 5. The destination token bridge calls [`SuperchainERC20.crosschainMint`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol#L26-L35) to mint tokens for the user/contract that called `SuperchainTokenBridge.sendERC20` originally. From 3a467ebf0f4276012b4886e8109cc263648b8b10 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Thu, 23 Jan 2025 10:56:54 -0600 Subject: [PATCH 3/7] Last @zainbacchus comments (for now, anyway) --- pages/stack/interop/superchain-erc20.mdx | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/pages/stack/interop/superchain-erc20.mdx b/pages/stack/interop/superchain-erc20.mdx index 65d6c399e..6579dea3c 100644 --- a/pages/stack/interop/superchain-erc20.mdx +++ b/pages/stack/interop/superchain-erc20.mdx @@ -13,7 +13,9 @@ import { InteropCallout } from '@/components/WipCallout' # SuperchainERC20 [`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) is an implementation of [ERC-7802](https://ethereum-magicians.org/t/erc-7802-crosschain-token-interface/21508) designed to enable asset interoperability in the Superchain. -Asset interoperability allows for tokens to securely move across chains without asset wrapping or liquidity pools for maximum capital efficiency, thus unifying liquidity and simplifying the user experience. +Asset interoperability allows tokens to move securely in the Superchain by burning tokens on the source chain and minting the same number of tokens that were burned on the destination chain. +Asset interoperability solves the issues of liquidity fragmentation and poor user experiences caused by asset wrapping or liquidity pools. +Instead, assets essentially teleport from one chain in the Superchain to another, providing users with a secure and capital-efficient way to transact within the Superchain. Additional features: @@ -84,7 +86,13 @@ Application developers must do two things to make their tokens `SuperchainERC20` Doing this setup now ensures that tokens benefit from interop (once it is available). * Grant permission to `SuperchainTokenBridge` (address `0x4200000000000000000000000000000000000028`) to call `crosschainMint` and `crosschainBurn`. - [`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) already does this for you. + If you are using [`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) this is already done for you. + + {/* + + Link to tutorial here + + */} * Deploy the ERC-20 contract at the same address on every chain in the Superchain. This is easiest when using [`create2`](https://book.getfoundry.sh/tutorials/create2-tutorial). @@ -109,7 +117,7 @@ For step-by-step information on implementing SuperchainERC20, see [Deploy assets * `SuperchainERC20` implements ERC-7802, which provides a minimal crosschain mint/burn interface designed to be a common pattern for the EVM ecosystem. * `SuperchainERC20` uses the shared trust assumptions of the Superchain. - Traffic originating in *any* chain is trusted, because they are all managed by The Optimism Foundation. + Traffic originating in any of the Superchain's chains is trusted, because all those chains [share the same security standard](https://docs.optimism.io/superchain/standard-configuration). Projects moving from other token implementations may need to adapt to the `SuperchainERC20` specification. From 50bd0f9954b5f5dc0514a9fc60e626005cd127d2 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Thu, 23 Jan 2025 11:04:49 -0600 Subject: [PATCH 4/7] Unified comments --- pages/stack/interop/superchain-erc20.mdx | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/pages/stack/interop/superchain-erc20.mdx b/pages/stack/interop/superchain-erc20.mdx index 6579dea3c..336692a15 100644 --- a/pages/stack/interop/superchain-erc20.mdx +++ b/pages/stack/interop/superchain-erc20.mdx @@ -88,11 +88,13 @@ Doing this setup now ensures that tokens benefit from interop (once it is availa * Grant permission to `SuperchainTokenBridge` (address `0x4200000000000000000000000000000000000028`) to call `crosschainMint` and `crosschainBurn`. If you are using [`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) this is already done for you. - {/* - - Link to tutorial here - - */} + {/* + + Add this after the tutorial is written + + For step-by-step information on implementing SuperchainERC20, see [Deploy assets using SuperchainERC20](/stack/interop/assets/deploy-superchain-erc20) + + */} * Deploy the ERC-20 contract at the same address on every chain in the Superchain. This is easiest when using [`create2`](https://book.getfoundry.sh/tutorials/create2-tutorial). @@ -103,14 +105,6 @@ Doing this setup now ensures that tokens benefit from interop (once it is availa This is critical because if somebody can deploy a different ERC-20 contract at the same address, on any superchain network, they can mint themselves as many tokens as they'd like and then bridge them to the network where the original ERC-20 contract is located. -{/* - -Add this after the tutorial is written - -For step-by-step information on implementing SuperchainERC20, see [Deploy assets using SuperchainERC20](/stack/interop/assets/deploy-superchain-erc20) - -*/} - ## Comparison to other token implementations `SuperchainERC20` differs from other token implementations in its focus and implementation: From 6e8dc2e776ca305dddb1131c556fecc2e1e7d9bd Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Thu, 23 Jan 2025 15:23:21 -0600 Subject: [PATCH 5/7] Apply suggestions from @krofax Co-authored-by: Blessing Krofegha --- pages/stack/interop/superchain-erc20.mdx | 40 +++++++++++++----------- 1 file changed, 21 insertions(+), 19 deletions(-) diff --git a/pages/stack/interop/superchain-erc20.mdx b/pages/stack/interop/superchain-erc20.mdx index 336692a15..8d32614f6 100644 --- a/pages/stack/interop/superchain-erc20.mdx +++ b/pages/stack/interop/superchain-erc20.mdx @@ -12,10 +12,12 @@ import { InteropCallout } from '@/components/WipCallout' # SuperchainERC20 -[`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) is an implementation of [ERC-7802](https://ethereum-magicians.org/t/erc-7802-crosschain-token-interface/21508) designed to enable asset interoperability in the Superchain. -Asset interoperability allows tokens to move securely in the Superchain by burning tokens on the source chain and minting the same number of tokens that were burned on the destination chain. -Asset interoperability solves the issues of liquidity fragmentation and poor user experiences caused by asset wrapping or liquidity pools. -Instead, assets essentially teleport from one chain in the Superchain to another, providing users with a secure and capital-efficient way to transact within the Superchain. +The [`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) contract implements [ERC-7802](https://ethereum-magicians.org/t/erc-7802-crosschain-token-interface/21508) to enable asset interoperability within the Superchain. + +Asset interoperability allows tokens to move securely across the Superchain by burning tokens on the source chain and minting an equivalent amount on the destination chain. This approach addresses issues such as liquidity fragmentation and poor user experiences caused by asset wrapping or reliance on liquidity pools. + +Instead of wrapping assets, this mechanism effectively "teleports" tokens between chains in the Superchain. It provides users with a secure and capital-efficient method for transacting across chains. + Additional features: @@ -82,8 +84,8 @@ sequenceDiagram ## Requirements -Application developers must do two things to make their tokens `SuperchainERC20` compatible. -Doing this setup now ensures that tokens benefit from interop (once it is available). +Application developers must complete two steps to make their tokens compatible with `SuperchainERC20`. +Setting this up in advance ensures tokens will benefit from interop when it becomes available. * Grant permission to `SuperchainTokenBridge` (address `0x4200000000000000000000000000000000000028`) to call `crosschainMint` and `crosschainBurn`. If you are using [`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) this is already done for you. @@ -99,19 +101,20 @@ Doing this setup now ensures that tokens benefit from interop (once it is availa * Deploy the ERC-20 contract at the same address on every chain in the Superchain. This is easiest when using [`create2`](https://book.getfoundry.sh/tutorials/create2-tutorial). - - To do this securely you must either write the deployer in such a way that only a specific trusted ERC-20 contract, such as `SuperchainERC20`, can be deployed through it, - or call the contract with `CREATE2` directly from an EOA you control. - This is critical because if somebody can deploy a different ERC-20 contract at the same address, on any superchain network, they can mint themselves as many tokens as they'd like and then bridge them to the network where the original ERC-20 contract is located. - + +To ensure security, you must either design the deployer to allow only a specific trusted ERC-20 contract, such as `SuperchainERC20`, to be deployed through it, or call `CREATE2` to deploy the contract directly from an EOA you control. + +This precaution is critical because if an unauthorized ERC-20 contract is deployed at the same address on any Superchain network, it could allow malicious actors to mint unlimited tokens and bridge them to the network where the original ERC-20 contract resides. + + ## Comparison to other token implementations -`SuperchainERC20` differs from other token implementations in its focus and implementation: +`SuperchainERC20` differs from other token implementations in both focus and design: + +* It implements `ERC-7802`, a minimal cross-chain mint/burn interface designed to establish a common standard across the EVM ecosystem. +* It relies on the shared trust assumptions of the Superchain. All traffic originating from any chain within the Superchain is trusted because these chains [share the same security standard](/superchain/standard-configuration). -* `SuperchainERC20` implements ERC-7802, which provides a minimal crosschain mint/burn interface designed to be a common pattern for the EVM ecosystem. -* `SuperchainERC20` uses the shared trust assumptions of the Superchain. - Traffic originating in any of the Superchain's chains is trusted, because all those chains [share the same security standard](https://docs.optimism.io/superchain/standard-configuration). Projects moving from other token implementations may need to adapt to the `SuperchainERC20` specification. @@ -121,10 +124,9 @@ Doing this setup now ensures that tokens benefit from interop (once it is availa ### What happens if I bridge to a chain that does not have the ERC-20 contract? -The initiating message will successfully burn the tokens on the source chain. -However, the executing message will try to call `crosschainMint` on a non-existent contract and fail. -Once a `SuperchainERC20` contract is properly deployed at the destination chain, you can attempt the executing message again and get your tokens. - +The initiating message will successfully burn the tokens on the source chain. +However, the executing message will fail because it attempts to call `crosschainMint` on a non-existent contract. +Once a `SuperchainERC20` contract is properly deployed on the destination chain, you can retry the executing message to retrieve your tokens. ## Next steps * Watch the [ERC20 to SuperchainERC20 video walkthrough](https://www.youtube.com/watch?v=Gb8glkyBdBA) to learn how to modify an existing ERC20 contract to make it interoperable within the Superchain. From e2f3ff3364ed7ce98a9033f08d53676cbbdac885 Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Thu, 23 Jan 2025 15:27:43 -0600 Subject: [PATCH 6/7] Update pages/stack/interop/superchain-erc20.mdx Co-authored-by: Blessing Krofegha --- pages/stack/interop/superchain-erc20.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/interop/superchain-erc20.mdx b/pages/stack/interop/superchain-erc20.mdx index 8d32614f6..afc1c2abc 100644 --- a/pages/stack/interop/superchain-erc20.mdx +++ b/pages/stack/interop/superchain-erc20.mdx @@ -94,7 +94,7 @@ Setting this up in advance ensures tokens will benefit from interop when it beco Add this after the tutorial is written - For step-by-step information on implementing SuperchainERC20, see [Deploy assets using SuperchainERC20](/stack/interop/assets/deploy-superchain-erc20) +For detailed, step-by-step instructions on implementing SuperchainERC20, refer to [Deploy assets using SuperchainERC20](/stack/interop/assets/deploy-superchain-erc20). */} From a573008e88117dfd0a41182ad19f83b5f2e5286a Mon Sep 17 00:00:00 2001 From: Ori Pomerantz Date: Thu, 23 Jan 2025 17:37:44 -0600 Subject: [PATCH 7/7] Fixed --- .../chain-operators/configuration/batcher.mdx | 98 +++++++++---------- pages/stack/interop/op-supervisor.mdx | 29 +++--- pages/stack/interop/superchain-erc20.mdx | 22 ++--- words.txt | 12 +-- 4 files changed, 79 insertions(+), 82 deletions(-) diff --git a/pages/builders/chain-operators/configuration/batcher.mdx b/pages/builders/chain-operators/configuration/batcher.mdx index 5d23e5fef..54db1a3d4 100644 --- a/pages/builders/chain-operators/configuration/batcher.mdx +++ b/pages/builders/chain-operators/configuration/batcher.mdx @@ -59,7 +59,7 @@ You can use [this calculator](https://docs.google.com/spreadsheets/d/12VIiXHaVEC ### active-sequencer-check-duration -The duration between checks to determine the active sequencer endpoint. The +The duration between checks to determine the active sequencer endpoint. The default value is `2m0s`. @@ -68,7 +68,7 @@ default value is `2m0s`. `OP_BATCHER_ACTIVE_SEQUENCER_CHECK_DURATION=2m0s` -### altda.da-server +### altda.da-server HTTP address of a DA Server. @@ -92,7 +92,7 @@ value is `false`. ### altda.enabled Enable Alt-DA mode -Alt-DA Mode is a Beta feature of the MIT licensed OP Stack. +Alt-DA Mode is a Beta feature of the MIT licensed OP Stack. While it has received initial review from core contributors, it is still undergoing testing, and may have bugs or other issues. The default value is `false`. @@ -145,7 +145,7 @@ Verify input data matches the commitments from the DA storage service. ### approx-compr-ratio -The approximate compression ratio (`<=1.0`). Only relevant for ratio +The approximate compression ratio (`<=1.0`). Only relevant for ratio compressor. The default value is `0.6`. @@ -167,9 +167,9 @@ is `0` for `SingularBatch`. ### check-recent-txs-depth -Indicates how many blocks back the batcher should look during startup for a -recent batch tx on L1. This can speed up waiting for node sync. It should be -set to the verifier confirmation depth of the sequencer (e.g. 4). The default +Indicates how many blocks back the batcher should look during startup for a +recent batch tx on L1. This can speed up waiting for node sync. It should be +set to the verifier confirmation depth of the sequencer (e.g. 4). The default value is `0`. @@ -180,7 +180,7 @@ value is `0`. ### compression-algo -The compression algorithm to use. Valid options: zlib, brotli, brotli-9, +The compression algorithm to use. Valid options: zlib, brotli, brotli-9, brotli-10, brotli-11. The default value is `zlib`. @@ -191,7 +191,7 @@ brotli-10, brotli-11. The default value is `zlib`. ### compressor -The type of compressor. Valid options: none, ratio, shadow. The default value +The type of compressor. Valid options: none, ratio, shadow. The default value is `shadow`. @@ -202,7 +202,7 @@ is `shadow`. ### data-availability-type -The data availability type to use for submitting batches to the L1. Valid +The data availability type to use for submitting batches to the L1. Valid options: calldata, blobs. The default value is `calldata`. @@ -245,8 +245,8 @@ HTTP provider URL for L1. ### l2-eth-rpc -HTTP provider URL for L2 execution engine. A comma-separated list enables the -active L2 endpoint provider. Such a list needs to match the number of +HTTP provider URL for L2 execution engine. A comma-separated list enables the +active L2 endpoint provider. Such a list needs to match the number of rollup-rpcs provided. @@ -308,7 +308,7 @@ Maximum number of blocks to add to a span batch. **Default is 0 (no maximum)**. ### max-channel-duration -The maximum duration of L1-blocks to keep a channel open. 0 to disable. The +The maximum duration of L1-blocks to keep a channel open. 0 to disable. The default value is `0`. @@ -319,7 +319,7 @@ default value is `0`. ### max-l1-tx-size-bytes -The maximum size of a batch tx submitted to L1. Ignored for blobs, where max +The maximum size of a batch tx submitted to L1. Ignored for blobs, where max blob size will be used. The default value is `120000`. @@ -391,7 +391,7 @@ Timeout for all network operations. The default value is `10s`. ### num-confirmations -Number of confirmations which we will wait after sending a transaction. The +Number of confirmations which we will wait after sending a transaction. The default value is `10`. @@ -412,7 +412,7 @@ HTTP address of a DA Server. ### altda.da-service -Use DA service type where commitments are generated by altda server. The +Use DA service type where commitments are generated by altda server. The default value is `false`. @@ -433,7 +433,7 @@ Enable altda mode. The default value is `false`. ### altda.verify-on-read -Verify input data matches the commitments from the DA storage service. The +Verify input data matches the commitments from the DA storage service. The default value is `true`. @@ -494,7 +494,7 @@ pprof listening port. The default value is `6060`. ### pprof.type -pprof profile type. One of cpu, heap, goroutine, threadcreate, block, mutex, +pprof profile type. One of cpu, heap, goroutine, threadcreate, block, mutex, allocs. @@ -515,7 +515,7 @@ The private key to use with the service. Must not be used with mnemonic. ### resubmission-timeout -Duration we will wait before resubmitting a transaction to L1. The default +Duration we will wait before resubmitting a transaction to L1. The default value is `48s`. @@ -527,7 +527,7 @@ value is `48s`. ### rollup-rpc HTTP provider URL for Rollup node. A comma-separated list enables the active L2 -endpoint provider. Such a list needs to match the number of l2-eth-rpcs +endpoint provider. Such a list needs to match the number of l2-eth-rpcs provided. @@ -568,7 +568,7 @@ rpc listening port. The default value is `8545`. ### safe-abort-nonce-too-low-count -Number of ErrNonceTooLow observations required to give up on a tx at a +Number of ErrNonceTooLow observations required to give up on a tx at a particular nonce without receiving confirmation. The default value is `3`. @@ -610,9 +610,9 @@ Signer endpoint the client will connect to. ### signer.header -Headers to pass to the remote signer. Format `key=value`. -Value can contain any character allowed in an HTTP header. -When using env vars, split multiple headers with commas. +Headers to pass to the remote signer. Format `key=value`.\ +Value can contain any character allowed in an HTTP header.\ +When using env vars, split multiple headers with commas.\ When using flags, provide one key-value pair per flag. @@ -654,7 +654,7 @@ tls key. The default value is `tls/tls.key`. ### stopped Initialize the batcher in a stopped state. The batcher can be started using the -admin_startBatcher RPC. The default value is `false`. +admin\_startBatcher RPC. The default value is `false`. `--stopped=` @@ -665,7 +665,7 @@ admin_startBatcher RPC. The default value is `false`. ### sub-safety-margin The batcher tx submission safety margin (in #L1-blocks) to subtract from a -channel's timeout and sequencing window, to guarantee safe inclusion of a +channel's timeout and sequencing window, to guarantee safe inclusion of a channel on L1. The default value is `10`. @@ -705,7 +705,7 @@ The total DA limit to start imposing on block building **when we are over the th `OP_BATCHER_THROTTLE_BLOCK_SIZE=50000` ---- +*** ### throttle-interval @@ -717,11 +717,11 @@ Interval between potential DA throttling actions. **Zero disables throttling**. `OP_BATCHER_THROTTLE_INTERVAL=5s` ---- +*** ### throttle-threshold -Threshold on `pending-blocks-bytes-current` beyond which the batcher instructs the +Threshold on `pending-blocks-bytes-current` beyond which the batcher instructs the\ block builder to start throttling transactions with larger DA demands. @@ -730,7 +730,7 @@ block builder to start throttling transactions with larger DA demands. `OP_BATCHER_THROTTLE_THRESHOLD=1500000` ---- +*** ### throttle-tx-size @@ -744,7 +744,7 @@ The DA size of transactions at which throttling begins **when we are over the th ### txmgr.fee-limit-threshold -The minimum threshold (in GWei) at which fee bumping starts to be capped. +The minimum threshold (in GWei) at which fee bumping starts to be capped. Allows arbitrary fee bumps below this threshold. The default value is `100`. @@ -755,7 +755,7 @@ Allows arbitrary fee bumps below this threshold. The default value is `100`. ### txmgr.min-basefee -Enforces a minimum base fee (in GWei) to assume when determining tx fees. 1 +Enforces a minimum base fee (in GWei) to assume when determining tx fees. 1 GWei by default. The default value is `1`. @@ -798,7 +798,7 @@ Frequency to poll for receipts. The default value is `12s`. ### txmgr.send-timeout -Timeout for sending transactions. If 0 it is disabled. The default value is +Timeout for sending transactions. If 0 it is disabled. The default value is `0s`. @@ -809,8 +809,8 @@ Timeout for sending transactions. If 0 it is disabled. The default value is ### wait-node-sync -Indicates if, during startup, the batcher should wait for a recent batcher tx -on L1 to finalize (via more block confirmations). This should help avoid +Indicates if, during startup, the batcher should wait for a recent batcher tx +on L1 to finalize (via more block confirmations). This should help avoid duplicate batcher txs. The default value is `false`. @@ -843,27 +843,27 @@ Print the version. The default value is false. The batcher policy defines high-level constraints and responsibilities regarding how L2 data is posted to L1. Below are the standard guidelines for configuring the batcher within the OP Stack. -| Parameter | Description | Administrator | Requirement | Notes | -|-----------|------------|---------------|-------------|--------| -| Data Availability Type | Specifies whether the batcher uses **blobs** or **calldata** to post transaction data to L1. | Batch submitter address | Ethereum (Blobs or Calldata) | - Alternative data availability (Alt-DA) is not yet supported in the standard configuration.
- The sequencer can switch at will between blob transactions and calldata, with no restrictions, because both are fully secured by L1. | -| Batch Submission Frequency | Determines how frequently the batcher submits aggregated transaction data to L1 (via the batcher transaction). | Batch submitter address | Must target **1,800 L1 blocks** (6 hours on Ethereum, assuming 12s L1 block time) or lower | - Batches must be posted before the sequencing window closes (commonly 12 hours by default).
- Leave a buffer for L1 network congestion and data size to ensure that each batch is fully committed in a timely manner. | -| Output Frequency | Defines how frequently L2 output roots are submitted to L1 (via the output oracle). | L1 Proxy Admin | **43,200 L2 blocks** (24 hours at 2s block times) or lower | - Once fault proofs are implemented, this value may become deprecated.
- It cannot be set to 0 (there must be some cadence for outputs). | +| Parameter | Description | Administrator | Requirement | Notes | +| -------------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Data Availability Type | Specifies whether the batcher uses **blobs** or **calldata** to post transaction data to L1. | Batch submitter address | Ethereum (Blobs or Calldata) | - Alternative data availability (Alt-DA) is not yet supported in the standard configuration.
- The sequencer can switch at will between blob transactions and calldata, with no restrictions, because both are fully secured by L1. | +| Batch Submission Frequency | Determines how frequently the batcher submits aggregated transaction data to L1 (via the batcher transaction). | Batch submitter address | Must target **1,800 L1 blocks** (6 hours on Ethereum, assuming 12s L1 block time) or lower | - Batches must be posted before the sequencing window closes (commonly 12 hours by default).
- Leave a buffer for L1 network congestion and data size to ensure that each batch is fully committed in a timely manner. | +| Output Frequency | Defines how frequently L2 output roots are submitted to L1 (via the output oracle). | L1 Proxy Admin | **43,200 L2 blocks** (24 hours at 2s block times) or lower | - Once fault proofs are implemented, this value may become deprecated.
- It cannot be set to 0 (there must be some cadence for outputs). | ### Additional Guidance -* **Data Availability Types**: - * **Calldata** is generally simpler but can be more expensive on mainnet Ethereum, depending on gas prices. - * **Blobs** are typically lower cost when your chain has enough transaction volume to fill large chunks of data. +* **Data Availability Types**: + * **Calldata** is generally simpler but can be more expensive on mainnet Ethereum, depending on gas prices. + * **Blobs** are typically lower cost when your chain has enough transaction volume to fill large chunks of data. * The `op-batcher` can toggle between these approaches by setting the `--data-availability-type=` flag or with the `OP_BATCHER_DATA_AVAILABILITY_TYPE` env variable. -* **Batch Submission Frequency** (`OP_BATCHER_MAX_CHANNEL_DURATION` and related flags): - * Standard OP Chains frequently target a maximum channel duration between 1–6 hours. - * Your chain should never exceed your L2's sequencing window (commonly 12 hours). +* **Batch Submission Frequency** (`OP_BATCHER_MAX_CHANNEL_DURATION` and related flags): + * Standard OP Chains frequently target a maximum channel duration between 1–6 hours. + * Your chain should never exceed your L2's sequencing window (commonly 12 hours). * If targeting a longer submission window (e.g., 5 or 6 hours), be aware that the [safe head](https://github.com/ethereum-optimism/specs/blob/main/specs/glossary.md#safe-l2-head) can stall up to that duration. -* **Output Frequency**: - * Used to post output roots to L1 for verification. - * The recommended maximum is 24 hours (43,200 blocks at 2s each), though many chains choose smaller intervals. +* **Output Frequency**: + * Used to post output roots to L1 for verification. + * The recommended maximum is 24 hours (43,200 blocks at 2s each), though many chains choose smaller intervals. * Will eventually be replaced or significantly changed by the introduction of fault proofs. Include these high-level "policy" requirements when you set up or modify your `op-batcher` configuration. See the [Batcher Configuration](#global-options) reference, which explains each CLI flag and environment variable in depth. diff --git a/pages/stack/interop/op-supervisor.mdx b/pages/stack/interop/op-supervisor.mdx index 9f7dfd835..4a3af2c43 100644 --- a/pages/stack/interop/op-supervisor.mdx +++ b/pages/stack/interop/op-supervisor.mdx @@ -11,14 +11,15 @@ import { InteropCallout } from '@/components/WipCallout' # OP-Supervisor -OP-Supervisor is a service that verifies cross-chain messages and manages interoperability between chains in the OP Stack. +OP-Supervisor is a service that verifies cross-chain messages and manages interoperability between chains in the OP Stack. The main information it contains about other blockchains is: -- Log entries, which could be [initiating messages](./explainer#how-messages-get-from-one-chain-to-the-other) for cross-domain messages. -- Blockchain heads, which are the latest blocks at various levels of confidence and safety: - - Unsafe (the latest block available through the gossip protocol) - - Local-safe (the latest block written to L1) - - Cross-safe (the latest block written to L1, and for which all the dependencies are written to L1) - - Finalized (the latest block written to L1, and that L1 block is safe from reorgs) + +* Log entries, which could be [initiating messages](./explainer#how-messages-get-from-one-chain-to-the-other) for cross-domain messages. +* Blockchain heads, which are the latest blocks at various levels of confidence and safety: + * Unsafe (the latest block available through the gossip protocol) + * Local-safe (the latest block written to L1) + * Cross-safe (the latest block written to L1, and for which all the dependencies are written to L1) + * Finalized (the latest block written to L1, and that L1 block is safe from reorgs) ```mermaid @@ -51,14 +52,14 @@ To do this, OP-Supervisor has to have RPC access to all the chains in the depend ## How other components use OP-Supervisor -- The execution client (typically `op-geth`) queries `op-supervisor` during block-building to verify if a message is sufficiently safe to include. - To do this, the execution client looks at every executing message and queries `op-supervisor` to see if there is a corresponding initiating message. +* The execution client (typically `op-geth`) queries `op-supervisor` during block-building to verify if a message is sufficiently safe to include. + To do this, the execution client looks at every executing message and queries `op-supervisor` to see if there is a corresponding initiating message. -- `op-node` queries cross-chain safety information and coordinates safety updates between OP stack nodes and `op-supervisor`. It uses the API provided by `op-supervisor` to: - - Retrieve the unsafe, local-safe, cross-safe, and finalized heads for other chains. - - Update the unsafe, local-safe, and finalized heads for its own chain. - - Attempt to promote blocks in its own chain to cross-safe status. - - Attempt to finalize L2 blocks based on L1 finality. +* `op-node` queries cross-chain safety information and coordinates safety updates between OP stack nodes and `op-supervisor`. It uses the API provided by `op-supervisor` to: + * Retrieve the unsafe, local-safe, cross-safe, and finalized heads for other chains. + * Update the unsafe, local-safe, and finalized heads for its own chain. + * Attempt to promote blocks in its own chain to cross-safe status. + * Attempt to finalize L2 blocks based on L1 finality. ### API diff --git a/pages/stack/interop/superchain-erc20.mdx b/pages/stack/interop/superchain-erc20.mdx index afc1c2abc..10db42031 100644 --- a/pages/stack/interop/superchain-erc20.mdx +++ b/pages/stack/interop/superchain-erc20.mdx @@ -12,13 +12,12 @@ import { InteropCallout } from '@/components/WipCallout' # SuperchainERC20 -The [`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) contract implements [ERC-7802](https://ethereum-magicians.org/t/erc-7802-crosschain-token-interface/21508) to enable asset interoperability within the Superchain. +The [`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) contract implements [ERC-7802](https://ethereum-magicians.org/t/erc-7802-crosschain-token-interface/21508) to enable asset interoperability within the Superchain. Asset interoperability allows tokens to move securely across the Superchain by burning tokens on the source chain and minting an equivalent amount on the destination chain. This approach addresses issues such as liquidity fragmentation and poor user experiences caused by asset wrapping or reliance on liquidity pools. Instead of wrapping assets, this mechanism effectively "teleports" tokens between chains in the Superchain. It provides users with a secure and capital-efficient method for transacting across chains. - Additional features: * **Simplified deployments**: Zero infrastructure cost to make your token cross-chain. @@ -84,17 +83,17 @@ sequenceDiagram ## Requirements -Application developers must complete two steps to make their tokens compatible with `SuperchainERC20`. +Application developers must complete two steps to make their tokens compatible with `SuperchainERC20`. Setting this up in advance ensures tokens will benefit from interop when it becomes available. * Grant permission to `SuperchainTokenBridge` (address `0x4200000000000000000000000000000000000028`) to call `crosschainMint` and `crosschainBurn`. If you are using [`SuperchainERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainERC20.sol) this is already done for you. - {/* + {/* Add this after the tutorial is written -For detailed, step-by-step instructions on implementing SuperchainERC20, refer to [Deploy assets using SuperchainERC20](/stack/interop/assets/deploy-superchain-erc20). + For detailed, step-by-step instructions on implementing SuperchainERC20, refer to [Deploy assets using SuperchainERC20](/stack/interop/assets/deploy-superchain-erc20). */} @@ -102,20 +101,18 @@ For detailed, step-by-step instructions on implementing SuperchainERC20, refer t This is easiest when using [`create2`](https://book.getfoundry.sh/tutorials/create2-tutorial). -To ensure security, you must either design the deployer to allow only a specific trusted ERC-20 contract, such as `SuperchainERC20`, to be deployed through it, or call `CREATE2` to deploy the contract directly from an EOA you control. + To ensure security, you must either design the deployer to allow only a specific trusted ERC-20 contract, such as `SuperchainERC20`, to be deployed through it, or call `CREATE2` to deploy the contract directly from an EOA you control. -This precaution is critical because if an unauthorized ERC-20 contract is deployed at the same address on any Superchain network, it could allow malicious actors to mint unlimited tokens and bridge them to the network where the original ERC-20 contract resides. + This precaution is critical because if an unauthorized ERC-20 contract is deployed at the same address on any Superchain network, it could allow malicious actors to mint unlimited tokens and bridge them to the network where the original ERC-20 contract resides. - ## Comparison to other token implementations `SuperchainERC20` differs from other token implementations in both focus and design: -* It implements `ERC-7802`, a minimal cross-chain mint/burn interface designed to establish a common standard across the EVM ecosystem. +* It implements `ERC-7802`, a minimal cross-chain mint/burn interface designed to establish a common standard across the EVM ecosystem. * It relies on the shared trust assumptions of the Superchain. All traffic originating from any chain within the Superchain is trusted because these chains [share the same security standard](/superchain/standard-configuration). - Projects moving from other token implementations may need to adapt to the `SuperchainERC20` specification. @@ -124,9 +121,10 @@ This precaution is critical because if an unauthorized ERC-20 contract is deploy ### What happens if I bridge to a chain that does not have the ERC-20 contract? -The initiating message will successfully burn the tokens on the source chain. -However, the executing message will fail because it attempts to call `crosschainMint` on a non-existent contract. +The initiating message will successfully burn the tokens on the source chain. +However, the executing message will fail because it attempts to call `crosschainMint` on a non-existent contract. Once a `SuperchainERC20` contract is properly deployed on the destination chain, you can retry the executing message to retrieve your tokens. + ## Next steps * Watch the [ERC20 to SuperchainERC20 video walkthrough](https://www.youtube.com/watch?v=Gb8glkyBdBA) to learn how to modify an existing ERC20 contract to make it interoperable within the Superchain. diff --git a/words.txt b/words.txt index 8e3c7ca44..a2dacd670 100644 --- a/words.txt +++ b/words.txt @@ -1,5 +1,5 @@ -accountqueue ACCOUNTQUEUE +accountqueue ACCOUNTSLOTS accountslots ADDI @@ -34,8 +34,8 @@ blobspace Blockdaemon Blockdaemon's blockhash -BLOCKLOGS blocklists +BLOCKLOGS blocklogs BLOCKPROFILERATE blockprofilerate @@ -75,7 +75,6 @@ Consen corsdomain counterfactually Crosschain -crosschain Crossmint Dapphub daserver @@ -85,6 +84,7 @@ DATADIR datadir Devnet devnet +Devnets devnets devx direnv @@ -175,7 +175,6 @@ JSPATH jspath jwtsecret Keccak -Learn leveldb lightkdf logfile @@ -194,7 +193,6 @@ MEMPROFILERATE memprofilerate Merkle merkle -mesage MFHI MFLO Minato @@ -274,7 +272,6 @@ PPROF pprof Precommitments precommitments -Preconfigured preconfigured predeploy Predeployed @@ -410,6 +407,7 @@ vhosts Viem viem Viem's +viem's VMDEBUG vmdebug VMODULE @@ -421,4 +419,4 @@ xtensibility ZKPs ZKVM Zora -zora \ No newline at end of file +zora