From 254276feffa6c82b4b743ec85c7a674a09e0b7dd Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 26 Feb 2025 23:39:31 +0100 Subject: [PATCH 01/27] Initial commit --- pages/stack/interop.mdx | 2 + pages/stack/interop/_meta.json | 1 + pages/stack/interop/token-compatible.mdx | 78 ++++++++++++++++++++++++ words.txt | 7 +-- 4 files changed, 82 insertions(+), 6 deletions(-) create mode 100644 pages/stack/interop/token-compatible.mdx diff --git a/pages/stack/interop.mdx b/pages/stack/interop.mdx index 4b5c0abee..e74c32888 100644 --- a/pages/stack/interop.mdx +++ b/pages/stack/interop.mdx @@ -17,6 +17,8 @@ Documentation covering Cross Chain Message, Explainer, Message Passing, Op Super } /> + } /> + } /> } /> diff --git a/pages/stack/interop/_meta.json b/pages/stack/interop/_meta.json index 07b56316e..ca76e742a 100644 --- a/pages/stack/interop/_meta.json +++ b/pages/stack/interop/_meta.json @@ -2,6 +2,7 @@ "explainer": "Superchain interop explainer", "predeploy": "Superchain interop predeploys", "message-passing": "Superchain interop message passing", + "token-compatible": "Superchain interop compatible token", "op-supervisor": "OP Supervisor", "superchain-weth": "Interoperable ETH", "superchain-erc20": "SuperchainERC20", diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx new file mode 100644 index 000000000..783c2d923 --- /dev/null +++ b/pages/stack/interop/token-compatible.mdx @@ -0,0 +1,78 @@ +--- +title: Superchain interop compatible token +lang: en-US +description: Learn how to enable seamless, low-latency cross-chain composability for your token within the Superchain. +--- + +import { Callout } from 'nextra/components' +import { InteropCallout } from '@/components/WipCallout' + + + +# Making your token Superchain interop compatible + +Superchain interop enables **secure, 0-slippage, 1-block latency cross-chain composability** on the Superchain. +The recommended approach for enabling interop capabilities is using **SuperchainERC20**, but there are other options depending on your needs. + +Tokens can move across chains by granting authority to a messaging service (bridge) to **mint/burn** them. +When enabling cross-chain functionality, it is essential to evaluate **security, cost, and latency**. +Superchain interop ensures that tokens move securely within the Superchain using **OP Stack permissionless fault proofs**, only requiring gas fees, and achieving **1-block latency**. + +## Why Superchain interop? + +* **Low latency:** 1-block finality ensures fast asset movement. +* **No slippage:** Transfers happen at a 1:1 rate with no price impact. +* **Security:** Protected by the OP Stack's permissionless fault proofs. +* **[Reorg awareness](./reorg):** Prevents the double-spend problem. + +## Implementation options + +Choosing the right implementation depends on your token's needs. Below are the available options: + +## **Comparison of Implementation Options** + +| Implementation | Security | Latency | Notes | +| --------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- | +| **SuperchainERC20** | ✅ **Most secure** – Fully protected by OP Stack permissionless fault proofs. No third-party dependencies. | ⚡ **1-block latency** within the Superchain. | **Recommended for Superchain-native tokens**. Provides the simplest and most secure interop. | +| **xERC20 (ERC-7281)** | ✅ Secure within the Superchain. Security outside the Superchain depends on the allowlisted third-party bridges. | ⚡ **1-block latency** in the Superchain. Outside latency depends on the messaging service used. | Good for projects that need **flexible bridge integrations**. | +| **OFT** | ✅ Secure within the Superchain. Outside security depends on allowlisted **Decentralized Verification Networks (DVNs)**. | ⚡ **1-block latency** in the Superchain. External latency varies based on DVN finality time. | Enables **cross-ecosystem movement** beyond the Superchain (e.g., Solana, Arbitrum). | +| **NTT** | ✅ Secure within the Superchain. External security depends on **allowlisted transceivers**. | ⚡ **1-block latency** in the Superchain. External latency depends on transceiver finality. | **Superchain integration is in progress**. Similar to OFT but uses Wormhole's network. | + +### **Key Takeaways** + +* **For highest security and lowest latency within the Superchain**, use **SuperchainERC20**. +* **For interoperability beyond the Superchain**, **xERC20, OFT, and NTT** provide options, but **security depends on external verification mechanisms**. +* **xERC20 is more flexible** but relies on the security of the allowlisted third-party bridges. +* **OFT and NTT are useful for non-Superchain ecosystems** but require allowlisting external validators. + +## Considerations for L1 deposited tokens + +The only **L1 deposited token** with a shared lockbox in the initial Superchain interop upgrade is **ETH**. + + + If you want to enable **Superchain interop for an L1 token**, you must: + + 1. **Choose a hub chain.** + 2. **Add the SuperchainERC20 interface** to the L2 representation of the token. + + +**Important:** The L2 representation can teleport within the Superchain, but it can **only exit to L1 through the hub chain**.\ +Depositing an L1 token into a different L2 will create a **new and separate token**, leading to **poor user experience**. We recommend **SuperchainERC20** for L2-native tokens until a shared lockbox for all ERC20 deposits is available. + +## Security considerations + +Superchain interop provides a **secure** way to transfer tokens, but security risks exist if multiple messaging services are allowlisted. + +### Weakest link risk + +If you allowlist both **Superchain interop and a third-party messaging service**, your token's security is only as strong as the weakest service. A compromised third-party service could allow malicious minting or double spending. + +## SuperchainTokenBridge vs. Superchain interop messaging + +The **SuperchainTokenBridge** is an abstraction built on top of the **Cross-Domain Messenger (CDM)**. Anyone can build a **custom bridge** on the **L2-to-L2 CDM**, but it may not follow the invariant of maintaining the same token address across chains. + +## Next steps + +* [Deploy a SuperchainERC20 token](/stack/interop/superchain-erc20) +* [Learn more about interoperability](/stack/interop/explainer) +* [Build a cross-chain app on the Superchain](/app-developers/get-started) diff --git a/words.txt b/words.txt index d57f74d8b..e92639a84 100644 --- a/words.txt +++ b/words.txt @@ -8,7 +8,6 @@ ADDIU ADDU airgap Allnodes -Allocs allocs Alphanet alphanet @@ -20,6 +19,7 @@ Ankr Apeworx Arweave authrpc +Autorelay autorelay autorelayer basefee @@ -168,14 +168,12 @@ IERC IGNOREPRICE ignoreprice Immunefi -implicitly Inator inator INFLUXDBV influxdbv initcode interopble -invokable IPCDISABLE ipcdisable ipcfile @@ -360,7 +358,6 @@ seqnr SEQUENCERHTTP sequencerhttp serv -settions signup SLLV SLTI @@ -401,7 +398,6 @@ synctarget syscalls thirdweb threadcreate -tility timeseries triggerable trustlessly @@ -436,7 +432,6 @@ VMODULE vmodule xlarge XORI -xtensibility ZKPs ZKVM Zora From caed3224c62a82662c60566e1fe4c7f04cbe4c12 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 26 Feb 2025 23:42:15 +0100 Subject: [PATCH 02/27] updated title --- pages/stack/interop/token-compatible.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index 783c2d923..36d4aa659 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -1,5 +1,5 @@ --- -title: Superchain interop compatible token +title: Superchain interop compatible tokens lang: en-US description: Learn how to enable seamless, low-latency cross-chain composability for your token within the Superchain. --- @@ -9,7 +9,7 @@ import { InteropCallout } from '@/components/WipCallout' -# Making your token Superchain interop compatible +# Superchain interop compatible tokens Superchain interop enables **secure, 0-slippage, 1-block latency cross-chain composability** on the Superchain. The recommended approach for enabling interop capabilities is using **SuperchainERC20**, but there are other options depending on your needs. From fcc8911fef7c90bad9e4537692259ffabd939be4 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 27 Feb 2025 00:48:26 +0100 Subject: [PATCH 03/27] Improved docs --- pages/stack/interop/token-compatible.mdx | 81 ++++++++++++------------ 1 file changed, 42 insertions(+), 39 deletions(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index 36d4aa659..6d6ae8a16 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -11,67 +11,70 @@ import { InteropCallout } from '@/components/WipCallout' # Superchain interop compatible tokens -Superchain interop enables **secure, 0-slippage, 1-block latency cross-chain composability** on the Superchain. -The recommended approach for enabling interop capabilities is using **SuperchainERC20**, but there are other options depending on your needs. +Superchain interop enables **secure, gas-only, 1-block latency cross-chain composability** on the [Superchain interop cluster](/stack/interop/explainer#superchain-interop-cluster).\ +The **recommended** approach for enabling interop capabilities for tokens is using **SuperchainERC20**, but there are other options depending on your needs. -Tokens can move across chains by granting authority to a messaging service (bridge) to **mint/burn** them. -When enabling cross-chain functionality, it is essential to evaluate **security, cost, and latency**. -Superchain interop ensures that tokens move securely within the Superchain using **OP Stack permissionless fault proofs**, only requiring gas fees, and achieving **1-block latency**. +## How tokens go cross-chain -## Why Superchain interop? +Compared to a traditional ERC-20 deployment on a single chain, tokens can move across chains by granting authority to a messaging service (bridge) to **cross-chain mint/burn** them.\ +When enabling cross-chain functionality, it is essential to evaluate **security, cost, and latency** of the respective messaging service. -* **Low latency:** 1-block finality ensures fast asset movement. -* **No slippage:** Transfers happen at a 1:1 rate with no price impact. +## Why Superchain interop messaging? + +* **Low latency:** 1-block latency ensures fast cross-chain token transfers. +* **No fees:** Transfers happen at a 1:1 rate with no liquidity pools—just gas. * **Security:** Protected by the OP Stack's permissionless fault proofs. -* **[Reorg awareness](./reorg):** Prevents the double-spend problem. +* **[Reorg awareness](./reorg):** Enables 1-block latency cross-chain composability that mitigates the double-spend problem. + +## SuperchainERC20 – The Recommended Option + +* **Most secure** – Fully protected by OP Stack permissionless fault proofs. No third-party dependencies.\ +* **1-block latency** within the Superchain.\ +* **Best for:** **Superchain-native tokens**, that need **the highest security, lowest latency, and seamless integration within the Superchain** + -## Implementation options +### Weakest Link Risk -Choosing the right implementation depends on your token's needs. Below are the available options: +If you allowlist both **Superchain interop and a third-party messaging service**, your token's security is **only as strong as the weakest service**.\ +A compromised third-party service could allow **malicious minting or double spending**. -## **Comparison of Implementation Options** +### SuperchainTokenBridge vs. Superchain interop messaging -| Implementation | Security | Latency | Notes | -| --------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- | -| **SuperchainERC20** | ✅ **Most secure** – Fully protected by OP Stack permissionless fault proofs. No third-party dependencies. | ⚡ **1-block latency** within the Superchain. | **Recommended for Superchain-native tokens**. Provides the simplest and most secure interop. | -| **xERC20 (ERC-7281)** | ✅ Secure within the Superchain. Security outside the Superchain depends on the allowlisted third-party bridges. | ⚡ **1-block latency** in the Superchain. Outside latency depends on the messaging service used. | Good for projects that need **flexible bridge integrations**. | -| **OFT** | ✅ Secure within the Superchain. Outside security depends on allowlisted **Decentralized Verification Networks (DVNs)**. | ⚡ **1-block latency** in the Superchain. External latency varies based on DVN finality time. | Enables **cross-ecosystem movement** beyond the Superchain (e.g., Solana, Arbitrum). | -| **NTT** | ✅ Secure within the Superchain. External security depends on **allowlisted transceivers**. | ⚡ **1-block latency** in the Superchain. External latency depends on transceiver finality. | **Superchain integration is in progress**. Similar to OFT but uses Wormhole's network. | +The **SuperchainTokenBridge** is an abstraction built on top of the **Cross-Domain Messenger (CDM)**.\ +Anyone can build a **custom bridge** on the **L2-to-L2 CDM**, but it may not follow the invariant of maintaining the **same token address across chains**. -### **Key Takeaways** -* **For highest security and lowest latency within the Superchain**, use **SuperchainERC20**. -* **For interoperability beyond the Superchain**, **xERC20, OFT, and NTT** provide options, but **security depends on external verification mechanisms**. -* **xERC20 is more flexible** but relies on the security of the allowlisted third-party bridges. -* **OFT and NTT are useful for non-Superchain ecosystems** but require allowlisting external validators. +## Alternative Implementation Options (ERC-7281 Standard) -## Considerations for L1 deposited tokens +If your token requires interoperability **beyond the Superchain**, you can consider one of the following **ERC-7281-compliant** options. These introduce **external dependencies** that must be allowlisted. -The only **L1 deposited token** with a shared lockbox in the initial Superchain interop upgrade is **ETH**. +### xERC20 (ERC-7281) - - If you want to enable **Superchain interop for an L1 token**, you must: +* **Security:** Secure within the Superchain. Security outside the Superchain depends on **allowlisted third-party bridges**. +* **Latency:** 1-block latency in the Superchain. Outside latency varies based on the **messaging service used**. +* **Best for:** Projects needing **flexible bridge integrations** while retaining control over allowlisted bridges. - 1. **Choose a hub chain.** - 2. **Add the SuperchainERC20 interface** to the L2 representation of the token. - +### OFT (Omnichain Fungible Token) -**Important:** The L2 representation can teleport within the Superchain, but it can **only exit to L1 through the hub chain**.\ -Depositing an L1 token into a different L2 will create a **new and separate token**, leading to **poor user experience**. We recommend **SuperchainERC20** for L2-native tokens until a shared lockbox for all ERC20 deposits is available. +* **Security:** Secure within the Superchain. Outside security depends on **allowlisted Decentralized Verification Networks (DVNs)**. +* **Latency:** 1-block latency within the Superchain. External latency depends on **DVN finality time**. +* **Best for:** Tokens requiring **cross-chain transfer** beyond the Superchain (e.g., Solana, Arbitrum). -## Security considerations +### NTT (Native Token Transfer) -Superchain interop provides a **secure** way to transfer tokens, but security risks exist if multiple messaging services are allowlisted. +* **Security:** Secure within the Superchain. External security depends on **allowlisted transceivers**. +* **Latency:** 1-block latency within the Superchain. External latency varies based on **transceiver finality**. +* **Best for:** Projects that want **Wormhole's network** for cross-chain transfer. *(Superchain integration is still in progress.)* -### Weakest link risk +### Key Takeaways -If you allowlist both **Superchain interop and a third-party messaging service**, your token's security is only as strong as the weakest service. A compromised third-party service could allow malicious minting or double spending. +* **SuperchainERC20** is the most secure and recommended option for native Superchain tokens. +* **All other options (xERC20, OFT, NTT) follow the ERC-7281 standard** and require allowlisting external verification mechanisms. +* **Interoperability outside the Superchain** introduces external dependencies and potential security risks. -## SuperchainTokenBridge vs. Superchain interop messaging -The **SuperchainTokenBridge** is an abstraction built on top of the **Cross-Domain Messenger (CDM)**. Anyone can build a **custom bridge** on the **L2-to-L2 CDM**, but it may not follow the invariant of maintaining the same token address across chains. -## Next steps +## Next Steps * [Deploy a SuperchainERC20 token](/stack/interop/superchain-erc20) * [Learn more about interoperability](/stack/interop/explainer) From 57708405b8dcc07b85205a091a262c39b9d76405 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 27 Feb 2025 00:52:58 +0100 Subject: [PATCH 04/27] updated the docs --- pages/stack/interop/token-compatible.mdx | 28 +++++++++++------------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index 6d6ae8a16..68952ad19 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -11,12 +11,12 @@ import { InteropCallout } from '@/components/WipCallout' # Superchain interop compatible tokens -Superchain interop enables **secure, gas-only, 1-block latency cross-chain composability** on the [Superchain interop cluster](/stack/interop/explainer#superchain-interop-cluster).\ -The **recommended** approach for enabling interop capabilities for tokens is using **SuperchainERC20**, but there are other options depending on your needs. +Superchain interop enables **secure, gas-only, 1-block latency cross-chain composability** on the [Superchain interop cluster](/stack/interop/explainer#superchain-interop-cluster). +The **recommended** approach for enabling interop capabilities for tokens is using [SuperchainERC20](/stack/interop/superchain-erc20), but there are other options depending on your needs. ## How tokens go cross-chain -Compared to a traditional ERC-20 deployment on a single chain, tokens can move across chains by granting authority to a messaging service (bridge) to **cross-chain mint/burn** them.\ +Compared to a traditional ERC-20 deployment on a single chain, tokens can move across chains by granting authority to a messaging service (bridge) to **cross-chain mint/burn** them. When enabling cross-chain functionality, it is essential to evaluate **security, cost, and latency** of the respective messaging service. ## Why Superchain interop messaging? @@ -28,23 +28,23 @@ When enabling cross-chain functionality, it is essential to evaluate **security, ## SuperchainERC20 – The Recommended Option -* **Most secure** – Fully protected by OP Stack permissionless fault proofs. No third-party dependencies.\ -* **1-block latency** within the Superchain.\ +* **Most secure** – Fully protected by OP Stack permissionless fault proofs. No third-party dependencies. +* **1-block latency** within the Superchain. * **Best for:** **Superchain-native tokens**, that need **the highest security, lowest latency, and seamless integration within the Superchain** -### Weakest Link Risk +### Weakest link risk -If you allowlist both **Superchain interop and a third-party messaging service**, your token's security is **only as strong as the weakest service**.\ +If you allowlist both **Superchain interop and a third-party messaging service**, your token's security is **only as strong as the weakest service**. A compromised third-party service could allow **malicious minting or double spending**. ### SuperchainTokenBridge vs. Superchain interop messaging -The **SuperchainTokenBridge** is an abstraction built on top of the **Cross-Domain Messenger (CDM)**.\ +The [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) is an abstraction built on top of the **Cross-Domain Messenger (CDM)**. Anyone can build a **custom bridge** on the **L2-to-L2 CDM**, but it may not follow the invariant of maintaining the **same token address across chains**. -## Alternative Implementation Options (ERC-7281 Standard) +## Alternative implementation options (ERC-7281 Standard) If your token requires interoperability **beyond the Superchain**, you can consider one of the following **ERC-7281-compliant** options. These introduce **external dependencies** that must be allowlisted. @@ -54,27 +54,25 @@ If your token requires interoperability **beyond the Superchain**, you can consi * **Latency:** 1-block latency in the Superchain. Outside latency varies based on the **messaging service used**. * **Best for:** Projects needing **flexible bridge integrations** while retaining control over allowlisted bridges. -### OFT (Omnichain Fungible Token) +### OFT * **Security:** Secure within the Superchain. Outside security depends on **allowlisted Decentralized Verification Networks (DVNs)**. * **Latency:** 1-block latency within the Superchain. External latency depends on **DVN finality time**. * **Best for:** Tokens requiring **cross-chain transfer** beyond the Superchain (e.g., Solana, Arbitrum). -### NTT (Native Token Transfer) +### NTT * **Security:** Secure within the Superchain. External security depends on **allowlisted transceivers**. * **Latency:** 1-block latency within the Superchain. External latency varies based on **transceiver finality**. * **Best for:** Projects that want **Wormhole's network** for cross-chain transfer. *(Superchain integration is still in progress.)* -### Key Takeaways +### Key takeaways * **SuperchainERC20** is the most secure and recommended option for native Superchain tokens. * **All other options (xERC20, OFT, NTT) follow the ERC-7281 standard** and require allowlisting external verification mechanisms. * **Interoperability outside the Superchain** introduces external dependencies and potential security risks. - - -## Next Steps +## Next steps * [Deploy a SuperchainERC20 token](/stack/interop/superchain-erc20) * [Learn more about interoperability](/stack/interop/explainer) From 92503d96611d99c29096378ac63f83139c88a5b9 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 27 Feb 2025 00:56:56 +0100 Subject: [PATCH 05/27] remove bold syntax --- pages/stack/interop/token-compatible.mdx | 28 ++++++++++++------------ 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index 68952ad19..afce16478 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -30,47 +30,47 @@ When enabling cross-chain functionality, it is essential to evaluate **security, * **Most secure** – Fully protected by OP Stack permissionless fault proofs. No third-party dependencies. * **1-block latency** within the Superchain. -* **Best for:** **Superchain-native tokens**, that need **the highest security, lowest latency, and seamless integration within the Superchain** +* **Best for:** **Superchain-native tokens**, that need **the highest security, lowest latency**, and seamless integration within the Superchain ### Weakest link risk -If you allowlist both **Superchain interop and a third-party messaging service**, your token's security is **only as strong as the weakest service**. -A compromised third-party service could allow **malicious minting or double spending**. +If you allowlist both Superchain interop and a third-party messaging service, your token's security is only as strong as the weakest service. +A compromised third-party service could allow malicious minting or double spending. ### SuperchainTokenBridge vs. Superchain interop messaging The [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) is an abstraction built on top of the **Cross-Domain Messenger (CDM)**. -Anyone can build a **custom bridge** on the **L2-to-L2 CDM**, but it may not follow the invariant of maintaining the **same token address across chains**. +Anyone can build a custom bridge on the **L2-to-L2 CDM**, but it may not follow the invariant of maintaining the same token address across chains. ## Alternative implementation options (ERC-7281 Standard) -If your token requires interoperability **beyond the Superchain**, you can consider one of the following **ERC-7281-compliant** options. These introduce **external dependencies** that must be allowlisted. +If your token requires interoperability beyond the Superchain, you can consider one of the following **ERC-7281-compliant** options. These introduce external dependencies that must be allowlisted. ### xERC20 (ERC-7281) -* **Security:** Secure within the Superchain. Security outside the Superchain depends on **allowlisted third-party bridges**. -* **Latency:** 1-block latency in the Superchain. Outside latency varies based on the **messaging service used**. -* **Best for:** Projects needing **flexible bridge integrations** while retaining control over allowlisted bridges. +* **Security:** Secure within the Superchain. Security outside the Superchain depends on allowlisted third-party bridges. +* **Latency:** 1-block latency in the Superchain. Outside latency varies based on the messaging service used. +* **Best for:** Projects needing flexible bridge integrations while retaining control over allowlisted bridges. ### OFT * **Security:** Secure within the Superchain. Outside security depends on **allowlisted Decentralized Verification Networks (DVNs)**. * **Latency:** 1-block latency within the Superchain. External latency depends on **DVN finality time**. -* **Best for:** Tokens requiring **cross-chain transfer** beyond the Superchain (e.g., Solana, Arbitrum). +* **Best for:** Tokens requiring cross-chain transfer beyond the Superchain (e.g., Solana, Arbitrum). ### NTT -* **Security:** Secure within the Superchain. External security depends on **allowlisted transceivers**. -* **Latency:** 1-block latency within the Superchain. External latency varies based on **transceiver finality**. -* **Best for:** Projects that want **Wormhole's network** for cross-chain transfer. *(Superchain integration is still in progress.)* +* **Security:** Secure within the Superchain. External security depends on allowlisted transceivers. +* **Latency:** 1-block latency within the Superchain. External latency varies based on transceiver finality. +* **Best for:** Projects that want Wormhole's network for cross-chain transfer. (Superchain integration is still in progress.) ### Key takeaways * **SuperchainERC20** is the most secure and recommended option for native Superchain tokens. -* **All other options (xERC20, OFT, NTT) follow the ERC-7281 standard** and require allowlisting external verification mechanisms. -* **Interoperability outside the Superchain** introduces external dependencies and potential security risks. +* All other options (xERC20, OFT, NTT) follow the ERC-7281 standard and require allowlisting external verification mechanisms. +* Interoperability outside the Superchain introduces external dependencies and potential security risks. ## Next steps From cebb17b5a900994004322ce7c4e065f18259b3c1 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 27 Feb 2025 00:57:19 +0100 Subject: [PATCH 06/27] updated header --- pages/stack/interop/token-compatible.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index afce16478..ef5b4a4c4 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -26,7 +26,7 @@ When enabling cross-chain functionality, it is essential to evaluate **security, * **Security:** Protected by the OP Stack's permissionless fault proofs. * **[Reorg awareness](./reorg):** Enables 1-block latency cross-chain composability that mitigates the double-spend problem. -## SuperchainERC20 – The Recommended Option +## SuperchainERC20 – The recommended option * **Most secure** – Fully protected by OP Stack permissionless fault proofs. No third-party dependencies. * **1-block latency** within the Superchain. From 09fcf17e0eeaaf5a5b2d4f4e0a328a31ea37c951 Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 17:51:25 -0700 Subject: [PATCH 07/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 36 +++++++++++++----------- 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index ef5b4a4c4..75427bea4 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -1,7 +1,7 @@ --- title: Superchain interop compatible tokens lang: en-US -description: Learn how to enable seamless, low-latency cross-chain composability for your token within the Superchain. +description: Learn how different tokens can benefit from Superchain interop and benefit from secure, low-latency, cross-chain composability. --- import { Callout } from 'nextra/components' @@ -16,22 +16,28 @@ The **recommended** approach for enabling interop capabilities for tokens is usi ## How tokens go cross-chain -Compared to a traditional ERC-20 deployment on a single chain, tokens can move across chains by granting authority to a messaging service (bridge) to **cross-chain mint/burn** them. -When enabling cross-chain functionality, it is essential to evaluate **security, cost, and latency** of the respective messaging service. +Compared to traditional ERC-20 tokens deployments on a single blockchain, cross-chain tokens can move between different networks through giving crosschainMint and crosschainBurn permissions to a verification mechanism (such as a bridge protocol) that validates when tokens should be burned on one chain and minted on another. -## Why Superchain interop messaging? +For example when transferring a SuperchainERC20 between chains in the Superchain interop cluster, the Superchain interop protocol ensures the tokens are burned on the source chain before authorizing the corresponding mint on the destination chain. + +When enabling cross-chain functionality for your token, it is essential to evaluate the security, cost, and latency of the respective verification mechanism. + + +## Why give your token cross-chain functionality with Superchain interop? * **Low latency:** 1-block latency ensures fast cross-chain token transfers. * **No fees:** Transfers happen at a 1:1 rate with no liquidity pools—just gas. -* **Security:** Protected by the OP Stack's permissionless fault proofs. +* **Security:** Fault Proofs secure Superchain interop end to end. * **[Reorg awareness](./reorg):** Enables 1-block latency cross-chain composability that mitigates the double-spend problem. ## SuperchainERC20 – The recommended option -* **Most secure** – Fully protected by OP Stack permissionless fault proofs. No third-party dependencies. +* **Most secure** – Fault Proofs secure Superchain interop end to end. No third-party dependencies. * **1-block latency** within the Superchain. -* **Best for:** **Superchain-native tokens**, that need **the highest security, lowest latency**, and seamless integration within the Superchain +* **Best for:** **Superchain-native tokens**, that need **a trust-minimized, simple**, and seamless integration within the Superchain + +## Alternative implementation options (ERC-7281 Standard) ### Weakest link risk @@ -43,34 +49,32 @@ A compromised third-party service could allow malicious minting or double spendi The [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) is an abstraction built on top of the **Cross-Domain Messenger (CDM)**. Anyone can build a custom bridge on the **L2-to-L2 CDM**, but it may not follow the invariant of maintaining the same token address across chains. - -## Alternative implementation options (ERC-7281 Standard) - If your token requires interoperability beyond the Superchain, you can consider one of the following **ERC-7281-compliant** options. These introduce external dependencies that must be allowlisted. ### xERC20 (ERC-7281) -* **Security:** Secure within the Superchain. Security outside the Superchain depends on allowlisted third-party bridges. +* **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. * **Latency:** 1-block latency in the Superchain. Outside latency varies based on the messaging service used. * **Best for:** Projects needing flexible bridge integrations while retaining control over allowlisted bridges. ### OFT -* **Security:** Secure within the Superchain. Outside security depends on **allowlisted Decentralized Verification Networks (DVNs)**. +* **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. * **Latency:** 1-block latency within the Superchain. External latency depends on **DVN finality time**. * **Best for:** Tokens requiring cross-chain transfer beyond the Superchain (e.g., Solana, Arbitrum). ### NTT -* **Security:** Secure within the Superchain. External security depends on allowlisted transceivers. +* **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. * **Latency:** 1-block latency within the Superchain. External latency varies based on transceiver finality. * **Best for:** Projects that want Wormhole's network for cross-chain transfer. (Superchain integration is still in progress.) ### Key takeaways -* **SuperchainERC20** is the most secure and recommended option for native Superchain tokens. -* All other options (xERC20, OFT, NTT) follow the ERC-7281 standard and require allowlisting external verification mechanisms. -* Interoperability outside the Superchain introduces external dependencies and potential security risks. +* **SuperchainERC20** is the simplest way for token issuers to get Superchain interop cluster wide distribution. +* Token issuers can use other options (xERC20, OFT, NTT) and allowlist Superchain interop or the SuperchainTokenBridge to benefit from Superchain interop. +* When using tokens other than SuperchainERC20, token issuers should include a ERC-7802 interface to simplify developer experience. +* Using 3rd party verification mechanisms introduces external dependencies and potential security risks. ## Next steps From 7632bf656313ccf54bf234cfef328b9171c3cd40 Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 17:59:41 -0700 Subject: [PATCH 08/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index 75427bea4..b13cb2f99 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -30,11 +30,15 @@ When enabling cross-chain functionality for your token, it is essential to evalu * **Security:** Fault Proofs secure Superchain interop end to end. * **[Reorg awareness](./reorg):** Enables 1-block latency cross-chain composability that mitigates the double-spend problem. -## SuperchainERC20 – The recommended option +## SuperchainERC20 -* **Most secure** – Fault Proofs secure Superchain interop end to end. No third-party dependencies. -* **1-block latency** within the Superchain. -* **Best for:** **Superchain-native tokens**, that need **a trust-minimized, simple**, and seamless integration within the Superchain +SuperchainERC20 is the simplest and most trust-minimized way to enable token interoperability within the Superchain. + +* **Security:** Fault Proofs secure Superchain interop end to end. No third-party dependencies. +* **Latency:** 1-block latency within the Superchain interop cluster. +* **Cost:** Gas on source chain and destination chain. +* **Cross-chain address:** Deterministic, no token registry required. +* **Supported ecosystem:** Superchain interop cluster. ## Alternative implementation options (ERC-7281 Standard) @@ -55,6 +59,8 @@ If your token requires interoperability beyond the Superchain, you can consider * **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. * **Latency:** 1-block latency in the Superchain. Outside latency varies based on the messaging service used. +* **Cost:** Variable based on allowlisted verification mechanisms. +* **Cross-chain address:** Deterministic or requires cross-chain registry per deployment. * **Best for:** Projects needing flexible bridge integrations while retaining control over allowlisted bridges. ### OFT From 54eea118ae865a980060a54a906f3be2eac2dd24 Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 18:06:49 -0700 Subject: [PATCH 09/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index b13cb2f99..dfb0087d4 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -41,12 +41,15 @@ SuperchainERC20 is the simplest and most trust-minimized way to enable token int * **Supported ecosystem:** Superchain interop cluster. -## Alternative implementation options (ERC-7281 Standard) +## Alternative implementation options + +While the SuperchainERC20 is the simplest and recommended implementation for giving your token Superchain interop capabilities, other leading token implementations can also benefit from Superchain interop. If you choose to a token standard other than SuperchainERC20 here are a few things to consider: + +### ERC-7802 ### Weakest link risk -If you allowlist both Superchain interop and a third-party messaging service, your token's security is only as strong as the weakest service. -A compromised third-party service could allow malicious minting or double spending. +If you allowlist both Superchain interop and a third-party verification mechanism, your token's security is only as strong as the weakest verification mechanism. ### SuperchainTokenBridge vs. Superchain interop messaging @@ -61,19 +64,25 @@ If your token requires interoperability beyond the Superchain, you can consider * **Latency:** 1-block latency in the Superchain. Outside latency varies based on the messaging service used. * **Cost:** Variable based on allowlisted verification mechanisms. * **Cross-chain address:** Deterministic or requires cross-chain registry per deployment. +* **Supported ecosystem:** EVM * **Best for:** Projects needing flexible bridge integrations while retaining control over allowlisted bridges. ### OFT * **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. * **Latency:** 1-block latency within the Superchain. External latency depends on **DVN finality time**. -* **Best for:** Tokens requiring cross-chain transfer beyond the Superchain (e.g., Solana, Arbitrum). +* **Cost:** Variable based on allowlisted verification mechanisms. +* **Cross-chain address:** Requires cross-chain registry per deployment. +* **Supported ecosystem:** EVM, Solana, MoveVM ### NTT * **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. * **Latency:** 1-block latency within the Superchain. External latency varies based on transceiver finality. -* **Best for:** Projects that want Wormhole's network for cross-chain transfer. (Superchain integration is still in progress.) +* **Cost:** Variable based on allowlisted verification mechanisms. +* **Cross-chain address:** Requires cross-chain registry per deployment. +* **Supported ecosystem:** EVM, Solana, MoveVM + ### Key takeaways From 4ba2bd7d525f5ba905853915e5bea3ced1ec84c8 Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 18:26:50 -0700 Subject: [PATCH 10/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index dfb0087d4..b41aef74d 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -11,12 +11,12 @@ import { InteropCallout } from '@/components/WipCallout' # Superchain interop compatible tokens -Superchain interop enables **secure, gas-only, 1-block latency cross-chain composability** on the [Superchain interop cluster](/stack/interop/explainer#superchain-interop-cluster). +Superchain interop enables **trust-minimized, 1-block latency cross-chain composability** on the [Superchain interop cluster](/stack/interop/explainer#superchain-interop-cluster). The **recommended** approach for enabling interop capabilities for tokens is using [SuperchainERC20](/stack/interop/superchain-erc20), but there are other options depending on your needs. ## How tokens go cross-chain -Compared to traditional ERC-20 tokens deployments on a single blockchain, cross-chain tokens can move between different networks through giving crosschainMint and crosschainBurn permissions to a verification mechanism (such as a bridge protocol) that validates when tokens should be burned on one chain and minted on another. +Compared to traditional ERC-20 tokens deployments on a single blockchain, cross-chain tokens can move between different blockchains through giving crosschainMint and crosschainBurn permissions to a verification mechanism (such as a bridge protocol) that validates when tokens should be burned on one chain and minted on another. For example when transferring a SuperchainERC20 between chains in the Superchain interop cluster, the Superchain interop protocol ensures the tokens are burned on the source chain before authorizing the corresponding mint on the destination chain. @@ -43,20 +43,22 @@ SuperchainERC20 is the simplest and most trust-minimized way to enable token int ## Alternative implementation options -While the SuperchainERC20 is the simplest and recommended implementation for giving your token Superchain interop capabilities, other leading token implementations can also benefit from Superchain interop. If you choose to a token standard other than SuperchainERC20 here are a few things to consider: +While the SuperchainERC20 is the simplest and recommended implementation for giving your token Superchain interop capabilities, other leading token implementations can also benefit from Superchain interop. If you choose a token standard other than SuperchainERC20 here are a few things to consider: -### ERC-7802 +#### ERC-7802 +[`ERC-7802`](https://ethereum-magicians.org/t/erc-7802-crosschain-token-interface/21508) is a minimal cross-chain mint/burn interface designed to establish a common standard across the EVM ecosystem for tokens to communicate cross-chain. Adding this interface to your token ensures downstream integrators can easily support your token. -### Weakest link risk +#### SuperchainTokenBridge vs. L2ToL2CrossDomainMessenger +Tokens can benefit from Superchain interop by either giving cross-chain mint/burn permissions to the `SuperchainTokenBridge` or the `L2ToL2CrossDomainMessenger`. -If you allowlist both Superchain interop and a third-party verification mechanism, your token's security is only as strong as the weakest verification mechanism. +The [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) is an abstraction built on top of the **`L2ToL2CrossDomainMessenger`** that facilitates token bridging using interop, but requires the token address be deterministic across chains. + +Alternatively, you can use the `L2ToL2CrossDomainMessenger` to faclitate cross-chain mint/burns **does not** require a deterministic address across chains but requires the token issuer to manage a token registry per chain. -### SuperchainTokenBridge vs. Superchain interop messaging -The [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) is an abstraction built on top of the **Cross-Domain Messenger (CDM)**. -Anyone can build a custom bridge on the **L2-to-L2 CDM**, but it may not follow the invariant of maintaining the same token address across chains. +#### Weakest link scenario -If your token requires interoperability beyond the Superchain, you can consider one of the following **ERC-7281-compliant** options. These introduce external dependencies that must be allowlisted. +If you allowlist both Superchain interop and a third-party verification mechanism, your token's security is only as strong as the weakest verification mechanism. ### xERC20 (ERC-7281) From e2da225193df10c8f72469f706e0b36b4b645043 Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 21:39:27 -0700 Subject: [PATCH 11/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 38 ++++++++++++++---------- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index b41aef74d..693bc102b 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -1,7 +1,7 @@ --- title: Superchain interop compatible tokens lang: en-US -description: Learn how different tokens can benefit from Superchain interop and benefit from secure, low-latency, cross-chain composability. +description: Learn how different tokens can use from Superchain interop and benefit from secure, low-latency, cross-chain composability. --- import { Callout } from 'nextra/components' @@ -12,29 +12,29 @@ import { InteropCallout } from '@/components/WipCallout' # Superchain interop compatible tokens Superchain interop enables **trust-minimized, 1-block latency cross-chain composability** on the [Superchain interop cluster](/stack/interop/explainer#superchain-interop-cluster). -The **recommended** approach for enabling interop capabilities for tokens is using [SuperchainERC20](/stack/interop/superchain-erc20), but there are other options depending on your needs. +The recommended approach for enabling Superchain interop capabilities for tokens is using [SuperchainERC20](/stack/interop/superchain-erc20), but there are other options depending on your needs. ## How tokens go cross-chain -Compared to traditional ERC-20 tokens deployments on a single blockchain, cross-chain tokens can move between different blockchains through giving crosschainMint and crosschainBurn permissions to a verification mechanism (such as a bridge protocol) that validates when tokens should be burned on one chain and minted on another. +Compared to traditional ERC-20 tokens deployments on a single blockchain, cross-chain tokens can move between different blockchains through giving `crosschainMint` and `crosschainBurn` permissions to a verification mechanism (such as a bridge protocol) that validates when tokens should be burned on one chain and minted on another. For example when transferring a SuperchainERC20 between chains in the Superchain interop cluster, the Superchain interop protocol ensures the tokens are burned on the source chain before authorizing the corresponding mint on the destination chain. When enabling cross-chain functionality for your token, it is essential to evaluate the security, cost, and latency of the respective verification mechanism. -## Why give your token cross-chain functionality with Superchain interop? +## Why give your token crosschain mint / burn functionality with Superchain interop? * **Low latency:** 1-block latency ensures fast cross-chain token transfers. -* **No fees:** Transfers happen at a 1:1 rate with no liquidity pools—just gas. +* **0-slippage:** Transfers happen at a 1:1 rate with no need for liquidity pools—just pay for gas. * **Security:** Fault Proofs secure Superchain interop end to end. * **[Reorg awareness](./reorg):** Enables 1-block latency cross-chain composability that mitigates the double-spend problem. ## SuperchainERC20 -SuperchainERC20 is the simplest and most trust-minimized way to enable token interoperability within the Superchain. +SuperchainERC20 is a simple and trust-minimized way to enable token interoperability within the Superchain. -* **Security:** Fault Proofs secure Superchain interop end to end. No third-party dependencies. +* **Security:** Fault Proofs secure Superchain interop end to end. No third-party dependencies to enable token interoperability. * **Latency:** 1-block latency within the Superchain interop cluster. * **Cost:** Gas on source chain and destination chain. * **Cross-chain address:** Deterministic, no token registry required. @@ -43,18 +43,17 @@ SuperchainERC20 is the simplest and most trust-minimized way to enable token int ## Alternative implementation options -While the SuperchainERC20 is the simplest and recommended implementation for giving your token Superchain interop capabilities, other leading token implementations can also benefit from Superchain interop. If you choose a token standard other than SuperchainERC20 here are a few things to consider: +While the SuperchainERC20 is a trust-minimized way to enable for giving your token Superchain interop capabilities, other token implementations can also benefit from Superchain interop. If you choose a token standard other than SuperchainERC20 here are a few things to consider: #### ERC-7802 [`ERC-7802`](https://ethereum-magicians.org/t/erc-7802-crosschain-token-interface/21508) is a minimal cross-chain mint/burn interface designed to establish a common standard across the EVM ecosystem for tokens to communicate cross-chain. Adding this interface to your token ensures downstream integrators can easily support your token. -#### SuperchainTokenBridge vs. L2ToL2CrossDomainMessenger +#### SuperchainTokenBridge and L2ToL2CrossDomainMessenger Tokens can benefit from Superchain interop by either giving cross-chain mint/burn permissions to the `SuperchainTokenBridge` or the `L2ToL2CrossDomainMessenger`. The [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) is an abstraction built on top of the **`L2ToL2CrossDomainMessenger`** that facilitates token bridging using interop, but requires the token address be deterministic across chains. -Alternatively, you can use the `L2ToL2CrossDomainMessenger` to faclitate cross-chain mint/burns **does not** require a deterministic address across chains but requires the token issuer to manage a token registry per chain. - +Alternatively, you can use the `L2ToL2CrossDomainMessenger` to faclitate cross-chain mint/burns and **does not** require a deterministic address across chains but requires the token issuer to manage a token registry per chain. #### Weakest link scenario @@ -62,6 +61,8 @@ If you allowlist both Superchain interop and a third-party verification mechanis ### xERC20 (ERC-7281) +xERC20 tokens are crosschain ERC-20 which can be transferred across chains by allowing the token owner to approve which bridges can mint/burn their token and the ability to set rate limits per bridge. + * **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. * **Latency:** 1-block latency in the Superchain. Outside latency varies based on the messaging service used. * **Cost:** Variable based on allowlisted verification mechanisms. @@ -71,6 +72,8 @@ If you allowlist both Superchain interop and a third-party verification mechanis ### OFT +OFT is a token standard used to send, receive, and compose assets across all the chains LayerZero supports. + * **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. * **Latency:** 1-block latency within the Superchain. External latency depends on **DVN finality time**. * **Cost:** Variable based on allowlisted verification mechanisms. @@ -79,6 +82,8 @@ If you allowlist both Superchain interop and a third-party verification mechanis ### NTT +NTT is a token standard used to send, receive, and compose assets across all the chains Wormhole supports. + * **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. * **Latency:** 1-block latency within the Superchain. External latency varies based on transceiver finality. * **Cost:** Variable based on allowlisted verification mechanisms. @@ -86,12 +91,13 @@ If you allowlist both Superchain interop and a third-party verification mechanis * **Supported ecosystem:** EVM, Solana, MoveVM -### Key takeaways +## Key takeaways -* **SuperchainERC20** is the simplest way for token issuers to get Superchain interop cluster wide distribution. -* Token issuers can use other options (xERC20, OFT, NTT) and allowlist Superchain interop or the SuperchainTokenBridge to benefit from Superchain interop. -* When using tokens other than SuperchainERC20, token issuers should include a ERC-7802 interface to simplify developer experience. -* Using 3rd party verification mechanisms introduces external dependencies and potential security risks. +* **SuperchainERC20** is a simple and trust-minimized way for token issuers to make their token available across the Superchain interop cluster. +* Token issuers can use other token standards (xERC20, OFT, NTT) and allowlist Superchain interop or the SuperchainTokenBridge to benefit from Superchain interop. +* When using tokens other than SuperchainERC20: + * Token issuers should include a ERC-7802 interface on the token to simplify downstream integrations. + * Using 3rd party verification mechanisms introduces external dependencies and potential security risks. ## Next steps From 03cefeeaf119ecc7a288299f6e66bceaa1bc353b Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 21:43:01 -0700 Subject: [PATCH 12/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index 693bc102b..fba119e2d 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -51,7 +51,7 @@ While the SuperchainERC20 is a trust-minimized way to enable for giving your tok #### SuperchainTokenBridge and L2ToL2CrossDomainMessenger Tokens can benefit from Superchain interop by either giving cross-chain mint/burn permissions to the `SuperchainTokenBridge` or the `L2ToL2CrossDomainMessenger`. -The [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) is an abstraction built on top of the **`L2ToL2CrossDomainMessenger`** that facilitates token bridging using interop, but requires the token address be deterministic across chains. +The [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) is an abstraction built on top of the **`L2ToL2CrossDomainMessenger`** that facilitates token bridging using Superchain interop, but requires the token address be deterministic across chains. Alternatively, you can use the `L2ToL2CrossDomainMessenger` to faclitate cross-chain mint/burns and **does not** require a deterministic address across chains but requires the token issuer to manage a token registry per chain. @@ -68,7 +68,6 @@ xERC20 tokens are crosschain ERC-20 which can be transferred across chains by al * **Cost:** Variable based on allowlisted verification mechanisms. * **Cross-chain address:** Deterministic or requires cross-chain registry per deployment. * **Supported ecosystem:** EVM -* **Best for:** Projects needing flexible bridge integrations while retaining control over allowlisted bridges. ### OFT @@ -93,11 +92,10 @@ NTT is a token standard used to send, receive, and compose assets across all the ## Key takeaways -* **SuperchainERC20** is a simple and trust-minimized way for token issuers to make their token available across the Superchain interop cluster. -* Token issuers can use other token standards (xERC20, OFT, NTT) and allowlist Superchain interop or the SuperchainTokenBridge to benefit from Superchain interop. -* When using tokens other than SuperchainERC20: - * Token issuers should include a ERC-7802 interface on the token to simplify downstream integrations. - * Using 3rd party verification mechanisms introduces external dependencies and potential security risks. +* `SuperchainERC20` is a simple and trust-minimized way for token issuers to make their token available across the Superchain interop cluster. +* Token issuers can use other token standards (xERC20, OFT, NTT) and use the `SuperchainTokenBridge` or `L2ToL2CrossDomainMessenger` to benefit from Superchain interop. +* Token issuers should include a ERC-7802 interface on the token to simplify downstream integrations. +* Using 3rd party verification mechanisms introduces external dependencies and potential security risks. ## Next steps From fbe15486a86e26156c536d7a6055f3c860c1a38f Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 22:02:00 -0700 Subject: [PATCH 13/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 30 +++++++++++++----------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index fba119e2d..e8164fa6f 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -12,7 +12,7 @@ import { InteropCallout } from '@/components/WipCallout' # Superchain interop compatible tokens Superchain interop enables **trust-minimized, 1-block latency cross-chain composability** on the [Superchain interop cluster](/stack/interop/explainer#superchain-interop-cluster). -The recommended approach for enabling Superchain interop capabilities for tokens is using [SuperchainERC20](/stack/interop/superchain-erc20), but there are other options depending on your needs. +The recommended approach for giving tokens Superchain interop capabilities is using [SuperchainERC20](/stack/interop/superchain-erc20), but there are other options depending on your needs. ## How tokens go cross-chain @@ -23,16 +23,18 @@ For example when transferring a SuperchainERC20 between chains in the Superchain When enabling cross-chain functionality for your token, it is essential to evaluate the security, cost, and latency of the respective verification mechanism. -## Why give your token crosschain mint / burn functionality with Superchain interop? +## Why use Superchain interop to move your tokens cross chain? + +Apps built with Superchain interop can essentially teleport tokens from one blockchain to another, providing users with a secure, low-latency, and capitally-efficient way to transact on the Superchain. * **Low latency:** 1-block latency ensures fast cross-chain token transfers. -* **0-slippage:** Transfers happen at a 1:1 rate with no need for liquidity pools—just pay for gas. +* **0-slippage:** Transfers happen at a 1:1 rate with no need for asset wrapping or liquidity pools—just pay for gas. * **Security:** Fault Proofs secure Superchain interop end to end. * **[Reorg awareness](./reorg):** Enables 1-block latency cross-chain composability that mitigates the double-spend problem. ## SuperchainERC20 -SuperchainERC20 is a simple and trust-minimized way to enable token interoperability within the Superchain. +SuperchainERC20 is a simple and trust-minimized way to enable token interoperability within the Superchain. You can learn more about SuperchainERC20 [here](/stack/interop/superchain-erc20). * **Security:** Fault Proofs secure Superchain interop end to end. No third-party dependencies to enable token interoperability. * **Latency:** 1-block latency within the Superchain interop cluster. @@ -51,7 +53,7 @@ While the SuperchainERC20 is a trust-minimized way to enable for giving your tok #### SuperchainTokenBridge and L2ToL2CrossDomainMessenger Tokens can benefit from Superchain interop by either giving cross-chain mint/burn permissions to the `SuperchainTokenBridge` or the `L2ToL2CrossDomainMessenger`. -The [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) is an abstraction built on top of the **`L2ToL2CrossDomainMessenger`** that facilitates token bridging using Superchain interop, but requires the token address be deterministic across chains. +The [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) is an abstraction built on top of the [`L2ToL2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/L2ToL2CrossDomainMessenger.sol) that facilitates token bridging using Superchain interop, but requires the token address be deterministic across chains. Alternatively, you can use the `L2ToL2CrossDomainMessenger` to faclitate cross-chain mint/burns and **does not** require a deterministic address across chains but requires the token issuer to manage a token registry per chain. @@ -61,30 +63,30 @@ If you allowlist both Superchain interop and a third-party verification mechanis ### xERC20 (ERC-7281) -xERC20 tokens are crosschain ERC-20 which can be transferred across chains by allowing the token owner to approve which bridges can mint/burn their token and the ability to set rate limits per bridge. +xERC20 tokens are crosschain ERC-20 which can be transferred across chains by allowing the token owner to approve which bridges can mint/burn their token and the ability to set rate limits per bridge. You can learn more about xERC20 and Superchain interop [here](https://github.com/ethereum-optimism/design-docs/pull/203). * **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. -* **Latency:** 1-block latency in the Superchain. Outside latency varies based on the messaging service used. +* **Latency:** 1-block latency in the Superchain. Outside the Superchain, latency is variable based on allowlisted verification mechanism. * **Cost:** Variable based on allowlisted verification mechanisms. * **Cross-chain address:** Deterministic or requires cross-chain registry per deployment. * **Supported ecosystem:** EVM ### OFT -OFT is a token standard used to send, receive, and compose assets across all the chains LayerZero supports. +OFT is a token standard used to send, receive, and compose assets across all the chains LayerZero supports. More information will be added about how OFTs can benefit from Superchain interop at a later date. * **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. -* **Latency:** 1-block latency within the Superchain. External latency depends on **DVN finality time**. +* **Latency:** 1-block latency within the Superchain. Outside the Superchain, latency is variable based on allowlisted verification (DVN) mechanism. * **Cost:** Variable based on allowlisted verification mechanisms. * **Cross-chain address:** Requires cross-chain registry per deployment. * **Supported ecosystem:** EVM, Solana, MoveVM ### NTT -NTT is a token standard used to send, receive, and compose assets across all the chains Wormhole supports. +NTT is a token standard used to send, receive, and compose assets across all the chains Wormhole supports. More information will be added about how NTTs can benefit from Superchain interop at a later date. * **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. -* **Latency:** 1-block latency within the Superchain. External latency varies based on transceiver finality. +* **Latency:** 1-block latency within the Superchain. Outside the Superchain, latency is variable based on allowlisted verification (transceiver) mechanism. * **Cost:** Variable based on allowlisted verification mechanisms. * **Cross-chain address:** Requires cross-chain registry per deployment. * **Supported ecosystem:** EVM, Solana, MoveVM @@ -93,9 +95,9 @@ NTT is a token standard used to send, receive, and compose assets across all the ## Key takeaways * `SuperchainERC20` is a simple and trust-minimized way for token issuers to make their token available across the Superchain interop cluster. -* Token issuers can use other token standards (xERC20, OFT, NTT) and use the `SuperchainTokenBridge` or `L2ToL2CrossDomainMessenger` to benefit from Superchain interop. -* Token issuers should include a ERC-7802 interface on the token to simplify downstream integrations. -* Using 3rd party verification mechanisms introduces external dependencies and potential security risks. +* Token issuers can use other token standards (xERC20, OFT, NTT) and give `crosschainMint` and `crosschainBurn` permissions to the `SuperchainTokenBridge` or `L2ToL2CrossDomainMessenger` to benefit from Superchain interop. +* Token issuers should include a ERC-7802 interface on their token to simplify downstream integrations. +* Using 3rd party verification mechanisms introduces additional trust assumptions. ## Next steps From 24afc8c97fd131c04f5d0deec919f2c661134369 Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 22:04:04 -0700 Subject: [PATCH 14/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index e8164fa6f..143be907c 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -55,7 +55,7 @@ Tokens can benefit from Superchain interop by either giving cross-chain mint/bur The [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) is an abstraction built on top of the [`L2ToL2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/L2ToL2CrossDomainMessenger.sol) that facilitates token bridging using Superchain interop, but requires the token address be deterministic across chains. -Alternatively, you can use the `L2ToL2CrossDomainMessenger` to faclitate cross-chain mint/burns and **does not** require a deterministic address across chains but requires the token issuer to manage a token registry per chain. +Alternatively, you can build a custom bridge using the `L2ToL2CrossDomainMessenger` to faclitate cross-chain mint/burns that **does not** require a deterministic address across chains but does require the token issuer to manage a token registry per chain. #### Weakest link scenario From 5a32025bae377064d498e89ea30b8c4c6b2335f5 Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 22:10:11 -0700 Subject: [PATCH 15/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index 143be907c..301b40fa2 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -14,7 +14,7 @@ import { InteropCallout } from '@/components/WipCallout' Superchain interop enables **trust-minimized, 1-block latency cross-chain composability** on the [Superchain interop cluster](/stack/interop/explainer#superchain-interop-cluster). The recommended approach for giving tokens Superchain interop capabilities is using [SuperchainERC20](/stack/interop/superchain-erc20), but there are other options depending on your needs. -## How tokens go cross-chain +## How to enable cross-chain token interoperability Compared to traditional ERC-20 tokens deployments on a single blockchain, cross-chain tokens can move between different blockchains through giving `crosschainMint` and `crosschainBurn` permissions to a verification mechanism (such as a bridge protocol) that validates when tokens should be burned on one chain and minted on another. @@ -23,13 +23,13 @@ For example when transferring a SuperchainERC20 between chains in the Superchain When enabling cross-chain functionality for your token, it is essential to evaluate the security, cost, and latency of the respective verification mechanism. -## Why use Superchain interop to move your tokens cross chain? +## Why use Superchain interop to enable cross-chain token interoperability Apps built with Superchain interop can essentially teleport tokens from one blockchain to another, providing users with a secure, low-latency, and capitally-efficient way to transact on the Superchain. -* **Low latency:** 1-block latency ensures fast cross-chain token transfers. -* **0-slippage:** Transfers happen at a 1:1 rate with no need for asset wrapping or liquidity pools—just pay for gas. * **Security:** Fault Proofs secure Superchain interop end to end. +* **Latency:** 1-block latency ensures fast cross-chain token transfers. +* **Cost:** Transfers happen at a 1:1 rate with no need for token wrapping or liquidity pools—just pay for gas. * **[Reorg awareness](./reorg):** Enables 1-block latency cross-chain composability that mitigates the double-spend problem. ## SuperchainERC20 @@ -73,7 +73,7 @@ xERC20 tokens are crosschain ERC-20 which can be transferred across chains by al ### OFT -OFT is a token standard used to send, receive, and compose assets across all the chains LayerZero supports. More information will be added about how OFTs can benefit from Superchain interop at a later date. +OFT is a token standard used to send, receive, and compose tokens across chains LayerZero supports. More information will be added about how OFTs can benefit from Superchain interop at a later date. * **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. * **Latency:** 1-block latency within the Superchain. Outside the Superchain, latency is variable based on allowlisted verification (DVN) mechanism. @@ -83,7 +83,7 @@ OFT is a token standard used to send, receive, and compose assets across all the ### NTT -NTT is a token standard used to send, receive, and compose assets across all the chains Wormhole supports. More information will be added about how NTTs can benefit from Superchain interop at a later date. +NTT is a token standard used to send, receive, and compose tokens chains Wormhole supports. More information will be added about how NTTs can benefit from Superchain interop at a later date. * **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. * **Latency:** 1-block latency within the Superchain. Outside the Superchain, latency is variable based on allowlisted verification (transceiver) mechanism. @@ -97,10 +97,9 @@ NTT is a token standard used to send, receive, and compose assets across all the * `SuperchainERC20` is a simple and trust-minimized way for token issuers to make their token available across the Superchain interop cluster. * Token issuers can use other token standards (xERC20, OFT, NTT) and give `crosschainMint` and `crosschainBurn` permissions to the `SuperchainTokenBridge` or `L2ToL2CrossDomainMessenger` to benefit from Superchain interop. * Token issuers should include a ERC-7802 interface on their token to simplify downstream integrations. -* Using 3rd party verification mechanisms introduces additional trust assumptions. ## Next steps -* [Deploy a SuperchainERC20 token](/stack/interop/superchain-erc20) -* [Learn more about interoperability](/stack/interop/explainer) -* [Build a cross-chain app on the Superchain](/app-developers/get-started) +* Build a [revolutionary app](/app-developers/get-started) that uses multiple blockchains within the Superchain +* Deploy a [SuperchainERC20](/stack/interop/tutorials/deploy-superchain-erc20) to the Superchain +* [Learn more about SuperchainERC20](/stack/interop/superchain-erc20) From d93730952317af5eb176811d013f2091fa9d8717 Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 22:13:36 -0700 Subject: [PATCH 16/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index 301b40fa2..8b561e742 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -1,7 +1,7 @@ --- title: Superchain interop compatible tokens lang: en-US -description: Learn how different tokens can use from Superchain interop and benefit from secure, low-latency, cross-chain composability. +description: Learn how different tokens can use Superchain interop and benefit from secure, low-latency, cross-chain composability. --- import { Callout } from 'nextra/components' @@ -34,7 +34,7 @@ Apps built with Superchain interop can essentially teleport tokens from one bloc ## SuperchainERC20 -SuperchainERC20 is a simple and trust-minimized way to enable token interoperability within the Superchain. You can learn more about SuperchainERC20 [here](/stack/interop/superchain-erc20). +`SuperchainERC20` is a simple and trust-minimized way to enable token interoperability within the Superchain. You can learn more about `SuperchainERC20` [here](/stack/interop/superchain-erc20). * **Security:** Fault Proofs secure Superchain interop end to end. No third-party dependencies to enable token interoperability. * **Latency:** 1-block latency within the Superchain interop cluster. @@ -43,9 +43,9 @@ SuperchainERC20 is a simple and trust-minimized way to enable token interoperabi * **Supported ecosystem:** Superchain interop cluster. -## Alternative implementation options +## Considerations when using other token implementations -While the SuperchainERC20 is a trust-minimized way to enable for giving your token Superchain interop capabilities, other token implementations can also benefit from Superchain interop. If you choose a token standard other than SuperchainERC20 here are a few things to consider: +While the `SuperchainERC20` is a trust-minimized way to enable for giving your token Superchain interop capabilities, other token implementations can also benefit from Superchain interop. If you choose a token standard other than SuperchainERC20 here are a few things to consider: #### ERC-7802 [`ERC-7802`](https://ethereum-magicians.org/t/erc-7802-crosschain-token-interface/21508) is a minimal cross-chain mint/burn interface designed to establish a common standard across the EVM ecosystem for tokens to communicate cross-chain. Adding this interface to your token ensures downstream integrators can easily support your token. @@ -61,6 +61,8 @@ Alternatively, you can build a custom bridge using the `L2ToL2CrossDomainMesseng If you allowlist both Superchain interop and a third-party verification mechanism, your token's security is only as strong as the weakest verification mechanism. +## Alternative token implementations + ### xERC20 (ERC-7281) xERC20 tokens are crosschain ERC-20 which can be transferred across chains by allowing the token owner to approve which bridges can mint/burn their token and the ability to set rate limits per bridge. You can learn more about xERC20 and Superchain interop [here](https://github.com/ethereum-optimism/design-docs/pull/203). @@ -96,7 +98,7 @@ NTT is a token standard used to send, receive, and compose tokens chains Wormhol * `SuperchainERC20` is a simple and trust-minimized way for token issuers to make their token available across the Superchain interop cluster. * Token issuers can use other token standards (xERC20, OFT, NTT) and give `crosschainMint` and `crosschainBurn` permissions to the `SuperchainTokenBridge` or `L2ToL2CrossDomainMessenger` to benefit from Superchain interop. -* Token issuers should include a ERC-7802 interface on their token to simplify downstream integrations. +* Token issuers should include a `ERC-7802` interface on their token to simplify downstream integrations. ## Next steps From 0facea56b1b70e37837cbe588b537d2e241909ea Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 22:14:22 -0700 Subject: [PATCH 17/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index 8b561e742..de6df4b6a 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -18,7 +18,7 @@ The recommended approach for giving tokens Superchain interop capabilities is us Compared to traditional ERC-20 tokens deployments on a single blockchain, cross-chain tokens can move between different blockchains through giving `crosschainMint` and `crosschainBurn` permissions to a verification mechanism (such as a bridge protocol) that validates when tokens should be burned on one chain and minted on another. -For example when transferring a SuperchainERC20 between chains in the Superchain interop cluster, the Superchain interop protocol ensures the tokens are burned on the source chain before authorizing the corresponding mint on the destination chain. +For example when transferring a `SuperchainERC20` between chains in the Superchain interop cluster, the Superchain interop protocol ensures the tokens are burned on the source chain before authorizing the corresponding mint on the destination chain. When enabling cross-chain functionality for your token, it is essential to evaluate the security, cost, and latency of the respective verification mechanism. From fc01c90b05e55d5eaf36844ec61df0bfbd3987fa Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 22:21:20 -0700 Subject: [PATCH 18/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index de6df4b6a..9f71d65f0 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -1,7 +1,7 @@ --- title: Superchain interop compatible tokens lang: en-US -description: Learn how different tokens can use Superchain interop and benefit from secure, low-latency, cross-chain composability. +description: Learn how different tokens can use Superchain interop to benefit from secure, low-latency, cross-chain composability. --- import { Callout } from 'nextra/components' From 7fde1e8e7edcf97d1880a6598f264a5a4162ebb8 Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 22:23:31 -0700 Subject: [PATCH 19/27] Update _meta.json --- pages/stack/interop/_meta.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pages/stack/interop/_meta.json b/pages/stack/interop/_meta.json index ca76e742a..ebf78446c 100644 --- a/pages/stack/interop/_meta.json +++ b/pages/stack/interop/_meta.json @@ -2,11 +2,11 @@ "explainer": "Superchain interop explainer", "predeploy": "Superchain interop predeploys", "message-passing": "Superchain interop message passing", - "token-compatible": "Superchain interop compatible token", "op-supervisor": "OP Supervisor", "superchain-weth": "Interoperable ETH", "superchain-erc20": "SuperchainERC20", - "reorg": "Interop reorg awareness", + "token-compatible": "Superchain interop compatible tokens", + "reorg": "Superchain interop reorg awareness", "interop-security": "Superchain interop transaction safety", "tools": "Tools", "tutorials": "Tutorials" From 96e989452171fc5179f29a05ead88602094cc82f Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 22:29:02 -0700 Subject: [PATCH 20/27] Update interop.mdx --- pages/stack/interop.mdx | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/pages/stack/interop.mdx b/pages/stack/interop.mdx index e74c32888..063bfe57f 100644 --- a/pages/stack/interop.mdx +++ b/pages/stack/interop.mdx @@ -1,5 +1,5 @@ --- -title: Interop +title: Superchain interop description: Documentation covering Cross Chain Message, Explainer, Message Passing, Op Supervisor, Superchain Erc20, Superchain Weth, Supersim, Transfer Superchainerc20 in the Interop section of the OP Stack ecosystem. lang: en-US --- @@ -8,34 +8,32 @@ import { Card, Cards } from 'nextra/components' # Interop -Documentation covering Cross Chain Message, Explainer, Message Passing, Op Supervisor, Superchain Erc20, Superchain Weth, Supersim, Transfer Superchainerc20 in the Interop section of the OP Stack ecosystem. +Documentation covering explainers and tutorials for using Superchain interop. - } /> + } /> - } /> + } /> - } /> + } /> - } /> + } /> } /> } /> - } /> + } /> - } /> - - } /> + } /> } /> - } /> + } /> } /> - } /> + } /> - + }/> From b5d187d5d48fe8e166613ee8e7c749248aa6bc5e Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 22:29:19 -0700 Subject: [PATCH 21/27] Update _meta.json --- pages/stack/interop/_meta.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/interop/_meta.json b/pages/stack/interop/_meta.json index ebf78446c..734346b9a 100644 --- a/pages/stack/interop/_meta.json +++ b/pages/stack/interop/_meta.json @@ -3,7 +3,7 @@ "predeploy": "Superchain interop predeploys", "message-passing": "Superchain interop message passing", "op-supervisor": "OP Supervisor", - "superchain-weth": "Interoperable ETH", + "superchain-weth": "Superchain ETH", "superchain-erc20": "SuperchainERC20", "token-compatible": "Superchain interop compatible tokens", "reorg": "Superchain interop reorg awareness", From 2f60bd5b74dd9543fda6d5bbce4bf20c714fdf4f Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 22:37:04 -0700 Subject: [PATCH 22/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index 9f71d65f0..0d55cf64d 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -27,10 +27,7 @@ When enabling cross-chain functionality for your token, it is essential to evalu Apps built with Superchain interop can essentially teleport tokens from one blockchain to another, providing users with a secure, low-latency, and capitally-efficient way to transact on the Superchain. -* **Security:** Fault Proofs secure Superchain interop end to end. -* **Latency:** 1-block latency ensures fast cross-chain token transfers. -* **Cost:** Transfers happen at a 1:1 rate with no need for token wrapping or liquidity pools—just pay for gas. -* **[Reorg awareness](./reorg):** Enables 1-block latency cross-chain composability that mitigates the double-spend problem. +3rd party interop solutions for L2s often wait for Ethereum finalization (15min+) when transferring tokens from an L2 to mitigate the double spend problem. However, that solution results in high latency and poor user experience. Superchain interop is reorg aware](./reorg) - this means users can transfer assets across chains in the Superchain with 1-block latency, and should a reorg happen, either both the source and destination transactions would remain, or both of them would revert. In every case, there is no window of opportunity to double spend. Low latency interop that mitigates the double spend problem is now possible with Superchain interop. ## SuperchainERC20 From 0ab687a97306f91dec811ae046510a740171df89 Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 22:44:07 -0700 Subject: [PATCH 23/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index 0d55cf64d..9ec5b7b54 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -27,7 +27,7 @@ When enabling cross-chain functionality for your token, it is essential to evalu Apps built with Superchain interop can essentially teleport tokens from one blockchain to another, providing users with a secure, low-latency, and capitally-efficient way to transact on the Superchain. -3rd party interop solutions for L2s often wait for Ethereum finalization (15min+) when transferring tokens from an L2 to mitigate the double spend problem. However, that solution results in high latency and poor user experience. Superchain interop is reorg aware](./reorg) - this means users can transfer assets across chains in the Superchain with 1-block latency, and should a reorg happen, either both the source and destination transactions would remain, or both of them would revert. In every case, there is no window of opportunity to double spend. Low latency interop that mitigates the double spend problem is now possible with Superchain interop. +3rd party interop solutions for L2s often wait for Ethereum finalization (15min+) when transferring tokens from an L2 to mitigate the double spend problem. However, that solution results in high latency and poor user experience. Superchain interop is [reorg aware](./reorg) - this means users can transfer assets across chains in the Superchain with 1-block latency, and should a reorg happen, either both the source and destination transactions would remain, or both of them would revert. In every case, there is no window of opportunity to double spend. Low latency interop that mitigates the double spend problem is now possible with Superchain interop. ## SuperchainERC20 From d96d630ba1f0a4bc3cabbaa7e321cac3b10faa9c Mon Sep 17 00:00:00 2001 From: Zain Bacchus Date: Wed, 26 Feb 2025 23:14:57 -0700 Subject: [PATCH 24/27] Update token-compatible.mdx --- pages/stack/interop/token-compatible.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index 9ec5b7b54..a163fab52 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -82,7 +82,7 @@ OFT is a token standard used to send, receive, and compose tokens across chains ### NTT -NTT is a token standard used to send, receive, and compose tokens chains Wormhole supports. More information will be added about how NTTs can benefit from Superchain interop at a later date. +NTT is a token standard used to send, receive, and compose tokens across chains Wormhole supports. More information will be added about how NTTs can benefit from Superchain interop at a later date. * **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. * **Latency:** 1-block latency within the Superchain. Outside the Superchain, latency is variable based on allowlisted verification (transceiver) mechanism. From 83868b761509ae3b920e10c747bc50476ba2e1bf Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 27 Feb 2025 17:42:22 +0100 Subject: [PATCH 25/27] fix lint --- pages/stack/interop/token-compatible.mdx | 2 +- words.txt | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index a163fab52..03461fd1a 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -52,7 +52,7 @@ Tokens can benefit from Superchain interop by either giving cross-chain mint/bur The [`SuperchainTokenBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/SuperchainTokenBridge.sol) is an abstraction built on top of the [`L2ToL2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/L2ToL2CrossDomainMessenger.sol) that facilitates token bridging using Superchain interop, but requires the token address be deterministic across chains. -Alternatively, you can build a custom bridge using the `L2ToL2CrossDomainMessenger` to faclitate cross-chain mint/burns that **does not** require a deterministic address across chains but does require the token issuer to manage a token registry per chain. +Alternatively, you can build a custom bridge using the `L2ToL2CrossDomainMessenger` to facilitate cross-chain mint/burns that **does not** require a deterministic address across chains but does require the token issuer to manage a token registry per chain. #### Weakest link scenario diff --git a/words.txt b/words.txt index e92639a84..cee537263 100644 --- a/words.txt +++ b/words.txt @@ -367,6 +367,7 @@ smartcard snapshotlog Snapsync snapsync +Solana Soneium soyboy Spearbit From e51372dbc3cfbc7fcfe71a74701ca65aa39cb150 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 27 Feb 2025 17:52:23 +0100 Subject: [PATCH 26/27] update breadcrumbs --- pages/stack/interop.mdx | 2 ++ 1 file changed, 2 insertions(+) diff --git a/pages/stack/interop.mdx b/pages/stack/interop.mdx index 063bfe57f..113b254de 100644 --- a/pages/stack/interop.mdx +++ b/pages/stack/interop.mdx @@ -33,6 +33,8 @@ Documentation covering explainers and tutorials for using Superchain interop. } /> + } /> + } /> }/> From 788e36b84e0e2fc6219d4fd0ae63da0e17a9d413 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 27 Feb 2025 17:59:52 +0100 Subject: [PATCH 27/27] add personas --- pages/stack/interop/token-compatible.mdx | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/pages/stack/interop/token-compatible.mdx b/pages/stack/interop/token-compatible.mdx index 03461fd1a..e61479203 100644 --- a/pages/stack/interop/token-compatible.mdx +++ b/pages/stack/interop/token-compatible.mdx @@ -2,6 +2,10 @@ title: Superchain interop compatible tokens lang: en-US description: Learn how different tokens can use Superchain interop to benefit from secure, low-latency, cross-chain composability. +topic: Superchain Interoperability +personas: ["Developer", "Architect"] +categories: ["Interoperability", "Token"] +content_type: guide --- import { Callout } from 'nextra/components'