SRC-5679: Token Minting and Burning

An extension for minting and burning SIP-20, SIP-721, and SIP-1155 tokens

Abstract

This SIP 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 SIP-721 and SIP-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.

1. Any contract complying with SIP-20 when extended with this SIP, MUST implement the following interface:

// The SIP-165 identifier of this interface is 0xd0017968
interface ISRC5679Ext20 {
   function mint(address _to, uint256 _amount, bytes calldata _data) external;
   function burn(address _from, uint256 _amount, bytes calldata _data) external;
}

1. Any contract complying with SIP-721 when extended with this SIP, MUST implement the following interface:

// The SIP-165 identifier of this interface is 0xcce39764
interface ISRC5679Ext721 {
   function safeMint(address _to, uint256 _id, bytes calldata _data) external;
   function burn(address _from, uint256 _id, bytes calldata _data) external;
}

1. Any contract complying with SIP-1155 when extended with this SIP, MUST implement the following interface:

// The SIP-165 identifier of this interface is 0xf4cedd5a
interface ISRC5679Ext1155 {
   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;
}

1. When the token is being minted, the transfer events MUST be emitted as if the token in the _amount for SIP-20 and SIP-1155 and token id being _id for SIP-721 and SIP-1155 were transferred from address 0x0 to the recipient address identified by _to. The total supply MUST increase accordingly.

2. When the token is being burned, the transfer events MUST be emitted as if the token in the _amount for SIP-20 and SIP-1155 and token id being _id for SIP-721 and SIP-1155 were transferred from the recipient address identified by _to to the address of 0x0. The total supply MUST decrease accordingly.

3. safeMint MUST implement the same receiver restrictions as safeTransferFrom as defined in SIP-721 and SIP-1155.

4. It’s RECOMMENDED for the client to implement SIP-165 identifiers as specified above.

Rationale

1. It’s possible that the interface be consolidated to the same as SIP-1155 which is always bearing _amount field, regardless of whether it’s a SIP-20, SIP-721 or SIP-1155. But we choose that each SRC 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 SIP-165 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 SIP-20 SIP-721 and SIP-1155 for maximum compatibility.

4. We have chosen to add safeMintBatch and burnBatch methods for SIP-1155 but not for SIP-721 to follow the convention of SIP-721 and SIP-1155 respectively.

5. We have not add extension for SIP-777 because it already handles Minting and Burning.

Backwards Compatibility

This SIP is designed to be compatible for SIP-20, SIP-721 and SIP-1155 respectively.

Security Considerations

This SIP 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 SIP we do recognize there are potentially other use case where a third type of role shall be entitled to burning. We keep this SIP less opinionated in such restriction but implementors should be cautious about designing the restriction.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Zainan Victor Zhou (@xinbenlv), "SRC-5679: Token Minting and Burning," Sila Improvement Proposals, no. 5679, September 2022. Available: https://sips.sila.org/SIPS/sip-5679.