Add EIP-5679: Token Minting and Burning (#5679)

* init

* Update ERC number

* Add content

* Add discussion-to

* Add ERC-165 identifiers

* Change public to external

* Update with batch and safe methods and add rationale.

* Fix format

* Fix EIPW errors

* Add mentioning of EIP-777

EIPS/eip-5679.md

@@ -0,0 +1,106 @@
+---
+eip: 5679
+title: Token Minting and Burning
+description: An extension for minting and burning tokens for EIP-20, EIP-721, EIP-1155.
+author: Zainan Victor Zhou (@xinbenlv)
+discussions-to: https://ethereum-magicians.org/t/erc-5679-mint-and-burn-tokens/10913
+status: Draft
+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 0xa73fd2a4
+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 0x0346d398
+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 0xdff2db76
+interface IERC5679Ext1155 {
+   function safeMint(address _to, uint256 _id, uint256 _amount, bytes[] calldata _data) external;
+   function safeMintBatch(address to, uint256[] memory ids, uint256[] memory amounts, bytes memory data) external;
+   function burn(address _from, uint256 _id, uint256 _amount, bytes[] calldata _data) external;
+   function burnBatch(address _from, uint256[] memory ids, uint256[] memory 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 transfer 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 transfer from the recipient address identified by `_to` to the address of `0x0`.
+The total supply **MUST** decrease accordingly.
+
+6. For EIP-721, the `safeMint` **MUST** operate with respect to the `ERC721TokenReceiver` hook functions.
+For EIP-1155, the `safeMint` and `safeMintBatch` **MUST** operate with respect to the `ERC1155TokenReceiver` hook functions.
+
+## 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
+
+Needs discussion.
+
+## Copyright
+Copyright and related rights waived via [CC0](../LICENSE.md).