ERC-7629: ERC-20/ERC-721 Unified Token Interface

introduces a single interface for ERC-20/ERC-721 tokens, enabling seamless interaction by defining common functions for both token types.

Metadata

Status: DraftStandards Track: ERCCreated: 2024-02-18

Authors

0xZeus1111 (@0xZeus1111), Nvuwa (@Nvuwa)

Requires

EIP-20, EIP-165, EIP-721

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This proposal introduces a protocol that establishes a unified interface for managing both ERC-20 fungible tokens and ERC-721 non-fungible tokens (NFTs) on the Ethereum blockchain. By defining a common set of functions applicable to both token types, developers can seamlessly interact with ERC-20 and ERC-721 tokens using a single interface. This simplifies integration efforts and enhances interoperability within decentralized applications (DApps).

Motivation

The proposal aims to address the demand for assets combining the liquidity of ERC-20 tokens and the uniqueness of ERC-721 tokens. Current standards present a fragmentation, requiring users to choose between these features. This proposal fills that gap by providing a unified token interface, enabling smooth transitions between ERC-20 and ERC-721 characteristics to accommodate diverse blockchain applications.

Specification

Introduces a token contract that combines features from both ERC-20 and ERC-721 standards.
Supports state transitions between ERC-20 and ERC-721 modes, facilitating seamless conversion and utilization of both liquidity and non-fungibility.
Defines essential functions and events to support token interactions, conversions, and queries.
Implements low gas consumption ERC-20 mode to maintain efficiency comparable to typical ERC-20 token transfers.

Compliant contracts MUST implement the following Solidity interface:

Rationale

Common Interface for Different Token Types:

Introduces a unified interface to address the fragmentation caused by separate ERC-20 and ERC-721 standards.
Standardizes functions like transferFrom, mint, and burn, enabling developers to interact with both token types without implementing distinct logic.

Transfer Functionality:

Includes transferFrom function for seamless movement of tokens between addresses, as it's a core component of both ERC-20 and ERC-721 standards.

Minting and Burning:

Incorporates mint and burn functions for creating and destroying tokens, essential for managing token supply and lifecycle.

Balance and Ownership Queries:

Provides functions like balanceOf and ownerOf for retrieving token balances and ownership information, crucial for both ERC-20 and ERC-721 tokens.

Compatibility and Extensibility:

Ensures compatibility with existing ERC-20 and ERC-721 implementations, minimizing disruption during transition.
Allows extension with additional functions and events for future enhancements.

Security Considerations:

Implements mechanisms to prevent common issues like reentrancy attacks and overflows, ensuring the security and robustness of the unified interface.

Backwards Compatibility

The proposed this proposal introduces a challenge in terms of backward compatibility due to the distinct balance query mechanisms utilized by ERC-20 and ERC-721 standards. ERC-20 employs balanceOf to check an account's token balance, while ERC-721 uses balanceOf to inquire about the quantity of tokens owned by an account. To reconcile these differences, the ERC must consider providing either two separate functions catering to each standard or adopting a more generalized approach.

Compatibility Points

The primary compatibility point lies in the discrepancy between ERC-20's balanceOf and ERC-721's balanceOf functionalities. Developers accustomed to the specific balance query methods in each standard may face challenges when transitioning to this proposal.

Proposed Solutions

Dual Balance Query Functions:

Introduce two distinct functions, erc20BalanceOf and erc721TotalSupply, to align with the conventions of ERC-20 and ERC-721, respectively. Developers can choose the function based on the token type they are working with.

Security Considerations

Due to the dual nature of this proposal, potential differences in protocol interpretation may arise, necessitating careful consideration during development.
Comprehensive security audits are recommended, especially during mode transitions by users, to ensure the safety of user assets.

Copyright