You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
| Needs Approval From | Mark Tyneway, Matt Solomon |
26
+
| Other Reviewers | Michael Amadi|
27
+
| Status | Final |
29
28
30
29
## Introduction
31
30
32
31
This document is intended to be shared publicly for review and visibility purposes. It covers the introduction of the `SuperchainERC20` standard, including its implementation and interface, the latter extending from `IERC7802`.
33
32
34
33
Token deployers building on Superchain are encouraged to review the document, as they are the main beneficiaries of this standard. It does not intend to cover contracts such as SuperchainTokenBridge or those involving migrated liquidity.
35
34
36
-
>🗂️ The proposed implementation of the standard doesn’t prevent a token issuer from using other token standards, such as xERC20, with the `SuperchainTokenBridge` to mint and burn tokens across an [interoperable set of chains](https://specs.optimism.io/interop/overview.html). More about this is explained in [xERC20-ERC7802 compatilibility](https://defi-wonderland.notion.site/xERC20-ERC7802-compatibility-14c9a4c092c780ca94a8cb81e980d813).
35
+
>🗂️ The proposed implementation of the standard doesn’t prevent a token issuer from using other token standards, such as xERC20, with the `SuperchainTokenBridge` to mint and burn tokens across an [interoperable set of chains](https://specs.optimism.io/interop/overview.html). More about this is explained in [xERC20-ERC7802 compatilibility](https://defi-wonderland.notion.site/xERC20-ERC7802-compatibility-14c9a4c092c780ca94a8cb81e980d813).
37
36
38
37
Below are references for this project:
39
38
@@ -52,10 +51,10 @@ Similar to ERC20, SuperchainERC20 implementations should be considered untrusted
52
51
53
52
### FM1: Unauthorized Access to `crosschainMint` & `crosschainBurn` Functions
54
53
55
-
-**Description:** The `crosschainMint` and `crosschainBurn` functions can only be called by the `SuperchainTokenBridge`, enforced by the check `msg.sender != Predeploys.SUPERCHAIN_TOKEN_BRIDGE`. If the bridge address is badly defined or the modifier bypassed, an entity could mint and burn tokens.
54
+
-**Description:** The `crosschainMint` and `crosschainBurn` functions can only be called by the `SuperchainTokenBridge`, enforced by the check `msg.sender != Predeploys.SUPERCHAIN_TOKEN_BRIDGE`. If the bridge address is badly defined or the modifier bypassed, an entity could mint and burn tokens.
56
55
-**Risk Assessment**: Medium.
57
-
- Potential impact: High. All tokens based on this implementation could be potentially at risk.
58
-
- Likelihood: Very Low. `Predeploys.SUPERCHAIN_TOKEN_BRIDGE` is defined via protocol upgrades. The conditional is sufficiently simple and battle-tested to give confidence in the implementation.
56
+
- Potential impact: High. All tokens based on this implementation could be potentially at risk.
57
+
- Likelihood: Very Low. `Predeploys.SUPERCHAIN_TOKEN_BRIDGE` is defined via protocol upgrades. The conditional is sufficiently simple and battle-tested to give confidence in the implementation.
59
58
-**Mitigation**: Current unit tests perform authorization checks for `crosschainMint` ([test](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/test/L2/SuperchainERC20.t.sol#L38)) and `crosschainBurn` ([test](https://github.com/ethereum-optimism/optimism/blob/1add88a41b8cdc5c488a18976e3e4fa4b02e7da4/packages/contracts-bedrock/test/L2/SuperchainERC20.t.sol#L77)). There should be tests to ensure that the `SuperchainTokenBridge` predeploy is correctly set during the interop fork upgrade, and is not subject to unexpected changes.
60
59
-**Detection**: Ideally, run an off-chain agent to monitor every `crosschainMint` and `crosschainBurn` event in real-time, perhaps it could be resource-intensive given the permissionless usage of `SuperchainERC20` and the expected large number of deployments. If that’s not feasible, rely on user-filed support tickets to flag unusual mint/burn activity, which the TBD team (see corresponding action item) can investigate for suspected unauthorized access.
61
60
-**Recovery Path(s)**: Equivocation (i.e. another implementation being set) on the `SuperchainTokenBridge` address would require a protocol upgrade or hard fork to restore the expected code.
@@ -64,10 +63,10 @@ Similar to ERC20, SuperchainERC20 implementations should be considered untrusted
64
63
65
64
-**Description**: The token on the destination chain is not yet deployed, which prevents the cross-chain transfer from finalizing (`relayERC20` fails). However, the token's deployment is permissioned, meaning it is solely up to the deployer to make the token available on the destination chain
66
65
-**Risk Assessment**: High.
67
-
- Potential impact: High. Users may lose access to their tokens temporarily or permanently. Two specific scenarios can arise:
68
-
1. Funds are stuck but can eventually be relayed if the deployment occurs before the message expiration window ends.
69
-
2. Funds are stuck and potentially lost if the deployment occurs after the message expiration time ends or never occurs.
70
-
- Likelihood: Medium. A deployer may choose not to deploy the token on all chains.
66
+
- Potential impact: High. Users may lose access to their tokens temporarily or permanently. Two specific scenarios can arise:
67
+
1. Funds are stuck but can eventually be relayed if the deployment occurs before the message expiration window ends.
68
+
2. Funds are stuck and potentially lost if the deployment occurs after the message expiration time ends or never occurs.
69
+
- Likelihood: Medium. A deployer may choose not to deploy the token on all chains.
71
70
-**Mitigation**: Trusted bridge frontends should prevent users from sending tokens to a chain where the token doesn’t exist. Double-check other trusted sources (such as Superchain Token List) for greater confidence.
72
71
-**Detection**: Support tickets filed by users reporting the issue.
73
72
-**Recovery Path(s)**: Communicate with the token owner and request deployment of the token on the missing chain.
@@ -76,19 +75,18 @@ Similar to ERC20, SuperchainERC20 implementations should be considered untrusted
76
75
77
76
-**Description**: The token on the destination chain is not yet deployed, which prevents the cross-chain transfer from finalizing (`relayERC20` fails). However, the token is permissionless to deploy, meaning anyone can deploy it.
78
77
-**Risk Assessment**: Medium
79
-
- Potential impact: Medium. Users are unable to access their tokens until the token is deployed.
80
-
- Likelihood: Medium. Tokens may not be deployed on all chains.
78
+
- Potential impact: Medium. Users are unable to access their tokens until the token is deployed.
79
+
- Likelihood: Medium. Tokens may not be deployed on all chains.
81
80
-**Mitigation**: Trusted bridge frontends should prevent users from sending tokens to any chain where the token does not exist. It is recommended to deploy tokens on every new chain added to the dependency set.
82
81
-**Detection**: Support tickets filed by users reporting the issue.
83
82
-**Recovery Path(s)**: Deploy the token.
84
83
85
-
86
84
### FM4: Token Contract Missing in Destination Chain: Token Deployer is Lost, or Unable to Deploy to Expected Address
87
85
88
86
-**Description**: For the `SuperchainTokenBridge` to validate cross-chain mints and burns correctly, the `SuperchainERC20` must appear at one consistent address on each chain when deployed. If a developer fails to deterministically deploy the token at the same address, the bridging logic cannot unify the token references across chains, leading to failed or incorrect cross-chain transfers.
89
87
-**Risk Assessment**: Medium
90
-
- Potential impact: High. Without a consistent address, interoperability for the token is effectively disabled and `relayERC20` are likely to fail, causing a lost.
91
-
- Likelihood: Very Low. The interoperable set of chains follows the same opcode behavior and ensures identical availability of deployer contracts, such as `create2Deployer`.
88
+
- Potential impact: High. Without a consistent address, interoperability for the token is effectively disabled and `relayERC20` are likely to fail, causing a lost.
89
+
- Likelihood: Very Low. The interoperable set of chains follows the same opcode behavior and ensures identical availability of deployer contracts, such as `create2Deployer`.
92
90
-**Mitigation**: For developers, employ the appropriate deterministic deployment tools, such as the one at `create2Deployer`. For users, refers to FM2 and FM3.
93
91
-**Detection**: Deployers should test the deployment method used and verify contract addresses after a mainnet deployment.
94
92
-**Recovery Path(s)**: Redeploy token contracts on a new address across chains and migrate userbase if it is needed.
@@ -97,10 +95,10 @@ Similar to ERC20, SuperchainERC20 implementations should be considered untrusted
97
95
98
96
-**Description**: The bridging logic assumes that if a `SuperchainERC20` contract address is identical across multiple chains, it refers to the expected code. However, if a deployer uses flawed or deployment methods that get compromised, a non-desired implementation may be deployed at the same address on one chain.
99
97
-**Risk Assessment**: Medium
100
-
- Potential impact: High. In the worst-case scenario, compromised methods open the door to malicious behavior, e.g. where an attacker can occupy the address, and forge bridging events, and gain the ability to mint tokens in other chains.
101
-
- Likelihood: Low. This is possible if the deployer engages in poor practices or lacks opsec. Two examples of this are:
102
-
- Custom factories that utilize CREATE and share the same address are used, where tokens are deployed using the same bytecode and nonce.
103
-
- Proxy contracts where the admin is compromised or the proxy address front-runned.
98
+
- Potential impact: High. In the worst-case scenario, compromised methods open the door to malicious behavior, e.g. where an attacker can occupy the address, and forge bridging events, and gain the ability to mint tokens in other chains.
99
+
- Likelihood: Low. This is possible if the deployer engages in poor practices or lacks opsec. Two examples of this are:
100
+
- Custom factories that utilize CREATE and share the same address are used, where tokens are deployed using the same bytecode and nonce.
101
+
- Proxy contracts where the admin is compromised or the proxy address front-runned.
104
102
-**Mitigation**: For developers, employ the appropriate deterministic deployment tools, such as the one at `create2Deployer`. In the case of permissioned deployments, common for proxy contracts, ensure to maintain control over those deployments and ownership.
105
103
-**Detection**: Support tickets filed by users reporting such issues.
106
104
-**Recovery Path(s)**: Pause the token contract where possible and proceed to redeploy and migrate userbase if it is needed.
@@ -109,13 +107,13 @@ Similar to ERC20, SuperchainERC20 implementations should be considered untrusted
109
107
110
108
The following action items need to be done:
111
109
112
-
-[ ] Resolve all the comments.
113
-
-[ ]FM1: Implement tests for `SuperchainTokenBridge` predeploy. Currently, the L2 Genesis project is under development and it should take care of these tests.
114
-
-[ ]FM1: Run an off-chain script to monitor `crosschainMint` and `crosschainBurn` events for parity and consistency with the expected `msg.sender` (`SuperchainTokenBridge`). (Owned by OP Labs)
115
-
-[ ] FM1: Communicate with the team responsible for responding to alerts about the need to define how issues will be raised to the security team.
116
-
-[ ]FM2, FM3, FM4: Communicate to bridge frontends to ensure they prevent users from sending tokens to a chain where the token doesn’t exist.
117
-
-[ ]FM4, FM5: Ensure that the documentation for SuperchainERC20 developers explains the need for deterministic deployment and how to achieve it, including that constructor args affect the resulting address, requiring consistency across chains.
118
-
-[ ]FM1, FM2, FM3, FM5: Communicate with the team in charge of responding to user-submitted support tickets about the need to create runbooks and define how issues are escalated to the security team or returned to the user when security involvement is not required.
-[x]FM1: Run an off-chain script to monitor `crosschainMint` and `crosschainBurn` events for parity and consistency with the expected `msg.sender` (`SuperchainTokenBridge`). (tracked in [Interop Monitoring issue](https://github.com/ethereum-optimism/optimism/issues/15178))
113
+
-[x] FM1: Communicate with the team responsible for responding to alerts about the need to define how issues will be raised to the security team.
114
+
-[ ] FM2, FM3, FM4: Communicate to bridge frontends to ensure they prevent users from sending tokens to a chain where the token doesn’t exist.
115
+
-[x]FM4, FM5: Ensure that the documentation for SuperchainERC20 developers explains the need for deterministic deployment and how to achieve it, including that constructor args affect the resulting address, requiring consistency across chains. ([SuperchainERC20 Requirements](https://docs.optimism.io/stack/interop/superchain-erc20#requirements))
116
+
-[x]FM1, FM2, FM3, FM5: Communicate with the team in charge of responding to user-submitted support tickets about the need to create runbooks and define how issues are escalated to the security team or returned to the user when security involvement is not required. ([Interop tutorials](https://docs.optimism.io/stack/interop/tutorials))
119
117
120
118
## Warning for Integrators
121
119
@@ -129,4 +127,4 @@ The reason why this should not be overlooked is that otherwise protocols can wro
129
127
130
128
Although this is a vector of attack that is true for all tokens, the proclivity of `SuperchainERC20s` to share their address make the attack more likely as the attacker can more easily predict the address of a token that a given protocol may support in new chains.
131
129
132
-
As an example, if `SuperchainERC20_A` is doing well in `Protocol_A` in Optimism, and `Protocol_A` decides to launch on Unichain as well, it's likely it will eventually support `SuperchainERC20_A` in there as well. With this, the attacker can get ahead and increase his balance in Unichain before `SuperchainERC20_A` is deployed there.
130
+
As an example, if `SuperchainERC20_A` is doing well in `Protocol_A` in Optimism, and `Protocol_A` decides to launch on Unichain as well, it's likely it will eventually support `SuperchainERC20_A` in there as well. With this, the attacker can get ahead and increase his balance in Unichain before `SuperchainERC20_A` is deployed there.
0 commit comments