prototype: remote superchain erc20

[hamdiallam]

/**
 * @title ERC20Reference
 * @notice An ERC20 that is a remote reference of a native ERC20 on its home chain. This can be thought
 *         about in the traditional sense of a pointer reference. On the home chain, any user can create
 *         an acquireable reference to their ERC20 for a given spender, acquired via `transferFrom()`.
 *         However, all `transfer()` calls incur a "dereference" back to the home chain to natively
 *         transfer the ERC20 to the desired recipient, backed by Superchain Message Passing. As a result,
 *         an ERC20 can be remotely controlled by an account without fungible wrapped representations.
 */
contract ERC20Reference is ERC20 {}

[hamdiallam]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• prototype: remote superchain erc20 #373 👈 (View in Graphite)
• chore: remove Promise.sol in favor of interop-lib #375
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[cloudflare-workers-and-pages]

Deploying supersim with    Cloudflare Pages

Latest commit:	1ac71e0
Status:	✅  Deploy successful!
Preview URL:	https://4876563d.supersim.pages.dev
Branch Preview URL:	https://phantom-superchain-erc20.supersim.pages.dev

View logs

[karlfloersch]

I worry that this ERC20 is too feature rich and will cause foot guns. For example things that won't work well:

• Approve
• TotalSupply

because they will all return values which seem correct but actually are broken. If you give someone an API, they will use it even if you don't intend for them to use it.

I think a way to adjust this is to actually revert if anything is called that we can't support 1:1 with an ERC20. That way, when integrating this into an existing application we can also get noisy errors if someone integrates the phantom and then their tests fail because they use approve

Oh another note -- the API we support is actually a bit nuanced because we don't actually fully support transferFrom or balanceOf. We ONLY support transferFrom(addr) or balanceOf(addr) if the addr==the contract which is using the token. So we should enforce that behavior as well

[hamdiallam]

yea 100%, inheriting ERC20 here was just to bootstrap this implementation and not concern myself with having erc20 stuff implemented.

transferFrom: agreed we should not implement this. However this API could by default be the crossDomainDepositFrom in the context of the phantom token to remotely transfer the funds into a recipient address. Kinda fits the name nicely. Only the messenger would be authorized as msg.sender.

++1 on approvals and such