ERC-5679: Token Minting and Burning
An extension for minting and burning EIP-20, EIP-721, and EIP-1155 tokens
Abstract
This EIP introduces a consistent way to extend token standards for minting and burning.
Motivation
Minting and Burning are typical actions for creating and destroying tokens. By establishing a consistent way to mint and burn a token, we complete the basic lifecycle.
Some implementations of EIP-721 and EIP-1155
have been able to use transfer
methods or the-like
to mint and burn tokens. However, minting and burning change token supply. The access controls
of minting and burning also usually follow different rules than transfer.
Therefore, creating separate methods for burning and minting simplifies implementations
and reduces security error.
Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
- Any contract complying with EIP-20 when extended with this EIP, MUST implement the following interface:
- Any contract complying with EIP-721 when extended with this EIP, MUST implement the following interface:
- Any contract complying with EIP-1155 when extended with this EIP, MUST implement the following interface:
-
When the token is being minted, the transfer events MUST be emitted as if the token in the
_amount
for EIP-20 and EIP-1155 and token id being_id
for EIP-721 and EIP-1155 were transferred from address0x0
to the recipient address identified by_to
. The total supply MUST increase accordingly. -
When the token is being burned, the transfer events MUST be emitted as if the token in the
_amount
for EIP-20 and EIP-1155 and token id being_id
for EIP-721 and EIP-1155 were transferred from the recipient address identified by_to
to the address of0x0
. The total supply MUST decrease accordingly. -
safeMint
MUST implement the same receiver restrictions assafeTransferFrom
as defined in EIP-721 and EIP-1155. -
It's RECOMMENDED for the client to implement EIP-165 identifiers as specified above.
Rationale
-
It's possible that the interface be consolidated to the same as EIP-1155 which is always bearing
_amount
field, regardless of whether it's a EIP-20, EIP-721 or EIP-1155. But we choose that each ERC token should have their own standard way of representing the amount of token to follow the same way of_id
and_amount
in their original token standard. -
We have chosen to identify the interface with EIP-165 identifiers each individually, instead of having a single identifier because the signatures of interface are different.
-
We have chosen NOT to create new events but to require the usage of existing transfer event as required by EIP-20 EIP-721 and EIP-1155 for maximum compatibility.
-
We have chosen to add
safeMintBatch
andburnBatch
methods for EIP-1155 but not for EIP-721 to follow the convention of EIP-721 and EIP-1155 respectively. -
We have not add extension for EIP-777 because it already handles Minting and Burning.
Backwards Compatibility
This EIP is designed to be compatible for EIP-20, EIP-721 and EIP-1155 respectively.
Security Considerations
This EIP depends on the security soundness of the underlying book keeping behavior of the token implementation. In particular, a token contract should carefully design the access control for which role is granted permission to mint a new token. Failing to safe guard such behavior can cause fraudulent issuance and an elevation of total supply.
The burning should also carefully design the access control. Typically only the following two roles are entitled to burn a token:
- Role 1. The current token holder
- Role 2. An role with special privilege.
Either Role 1 OR Role 2 or a consensus between the two are entitled to conduct the burning action. However as author of this EIP we do recognize there are potentially other use case where a third type of role shall be entitled to burning. We keep this EIP less opinionated in such restriction but implementors should be cautious about designing the restriction.
Copyright
Copyright and related rights waived via CC0.