125 lines
5.7 KiB
Markdown
125 lines
5.7 KiB
Markdown
---
|
|
eip: 5679
|
|
title: Token Minting and Burning
|
|
description: An extension for minting and burning EIP-20, EIP-721, and EIP-1155 tokens
|
|
author: Zainan Victor Zhou (@xinbenlv)
|
|
discussions-to: https://ethereum-magicians.org/t/erc-5679-mint-and-burn-tokens/10913
|
|
status: Final
|
|
type: Standards Track
|
|
category: ERC
|
|
created: 2022-09-17
|
|
requires: 20, 165, 721, 1155
|
|
---
|
|
|
|
## 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](./eip-721.md) and [EIP-1155](./eip-1155.md)
|
|
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.
|
|
|
|
1. Any contract complying with [EIP-20](./eip-20.md) when extended with this EIP,
|
|
**MUST** implement the following interface:
|
|
|
|
```solidity
|
|
// The EIP-165 identifier of this interface is 0xd0017968
|
|
interface IERC5679Ext20 {
|
|
function mint(address _to, uint256 _amount, bytes calldata _data) external;
|
|
function burn(address _from, uint256 _amount, bytes calldata _data) external;
|
|
}
|
|
```
|
|
|
|
2. Any contract complying with [EIP-721](./eip-721.md) when extended with this EIP,
|
|
**MUST** implement the following interface:
|
|
|
|
```solidity
|
|
// The EIP-165 identifier of this interface is 0xcce39764
|
|
interface IERC5679Ext721 {
|
|
function safeMint(address _to, uint256 _id, bytes calldata _data) external;
|
|
function burn(address _from, uint256 _id, bytes calldata _data) external;
|
|
}
|
|
```
|
|
|
|
3. Any contract complying with [EIP-1155](./eip-1155.md) when extended with this EIP,
|
|
**MUST** implement the following interface:
|
|
|
|
```solidity
|
|
// The EIP-165 identifier of this interface is 0xf4cedd5a
|
|
interface IERC5679Ext1155 {
|
|
function safeMint(address _to, uint256 _id, uint256 _amount, bytes calldata _data) external;
|
|
function safeMintBatch(address to, uint256[] calldata ids, uint256[] calldata amounts, bytes calldata data) external;
|
|
function burn(address _from, uint256 _id, uint256 _amount, bytes[] calldata _data) external;
|
|
function burnBatch(address _from, uint256[] calldata ids, uint256[] calldata amounts, bytes calldata _data) external;
|
|
}
|
|
```
|
|
|
|
4. 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 address `0x0` to the recipient address identified by `_to`.
|
|
The total supply **MUST** increase accordingly.
|
|
|
|
5. 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 of `0x0`.
|
|
The total supply **MUST** decrease accordingly.
|
|
|
|
6. `safeMint` MUST implement the same receiver restrictions as `safeTransferFrom` as defined in
|
|
[EIP-721](./eip-721.md) and [EIP-1155](./eip-1155.md).
|
|
|
|
7. It's RECOMMENDED for the client to implement [EIP-165](./eip-165.md) identifiers as specified above.
|
|
|
|
## Rationale
|
|
|
|
1. 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.
|
|
|
|
2. We have chosen to identify the interface with [EIP-165](./eip-165.md) identifiers each individually,
|
|
instead of having a single identifier because the signatures of interface are different.
|
|
|
|
3. 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.
|
|
|
|
4. We have chosen to add `safeMintBatch` and `burnBatch` methods for EIP-1155 but not for EIP-721 to follow the
|
|
convention of EIP-721 and EIP-1155 respectively.
|
|
|
|
5. We have not add extension for [EIP-777](./eip-777.md) 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](../LICENSE.md).
|