Abstract

This EIP defines standard functions for granular approval of EIP-1155 tokens by both id and amount. This EIP extends EIP-1155.

Motivation

EIP-1155's popularity means that multi-token management transactions occur on a daily basis. Although it can be used as a more comprehensive alternative to EIP-721, EIP-1155 is most commonly used as intended: creating multiple ids, each with multiple tokens. While many projects interface with these semi-fungible tokens, by far the most common interactions are with NFT marketplaces.

Due to the nature of the blockchain, programming errors or malicious operators can cause permanent loss of funds. It is therefore essential that transactions are as trustless as possible. EIP-1155 uses the setApprovalForAll function, which approves ALL tokens with a specific id. This system has obvious minimum required trust flaws. This EIP combines ideas from EIP-20 and EIP-721 in order to create a trust mechanism where an owner can allow a third party, such as a marketplace, to approve a limited (instead of unlimited) number of tokens of one id.

Specification

The keywords “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.

Contracts using this EIP MUST implement the IERC1155ApprovalByAmount interface.

Interface implementation

/**
 * @title ERC-1155 Approval By Amount Extension
 * Note: the ERC-165 identifier for this interface is 0x1be07d74
 */
interface IERC1155ApprovalByAmount is IERC1155 {

    /**
     * @notice Emitted when `account` grants or revokes permission to `operator` to transfer their tokens, according to
     * `id` and with an amount: `amount`.
     */
    event ApprovalByAmount(address indexed account, address indexed operator, uint256 id, uint256 amount);

    /**
     * @notice Grants permission to `operator` to transfer the caller's tokens, according to `id`, and an amount: `amount`.
     * Emits an {ApprovalByAmount} event.
     *
     * Requirements:
     * - `operator` cannot be the caller.
     */
    function approve(address operator, uint256 id, uint256 amount) external;

    /**
     * @notice Returns the amount allocated to `operator` approved to transfer `account`'s tokens, according to `id`.
     */
    function allowance(address account, address operator, uint256 id) external view returns (uint256);
}

The approve(address operator, uint256 id, uint256 amount) function MUST be either public or external.

The allowance(address account, address operator, uint256 id) function MUST be either public or external and MUST be view.

The safeTrasferFrom function (as defined by EIP-1155) MUST:

• Not revert if the user has approved msg.sender with a sufficient amount
• Subtract the transferred amount of tokens from the approved amount if msg.sender is not approved with setApprovalForAll

In addition, the safeBatchTransferFrom MUST:

• Add an extra condition that checks if the allowance of all ids have the approved amounts (See _checkApprovalForBatch function reference implementation)

The ApprovalByAmount event MUST be emitted when a certain number of tokens are approved.

The supportsInterface method MUST return true when called with 0x1be07d74.

Rationale

The name "EIP-1155 Approval By Amount Extension" was chosen because it is a succinct description of this EIP. Users can approve their tokens by id and amount to operators.

By having a way to approve and revoke in a manner similar to EIP-20, the trust level can be more directly managed by users:

• Using the approve function, users can approve an operator to spend an amount of tokens for each id.
• Using the allowance function, users can see the approval that an operator has for each id.

The EIP-20 name patterns were used due to similarities with EIP-20 approvals.

Backwards Compatibility

This standard is compatible with EIP-1155.

Reference Implementation

The reference implementation can be found here.

Security Considerations

Users of this EIP must thoroughly consider the amount of tokens they give permission to operators, and should revoke unused authorizations.

Copyright

Copyright and related rights waived via CC0.