Pure Super Token with xERC20 support

[d10r]

What & Why

We want a canonical implementation of a Pure SuperToken which acts as a representation of an underlying ERC20 located on a different chain.
In order to have a common code base independent of the bridge, we add the xERC20 interface to the token contract.
Currently supported bridges

AC

• Implementation
• xERC20 specific unit tests
• deployment tooling

How

The principle was pioneered by the FRACTION token. In that case, the xERC20 interface was implemented in the logic contract, see https://polygonscan.com/address/0xfd5036ace91006ff84918e1884161999099950f0#code.
This pattern however adds maintenance overhead, as a fork of SuperToken with xERC20 added needs to be maintained. Also, SuperToken is already close to the contract size limit. The current FRACTION logic implements just a minimal version of xERC20 (as the interface was smaller at the time of its implementation).

Since targeting use cases of yet-to-be-deployed tokens, we can also implement the xERC20 logic in the proxy contract itself. This avoids the additional maintenance cost of a forked SuperToken logic.

There is a reference implementation at https://github.com/defi-wonderland/xERC20.
The plan is to port the xERC20 specific implementation to this repo, based on PureSuperToken.sol.

[d10r]

I considered starting from a forked https://github.com/defi-wonderland/xERC20 and adding Super Token there. But it's more cumbersome to get into a 3rd party repo, especially considering that it requires via-ir (stack too deep errors otherwise), making the development process much more cumbersome.

So now I continue with BridgedSuperToken.sol, adding xER20 specific unit tests.

Or maybe I start with a new repo, so I don't have the bootstrapping trouble (v2 here is without foundry).

Functionality to be added:

setters:
setLockbox: This will be needed only where the bridge can't mint/burn, which is the Home token. Not used on the remote tokens.
setLimits: Sets a limit (amount) per bridge for how much can be minded or burned. All time?
mint:
burn:

getters:
mintingMaxLimitOf, burningMaxLimitOf: gets the max mint/burn limits settable for the given bridge (?)
mintingCurrentLimitOf, burningCurrentLimitOf: get the current mint/burn limits for the given bridge

Explanation of the rate limiting mechanism

The proposed interface specifies a data structure and methods for setting and querying limits, but doesn't specify the concrete algorithm for how to interpret the params.
Deriving from the reference implementation:
Per bridge, the token admin sets a minting limit and a burning limit.
From this amounts and a hardcoded timeframe of 1 day (constant DURATION, which isn't part of the spec), ratePerSecond is derived.

When a mint is attempted, mintingCurrentLimitOf is invoked. It implements a limit based on a rolling timeframe, which "regenerates" itself with time passing, up to the set max.

This means that in order to allow higher bursts, the DURATION should be set to a high value, while in order to allow high overall throughput with limited bursts, DURATION should be set lower.

Issues

testBurnReducesAllowance fails, because selfBurn doesn't reduce the allowance.
So we do first selfTransferFrom to the bridge, then selfBurn from the bridge account.

[d10r]

Implementation repo: https://github.com/d10r/xerc20-supertoken

[d10r]

TODO: check what exactly we want on the home chain. Does it make sense to add any xERC20 specific extensions?

[d10r]

next: tooling to deploy between Optimism Stack based L1 and L2.

See https://github.com/superfluid-finance/averageX/issues/44

L1StandardBridge.bridgeERC20To(address _localToken, address _remoteToken, address _to, uint256 _amount, uint32 _minGasLimit, bytes calldata _extraData)

Testnet

L1StandardBridge: 0xFBb0621E0B23b5478B630BD55a5f21f67730B0F1
L2StandardBridge: 0x4200000000000000000000000000000000000010

The repo now has a variant OPBridgedSuperTokenProxy which implements the interface IOptimismMintableERC20 required by the Superchain Standard Bridge.

[d10r]

deployment tooling (combination of foundry and shell script) added, now allows usage like this:

./deploy.sh L2 optimism-sepolia

See https://github.com/d10r/xerc20-supertoken?tab=readme-ov-file#build--deploy