test: superc20 tob properties

[0xteddybear]

Preferred this approach to

• test a supertoken in isolation -> would amount to testing the solady erc20 implementation, + I would like to get the ToB invariants checked against contracts that had 'real' state transitions from the core test suite
• modifying/extending the ToB contracts so they assert against every supertoken: if there's an issue with one token, the fuzzer is going to find it eventually by testing one token at a time (I hope)

ToB properties, however, don't only check the invariants but also cause valid ERC20 state transitions, so we got that for free ✨

edit: had to guide the fuzzer a bit more to actually cover most ToB properties (making the paragraph above a bit less true), and discovered two that solady's erc20 implementation doesn't comply with

[simon-something]

this isn't an assumption somewhere else in the codebase, right (like in a mint or burn or smth)?

[0xteddybear]

no, it's not checked anywhere else and I didn't find it in the docs either. Perhaps it's worth checking with @0xParticle :

• Is it okay for transfers to the zero address to succeed?
• Is it okay for transferFroms to the zero address to succeed?
• and, is it okay for the above to update the balance of address(0), so it could be non-zero?

the above implies there will not be a bijection between OptimismSuperchainERC20 Transfer({from: somebody, to: address(0), amount: something}) events and sendERC20 calls

[0xParticle]

This is actually an historical discussion. The ERC20 standard does not mention anything about these scenarios, so implementation can block or not transfers to the zero address. Same for tracking the balance of the zero address.

• OZ, for instance, does check and revert on transfers to the zero address. This is an opinionated design, but its fine as it can prevent potential bugs.
• The implementation you are testing uses solady ERC20 which doesn't check for zero address on transfers for gas optimization purposes.
  Also, keep in mind that transfers to the zero address have a use case, which is to effectively burn tokens.

So, answering the 3 bullet points, the three scenarios are ok as its ERC20 compliant.

Regarding the symmetry between transfers and bridging, I think its fine.

• As I said, the primary use case for transfering tokens to the zero address is "burning", and that action is already available using the transfer and transferFrom methods in the solady implementation. I don't see why someone would do it via a bridge, unless they want to waste gas.
• That said, blocking the bridging to the zero address is an opinionated design choice, but it does feel like touching the bridge should be reserved to the intended use of it (clients will be grateful).