Pure Super Token with xERC20 support about custom-supertokens HOT 5 OPEN

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.

from custom-supertokens.

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

from custom-supertokens.

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

from custom-supertokens.

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.

from custom-supertokens.

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

from custom-supertokens.