This EIP proposes a standard interface for non-fungible double signature Soulbound multi-tokens. Previous account-bound token standards face the issue of users losing their account keys or having them rotated, thereby losing their tokens in the process. This EIP provides a solution to this issue that allows for the recycling of SBTs.
This EIP was inspired by the main characteristics of the EIP-1155 token and by articles in which benefits and potential use cases of Soulbound/Accountbound Tokens (SBTs) were presented. This design also allows for batch token transfers, saving on transaction costs. Trading of multiple tokens can be built on top of this standard and it removes the need to approve individual token contracts separately. It is also easy to describe and mix multiple fungible or non-fungible token types in a single contract.
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.
Smart contracts implementing this EIP MUST implement all of the functions in the EIP-5516 interface.
Smart contracts implementing this EIP MUST implement the EIP-165 supportsInterface function and and MUST return the constant value true if 0x8314f22b is passed through the interfaceID argument. They also MUST implement the EIP-1155 Interface and MUST return the constant value true if 0xd9b67a26 is passed through the interfaceID argument. Furthermore, they MUST implement the EIP-1155 Metadata interface, and MUST return the constant value true if 0x0e89341c is passed through the interfaceID argument.
See EIP-1155
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.4;
/**
@title Soulbound, Multi-Token standard.
@notice Interface of the EIP-5516
Note: The ERC-165 identifier for this interface is 0x8314f22b.
*/
interface IERC5516 {
/**
* @dev Emitted when `account` claims or rejects pending tokens under `ids[]`.
*/
event TokenClaimed(
address indexed operator,
address indexed account,
bool[] actions,
uint256[] ids
);
/**
* @dev Emitted when `from` transfers token under `id` to every address at `to[]`.
*/
event TransferMulti(
address indexed operator,
address indexed from,
address[] to,
uint256 amount,
uint256 id
);
/**
* @dev Get tokens owned by a given address.
*/
function tokensFrom(address from) external view returns (uint256[] memory);
/**
* @dev Get tokens awaiting to be claimed by a given address.
*/
function pendingFrom(address from) external view returns (uint256[] memory);
/**
* @dev Claims or Reject pending `id`.
*
* Requirements:
* - `account` must have a pending token under `id` at the moment of call.
* - `account` must not own a token under `id` at the moment of call.
*
* Emits a {TokenClaimed} event.
*
*/
function claimOrReject(
address account,
uint256 id,
bool action
) external;
/**
* @dev Claims or Reject pending tokens under `ids[]`.
*
* Requirements for each `id` `action` pair:
* - `account` must have a pending token under `id` at the moment of call.
* - `account` must not own a token under `id` at the moment of call.
*
* Emits a {TokenClaimed} event.
*
*/
function claimOrRejectBatch(
address account,
uint256[] memory ids,
bool[] memory actions
) external;
/**
* @dev Transfers `id` token from `from` to every address at `to[]`.
*
* Requirements:
*
* - `from` MUST be the creator(minter) of `id`.
* - All addresses in `to[]` MUST be non-zero.
* - All addresses in `to[]` MUST have the token `id` under `_pendings`.
* - All addresses in `to[]` MUST not own a token type under `id`.
*
* Emits a {TransfersMulti} event.
*
*/
function batchTransfer(
address from,
address[] memory to,
uint256 id,
uint256 amount,
bytes memory data
) external;
}
We believe that Soulbound Tokens serve as a specialized subset of existing EIP-1155 tokens. The advantage of such a design is the seamless compatibility of SBTs with existing NFT services. Service providers can treat SBTs like NFTs and do not need to make drastic changes to their existing codebase.
Making the standard mostly compatible with EIP-1155 also allows for SBTs to bind to multiple addresses and to Smart Contracts.
The Double-Signature functionality was implemented to prevent the receipt of unwanted tokens. It symbolizes a handshake between the token receiver and sender, implying that both parties agree on the token transfer.
The EIP-1155 Metadata Interface was implemented for further compatibility with EIP-1155.
As the Ethereum ecosystem continues to grow, many DApps are relying on traditional databases and explorer API services to retrieve and categorize data. The EIP-1155 standard guarantees that event logs emitted by the smart contract will provide enough data to create an accurate record of all current token balances. A database or explorer may listen to events and be able to provide indexed and categorized searches of every EIP-1155 token in the contract.
Quoted from EIP-1155
This EIP extends this concept to the Double Signature functionality: The {TokenClaimed} event logs all the necessary information of a ClaimOrReject(...) or ClaimOrRejectBatch(...) function call, storing relevant information about the actions performed by the user. This also applies to the batchTransfer(...) function: It emits the {TransferMulti} event and logs necessary data.
Given the non-transferability property of SBTs, if a user's keys to an account get compromised or rotated, such user may lose the ability to associate themselves with the token.
Given the multi-owner characteristic of EIP-1155 compliant interfaces and contracts, SBTs will be able to bind to multiple accounts, providing a potential solution to the issue.
Multi-owner SBTs can also be issued to a contract account that implements a multi-signature functionality (As recommended in EIP-4973); this can be achieved via the EIP-1155 Token Receiver interface.
The multi-token functionality permits the implementation of multiple token types in the same contract. Furthermore, all emitted tokens are stored in the same contract, preventing redundant bytecode from being deployed to the blockchain. It also facilitates transfer to token issuers, since all issued tokens are stored and can be accessed under the same contract address.
batchTransfer functionThis EIP supports transfers to multiple recipients. This eases token transfer to a large number of addresses, making it more gas-efficient and user-friendly.
This proposal is only partially compatible with EIP-1155, because it makes tokens non-transferable after the first transfer.
You can find an implementation of this standard in ../static/assets/EIP-5516.
Needs discussion.
Copyright and related rights waived via CC0.