feat: adding permit2 support to SuperWETH and SuperchainERC20 #58
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Adds Permit2 support to
SuperchainWETH
andSuperchainERC20
contracts.Information and Questions
Solady doesn't make use of its
allowance
function intransferFrom
, instead it computes and reads from the slot directly. This means that overriding theallowance
function doesn't affect thetransferFrom
function. For this reason I had to overridetransferFrom
and add a special case for when PERMIT2 is themsg.sender
. The logic within that if block is the sametransferFrom
performs when updating the balances offrom
andto
.Despite
allowance
not being used intransferFrom
I still overrode it in case integrators fetch it to perform further logic. If I hadn't it would return0
and that may mess up some of their logic.When it came to
SuperchainWETH
I noticed it inherited fromWETH98
which hasallowance
as a public mapping. This means it can't be overriden. I came up with two potential approaches:allowance
to_allowances
and making it a private state variable. This allowed me to add anallowance
getter and to make it virtual so I could override it easily. This also meant modifying a bit of logic from this contract and fromDelayedWETH
.transferFrom
virtual and adding the case whenPERMIT2
is the caller at the beginning.I went for approach 2. However this approach doesn't reflect the virtual allowance of PERMIT2, so I'm not 100% sold this is the best approach. The main reason why I chose it was because it didn't affect the logic (other than adding a virtual keyword) of WETH98 nor any contract that inherited from it, and because I was not certain whether there were certain design guidelines that
WETH98
had to follow.I can implement the first approach quickly if needed. Also any other potential approached that I may have missed are welcomed.
One more doubt I had was whether to add this logic to the
SuperchainERC20
or not. By adding it here we are forcing all contracts extending from it to supportPermit2
. Extension can then opt-out. Another approach would be to not add it to theSuperchainERC20
and have the extensions opt-in instead.Lastly, these implementations and the current one on
OptimismMintableERC20
doesn't have a way to revoke the infinite allowance. Are we sure we don't want to add this?