4.9 KiB
eip | title | description | author | discussions-to | status | last-call-deadline | type | category | created | requires |
---|---|---|---|---|---|---|---|---|---|---|
5216 | EIP-1155 Approval By Amount Extension | Extension for EIP-1155 secure approvals | Iván Mañús (@ivanmmurciaua), Juan Carlos Cantó (@EscuelaCryptoES) | https://ethereum-magicians.org/t/eip-erc1155-approval-by-amount/9898 | Last Call | 2022-11-12 | Standards Track | ERC | 2022-07-11 | 20, 165, 1155 |
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 id
s, 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 sufficientamount
- Subtract the transferred amount of tokens from the approved amount if
msg.sender
is not approved withsetApprovalForAll
In addition, the safeBatchTransferFrom
MUST:
- Add an extra condition that checks if the
allowance
of allids
have the approvedamounts
(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 operator
s.
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 anamount
of tokens for eachid
. - Using the
allowance
function, users can see the approval that an operator has for eachid
.
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.