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
SuperToken wrappers and Pools created by framework contracts can end up having the same address as another artifact on another chain. This is not per se an issue, but can cause confusion (e.g. in cross-chain searches like in console) and may be abused by phishers.
We should thus check the extent of the problem and potentially do something about it.
Enumerate the relevant (factory) contracts and check address matches across chains
Elaborate a recommendation for what to do about it
Technical
This can happen because of a combination of 2 factors:
use of the same deployer EOA across chains (the "GH-Agent account"). Depending on the somewhat random order of transaction, this can lead to deployed contracts having the same address (determined by nonce) as contracts (can be the same of a different one) on another chain.
contracts created by those contracts again have their address derived from the nonce because CREATE (the conventional one) is used.
If we eliminate one of those factors, no accidental address matches are possible.
While we can't easily change the address of framework contracts (the proxies), we could do an update which switches factories to using CREATE2, making sure the nonce eliminates conflicts (e.g. including chainId).
This is somewhat related to the "canonical SuperToken wrapper feature" (see createCanonicalERC20Wrapper) which was never rolled out. In case we do something here, we may want to tackle that one too, but maybe a simpler version of it which is easier to rollout and maintain.
The text was updated successfully, but these errors were encountered:
What & Why
SuperToken wrappers and Pools created by framework contracts can end up having the same address as another artifact on another chain. This is not per se an issue, but can cause confusion (e.g. in cross-chain searches like in console) and may be abused by phishers.
We should thus check the extent of the problem and potentially do something about it.
Issue Origin: https://discord.com/channels/752490247643725875/752493348169711696/1288506722352369666
AC
Technical
This can happen because of a combination of 2 factors:
CREATE
(the conventional one) is used.If we eliminate one of those factors, no accidental address matches are possible.
While we can't easily change the address of framework contracts (the proxies), we could do an update which switches factories to using
CREATE2
, making sure the nonce eliminates conflicts (e.g. including chainId).This is somewhat related to the "canonical SuperToken wrapper feature" (see createCanonicalERC20Wrapper) which was never rolled out. In case we do something here, we may want to tackle that one too, but maybe a simpler version of it which is easier to rollout and maintain.
The text was updated successfully, but these errors were encountered: