Is this ready for review?

@tynes It's now ready to review. We decided to make SuperchainERC20 as minimal as possible and abstract so that contracts extending from it can choose what sort of storage to use freely.

We only have one design question, and it's around the address zero check in the SuperchainERC20#sendERC20 function. For it to be fully compliant with the standard or a hundred percent unopionionated it should not have it. However, it seems like a check most contracts extending for it would want. We weren't sure whether to leave it or not. We removed it from relayERC20 as it didn't make sense there if it was already checked in sendERC20. Any thoughts on this would be appreciated.

Curious how you would feel about supporting #11899 as part of this. The rationale is here #11880

Since we updated the OptimismMintableERC20 with this feature, I think it makes sense to also have it in the OptimismSuperchainERC20. Definitely hear your argument about being minimal, but not having this feature would create an inconsistent experience. It basically gives a superpower to the tokens

edit: I suppose this could be done in a follow up

Looks like the recently added interface check failed

@tynes It's now ready to review. We decided to make SuperchainERC20 as minimal as possible and abstract so that contracts extending from it can choose what sort of storage to use freely.

We only have one design question, and it's around the address zero check in the SuperchainERC20#sendERC20 function. For it to be fully compliant with the standard or a hundred percent unopionionated it should not have it. However, it seems like a check most contracts extending for it would want. We weren't sure whether to leave it or not. We removed it from relayERC20 as it didn't make sense there if it was already checked in sendERC20. Any thoughts on this would be appreciated.

Definitely on board with leaving it in there

Tests look great to me! Ready to merge after the checks are passing CI

@tynes Assigned this issue to us: #11899. Will take care of this next. Thought it was cleaner to make it in a separate PR as it touches on the SuperchainWETH contract as well. I also created a task for us to refine the interfaces when a standard is introduced.

Also, as a note, for these last commits I added the main thing I felt to be untidy was to create an interface for Solady's ERC20, not due to the interface per se, but because I was not certain where to place it. I created a directory called dependency/interface and placed it there, but doubt it will see much use outside of this particular interface, so if you have any nit or opinion on this, let me know. Either way, a fun thing the interface-checker showed me is that Solady's ERC20 has named returns for some functions that OZ's ERC20 doesn't.

Lastly, on the ISemver being part of the IOptimismMintableERC20Extensions I'm a bit on the fence. It is mostly because I felt it mixed two concepts, one being the additional events and functions of the OptimismMintableERC20 and the other being versioning, but have no strong opinions here, so I can add it in a quick commit if you or anyone would like it there better.

@tynes Assigned this issue to us: #11899. Will take care of this next. Thought it was cleaner to make it in a separate PR as it touches on the SuperchainWETH contract as well. I also created a task for us to refine the interfaces when a standard is introduced.

Also, as a note, for these last commits I added the main thing I felt to be untidy was to create an interface for Solady's ERC20, not due to the interface per se, but because I was not certain where to place it. I created a directory called dependency/interface and placed it there, but doubt it will see much use outside of this particular interface, so if you have any nit or opinion on this, let me know. Either way, a fun thing the interface-checker showed me is that Solady's ERC20 has named returns for some functions that OZ's ERC20 doesn't.

Lastly, on the ISemver being part of the IOptimismMintableERC20Extensions I'm a bit on the fence. It is mostly because I felt it mixed two concepts, one being the additional events and functions of the OptimismMintableERC20 and the other being versioning, but have no strong opinions here, so I can add it in a quick commit if you or anyone would like it there better.

This all sounds good to me