ERC-5216 ERC-1155 quantity specified approval extension (ERC-1155 Allowance Extension)
Last Call · NFTs & multi-token · created 2022-07-11
An extension standard that lets ERC-1155 tokens be approved to a third party per id in a fixed amount. It splits the all-or-nothing approval authority into unit quantities.
Why it is needed
ERC-1155, which handles multiple token types in a single contract, is used in countless transactions every day, most commonly in interactions with NFT marketplaces. However, ERC-1155 only provides setApprovalForAll as its approval mechanism, which approves the entire balance of a given id at once. Given the nature of blockchains, a programming error or a malicious operator can cause funds to be lost permanently, so transactions should be as trust-minimized as possible. The all-or-nothing approval scheme, which entrusts far more authority than necessary, has a clear flaw from a minimal-trust standpoint. This standard combines ideas from ERC-20 and ERC-721 to create a trust mechanism that lets an owner approve a third party, such as a marketplace, for a limited amount of a given id's tokens rather than an unlimited amount.
What to implement
event Approval(address indexed account, address indexed operator, uint256 id, uint256 amount);: The event emitted when account grants or revokes operator's authority to transfer amount of a specific id's tokens.function approve(address operator, uint256 id, uint256 amount) external;: Grants operator the authority to transfer amount of a specific id from the caller's tokens. Emits an Approval event, and operator cannot be the caller itself.function allowance(address account, address operator, uint256 id) external view returns (uint256);: Returns the amount operator is approved to transfer from account's tokens for a specific id.
In depth
The IERC5216 interface and ERC-165 identifier
A contract using this standard MUST implement the IERC5216 interface. IERC5216 is an extension that inherits IERC1155 and consists of the Approval event and the approve and allowance functions. This interface's ERC-165 identifier is 0x1be07d74, and supportsInterface MUST return true when called with 0x1be07d74.
Requirements for the approve function
approve(address operator, uint256 id, uint256 amount) MUST be public or external. It grants operator the authority to transfer amount of the caller's tokens with the given id, and operator cannot be the caller itself. An Approval event MUST be emitted whenever a token amount is approved.
Requirements for the allowance function
allowance(address account, address operator, uint256 id) MUST be public or external and view. It returns the amount operator has been approved and allocated to transfer from account's tokens of the given id. Users can use this function to check an operator's approval per id.
Behavior rules for safeTransferFrom
safeTransferFrom as defined by ERC-1155 must follow two rules. First, if the user has approved msg.sender for a sufficient amount, the transfer must not revert. Second, if msg.sender is not approved via setApprovalForAll, the transferred token amount must be deducted from the allowance. In other words, an operator with blanket approval behaves as before, while an operator with only an amount-based approval has its limit reduced each time it is used.
Additional condition for safeBatchTransferFrom
safeBatchTransferFrom, which moves multiple ids at once, must add a check confirming that the allowance for every id covers the approved amounts. The _checkApprovalForBatch function in the reference implementation is an example of this check.
A design that follows ERC-20 naming conventions
The name of this standard, ERC-1155 Allowance Extension, was chosen to concisely describe its contents. Because of its similarity to ERC-20 approvals, it reuses ERC-20's naming conventions, approve and allowance. Users can directly manage their trust level by approving an amount per id with approve and checking an operator's approval with allowance. This standard is backward compatible with ERC-1155.
Standard status
As of the original text, this proposal's status is Last Call, with the last call deadline having been November 12, 2022. Requirements follow the keyword interpretations of RFC 2119, such as MUST and SHOULD.
Things to watch out for
- Carefully setting and revoking approved amounts: Users of this standard must carefully weigh how much of a token to allow an operator to use, and must revoke any approvals that are no longer in use.