transmissions11 / solmate

Modern, opinionated, and gas optimized building blocks for smart contract development.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Feature request, add vanilla ERC20 without EIP-2612 (PERMIT) to token library

eugenioclrc opened this issue · comments

I propose the addition of a "Vanilla" ERC20 contract to the Solmate token contract library, specifically one that excludes the EIP-2612 (PERMIT) implementation.

Rationale:

In a recent exploration of a protocol, i discovered that OZ implementation was better than Solmate. Mainly because the protocol needs to deploy multiple tokens and using the current Solmate ERC20 implementation incurs higher byte-size and consequent deployment costs compared to the OpenZeppelin implementation. This is primarily due to the inclusion of EIP-2612 (PERMIT) functionality in Solmate's ERC20 contract. While Solmate's ERC20 might offer more cost-effective interactions post-deployment, the initial deployment cost is a critical factor for protocols requiring the deployment of multiple tokens.

Proposed Solution:

Introduce a streamlined version of the ERC20 contract within the Solmate library. This version would exclude the EIP-2612 (PERMIT) feature, thereby reducing the contract's byte size and lowering deployment costs. This "Vanilla" ERC20 contract would cater to use cases where the PERMIT functionality is not required, offering a more cost-efficient solution for such scenarios.

Benefits:

  • Reduced Deployment Costs: A smaller contract size directly translates to lower gas costs during deployment, which is especially beneficial for projects deploying multiple tokens.
  • Flexibility: By offering both the full-featured ERC20 and a "Vanilla" version, Solmate can cater to a broader range of use cases and developer preferences.

I believe this addition would significantly enhance the utility and appeal of the Solmate library, especially for projects with specific deployment cost constraints.