You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
I believe this addition would significantly enhance the utility and appeal of the Solmate library, especially for projects with specific deployment cost constraints.
The text was updated successfully, but these errors were encountered: