Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Submit EIP-4973 - Account-bound tokens #4973

Merged
merged 37 commits into from
May 18, 2022
Merged
Show file tree
Hide file tree
Changes from 21 commits
Commits
Show all changes
37 commits
Select commit Hold shift + click to select a range
b8e717d
Add EIP-1238.md
TimDaub Apr 1, 2022
391cca9
Rename from 1238 to 4966
TimDaub Apr 5, 2022
9754700
Address feedback from PR
TimDaub Apr 5, 2022
8d7368e
Change name from 4966 to 4973
TimDaub Apr 10, 2022
6c2a00c
Fix header property order
TimDaub Apr 10, 2022
40522db
Remove 79 character manual word wrapping
TimDaub Apr 10, 2022
2e2dd82
Fix syntax error for incomplete link tag
TimDaub Apr 10, 2022
82dc89a
Remove Caveat section (for now)
TimDaub Apr 10, 2022
503d9c5
Clarify standards text
TimDaub Apr 10, 2022
c5dfe52
Run through grammarly
TimDaub Apr 10, 2022
48304f8
Update discussion link
TimDaub Apr 10, 2022
cd26e76
Update EIPS/eip-4973.md
TimDaub Apr 18, 2022
c6b6c2b
Update EIPS/eip-4973.md
TimDaub Apr 18, 2022
594bdaa
Update EIPS/eip-4973.md
TimDaub Apr 18, 2022
f2bf116
Update EIPS/eip-4973.md
TimDaub Apr 18, 2022
73525e9
Relicense to CC0-1.0
TimDaub Apr 18, 2022
b71be06
More copyediting
TimDaub Apr 18, 2022
bc16f29
Rename from "Soulbound" to "Account-bound" tokens
TimDaub Apr 18, 2022
9e26685
Add section on "Exception handling"
TimDaub Apr 18, 2022
a68efbe
Add section on revocation
TimDaub Apr 18, 2022
15527ff
Update EIPS/eip-4973.md
TimDaub Apr 22, 2022
22641bd
Rename to 'Account-bound Tokens'
TimDaub May 2, 2022
845c337
Correct co-author section
TimDaub May 2, 2022
057710f
Correct TLA from non-sensical 'ACT' to 'ABT'
TimDaub May 4, 2022
9ef6c49
Remove superfluous, explicit interface definitions
TimDaub May 4, 2022
04d7113
Add 'Naming' section
TimDaub May 4, 2022
c7a6e03
Consistently use EIP-XXXX format
TimDaub May 4, 2022
1a0b1ba
Remove reference to badge concept
TimDaub May 4, 2022
21ae681
Correctly apply camelCase in tests
TimDaub May 4, 2022
835c9f2
Update reference implementation
TimDaub May 5, 2022
6754cba
Replace `event Transfer` w/ Attest/Revoke
TimDaub May 5, 2022
4be4df0
Fix username prefix in author field
TimDaub May 9, 2022
5df30fc
Fix broken link to eip-721.md
TimDaub May 9, 2022
1aefe9a
Fix typo
TimDaub May 9, 2022
acdc991
Fix link to reference implementation
TimDaub May 9, 2022
50d2c65
Update EIPS/eip-4973.md
MicahZoltu May 16, 2022
194f910
Update EIPS/eip-4973.md
TimDaub May 18, 2022
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
127 changes: 127 additions & 0 deletions EIPS/eip-4973.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,127 @@
---
eip: 4973
title: Non-Transferrable Non-Fungible Account-bound Tokens (formerly Soulbound Tokens or "Badges")
TimDaub marked this conversation as resolved.
Show resolved Hide resolved
TimDaub marked this conversation as resolved.
Show resolved Hide resolved
description: A standard interface for non-transferrable non-fungible tokens, also known as "account-bound" or "soulbound tokens" or "badges".
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd recommend removing "standard", but I think it's fine to leave in for the draft.

Suggested change
description: A standard interface for non-transferrable non-fungible tokens, also known as "account-bound" or "soulbound tokens" or "badges".
description: An interface for non-transferrable non-fungible tokens, also known as "account-bound" or "soulbound tokens" or "badges".

author: Nicola Greco, Tim Daubenschütz (@TimDaub)
TimDaub marked this conversation as resolved.
Show resolved Hide resolved
discussions-to: https://ethereum-magicians.org/t/eip-4973-non-transferrable-non-fungible-tokens-soulbound-tokens-or-badges/8825
status: Draft
type: Standards Track
category: ERC
created: 2022-04-01
requires: 165, 721
---

## Abstract

Proposes a standard API for account-bound Tokens (ACT), also known as Badges, within smart contracts. An ACT is a non-fungible token bound to a single account, and cannot be transferred between accounts. This EIP defines basic functionality to gift, mint, and track ACTs.
TimDaub marked this conversation as resolved.
Show resolved Hide resolved

## Motivation

The Ethereum community has expressed a need for non-transferrable, non-fungible tokens. Common use cases include tracking an individual's achievements (which can be used as credentials), or items that cannot be transferred (like certain loot in multiplayer online games).

The purpose of this document is to make ACTs a reality on Ethereum by creating consensus around a **maximally backward-compatible** but otherwise **minimal** interface definition.

## 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.

`ERC-4973` tokens _must_ implement the interfaces:

- [ERC-165](./eip-165.md)'s `ERC165` (`0x01ffc9a7`)
- [ERC-721](./eip-721.md)'s `ERC721Metadata` (`0x5b5e139f`)

`ERC-4973` tokens _must not_ implement the interfaces:

- [ERC-721](./eip-721.md)'s `ERC721` (`0x80ac58cd`)

```solidity
pragma solidity ^0.8.6;

/// @title Non-Transferrable Non-Fungible Account-bound Tokens (formerly Soulbound Tokens or "Badges")
/// @dev See https://eips.ethereum.org/EIPS/eip-4973
/// Note: the ERC-165 identifier for this interface is 0x6352211e.
interface IERC4973 /* is ERC165, ERC721Metadata */ {
/// @dev This emits when transfer of any account-bound token is established by
/// any mechanism. This event emits when ACTs are created (`from` == 0) and
/// destroyed or revoked (`to` == 0). Exception: during contract creation, any
/// number of ACTs may be created and assigned without emitting Transfer.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd personally prefer to see this exception removed. If there is a concern due to a large amount of tokens being minted in contract creation, a merkle drop or signature-based claim system should be implemented, imho.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also pretty unsure how a 3rd party indexer can index a contract that can create any number of accounts on deployment or have them already assigned.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no strong opinion on this and honestly, I've just copied it from the original comment in EIP-721.

event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
/// @notice Find the address bound to an ERC4973 account-bound token
/// @dev ACTs assigned to zero address are considered invalid, and queries
/// about them do throw.
/// @param _tokenId The identifier for an ACT
/// @return The address of the owner bound to the ACT
function ownerOf(uint256 _tokenId) external view returns (address);
}

interface ERC165 {
/// @notice Query if a contract implements an interface
/// @param interfaceID The interface identifier, as specified in ERC-165
/// @dev Interface identification is specified in ERC-165. This function
/// uses less than 30,000 gas.
/// @return `true` if the contract implements `interfaceID` and
/// `interfaceID` is not 0xffffffff, `false` otherwise
function supportsInterface(bytes4 interfaceID) external view returns (bool);
}

/// @title ERC-721 Non-Fungible Token Standard, optional metadata extension
/// @dev See https://eips.ethereum.org/EIPS/eip-721
/// Note: the ERC-165 identifier for this interface is 0x5b5e139f.
interface ERC721Metadata /* is ERC721 */ {
/// @notice A descriptive name for a collection of NFTs in this contract
function name() external view returns (string _name);

/// @notice An abbreviated name for NFTs in this contract
function symbol() external view returns (string _symbol);

/// @notice A distinct Uniform Resource Identifier (URI) for a given asset.
/// @dev Throws if `_tokenId` is not a valid NFT. URIs are defined in RFC
/// 3986. The URI may point to a JSON file that conforms to the "ERC721
/// Metadata JSON Schema".
function tokenURI(uint256 _tokenId) external view returns (string);
}
TimDaub marked this conversation as resolved.
Show resolved Hide resolved
```

For "ERC721 Metadata JSON Schema", see [`ERC721`](./eip-721.md).
TimDaub marked this conversation as resolved.
Show resolved Hide resolved

## Rationale

### Interface

`ERC4973` shall be maximally backward-compatible but still only expose a minimal and simple to implement interface definition.
TimDaub marked this conversation as resolved.
Show resolved Hide resolved

As [`ERC721`](./eip-721.md) tokens have seen widespread adoption with wallet providers and marketplaces, using its `ERC721Metadata` interface with [`ERC165`](./eip-165.md) for feature-detection potentially allows implementers to support `ERC4973` tokens out of the box.

If an implementer of [`ERC721`](./eip-721.md) properly built [`ERC165`](./eip-165.md)'s `function supportsInterface(bytes4 interfaceID)` function, already by recognizing that [`ERC721`](./eip-721.md)'s track and transfer interface component with the identifier `0x80ac58cd` is not implemented, transferring of a token should not be suggested as a user interface option.

Still, however, since `ERC4973` supports [`ERC721`](./eip-721.md)'s `ERC721Metadata` extension, an account-bound token should be displayed in wallets and marketplaces with no changes needed.

Although other possible implementations of account-bound tokens are possible, e.g., by having all transfer functions revert, `ERC4973` is superior as it supports feature detection through [`ERC165`](./eip-165.md).

### Naming
TimDaub marked this conversation as resolved.
Show resolved Hide resolved

To precisely identify the standard's concept, we're referring to tokens as "account-bound" rather than "soulbound." Calling ERC4973 tokens "soulbound" would have opened the possibility to overinterpret its functionality as being bound to "a human's soul" - an idea we're not setting out to solve here. Rather, ERC4973 tokens are tied to specific Ethereum accounts and are therefore called "account-bound."

### Exception handling

Given the non-transferable between accounts property of ACTs, if a user's keys to an account or a contract get compromised or rotated, a user may lose the ability to associate themselves with the token. In some cases, this can be the desired effect. Therefore, it is suggested to implement re-issuance and potential revocation processes on the issuer side to enable recourse when it is not.

This document is deliberately abstaining from offering a standardized form of exception handling in cases where user keys are compromised or rotated.

In cases where implementers want to make account-bound tokens sharable among different accounts, e.g., to avoid losing access when keys get compromised, we suggest issuing the account-bound token towards a contract's account that implements a multi-signature functionality.
TimDaub marked this conversation as resolved.
Show resolved Hide resolved

### Revocations
TimDaub marked this conversation as resolved.
Show resolved Hide resolved

Revocations are optionally implementable by allowing an issuer to emit a secondary `event Transfer` with `to == 0` after emitting the initial minting `event Transfer` with `from == 0`.

## Backwards Compatibility

We have adopted the [`ERC165`](./eip-165.md) and `ERC721Metadata` functions purposefully to create a high degree of backward compatibility with [`ERC721`](./eip-721.md)'s implementers. Additionally, we have deliberately used [`ERC721`](./eip-721md`) terminology and definitions such as `event Transfer(...)` and `function ownerOf(...)` to minimize the effort of familiarization for `ERC4973` implementers already familiar with, e.g., [`ERC20`](./eip-20.md) or [`ERC721`](./eip-721.md).

## Reference Implementation

You can find an implementation of this standard in [../assets/eip-4973](../assets/eip-4973).
TimDaub marked this conversation as resolved.
Show resolved Hide resolved

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
MicahZoltu marked this conversation as resolved.
Show resolved Hide resolved
7 changes: 7 additions & 0 deletions assets/eip-4973/foundry.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
[default]
src = 'src'
out = 'out'
libs = ['lib']
remappings = ['ds-test/=lib/ds-test/src/','openzeppelin-contracts/=lib/openzeppelin-contracts/contracts/']

# See more config options https://github.com/gakonst/foundry/tree/master/config
78 changes: 78 additions & 0 deletions assets/eip-4973/src/ERC4973.sol
Original file line number Diff line number Diff line change
@@ -0,0 +1,78 @@
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.6;

import {ERC165} from "openzeppelin-contracts/utils/introspection/ERC165.sol";
import {Counters} from "openzeppelin-contracts/utils/Counters.sol";

import {IERC721Metadata} from "./interfaces/IERC721Metadata.sol";
import {IERC4973} from "./interfaces/IERC4973.sol";


abstract contract ERC4973 is ERC165, IERC721Metadata, IERC4973 {
TimDaub marked this conversation as resolved.
Show resolved Hide resolved
using Counters for Counters.Counter;

Counters.Counter private _tokenIds;
string private _name;
string private _symbol;

mapping(uint256 => address) private _bonds;
TimDaub marked this conversation as resolved.
Show resolved Hide resolved
mapping(uint256 => string) private _tokenURIs;

constructor(
string memory name_,
string memory symbol_
) {
_name = name_;
_symbol = symbol_;
}

function supportsInterface(bytes4 interfaceId) public view override returns (bool) {
return
interfaceId == type(IERC721Metadata).interfaceId ||
interfaceId == type(IERC4973).interfaceId ||
super.supportsInterface(interfaceId);
}

function name() public view virtual override returns (string memory) {
return _name;
}

function symbol() public view virtual override returns (string memory) {
return _symbol;
}

function tokenURI(uint256 tokenId) public view virtual override returns (string memory) {
require(_exists(tokenId), "tokenURI: token doesn't exist");
return _tokenURIs[tokenId];
}

function _exists(uint256 tokenId) internal view virtual returns (bool) {
return _bonds[tokenId] != address(0);
}

function ownerOf(uint256 tokenId) public view virtual returns (address) {
address owner = _bonds[tokenId];
require(owner != address(0), "ownerOf: token doesn't exist");
return owner;
}

function _mint(
TimDaub marked this conversation as resolved.
Show resolved Hide resolved
string calldata uri
) internal virtual returns (uint256) {
uint256 tokenId = _tokenIds.current();
_bonds[tokenId] = msg.sender;
TimDaub marked this conversation as resolved.
Show resolved Hide resolved
_tokenURIs[tokenId] = uri;
_tokenIds.increment();
emit Transfer(address(0), msg.sender, tokenId);
return tokenId;
}

function _burn(uint256 tokenId) internal virtual {
address owner = ownerOf(tokenId);

delete _bonds[tokenId];
delete _tokenURIs[tokenId];

emit Transfer(owner, address(0), tokenId);
}
}
72 changes: 72 additions & 0 deletions assets/eip-4973/src/ERC4973.t.sol
Original file line number Diff line number Diff line change
@@ -0,0 +1,72 @@
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.6;

import {DSTest} from "ds-test/test.sol";
import {IERC165} from "openzeppelin-contracts/utils/introspection/IERC165.sol";

import {IERC721Metadata} from "./interfaces/IERC721Metadata.sol";
import {IERC4973} from "./interfaces/IERC4973.sol";
import {ERC4973} from "./ERC4973.sol";

contract AccountboundToken is ERC4973 {
constructor() ERC4973("Name", "Symbol") {}

function mint(
string calldata uri
) external returns (uint256) {
return super._mint(uri);
}

function burn(uint256 tokenId) external {
super._burn(tokenId);
}
}

contract ERC4973Test is DSTest {
AccountboundToken abt;
TimDaub marked this conversation as resolved.
Show resolved Hide resolved

function setUp() public {
abt = new AccountboundToken();
}

function testIERC165() public {
assertTrue(abt.supportsInterface(type(IERC165).interfaceId));
}

function testIERC721Metadata() public {
assertTrue(abt.supportsInterface(type(IERC721Metadata).interfaceId));
}

function testIERC4973() public {
assertTrue(abt.supportsInterface(type(IERC4973).interfaceId));
assertEq(type(IERC4973).interfaceId, 0x0);
}

function testCheckMetadata() public {
assertEq(abt.name(), "Name");
assertEq(abt.symbol(), "Symbol");
}

function testMint() public {
string memory tokenURI = "https://example.com/metadata.json";
uint256 tokenId = abt.mint(tokenURI);
assertEq(abt.tokenURI(tokenId), tokenURI);
}

function testMintAndBurn() public {
string memory tokenURI = "https://example.com/metadata.json";
uint256 tokenId = abt.mint(tokenURI);
assertEq(abt.tokenURI(tokenId), tokenURI);
assertEq(abt.ownerOf(tokenId), address(this));
abt.burn(tokenId);
}

function testFailRequestingNonExistentTokenURI() public view {
abt.tokenURI(1337);
}

function testFailGetBonderOfNonExistentTokenId() public view {
abt.ownerOf(1337);
}
}

19 changes: 19 additions & 0 deletions assets/eip-4973/src/interfaces/IERC4973.sol
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.6;

/// @title Non-Transferrable Non-Fungible Account-bound Tokens (formerly Soulbound Tokens or "Badges")
TimDaub marked this conversation as resolved.
Show resolved Hide resolved
/// @dev See https://eips.ethereum.org/EIPS/eip-4973
/// Note: the ERC-165 identifier for this interface is 0x6352211e.
interface IERC4973 /* is ERC165, ERC721Metadata */ {
TimDaub marked this conversation as resolved.
Show resolved Hide resolved
/// @dev This emits when transfer of any account-bound token is established by any
/// mechanism. This event emits when ACTs are created (`from` == 0) and
TimDaub marked this conversation as resolved.
Show resolved Hide resolved
/// destroyed (`to` == 0). Exception: during contract creation, any number of
/// ACTs may be created and assigned without emitting Transfer.
event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
/// @notice Find the address bound to an ERC4973 account-bound token
/// @dev ACTs assigned to zero address are considered invalid, and queries
/// about them do throw.
/// @param _tokenId The identifier for an ACT
/// @return The address of the owner bound to the ACT
function ownerOf(uint256 _tokenId) external view returns (address);
}
8 changes: 8 additions & 0 deletions assets/eip-4973/src/interfaces/IERC721Metadata.sol
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.6;

interface IERC721Metadata {
function name() external view returns (string memory);
function symbol() external view returns (string memory);
function tokenURI(uint256 tokenId) external view returns (string memory);
}