💥 Make `erc20` `owner`less With an `erc20_ownable` Extension

[romanagureev]

The erc20 module currently enforces the ownable module, even though an authorised minter is unnecessary for many use cases (e.g. vaults or LP tokens). Limiting the base implementation to balance and approval logic would make it more broadly applicable. An ownership-based variant could be provided separately as erc20_ownable.

[pcaversaccio]

So 🐍 snekmate has a master contract philosophy; this entails a few benefits:

• Invariant testing: Having all potential state mutations in one contract makes it significantly easier to write complete invariant tests. With a minimal base + optional extensions, you'd need separate test suites for each combination.
• Security through simplicity: One well-audited, battle-tested implementation is safer than multiple composable pieces that need to work correctly together.
• Real-world usage: The vast majority of ERC-20 deployments need some form of controlled supply management, even if just for initial minting.

For use cases that do not need ownership or an authorised minter (like vaults or LP tokens), you can simply not export any of the ownable functions (incl. the erc20-specific mint, set_minter, transfer_ownership, and renounce_ownership functions), and initialise the ownable module without having any effects in the constructor (the overhead is negligible imho):

# pragma version ~=0.4.3

from ethereum.ercs import IERC20
from ethereum.ercs import IERC20Detailed
from snekmate.auth import ownable
from snekmate.tokens import erc20

initializes: ownable
initializes: erc20[ownable := ownable]

implements: IERC20
implements: IERC20Detailed

exports: (
    erc20.IERC20,
    erc20.IERC20Detailed,
)

@deploy
def __init__():
    ownable.__init__()
    erc20.__init__("Vyper", "VY", 18, "Vyper", "1")

[romanagureev]

It adds extra storage slots and events, hence code size.

[pcaversaccio]

It adds extra storage slots and events, hence code size.

EIP-7954 - which increases the initcode size limit to 65,536 bytes and the contract code size limit to 32,768 bytes - is considered for inclusion for the Glamsterdam hard fork. I hope that this will remedy all code size issues in the future.