From 3bdea52d41321ebbaa411b544386c8e1dad95cde Mon Sep 17 00:00:00 2001 From: Jarno Marttila Date: Tue, 19 Apr 2022 12:54:56 +0200 Subject: [PATCH 01/24] Shareable NFT eip draft --- EIPS/eip-shareable-nft.md | 145 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 EIPS/eip-shareable-nft.md diff --git a/EIPS/eip-shareable-nft.md b/EIPS/eip-shareable-nft.md new file mode 100644 index 00000000000000..2437da8e6bf878 --- /dev/null +++ b/EIPS/eip-shareable-nft.md @@ -0,0 +1,145 @@ +--- +eip: to-be-numberd +title: Shareable non-transferable non-fungible token standard +description: A standard interface for shareable non-transferable NFTs +author: ATARCA team +discussions-to: https://ethereum-magicians.org/t/new-nft-concept-shareable-nfts/8681 +status: Draft +type: Standards Track +category: ERC +created: 2022-01-28 +requires: 165 +--- + +## Abstract + +The following defines a standard interface for shareable tokens used in [ATARCA project](https://atarca.eu/) (Grant agreement 964678) to create shareable non-transferable non-fungible tokens. The standard allows creation of tokens that can hold value, but cannot be exchanged for rival goods such as money, cryptocurrencies or other goods that hold monetary value. Shareability of tokens can be understood as re-minting of a token for a new recipient e.g. by making a copy of the token and by giving it away while retaining the original one. The sharing and its associated events allow construction of a graph describing who has shared what to which party. + +## Motivation + +Traditional NFT standards such as ERC-721 and ERC-1155 have been developed to introduce artificial digital scarcity and to capture rival value. NFT standards and implementations don't necessarily have to be exhibit scarcity and in certain use cases such as in ATARCA project we wish to avoid introduction of deliberate scarcity. + +In ATARCA project we attempt to capture positive externalities in ecosystems with new types of incentive mechanisms that exhibit anti-rival logic, serve as an unit of accounting and function as medium of sharing. We envision that shareable tokens can work both as incentives but also as representations of items that are typically digital in their nature and gain more value as they are shared. + +These requirements have set us to define shareable non-transferable NFTs. These shareable NFTs can be “shared” in the same way digital goods can be shared, at an almost zero technical transaction cost. They are used to instantiate quantified anti-rival value, a medium of sharing. Hence, they work somewhat as money, being a store of value and a unit of account, but instead of being a medium of exchange, they are a medium of sharing. + +Typical NFT standards such as ERC-721 and ERC-1155 do not define a sharing modality. Instead ERC standards define user interfaces for typical rival use cases such as token minting and token transactions that the NFT contract implementations should fulfil. The ‘standard’ contract implementations may extend the functionalities beyond the definition of interfaces. The tokens developed in the ATARCA experiments are designed to be token standard compatible at the interface level. However the implementation of token contracts may contain extended functionalities to match the requirements of the experiments such as the requirement of 'shareability'. In reflection to standard token definitions, shareability of a token could be thought of as re-mintability of an existing token. Contracts define re-mintable non-transferable tokens which retain some reference to previous tokens upon and after re-minting. + +## 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. + +```solidity +import "@openzeppelin/contracts/utils/introspection/IERC165.sol"; + +interface IERCsntNFT is IERC165 { + + /// @dev This emits when a token is shared, reminted and given to another wallet that isn't function caller + event Share(address indexed from, address indexed to, uint256 indexed tokenId, uint256 derivedFromtokenId); + + /// @dev Shares, remints an existing token, gives a newly minted token a fresh token id, keeps original token at function callers possession and transfers newly minted token to receiver which should be another address than function caller. + function share(address to, uint256 tokenIdToBeShared, uint256 newTokenId) external virtual; + +} +``` + +## Rationale + +Current NFT standards define transferable non-fungible tokens. However to be able to create shareable NFTs we see that existing NFT contracts could be extended with an interface which defines the basic principles of sharing, namely the Event of sharing and the function method of sharing. In ATARCA we have chosen to go with shareable non-transferable NFTs which in our use case denote an award or merit for done effort. + +Shareable tokens can be transferable or non-transferable as it is up to implementation details of the token contract. In the reference implementation we have a general case distilled from the ATARCA case that defines a shareable non-transferable NFTs using the shareable NFT interface. + + + +## Backwards Compatibility + +TBD + +## Reference Implementation + +Following reference implementation demonstrates a general use case of one of our pilots. In this case a shareable non-transferable token represents a contribution done to a community that the contract owner has decided to merit with a token. Contract owner can mint a merit token and give it to a person. This token can be further shared by the receiver to other parties for example to share the received merit to others that have participated or influenced his contribution. + +``` +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.0; + +import "./IERCsntNFT.sol"; +import "@openzeppelin/contracts/token/ERC721/IERC721.sol"; +import "@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol"; +import "@openzeppelin/contracts/utils/Address.sol"; +import "@openzeppelin/contracts/utils/Context.sol"; +import "@openzeppelin/contracts/utils/Strings.sol"; +import "@openzeppelin/contracts/utils/introspection/ERC165.sol"; +import "@openzeppelin/contracts/token/ERC721/extensions/IERC721Metadata.sol"; +import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol"; +import "@openzeppelin/contracts/access/Ownable.sol"; + +contract ShareableERC721 is ERC721URIStorage, Ownable, IERCsntNFT { + + string baseURI; + + constructor(string memory _name, string memory _symbol) ERC721(_name, _symbol) {} + + function mint( + address account, + uint256 tokenId + ) external onlyOwner { + _mint(account, tokenId); + } + + function setTokenURI( + uint256 tokenId, + string memory tokenURI + ) external { + _setTokenURI(tokenId, tokenURI); + } + + function setBaseURI(string memory baseURI_) external { + baseURI = baseURI_; + } + + function _baseURI() internal view override returns (string memory) { + return baseURI; + } + + function share(address to, uint256 tokenIdToBeShared, uint256 newTokenId) external virtual { + require(to != address(0), "ERC721: mint to the zero address"); + require(_exists(tokenIdToBeShared), "ShareableERC721: token to be shared must exist"); + require(!_exists(newTokenId), "token with given id already exists"); + + require(msg.sender == ownerOf(tokenIdToBeShared), "Method caller must be the owner of token"); + + string memory _tokenURI = tokenURI(tokenIdToBeShared); + _mint(to, newTokenId); + _setTokenURI(newTokenId, _tokenURI); + + emit Share(msg.sender, to, newTokenId, tokenIdToBeShared); + } + + function transferFrom( + address from, + address to, + uint256 tokenId + ) public virtual override { + revert('In this reference implementation tokens are not transferrable'); + } + + function safeTransferFrom( + address from, + address to, + uint256 tokenId + ) public virtual override { + revert('In this reference implementation tokens are not transferrable'); + } +} + + + +``` +## Security Considerations + +TBD + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From eed80daf03a40401c434f5c5931bb55ae18eea67 Mon Sep 17 00:00:00 2001 From: Jarno Marttila Date: Wed, 20 Apr 2022 16:38:53 +0200 Subject: [PATCH 02/24] EIP numbering to reflect PR number --- EIPS/{eip-shareable-nft.md => eip-5023.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename EIPS/{eip-shareable-nft.md => eip-5023.md} (99%) diff --git a/EIPS/eip-shareable-nft.md b/EIPS/eip-5023.md similarity index 99% rename from EIPS/eip-shareable-nft.md rename to EIPS/eip-5023.md index 2437da8e6bf878..ff557c387c4240 100644 --- a/EIPS/eip-shareable-nft.md +++ b/EIPS/eip-5023.md @@ -1,5 +1,5 @@ --- -eip: to-be-numberd +eip: 5023 title: Shareable non-transferable non-fungible token standard description: A standard interface for shareable non-transferable NFTs author: ATARCA team From 144b13945e7083bee5e094f74296bf40cdc7b4fe Mon Sep 17 00:00:00 2001 From: Jarno Marttila Date: Tue, 26 Apr 2022 11:04:23 +0200 Subject: [PATCH 03/24] added a named author from ATARCA team to build consensus with community --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index ff557c387c4240..1458f9f3c9f0a0 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -2,7 +2,7 @@ eip: 5023 title: Shareable non-transferable non-fungible token standard description: A standard interface for shareable non-transferable NFTs -author: ATARCA team +author: Jarno Marttila (@yaruno) discussions-to: https://ethereum-magicians.org/t/new-nft-concept-shareable-nfts/8681 status: Draft type: Standards Track From c0eca19e636e9a83bd164a560e763a8419125d30 Mon Sep 17 00:00:00 2001 From: Jarno Marttila Date: Tue, 26 Apr 2022 13:47:52 +0200 Subject: [PATCH 04/24] added a named author from ATARCA team to build consensus with community --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index 1458f9f3c9f0a0..74442ba0444760 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -2,7 +2,7 @@ eip: 5023 title: Shareable non-transferable non-fungible token standard description: A standard interface for shareable non-transferable NFTs -author: Jarno Marttila (@yaruno) +author: Jarno Marttila (@yaruno), Martin Moravek (@mmartinmo) discussions-to: https://ethereum-magicians.org/t/new-nft-concept-shareable-nfts/8681 status: Draft type: Standards Track From 77d918969ddaf80f3da002cc8e18ae74dff7c37b Mon Sep 17 00:00:00 2001 From: yaruno Date: Mon, 9 May 2022 16:22:23 +0200 Subject: [PATCH 05/24] Update EIPS/eip-5023.md Removed links to external sources according to suggestion. Co-authored-by: Micah Zoltu --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index 74442ba0444760..fc9770936e8e44 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -13,7 +13,7 @@ requires: 165 ## Abstract -The following defines a standard interface for shareable tokens used in [ATARCA project](https://atarca.eu/) (Grant agreement 964678) to create shareable non-transferable non-fungible tokens. The standard allows creation of tokens that can hold value, but cannot be exchanged for rival goods such as money, cryptocurrencies or other goods that hold monetary value. Shareability of tokens can be understood as re-minting of a token for a new recipient e.g. by making a copy of the token and by giving it away while retaining the original one. The sharing and its associated events allow construction of a graph describing who has shared what to which party. +This standard allows creation of tokens that can hold value, but cannot be exchanged for rival goods such as money, cryptocurrencies or other goods that hold monetary value. Shareability of tokens can be understood as re-minting of a token for a new recipient e.g. by making a copy of the token and by giving it away while retaining the original one. The sharing and its associated events allow construction of a graph describing who has shared what to which party. ## Motivation From a8f3325a19cfe97bf998b7a9d90ccb7d2389e7c7 Mon Sep 17 00:00:00 2001 From: yaruno Date: Mon, 9 May 2022 16:23:59 +0200 Subject: [PATCH 06/24] Update EIPS/eip-5023.md Removed reference to specific ERC-165 implementation. Co-authored-by: Micah Zoltu --- EIPS/eip-5023.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index fc9770936e8e44..5748945c814ebe 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -30,8 +30,6 @@ Typical NFT standards such as ERC-721 and ERC-1155 do not define a sharing modal 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. ```solidity -import "@openzeppelin/contracts/utils/introspection/IERC165.sol"; - interface IERCsntNFT is IERC165 { /// @dev This emits when a token is shared, reminted and given to another wallet that isn't function caller From 146f2d7f18d7a2be9f9ef3cde87a7a569887f8ab Mon Sep 17 00:00:00 2001 From: Jarno Marttila Date: Mon, 9 May 2022 16:27:54 +0200 Subject: [PATCH 07/24] Corrected licence on reference implementation --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index 5748945c814ebe..f2bf27d3728b62 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -58,7 +58,7 @@ TBD Following reference implementation demonstrates a general use case of one of our pilots. In this case a shareable non-transferable token represents a contribution done to a community that the contract owner has decided to merit with a token. Contract owner can mint a merit token and give it to a person. This token can be further shared by the receiver to other parties for example to share the received merit to others that have participated or influenced his contribution. ``` -// SPDX-License-Identifier: MIT +// SPDX-License-Identifier: CC0 pragma solidity ^0.8.0; import "./IERCsntNFT.sol"; From f8d097c8555b2c734e0dc19273ee5d656fcf5734 Mon Sep 17 00:00:00 2001 From: yaruno Date: Fri, 13 May 2022 14:53:21 +0200 Subject: [PATCH 08/24] Update EIPS/eip-5023.md Licence should link to licence file in repository. Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index f2bf27d3728b62..9e4abe27e0c7db 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -140,4 +140,4 @@ TBD ## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). +Copyright and related rights waived via [CC0](../LICENSE). From ac65930fc8360df3acc606c56370ae9a28f1f4d5 Mon Sep 17 00:00:00 2001 From: yaruno Date: Fri, 13 May 2022 15:22:16 +0200 Subject: [PATCH 09/24] Update EIPS/eip-5023.md license file ending corrected Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index 9e4abe27e0c7db..21ff912360be7a 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -140,4 +140,4 @@ TBD ## Copyright -Copyright and related rights waived via [CC0](../LICENSE). +Copyright and related rights waived via [CC0](../LICENSE.md). From fa218c478a353ee91493a01e540d3426b5883ccc Mon Sep 17 00:00:00 2001 From: yaruno Date: Mon, 23 May 2022 11:39:15 +0200 Subject: [PATCH 10/24] Update EIPS/eip-5023.md Removed mention of standard as suggested. Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index 21ff912360be7a..463dc95d75df1f 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -1,6 +1,6 @@ --- eip: 5023 -title: Shareable non-transferable non-fungible token standard +title: Shareable non-transferable non-fungible token description: A standard interface for shareable non-transferable NFTs author: Jarno Marttila (@yaruno), Martin Moravek (@mmartinmo) discussions-to: https://ethereum-magicians.org/t/new-nft-concept-shareable-nfts/8681 From 38970ea27e9580e399b1942520e9cbf86b672d91 Mon Sep 17 00:00:00 2001 From: yaruno Date: Mon, 23 May 2022 11:39:41 +0200 Subject: [PATCH 11/24] Update EIPS/eip-5023.md Removed mention of standard as suggested. Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index 463dc95d75df1f..658422c4282745 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -1,7 +1,7 @@ --- eip: 5023 title: Shareable non-transferable non-fungible token -description: A standard interface for shareable non-transferable NFTs +description: An interface for shareable non-transferable NFTs author: Jarno Marttila (@yaruno), Martin Moravek (@mmartinmo) discussions-to: https://ethereum-magicians.org/t/new-nft-concept-shareable-nfts/8681 status: Draft From 2ecbe87c39f87b68ed0b7aca252dac024c295fb7 Mon Sep 17 00:00:00 2001 From: yaruno Date: Mon, 23 May 2022 11:41:37 +0200 Subject: [PATCH 12/24] Update EIPS/eip-5023.md Grammatical corrections Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index 658422c4282745..c2e547249ad8cf 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -17,7 +17,7 @@ This standard allows creation of tokens that can hold value, but cannot be excha ## Motivation -Traditional NFT standards such as ERC-721 and ERC-1155 have been developed to introduce artificial digital scarcity and to capture rival value. NFT standards and implementations don't necessarily have to be exhibit scarcity and in certain use cases such as in ATARCA project we wish to avoid introduction of deliberate scarcity. +Traditional NFT standards such as ERC-721 and ERC-1155 have been developed to introduce artificial digital scarcity and to capture rival value. NFT standards and implementations don't necessarily have to exhibit scarcity and in certain use cases such as in ATARCA project we wish to avoid introduction of deliberate scarcity. In ATARCA project we attempt to capture positive externalities in ecosystems with new types of incentive mechanisms that exhibit anti-rival logic, serve as an unit of accounting and function as medium of sharing. We envision that shareable tokens can work both as incentives but also as representations of items that are typically digital in their nature and gain more value as they are shared. From 40313b16ade6b6f7a6e117a02b7a64811e1a7bbc Mon Sep 17 00:00:00 2001 From: Jarno Marttila Date: Tue, 24 May 2022 09:57:56 +0200 Subject: [PATCH 13/24] Renamed interface to follow convention of naming them after EIP number --- EIPS/eip-5023.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index c2e547249ad8cf..7f577429300fee 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -30,7 +30,7 @@ Typical NFT standards such as ERC-721 and ERC-1155 do not define a sharing modal 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. ```solidity -interface IERCsntNFT is IERC165 { +interface IERC5023 is IERC165 { /// @dev This emits when a token is shared, reminted and given to another wallet that isn't function caller event Share(address indexed from, address indexed to, uint256 indexed tokenId, uint256 derivedFromtokenId); @@ -61,7 +61,7 @@ Following reference implementation demonstrates a general use case of one of our // SPDX-License-Identifier: CC0 pragma solidity ^0.8.0; -import "./IERCsntNFT.sol"; +import "./IERC5023.sol"; import "@openzeppelin/contracts/token/ERC721/IERC721.sol"; import "@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol"; import "@openzeppelin/contracts/utils/Address.sol"; @@ -72,7 +72,7 @@ import "@openzeppelin/contracts/token/ERC721/extensions/IERC721Metadata.sol"; import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol"; import "@openzeppelin/contracts/access/Ownable.sol"; -contract ShareableERC721 is ERC721URIStorage, Ownable, IERCsntNFT { +contract ShareableERC721 is ERC721URIStorage, Ownable, IERC5023 { string baseURI; From fe2cc815d14541e263ac5b0a0ce097309281495f Mon Sep 17 00:00:00 2001 From: Jarno Marttila Date: Tue, 24 May 2022 11:59:05 +0200 Subject: [PATCH 14/24] Interface functions are implicitly virtual --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index 7f577429300fee..999c29b2618121 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -36,7 +36,7 @@ interface IERC5023 is IERC165 { event Share(address indexed from, address indexed to, uint256 indexed tokenId, uint256 derivedFromtokenId); /// @dev Shares, remints an existing token, gives a newly minted token a fresh token id, keeps original token at function callers possession and transfers newly minted token to receiver which should be another address than function caller. - function share(address to, uint256 tokenIdToBeShared, uint256 newTokenId) external virtual; + function share(address to, uint256 tokenIdToBeShared, uint256 newTokenId) external; } ``` From 5f4c6b74c903e40b9a38cdddd582ac8d0e8c4067 Mon Sep 17 00:00:00 2001 From: Jarno Marttila Date: Tue, 24 May 2022 12:18:14 +0200 Subject: [PATCH 15/24] Interface ID for IERC5023 --- EIPS/eip-5023.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index 999c29b2618121..c7f6718f0ddb2a 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -30,6 +30,7 @@ Typical NFT standards such as ERC-721 and ERC-1155 do not define a sharing modal 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. ```solidity +/// Note: the ERC-165 identifier for this interface is 0xd763f0cf interface IERC5023 is IERC165 { /// @dev This emits when a token is shared, reminted and given to another wallet that isn't function caller From f6e31fec3fc0cdf0e04333978ffdf435c9234e25 Mon Sep 17 00:00:00 2001 From: yaruno Date: Thu, 2 Jun 2022 13:41:09 +0200 Subject: [PATCH 16/24] Update EIPS/eip-5023.md Grammar Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com> --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index c7f6718f0ddb2a..359afede887799 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -17,7 +17,7 @@ This standard allows creation of tokens that can hold value, but cannot be excha ## Motivation -Traditional NFT standards such as ERC-721 and ERC-1155 have been developed to introduce artificial digital scarcity and to capture rival value. NFT standards and implementations don't necessarily have to exhibit scarcity and in certain use cases such as in ATARCA project we wish to avoid introduction of deliberate scarcity. +Traditional NFT standards such as ERC-721 and ERC-1155 have been developed to introduce artificial digital scarcity and to capture rival value. NFT standards and implementations don't necessarily have to exhibit scarcity and in certain use cases, such as in the ATARCA project, it's preferable to avoid the introduction of deliberate scarcity. In ATARCA project we attempt to capture positive externalities in ecosystems with new types of incentive mechanisms that exhibit anti-rival logic, serve as an unit of accounting and function as medium of sharing. We envision that shareable tokens can work both as incentives but also as representations of items that are typically digital in their nature and gain more value as they are shared. From a4226c7bcfe88beb5a85e95b1da698f717921154 Mon Sep 17 00:00:00 2001 From: yaruno Date: Mon, 4 Jul 2022 14:47:15 +0200 Subject: [PATCH 17/24] Update EIPS/eip-5023.md First mention of EIP should have a link to it. Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index 359afede887799..ca1886373b05af 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -17,7 +17,7 @@ This standard allows creation of tokens that can hold value, but cannot be excha ## Motivation -Traditional NFT standards such as ERC-721 and ERC-1155 have been developed to introduce artificial digital scarcity and to capture rival value. NFT standards and implementations don't necessarily have to exhibit scarcity and in certain use cases, such as in the ATARCA project, it's preferable to avoid the introduction of deliberate scarcity. +Traditional NFT standards such as [EIP-721](./eip-721.md) and [EIP-1155](./eip-1155.md) have been developed to introduce artificial digital scarcity and to capture rival value. NFT standards and implementations don't necessarily have to exhibit scarcity and in certain use cases, such as in the ATARCA project, it's preferable to avoid the introduction of deliberate scarcity. In ATARCA project we attempt to capture positive externalities in ecosystems with new types of incentive mechanisms that exhibit anti-rival logic, serve as an unit of accounting and function as medium of sharing. We envision that shareable tokens can work both as incentives but also as representations of items that are typically digital in their nature and gain more value as they are shared. From ec7bad9d45bbbbcce7509aed2eee5b1242e9e54f Mon Sep 17 00:00:00 2001 From: yaruno Date: Mon, 4 Jul 2022 14:48:50 +0200 Subject: [PATCH 18/24] Update EIPS/eip-5023.md CC0 should have a version number attached to it. Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index ca1886373b05af..d2503446d62964 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -59,7 +59,7 @@ TBD Following reference implementation demonstrates a general use case of one of our pilots. In this case a shareable non-transferable token represents a contribution done to a community that the contract owner has decided to merit with a token. Contract owner can mint a merit token and give it to a person. This token can be further shared by the receiver to other parties for example to share the received merit to others that have participated or influenced his contribution. ``` -// SPDX-License-Identifier: CC0 +// SPDX-License-Identifier: CC0-1.0 pragma solidity ^0.8.0; import "./IERC5023.sol"; From d1cbef55e057379531f07e75a03209914f39fe1c Mon Sep 17 00:00:00 2001 From: Jarno Date: Wed, 12 Oct 2022 15:36:13 +0200 Subject: [PATCH 19/24] reworking the EIP --- EIPS/eip-5023.md | 56 ++++++++++++++++++++++++++++++++++-------------- 1 file changed, 40 insertions(+), 16 deletions(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index d2503446d62964..3581fca8fa6b8e 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -1,7 +1,7 @@ --- eip: 5023 -title: Shareable non-transferable non-fungible token -description: An interface for shareable non-transferable NFTs +title: Shareable non-fungible token +description: An interface for creating value-holding tokens that can be shared by multiple owners instead of transferring author: Jarno Marttila (@yaruno), Martin Moravek (@mmartinmo) discussions-to: https://ethereum-magicians.org/t/new-nft-concept-shareable-nfts/8681 status: Draft @@ -13,17 +13,26 @@ requires: 165 ## Abstract -This standard allows creation of tokens that can hold value, but cannot be exchanged for rival goods such as money, cryptocurrencies or other goods that hold monetary value. Shareability of tokens can be understood as re-minting of a token for a new recipient e.g. by making a copy of the token and by giving it away while retaining the original one. The sharing and its associated events allow construction of a graph describing who has shared what to which party. +This standard allows creation of tokens that can hold value and that can be shared. Shareability of tokens can be understood as re-minting of a token for a new recipient e.g. by making a copy of the token and by giving it away while retaining 'the original one'. The sharing and its associated events allow construction of a graph describing who has shared what to which party. + +This EIP defines an interoperable interface that fulfils the concept of shareable of tokens and demonstrates the application of it through a reference implementation. + ## Motivation -Traditional NFT standards such as [EIP-721](./eip-721.md) and [EIP-1155](./eip-1155.md) have been developed to introduce artificial digital scarcity and to capture rival value. NFT standards and implementations don't necessarily have to exhibit scarcity and in certain use cases, such as in the ATARCA project, it's preferable to avoid the introduction of deliberate scarcity. +Traditional NFT standards such as [EIP-721](./eip-721.md) and [EIP-1155](./eip-1155.md) have been developed to introduce artificial digital scarcity and to capture rival value. NFT standards and implementations don't necessarily have to exhibit scarcity and in certain use cases it's preferable to avoid the introduction of deliberate scarcity. + +We have attempted to capture positive externalities in ecosystems with new types of incentive mechanisms that exhibit anti-rival logic, serve as an unit of accounting and function as medium of sharing. We envision that shareable tokens can work both as incentives but also as representations of items that are typically digital in their nature and gain more value as they are shared. -In ATARCA project we attempt to capture positive externalities in ecosystems with new types of incentive mechanisms that exhibit anti-rival logic, serve as an unit of accounting and function as medium of sharing. We envision that shareable tokens can work both as incentives but also as representations of items that are typically digital in their nature and gain more value as they are shared. +These requirements have set us to define shareable NFTs and more specifically a variation of shareable NFTs called non-transferable shareable NFTs. These shareable NFTs can be “shared” in the same way digital goods can be shared, at an almost zero technical transaction cost. We have utilized them to capture anti-rival value in terms of accounting positive externalities in an economic system. -These requirements have set us to define shareable non-transferable NFTs. These shareable NFTs can be “shared” in the same way digital goods can be shared, at an almost zero technical transaction cost. They are used to instantiate quantified anti-rival value, a medium of sharing. Hence, they work somewhat as money, being a store of value and a unit of account, but instead of being a medium of exchange, they are a medium of sharing. +Typical NFT standards such as EIP-721 and EIP-1155 do not define a sharing modality. Instead ERC standards define interfaces for typical rival use cases such as token minting and token transactions that the NFT contract implementations should fulfil. The ‘standard contract implementations' may extend the functionalities of these standards beyond the definition of interfaces. The shareable tokens that we have designed and developed in our experiments are designed to be token standard compatible at the interface level. However the implementation of token contracts may contain extended functionalities to match the requirements of the experiments such as the requirement of 'shareability'. In reflection to standard token definitions, shareability of a token could be thought of as re-mintability of an existing token to another party while retaining the original version of it. -Typical NFT standards such as ERC-721 and ERC-1155 do not define a sharing modality. Instead ERC standards define user interfaces for typical rival use cases such as token minting and token transactions that the NFT contract implementations should fulfil. The ‘standard’ contract implementations may extend the functionalities beyond the definition of interfaces. The tokens developed in the ATARCA experiments are designed to be token standard compatible at the interface level. However the implementation of token contracts may contain extended functionalities to match the requirements of the experiments such as the requirement of 'shareability'. In reflection to standard token definitions, shareability of a token could be thought of as re-mintability of an existing token. Contracts define re-mintable non-transferable tokens which retain some reference to previous tokens upon and after re-minting. +Sharing is an interesting concept as it can be thought and perceived in different ways. For example, when we talk about sharing we can think about it is as digital copying, giving a copy of a digital resource while retaining a version by ourselves. Sharing can also be fractional or sharing could be about giving rights to use a certain resource. The concept of shareability and the context of shareability can take different forms and one might use different types of implementatins for instances of shareable tokens. Hence we haven't restricted that the interface should require any specific token type. + +Shareable tokens can be made non-transferable at the contract implementaiton level. Doing so, makes them shareable non-transferable tokens. In the reference implementation we have distilled a general case from our use cases that defines a shareable non-transferable NFTs using the shareable NFT interface. + +We believe that the wider audience should benefit from an abstraction level higher definition for shareability, such as this interface implementation, that defines minimum amount of functions that would be implemented to satisfy the concept of shareability. ## Specification @@ -37,18 +46,30 @@ interface IERC5023 is IERC165 { event Share(address indexed from, address indexed to, uint256 indexed tokenId, uint256 derivedFromtokenId); /// @dev Shares, remints an existing token, gives a newly minted token a fresh token id, keeps original token at function callers possession and transfers newly minted token to receiver which should be another address than function caller. - function share(address to, uint256 tokenIdToBeShared, uint256 newTokenId) external; + function share(address to, uint256 tokenIdToBeShared) returns(uint256 newTokenId) external; } ``` ## Rationale -Current NFT standards define transferable non-fungible tokens. However to be able to create shareable NFTs we see that existing NFT contracts could be extended with an interface which defines the basic principles of sharing, namely the Event of sharing and the function method of sharing. In ATARCA we have chosen to go with shareable non-transferable NFTs which in our use case denote an award or merit for done effort. +Current NFT standards define transferable non-fungible tokens, but not shareable non-fungible tokens. To be able to create shareable NFTs we see that existing NFT contracts could be extended with an interface which defines the basic principles of sharing, namely the Event of sharing and the function method of sharing. Definition of how transferability of tokens should be handled is left to the contract implementor. In case transfering is left enable shareable tokens behave similarily to the existing tokens, except when they are shared, a version of token is retained. In case transfering is disabled, shareable tokens become shareable non-transferable tokens, where they can be minted and given or shared to other people, but they cannot be transferred away. + +Imagine that Bob works together with Alice on a project. Bob earns an unique NFT indicating that he has made effort to the project, but Bob feels that his accomplishments are not only out of his own accord. Bob wants to share his token with Alice to indicate that also Alice deserves recognition of having put effort on their project. Bob initiates token sharing by calling `Share` method on the contract which has his token and indicates which one of his tokens he wishes to share and to whom by passing address and token id parameters. A new token is minted for Alice and a `Share` event is initiated to communicate that it was Bob whom shared his token to Alice by logging addresses who shared a token id to whose address and which token id was this new token derived from. -Shareable tokens can be transferable or non-transferable as it is up to implementation details of the token contract. In the reference implementation we have a general case distilled from the ATARCA case that defines a shareable non-transferable NFTs using the shareable NFT interface. +Over time, a tree-like structures can be formed from the Share event information. If Bob shared to Alice, and Alice shared further to Charlie and Alice also shared to David a rudimentary tree structure forms out from sharing activity. This share event data can be later on utilized to gain more information of share activities that the tokens represent. +``` +B -> A -> C + \ + > D +``` +These tree structures can be further aggregated and collapsed to network representations e.g. social graphs on basis of whom has shared to whom over a span of time. E.g. if Bob shared a token to Alice, and Alice has shared a different token to Charlie and Bob has shared a token to Charlie, connections form between all these parties through sharing activities. +``` + B----A----C + \_______/ +``` ## Backwards Compatibility @@ -73,9 +94,11 @@ import "@openzeppelin/contracts/token/ERC721/extensions/IERC721Metadata.sol"; import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol"; import "@openzeppelin/contracts/access/Ownable.sol"; -contract ShareableERC721 is ERC721URIStorage, Ownable, IERC5023 { +contract ShareableERC721 is ERC721URIStorage, Ownable, IERC5023 /* EIP165 */ { string baseURI; + + uint256 internal _currentIndex; constructor(string memory _name, string memory _symbol) ERC721(_name, _symbol) {} @@ -101,18 +124,19 @@ contract ShareableERC721 is ERC721URIStorage, Ownable, IERC5023 { return baseURI; } - function share(address to, uint256 tokenIdToBeShared, uint256 newTokenId) external virtual { + function share(address to, uint256 tokenIdToBeShared) external returns(uint256 newTokenId) { require(to != address(0), "ERC721: mint to the zero address"); require(_exists(tokenIdToBeShared), "ShareableERC721: token to be shared must exist"); - require(!_exists(newTokenId), "token with given id already exists"); require(msg.sender == ownerOf(tokenIdToBeShared), "Method caller must be the owner of token"); string memory _tokenURI = tokenURI(tokenIdToBeShared); - _mint(to, newTokenId); - _setTokenURI(newTokenId, _tokenURI); + _mint(to, _currentIndex); + _setTokenURI(_currentIndex, _tokenURI); + + emit Share(msg.sender, to, _currentIndex, tokenIdToBeShared); - emit Share(msg.sender, to, newTokenId, tokenIdToBeShared); + return _currentIndex; } function transferFrom( From 72205375bdfed8bb4119339a8101fd3de99525e1 Mon Sep 17 00:00:00 2001 From: Jarno Date: Wed, 12 Oct 2022 15:42:09 +0200 Subject: [PATCH 20/24] Clarification when Share event is to be emitted --- EIPS/eip-5023.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index 3581fca8fa6b8e..d5edd65c9842b2 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -51,6 +51,8 @@ interface IERC5023 is IERC165 { } ``` +Share event is expected to be emitted when function method share is succesfully called and a new token on basis of a given token id is minted and transferred to a recipient. + ## Rationale Current NFT standards define transferable non-fungible tokens, but not shareable non-fungible tokens. To be able to create shareable NFTs we see that existing NFT contracts could be extended with an interface which defines the basic principles of sharing, namely the Event of sharing and the function method of sharing. Definition of how transferability of tokens should be handled is left to the contract implementor. In case transfering is left enable shareable tokens behave similarily to the existing tokens, except when they are shared, a version of token is retained. In case transfering is disabled, shareable tokens become shareable non-transferable tokens, where they can be minted and given or shared to other people, but they cannot be transferred away. From bc4ce39418fcfb0669c064ea9b94584aadc7a75f Mon Sep 17 00:00:00 2001 From: yaruno Date: Fri, 14 Oct 2022 15:41:34 +0200 Subject: [PATCH 21/24] Update EIPS/eip-5023.md Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index d5edd65c9842b2..48bb321574dbc4 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -1,6 +1,6 @@ --- eip: 5023 -title: Shareable non-fungible token +title: Shareable Non-Fungible Token description: An interface for creating value-holding tokens that can be shared by multiple owners instead of transferring author: Jarno Marttila (@yaruno), Martin Moravek (@mmartinmo) discussions-to: https://ethereum-magicians.org/t/new-nft-concept-shareable-nfts/8681 From 7d5a285fb2ca59fac55ef64bfef7e39bae590ab8 Mon Sep 17 00:00:00 2001 From: yaruno Date: Fri, 14 Oct 2022 15:42:49 +0200 Subject: [PATCH 22/24] Update EIPS/eip-5023.md Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index 48bb321574dbc4..7aa5f47d90bf36 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -1,7 +1,7 @@ --- eip: 5023 title: Shareable Non-Fungible Token -description: An interface for creating value-holding tokens that can be shared by multiple owners instead of transferring +description: An interface for creating value-holding tokens shareable by multiple owners author: Jarno Marttila (@yaruno), Martin Moravek (@mmartinmo) discussions-to: https://ethereum-magicians.org/t/new-nft-concept-shareable-nfts/8681 status: Draft From badb19ea33831cf34dbea85dc52136b247e995db Mon Sep 17 00:00:00 2001 From: yaruno Date: Fri, 14 Oct 2022 15:46:43 +0200 Subject: [PATCH 23/24] Update EIPS/eip-5023.md Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> --- EIPS/eip-5023.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index 7aa5f47d90bf36..4df5518275511a 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -13,9 +13,7 @@ requires: 165 ## Abstract -This standard allows creation of tokens that can hold value and that can be shared. Shareability of tokens can be understood as re-minting of a token for a new recipient e.g. by making a copy of the token and by giving it away while retaining 'the original one'. The sharing and its associated events allow construction of a graph describing who has shared what to which party. - -This EIP defines an interoperable interface that fulfils the concept of shareable of tokens and demonstrates the application of it through a reference implementation. +This EIP standardizes an interface for non-fungible value-holding shareable tokens. Shareability is accomplished by minting copies of existing tokens for new recipients. Sharing and associated events allow the construction of a graph describing who has shared what to which party. ## Motivation From 03ba033ba1941f1c845481161575c3bedc017673 Mon Sep 17 00:00:00 2001 From: yaruno Date: Fri, 14 Oct 2022 15:48:32 +0200 Subject: [PATCH 24/24] Update EIPS/eip-5023.md Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> --- EIPS/eip-5023.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5023.md b/EIPS/eip-5023.md index 4df5518275511a..ae4c0fc0372109 100644 --- a/EIPS/eip-5023.md +++ b/EIPS/eip-5023.md @@ -18,7 +18,7 @@ This EIP standardizes an interface for non-fungible value-holding shareable toke ## Motivation -Traditional NFT standards such as [EIP-721](./eip-721.md) and [EIP-1155](./eip-1155.md) have been developed to introduce artificial digital scarcity and to capture rival value. NFT standards and implementations don't necessarily have to exhibit scarcity and in certain use cases it's preferable to avoid the introduction of deliberate scarcity. +NFT standards such as [EIP-721](./eip-721.md) and [EIP-1155](./eip-1155.md) have been developed to standardize scarce digital resources. However, many non-fungible digital resources need not be scarce. We have attempted to capture positive externalities in ecosystems with new types of incentive mechanisms that exhibit anti-rival logic, serve as an unit of accounting and function as medium of sharing. We envision that shareable tokens can work both as incentives but also as representations of items that are typically digital in their nature and gain more value as they are shared.