|
| 1 | +--- |
| 2 | +title: Superchain interop compatible tokens |
| 3 | +lang: en-US |
| 4 | +description: Learn how different tokens can use Superchain interop to benefit from secure, low-latency, cross-chain composability. |
| 5 | +topic: Superchain Interoperability |
| 6 | +personas: ["Developer", "Architect"] |
| 7 | +categories: ["Interoperability", "Token"] |
| 8 | +content_type: guide |
| 9 | +--- |
| 10 | + |
| 11 | +import { Callout } from 'nextra/components' |
| 12 | +import { InteropCallout } from '@/components/WipCallout' |
| 13 | + |
| 14 | +<InteropCallout /> |
| 15 | + |
| 16 | +# Superchain interop compatible tokens |
| 17 | + |
| 18 | +Superchain interop enables **trust-minimized, 1-block latency cross-chain composability** on the [Superchain interop cluster](/stack/interop/explainer#superchain-interop-cluster). |
| 19 | +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. |
| 20 | + |
| 21 | +## How to enable cross-chain token interoperability |
| 22 | + |
| 23 | +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. |
| 24 | + |
| 25 | +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. |
| 26 | + |
| 27 | +When enabling cross-chain functionality for your token, it is essential to evaluate the security, cost, and latency of the respective verification mechanism. |
| 28 | + |
| 29 | + |
| 30 | +## Why use Superchain interop to enable cross-chain token interoperability |
| 31 | + |
| 32 | +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. |
| 33 | + |
| 34 | +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. |
| 35 | + |
| 36 | +## SuperchainERC20 |
| 37 | + |
| 38 | +`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). |
| 39 | + |
| 40 | +* **Security:** Fault Proofs secure Superchain interop end to end. No third-party dependencies to enable token interoperability. |
| 41 | +* **Latency:** 1-block latency within the Superchain interop cluster. |
| 42 | +* **Cost:** Gas on source chain and destination chain. |
| 43 | +* **Cross-chain address:** Deterministic, no token registry required. |
| 44 | +* **Supported ecosystem:** Superchain interop cluster. |
| 45 | + |
| 46 | + |
| 47 | +## Considerations when using other token implementations |
| 48 | + |
| 49 | +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: |
| 50 | + |
| 51 | +#### ERC-7802 |
| 52 | +[`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. |
| 53 | + |
| 54 | +#### SuperchainTokenBridge and L2ToL2CrossDomainMessenger |
| 55 | +Tokens can benefit from Superchain interop by either giving cross-chain mint/burn permissions to the `SuperchainTokenBridge` or the `L2ToL2CrossDomainMessenger`. |
| 56 | + |
| 57 | +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. |
| 58 | + |
| 59 | +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. |
| 60 | + |
| 61 | +#### Weakest link scenario |
| 62 | + |
| 63 | +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. |
| 64 | + |
| 65 | +## Alternative token implementations |
| 66 | + |
| 67 | +### xERC20 (ERC-7281) |
| 68 | + |
| 69 | +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). |
| 70 | + |
| 71 | +* **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. |
| 72 | +* **Latency:** 1-block latency in the Superchain. Outside the Superchain, latency is variable based on allowlisted verification mechanism. |
| 73 | +* **Cost:** Variable based on allowlisted verification mechanisms. |
| 74 | +* **Cross-chain address:** Deterministic or requires cross-chain registry per deployment. |
| 75 | +* **Supported ecosystem:** EVM |
| 76 | + |
| 77 | +### OFT |
| 78 | + |
| 79 | +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. |
| 80 | + |
| 81 | +* **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. |
| 82 | +* **Latency:** 1-block latency within the Superchain. Outside the Superchain, latency is variable based on allowlisted verification (DVN) mechanism. |
| 83 | +* **Cost:** Variable based on allowlisted verification mechanisms. |
| 84 | +* **Cross-chain address:** Requires cross-chain registry per deployment. |
| 85 | +* **Supported ecosystem:** EVM, Solana, MoveVM |
| 86 | + |
| 87 | +### NTT |
| 88 | + |
| 89 | +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. |
| 90 | + |
| 91 | +* **Security:** Variable due to weakest-link scenario based on allowlisted verification mechanisms. |
| 92 | +* **Latency:** 1-block latency within the Superchain. Outside the Superchain, latency is variable based on allowlisted verification (transceiver) mechanism. |
| 93 | +* **Cost:** Variable based on allowlisted verification mechanisms. |
| 94 | +* **Cross-chain address:** Requires cross-chain registry per deployment. |
| 95 | +* **Supported ecosystem:** EVM, Solana, MoveVM |
| 96 | + |
| 97 | + |
| 98 | +## Key takeaways |
| 99 | + |
| 100 | +* `SuperchainERC20` is a simple and trust-minimized way for token issuers to make their token available across the Superchain interop cluster. |
| 101 | +* 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. |
| 102 | +* Token issuers should include a `ERC-7802` interface on their token to simplify downstream integrations. |
| 103 | + |
| 104 | +## Next steps |
| 105 | + |
| 106 | +* Build a [revolutionary app](/app-developers/get-started) that uses multiple blockchains within the Superchain |
| 107 | +* Deploy a [SuperchainERC20](/stack/interop/tutorials/deploy-superchain-erc20) to the Superchain |
| 108 | +* [Learn more about SuperchainERC20](/stack/interop/superchain-erc20) |
0 commit comments