From b7db763b1e01d1f42d03af81db871c13d0406736 Mon Sep 17 00:00:00 2001 From: Billy Rennekamp Date: Sun, 2 Dec 2018 15:22:36 +0100 Subject: [PATCH 01/24] first draft --- EIPS/eip-rft.md | 199 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 199 insertions(+) create mode 100644 EIPS/eip-rft.md diff --git a/EIPS/eip-rft.md b/EIPS/eip-rft.md new file mode 100644 index 00000000000000..95fba95d57b27c --- /dev/null +++ b/EIPS/eip-rft.md @@ -0,0 +1,199 @@ +--- +eip: +title: Re-Fungible Token Standard (RFT) +author: Billy Rennekamp (@okwme), Dan Long (dan@artblx.com), Kiryl Yermakou (kiryl@artblx.com), Nate van der Ende (nate@artblx.com) +discussions-to: +status: Draft +type: Standards Track +category: ERC +created: 2018-11-18 +requires: EIP-20, EIP-165, EIP-721 +--- + +## Simple Summary + +This improvement proposal outlines an extension to the ERC-20 Token Standard and utilization of ERC-165 Standard Interface Detection. The purpose is to enable the ability to distinguish when an ERC-20 token represents shared ownership of an ERC-721 non-fungible token (NFT) and by extension any potentially underlying asset therein. This is made possible by a re-fungible token (RFT) contract assuming ownership of a non-fungible token. + +## Abstract + +The intention of this proposal, the Re-Fungible Token Standard, is to extend the ERC-20 Token Standard and utilize ERC-165 Standard Interface Detection in order to represent the shared ownership of an ERC-721 Non-Fungible Token. The ERC-20 Token Standard was modified as little as possible in order to allow this new class of token to operate in all of the ways and locations which are familiar to assets that follow the original ERC-20 specification. While there are many possible variations of this specification that would enable many different capabilities and scenarios for shared ownership, this proposal is focused on the minimal commonalities to enable as much flexibility as possible for various further extensions. This proposal makes it possible to verify, from the contract level or from an external query, whether a fungible token represents a form of shared ownership of a non-fungible token. The inclusion of ERC-165 makes it possible to verify, from the contract level or from an external query, whether a non-fungible token is owned by ERC-20 token representing shared ownership. + +## Motivation + +Shared ownership occurs across many industries and for many reasons. As more assets are registered, regulated and/or represented by the ERC-721 Non-Fungible Token Standard there will be more instances where the need for shared ownership of these assets will arise. For example, ArtBlx LLC. is working towards facilitating a protocol for fractionalizing physical, digital and conceptual artworks. The fungible tokens created from this process will have a value attached to the non-fungible tokens which they represent. This will be useful for price discovery of the underlying asset, liquidity for shared owners and as a new class of asset which can be used as collateral for loans or other financial instruments like stable coins. Providing an interface to this special class of fungible tokens is necessary to allow third parties to recognize them as a special class of fungible token and to recognize when a non-fungible token has been fractionalized. This might be useful in the case of a wallet who would want to utilize the metadata of the underlying NFT to show additional info next to an RFT, or on an exchange who might want to make that sort of info similarly available, or an NFT marketplace who may want to direct customers to a relevant exchange who wish to purchase shares in a NFT which is owned by an RFT. Anywhere an ERC-20 is applicable it would be useful for a user to know whether that token represents a shared NFT, and what attributes that NFT may have. + +## Specification + +At a minimum, third parties need two things: 1) to be able to distinguish re-fungible tokens from other token standards and 2) to determine which non-fungible token is fractionally owned. These two scenarios can be encountered from the perspective of initial contact with the non-fungible token or from the perspective of initial contact with the re-fungible token. + +#### Inital Contact with the Re-Fungible Token + +In order for a third party to confirm which non-fungible token is owned by the re-fungible token there needs to be a pointer from the RFT contract to the NFT contract and the relevant token id. This is possible with two public getters named `parentToken()` and `parentTokenId()`. The first getter returns a variable of type `address` and designates the contract address of the Non-Fungible Token contract. The second getter returns a variable of type `uint256` and designates the token ID of the Non-Fungible Token. With these getters, the identity of the Non-Fungible Token can be determined. Below is an example of the Re-Fungible Token Standard interface that includes these getter functions: + +```solidity +pragma solidity ^0.4.20; + +/// @dev Note: the ERC-165 identifier for this interface is 0x5755c3f2. +interface RFT /* is ERC20, ERC165 */ { + + function parentToken() external view returns(address _parentToken); + function parentTokenId() external view returns(uint256 _parentTokenId); + +} +``` + +The validity of this claim can be confirmed from another contract (on-chain) or from interacting with an RPC endpoint (off-chain). Below is an example of the on-chain scenario: + +```solidity +pragma solidity ^0.4.20; + +import './RFT.sol'; +import './ERC721.sol'; + +contract ConfirmRFT { + + function confirmRFT(address _RFT) external view returns(bool) { + address _NFT = RFT(_RFT).parentToken(); // returns address of NFT contract + uint256 _tokenId = RFT(_RFT).parentTokenId(); // returns id of ID of NFT + + return + NFT(_NFT).supportsInterface(0x80ac58cd) && // confirm it is ERC-721 + NFT(_NFT).ownerOf(_tokenId) == _RFT; // confirm the owner of the NFT is the RFT contract address + } + +} +``` + +Below is an off-chain example using an instance of web3.js in javascript: +```javascript +async function confirmRFT(web3) { + + const ERC721ABI = [...] // abi for ERC721 + const RFTABI = [...] // abi for RFT + const RFTAddress = '0x0123456789abcdef0123456789abcdef' // address for the deployed RFT + + const RFTContract = new web3.eth.Contract(RFTABI, RFTAddress) // deployed RFT contract instance + const ERC721Address = await RFTcontract.methods.parentToken().call() // returns address of NFT contract + const ERC721TokenId = await RFTcontract.methods.parentTokenId().call() // returns id of ID of NFT + + const ERC721Contract = new web3.eth.Contract(ERC721ABI, ERC721Address) // deployed ERC721 (as reported by RFT) + const isERC721 = await ERC721Contract.methods.supportsInterface('0x80ac58cd').call() // confirm it is ERC-721 + const ownerOfAddress = await ERC721Contract.methods.ownerOf(ERC721TokenId).call() // get the owner of the NFT + + return ERC721Response.toLowerCase() === RFTAddress.toLowerCase() // confirm the owner of the NFT is the RFT contract +} +``` + +#### Inital Contact with the Non-Fungible Token + +When checking the owner of a specific non-fungible token it's important to be able to determine whether owner is in fact a re-fungible token contract. This is possible by utilizing ERC-165 Standard Interface Detection. In order to comply with that standard a contract must include the following getter function which returns `true` when passed the `bytes4` parameter `0x01ffc9a7`: +``` +function supportsInterface(bytes4 interfaceID) external view returns (bool); +``` +After establishing support for this interface it becomes useful in determining whether the contract adheres to the Re-Fungible Token Standard. To do so the `supportsInterface(bytes4 interfaceID)` getter function must return `true` when passed the `bytes4` parameter `0x5755c3f2` which is the result of `bytes4(keccak256('parentToken()')) ^ bytes4(keccak256('parentTokenId()'))` or `parentToken.selector ^ parentTokenId.selector`. This could be achieved with the following code: +```solidity +pragma solidity ^0.4.20; + +import "./ERC20.sol"; + +/// @dev Note: the ERC-165 identifier for this interface is 0x5755c3f2. +interface RFT is ERC20 /*, ERC165 */ { + + function supportsInterface(bytes4 interfaceID) external view returns(bool) { + return + interfaceID == this.supportsInterface.selector || // ERC165 + interfaceID == this.parentToken.selector || // parentToken() + interfaceID == this.parentTokenId.selector || // parentTokenId() + interfaceID == this.parentToken.selector ^ this.parentTokenId.selector; // RFT + } + + function parentToken() external view returns(address _parentToken); + function parentTokenId() external view returns(uint256 _parentTokenId); + +} +``` +The flow of actually checking the status of a non-fungible token owner as a re-fungible token contract can be done from another contract (on-chain) as well as with an RPC endpoint (off-chain). Below is an example of the on-chain scenario: +```solidity +pragma solidity ^0.4.20; + +import './RFT.sol'; +import './ERC721.sol'; + +contract ConfirmRFT { + + function confirmRFT(address _NFT, uint256 _tokenId) external view returns(bool) { + address _RFT = ERC721(_NFT).ownerOf(_tokenId); // get the owner of the NFT + + return + RFT(_RFT).supportsInterface(0x01ffc9a7) && // confirm it supports ERC-165 + RFT(_RFT).supportsInterface(0x5755c3f2) // confirm it is RFT + } + +} +``` +Below is an off-chain example using web3.js in javascript: +```javascript +async function confirmRFT(web3) { + + const ERC721ABI = [...] // abi for ERC721 + const RFTABI = [...] // abi for RFT + const ERC721Address = '0x0123456789abcdef0123456789abcdef' // address for the deployed NFT + const ERC721TokenId = '7' // token Id of the NFT + + const ERC721Contract = new web3.eth.Contract(ERC721ABI, ERC721Address) // deployed ERC721 + const RFTAddress = await ERC721Contract.methods.ownerOf(ERC721TokenId).call() // owner address of the NFT + + + const RFTContract = new web3.eth.Contract(RFTABI, RFTAddress) // deployed RFT contract instance + const isERC165 = await RFTContract.methods.supportsInterface('0x01ffc9a7').call() // confirm it is ERC-165 + return isERC165 && await RFTContract.methods.supportsInterface('0x5755c3f2').call() // confirm it is RFT + +} +``` +## Rationale + +Most of the decisions made around the design of this standard were done in the hopes of keeping it as flexible as possible for as many use cases as possible. This includes making the standard 100% backwards compatible with ERC-20 Token Standard and able to interact with any previously deployed or future ERC-721 non-fungible token. This allows for each project to determine their own system for minting, burning and governing their re-fungible tokens depending on their specific use case. + +There are a number of other ERCs which have similarities to this proposal however they are often overly opinionated and restict many valid variations which could arise in different scenarios. Many of them break ERC-20 or ERC-721 in the process, or are at their core solving a different problem. We believe a token standard should cover only the required commonality between an otherwise diverse set of scenarios in order for them to behave as expected where necessary but allow them to achieve their individual goals elsewhere. Below are a list of the proposals considered due to some similarities as well as why they may not fulfill the requirements of this standard. + +* [ERC-864: Divisible non-fungible tokens](https://github.com/ethereum/EIPs/issues/864) + * Proposes a replacement for ERC-20, not ERC-20 compatible + * Not a complete proposal +* [ERC-1155: Multi Token Standard](https://github.com/ethereum/EIPs/issues/1155) + * Combines ERC-20 and ERC-721 into a single contract + * Not ERC-20 backwards compatible +* [EIP-1178: Multi-class Token Standard](https://github.com/ethereum/EIPs/pull/1178) + * Solves a different problem (multiple classes of ERC-20 in one contract) +* [ERC-1410: Partially Fungible Token Standard](https://github.com/ethereum/EIPs/issues/1410) + * Solves a different problem (multiple classes of ERC-20 in one contract) +* [ERC-1528: Refungible ERC721 Asset with Fungible ERC20](https://github.com/ethereum/EIPs/issues/1528) + * Combines ERC-20 and ERC-721 into a single contract + * Not ERC-721 backwards compatibile + * Limits the types of assets which can become re-fungible +* [ERC-1553: Asset Token Standard](https://github.com/ethereum/EIPs/issues/1553) + * Standard for defining real world assets and ownership via ERC-20 + * Only for real world assets + * Primarily concerned with a different objective (correlating real world and on chain assets) + +## Backwards Compatibility + +The Re-Fungible Token Standard is 100% backwards compatible with ERC-20 Token Standard. It is a small extension to the original specification and meant to be further extended for more specific use cases. Keeping the standard compatible with ERC-20 is important to allow for this token to benefit from the ecosystem that has grown around supporting the ubiquitous ERC-20 Token Standard. + +The Re-Fungible Token Standard is intended to interact with the ERC-721 Non-Fungible Token Standard. It is kept purposefully agnostic to extensions beyond the standard in order to allow specific projects to design their own token relationships such as governance over, rights to or permissions on each non-fungible token relative to the respective re-fungible token owners. + +## Implementation + +```solidity +pragma solidity ^0.4.20; + +/// @dev Note: the ERC-165 identifier for this interface is 0x5755c3f2. +interface RFT /* is ERC20, ERC165 */ { + + function parentToken() external view returns(address _parentToken); + function parentTokenId() external view returns(uint256 _parentTokenId); + +} +``` + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From c236454b9d899402b2cac3816d2b0b790e5b3319 Mon Sep 17 00:00:00 2001 From: Billy Rennekamp Date: Sun, 2 Dec 2018 15:34:15 +0100 Subject: [PATCH 02/24] discussion link --- EIPS/eip-rft.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-rft.md b/EIPS/eip-rft.md index 95fba95d57b27c..890ee5ce2d4ca7 100644 --- a/EIPS/eip-rft.md +++ b/EIPS/eip-rft.md @@ -2,7 +2,7 @@ eip: title: Re-Fungible Token Standard (RFT) author: Billy Rennekamp (@okwme), Dan Long (dan@artblx.com), Kiryl Yermakou (kiryl@artblx.com), Nate van der Ende (nate@artblx.com) -discussions-to: +discussions-to: https://github.com/ethereum/EIPs/pull/1633 status: Draft type: Standards Track category: ERC From 285fd9e4686323e8b698e93fd2d695ea59fcccb1 Mon Sep 17 00:00:00 2001 From: Billy Rennekamp Date: Mon, 3 Dec 2018 15:42:33 +0100 Subject: [PATCH 03/24] wording --- EIPS/eip-rft.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-rft.md b/EIPS/eip-rft.md index 890ee5ce2d4ca7..96aa8a6d0c665f 100644 --- a/EIPS/eip-rft.md +++ b/EIPS/eip-rft.md @@ -20,11 +20,11 @@ The intention of this proposal, the Re-Fungible Token Standard, is to extend the ## Motivation -Shared ownership occurs across many industries and for many reasons. As more assets are registered, regulated and/or represented by the ERC-721 Non-Fungible Token Standard there will be more instances where the need for shared ownership of these assets will arise. For example, ArtBlx LLC. is working towards facilitating a protocol for fractionalizing physical, digital and conceptual artworks. The fungible tokens created from this process will have a value attached to the non-fungible tokens which they represent. This will be useful for price discovery of the underlying asset, liquidity for shared owners and as a new class of asset which can be used as collateral for loans or other financial instruments like stable coins. Providing an interface to this special class of fungible tokens is necessary to allow third parties to recognize them as a special class of fungible token and to recognize when a non-fungible token has been fractionalized. This might be useful in the case of a wallet who would want to utilize the metadata of the underlying NFT to show additional info next to an RFT, or on an exchange who might want to make that sort of info similarly available, or an NFT marketplace who may want to direct customers to a relevant exchange who wish to purchase shares in a NFT which is owned by an RFT. Anywhere an ERC-20 is applicable it would be useful for a user to know whether that token represents a shared NFT, and what attributes that NFT may have. +Shared ownership occurs across many industries and for many reasons. As more assets are registered, regulated and/or represented by the ERC-721 Non-Fungible Token Standard there will be more instances where the need for shared ownership of these assets will arise. For example, ArtBlx Inc. is working towards facilitating a protocol for collective ownership of physical, digital and conceptual artworks. The fungible tokens created from this process will have a value attached to the non-fungible tokens which they represent. This will be useful for price discovery of the underlying asset, liquidity for shared owners and as a new class of asset which can be used as collateral for loans or other financial instruments like stable coins. Providing an interface to this special class of fungible tokens is necessary to allow third parties to recognize them as a special class of fungible token and to recognize when a non-fungible token has been fractionalized. This might be useful in the case of a wallet who would want to utilize the metadata of the underlying NFT to show additional info next to an RFT, or on an exchange who might want to make that sort of info similarly available, or an NFT marketplace who may want to direct customers to a relevant exchange who wish to purchase shares in a NFT which is owned by an RFT. Anywhere an ERC-20 is applicable it would be useful for a user to know whether that token represents a shared NFT, and what attributes that NFT may have. ## Specification -At a minimum, third parties need two things: 1) to be able to distinguish re-fungible tokens from other token standards and 2) to determine which non-fungible token is fractionally owned. These two scenarios can be encountered from the perspective of initial contact with the non-fungible token or from the perspective of initial contact with the re-fungible token. +At a minimum, third parties need two things: 1) to be able to distinguish re-fungible tokens from other token standards and 2) to determine which non-fungible token has shared ownership. These two scenarios can be encountered from the perspective of initial contact with the non-fungible token or from the perspective of initial contact with the re-fungible token. #### Inital Contact with the Re-Fungible Token From 3147ae63c57a0123ec97c1bfa7fed47ab50b73e5 Mon Sep 17 00:00:00 2001 From: Billy Rennekamp Date: Mon, 3 Dec 2018 15:43:50 +0100 Subject: [PATCH 04/24] rename eip file --- EIPS/{eip-rft.md => eip-1633.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename EIPS/{eip-rft.md => eip-1633.md} (100%) diff --git a/EIPS/eip-rft.md b/EIPS/eip-1633.md similarity index 100% rename from EIPS/eip-rft.md rename to EIPS/eip-1633.md From fe54a5edbaa3e4fcf3ced5289463096b6be66c87 Mon Sep 17 00:00:00 2001 From: Billy Rennekamp Date: Mon, 3 Dec 2018 15:50:17 +0100 Subject: [PATCH 05/24] make build pass? --- EIPS/eip-1633.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 96aa8a6d0c665f..d0e343346310c9 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -1,8 +1,8 @@ --- -eip: +eip: 1633 title: Re-Fungible Token Standard (RFT) author: Billy Rennekamp (@okwme), Dan Long (dan@artblx.com), Kiryl Yermakou (kiryl@artblx.com), Nate van der Ende (nate@artblx.com) -discussions-to: https://github.com/ethereum/EIPs/pull/1633 +discussions-to: https://github.com/ethereum/EIPs/issues/1634 status: Draft type: Standards Track category: ERC From cc044b1105b150435021489aa9521db9a6b24b6e Mon Sep 17 00:00:00 2001 From: Billy Rennekamp Date: Mon, 3 Dec 2018 15:55:24 +0100 Subject: [PATCH 06/24] build --- EIPS/eip-1633.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index d0e343346310c9..d72f11b21c4fa7 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -7,7 +7,7 @@ status: Draft type: Standards Track category: ERC created: 2018-11-18 -requires: EIP-20, EIP-165, EIP-721 +requires: 20, 165, 721 --- ## Simple Summary From bf5530473e645d6c155d2d838b9eb227351cae2b Mon Sep 17 00:00:00 2001 From: Billy Rennekamp Date: Mon, 3 Dec 2018 16:00:44 +0100 Subject: [PATCH 07/24] wording --- EIPS/eip-1633.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index d72f11b21c4fa7..57a036a1242be1 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -20,11 +20,11 @@ The intention of this proposal, the Re-Fungible Token Standard, is to extend the ## Motivation -Shared ownership occurs across many industries and for many reasons. As more assets are registered, regulated and/or represented by the ERC-721 Non-Fungible Token Standard there will be more instances where the need for shared ownership of these assets will arise. For example, ArtBlx Inc. is working towards facilitating a protocol for collective ownership of physical, digital and conceptual artworks. The fungible tokens created from this process will have a value attached to the non-fungible tokens which they represent. This will be useful for price discovery of the underlying asset, liquidity for shared owners and as a new class of asset which can be used as collateral for loans or other financial instruments like stable coins. Providing an interface to this special class of fungible tokens is necessary to allow third parties to recognize them as a special class of fungible token and to recognize when a non-fungible token has been fractionalized. This might be useful in the case of a wallet who would want to utilize the metadata of the underlying NFT to show additional info next to an RFT, or on an exchange who might want to make that sort of info similarly available, or an NFT marketplace who may want to direct customers to a relevant exchange who wish to purchase shares in a NFT which is owned by an RFT. Anywhere an ERC-20 is applicable it would be useful for a user to know whether that token represents a shared NFT, and what attributes that NFT may have. +Shared ownership occurs across many industries and for many reasons. As more assets are registered, regulated and/or represented by the ERC-721 Non-Fungible Token Standard there will be more instances where the need for shared ownership of these assets will arise. For example, ArtBlx Inc. is working towards facilitating a protocol for collective ownership of physical, digital and conceptual artworks. The fungible tokens created from this process will have a value attached to the non-fungible tokens which they represent. This will be useful for price discovery of the underlying asset, liquidity for shared owners and as a new class of asset which can be used as collateral for loans or other financial instruments like stable coins. Providing an interface to this special class of fungible tokens is necessary to allow third parties to recognize them as a special class of fungible token and to recognize when a non-fungible token is collectively owned. This might be useful in the case of a wallet who would want to utilize the metadata of the underlying NFT to show additional info next to an RFT, or on an exchange who might want to make that sort of info similarly available, or an NFT marketplace who may want to direct customers to a relevant exchange who wish to purchase shares in a NFT which is owned by an RFT. Anywhere an ERC-20 is applicable it would be useful for a user to know whether that token represents a shared NFT, and what attributes that NFT may have. ## Specification -At a minimum, third parties need two things: 1) to be able to distinguish re-fungible tokens from other token standards and 2) to determine which non-fungible token has shared ownership. These two scenarios can be encountered from the perspective of initial contact with the non-fungible token or from the perspective of initial contact with the re-fungible token. +At a minimum, third parties need two things: 1) to be able to distinguish re-fungible tokens from other token standards and 2) to determine when a non-fungible token is collectively owned. These two scenarios can be encountered from the perspective of initial contact with the non-fungible token or from the perspective of initial contact with the re-fungible token. #### Inital Contact with the Re-Fungible Token From 82627f2d3300046b58c681834f071211e3752d5e Mon Sep 17 00:00:00 2001 From: Billy Rennekamp Date: Mon, 3 Dec 2018 16:01:48 +0100 Subject: [PATCH 08/24] caps --- EIPS/eip-1633.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 57a036a1242be1..9be9d5716ffa18 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -20,7 +20,7 @@ The intention of this proposal, the Re-Fungible Token Standard, is to extend the ## Motivation -Shared ownership occurs across many industries and for many reasons. As more assets are registered, regulated and/or represented by the ERC-721 Non-Fungible Token Standard there will be more instances where the need for shared ownership of these assets will arise. For example, ArtBlx Inc. is working towards facilitating a protocol for collective ownership of physical, digital and conceptual artworks. The fungible tokens created from this process will have a value attached to the non-fungible tokens which they represent. This will be useful for price discovery of the underlying asset, liquidity for shared owners and as a new class of asset which can be used as collateral for loans or other financial instruments like stable coins. Providing an interface to this special class of fungible tokens is necessary to allow third parties to recognize them as a special class of fungible token and to recognize when a non-fungible token is collectively owned. This might be useful in the case of a wallet who would want to utilize the metadata of the underlying NFT to show additional info next to an RFT, or on an exchange who might want to make that sort of info similarly available, or an NFT marketplace who may want to direct customers to a relevant exchange who wish to purchase shares in a NFT which is owned by an RFT. Anywhere an ERC-20 is applicable it would be useful for a user to know whether that token represents a shared NFT, and what attributes that NFT may have. +Shared ownership occurs across many industries and for many reasons. As more assets are registered, regulated and/or represented by the ERC-721 Non-Fungible Token Standard there will be more instances where the need for shared ownership of these assets will arise. For example, ARTBLX Inc. is working towards facilitating a protocol for collective ownership of physical, digital and conceptual artworks. The fungible tokens created from this process will have a value attached to the non-fungible tokens which they represent. This will be useful for price discovery of the underlying asset, liquidity for shared owners and as a new class of asset which can be used as collateral for loans or other financial instruments like stable coins. Providing an interface to this special class of fungible tokens is necessary to allow third parties to recognize them as a special class of fungible token and to recognize when a non-fungible token is collectively owned. This might be useful in the case of a wallet who would want to utilize the metadata of the underlying NFT to show additional info next to an RFT, or on an exchange who might want to make that sort of info similarly available, or an NFT marketplace who may want to direct customers to a relevant exchange who wish to purchase shares in a NFT which is owned by an RFT. Anywhere an ERC-20 is applicable it would be useful for a user to know whether that token represents a shared NFT, and what attributes that NFT may have. ## Specification From 7b28d3fbe74e9dd16c671f1838dfac97b1a7ba58 Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Sat, 5 Dec 2020 11:27:55 +0100 Subject: [PATCH 09/24] Update EIPS/eip-1633.md --- EIPS/eip-1633.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 9be9d5716ffa18..4565362b3e9a6d 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -3,7 +3,7 @@ eip: 1633 title: Re-Fungible Token Standard (RFT) author: Billy Rennekamp (@okwme), Dan Long (dan@artblx.com), Kiryl Yermakou (kiryl@artblx.com), Nate van der Ende (nate@artblx.com) discussions-to: https://github.com/ethereum/EIPs/issues/1634 -status: Draft +status: Last Call type: Standards Track category: ERC created: 2018-11-18 From a3905e68233bffd44b9b7f1d73269ea6c9c41608 Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Wed, 6 Jan 2021 16:50:03 +0100 Subject: [PATCH 10/24] Update EIPS/eip-1633.md --- EIPS/eip-1633.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 4565362b3e9a6d..9be9d5716ffa18 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -3,7 +3,7 @@ eip: 1633 title: Re-Fungible Token Standard (RFT) author: Billy Rennekamp (@okwme), Dan Long (dan@artblx.com), Kiryl Yermakou (kiryl@artblx.com), Nate van der Ende (nate@artblx.com) discussions-to: https://github.com/ethereum/EIPs/issues/1634 -status: Last Call +status: Draft type: Standards Track category: ERC created: 2018-11-18 From d7e46d2df3b34d039c4e7d35e31337fed74846be Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Wed, 6 Jan 2021 16:50:38 +0100 Subject: [PATCH 11/24] Update EIPS/eip-1633.md Co-authored-by: Micah Zoltu --- EIPS/eip-1633.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 9be9d5716ffa18..8a2ce3221afb2f 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -11,7 +11,6 @@ requires: 20, 165, 721 --- ## Simple Summary - This improvement proposal outlines an extension to the ERC-20 Token Standard and utilization of ERC-165 Standard Interface Detection. The purpose is to enable the ability to distinguish when an ERC-20 token represents shared ownership of an ERC-721 non-fungible token (NFT) and by extension any potentially underlying asset therein. This is made possible by a re-fungible token (RFT) contract assuming ownership of a non-fungible token. ## Abstract From 53bb84915a300762deee09b1b7ffb37569b24cb6 Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Wed, 6 Jan 2021 16:51:18 +0100 Subject: [PATCH 12/24] Update EIPS/eip-1633.md Co-authored-by: Micah Zoltu --- EIPS/eip-1633.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 8a2ce3221afb2f..449228e2a9892c 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -11,7 +11,7 @@ requires: 20, 165, 721 --- ## Simple Summary -This improvement proposal outlines an extension to the ERC-20 Token Standard and utilization of ERC-165 Standard Interface Detection. The purpose is to enable the ability to distinguish when an ERC-20 token represents shared ownership of an ERC-721 non-fungible token (NFT) and by extension any potentially underlying asset therein. This is made possible by a re-fungible token (RFT) contract assuming ownership of a non-fungible token. +[ERC-20](./eip-20.md) extension for proportional ownership of an [ERC-721](./eip-721.md) token. ## Abstract From 602ae06d4ad99785ac4643fa0db0698b99d8f776 Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Wed, 6 Jan 2021 16:51:28 +0100 Subject: [PATCH 13/24] Update EIPS/eip-1633.md Co-authored-by: Micah Zoltu --- EIPS/eip-1633.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 449228e2a9892c..05403e0079f8b0 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -14,7 +14,6 @@ requires: 20, 165, 721 [ERC-20](./eip-20.md) extension for proportional ownership of an [ERC-721](./eip-721.md) token. ## Abstract - The intention of this proposal, the Re-Fungible Token Standard, is to extend the ERC-20 Token Standard and utilize ERC-165 Standard Interface Detection in order to represent the shared ownership of an ERC-721 Non-Fungible Token. The ERC-20 Token Standard was modified as little as possible in order to allow this new class of token to operate in all of the ways and locations which are familiar to assets that follow the original ERC-20 specification. While there are many possible variations of this specification that would enable many different capabilities and scenarios for shared ownership, this proposal is focused on the minimal commonalities to enable as much flexibility as possible for various further extensions. This proposal makes it possible to verify, from the contract level or from an external query, whether a fungible token represents a form of shared ownership of a non-fungible token. The inclusion of ERC-165 makes it possible to verify, from the contract level or from an external query, whether a non-fungible token is owned by ERC-20 token representing shared ownership. ## Motivation From f3bac67361a7c257f6e6a6c99a5d5d45b73def21 Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Wed, 6 Jan 2021 16:51:50 +0100 Subject: [PATCH 14/24] Update EIPS/eip-1633.md Co-authored-by: Micah Zoltu --- EIPS/eip-1633.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 05403e0079f8b0..66d996c598d9ce 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -17,7 +17,6 @@ requires: 20, 165, 721 The intention of this proposal, the Re-Fungible Token Standard, is to extend the ERC-20 Token Standard and utilize ERC-165 Standard Interface Detection in order to represent the shared ownership of an ERC-721 Non-Fungible Token. The ERC-20 Token Standard was modified as little as possible in order to allow this new class of token to operate in all of the ways and locations which are familiar to assets that follow the original ERC-20 specification. While there are many possible variations of this specification that would enable many different capabilities and scenarios for shared ownership, this proposal is focused on the minimal commonalities to enable as much flexibility as possible for various further extensions. This proposal makes it possible to verify, from the contract level or from an external query, whether a fungible token represents a form of shared ownership of a non-fungible token. The inclusion of ERC-165 makes it possible to verify, from the contract level or from an external query, whether a non-fungible token is owned by ERC-20 token representing shared ownership. ## Motivation - Shared ownership occurs across many industries and for many reasons. As more assets are registered, regulated and/or represented by the ERC-721 Non-Fungible Token Standard there will be more instances where the need for shared ownership of these assets will arise. For example, ARTBLX Inc. is working towards facilitating a protocol for collective ownership of physical, digital and conceptual artworks. The fungible tokens created from this process will have a value attached to the non-fungible tokens which they represent. This will be useful for price discovery of the underlying asset, liquidity for shared owners and as a new class of asset which can be used as collateral for loans or other financial instruments like stable coins. Providing an interface to this special class of fungible tokens is necessary to allow third parties to recognize them as a special class of fungible token and to recognize when a non-fungible token is collectively owned. This might be useful in the case of a wallet who would want to utilize the metadata of the underlying NFT to show additional info next to an RFT, or on an exchange who might want to make that sort of info similarly available, or an NFT marketplace who may want to direct customers to a relevant exchange who wish to purchase shares in a NFT which is owned by an RFT. Anywhere an ERC-20 is applicable it would be useful for a user to know whether that token represents a shared NFT, and what attributes that NFT may have. ## Specification From b77704e2d7c826500ad4f11ba45621720c00cc5b Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Wed, 6 Jan 2021 16:52:03 +0100 Subject: [PATCH 15/24] Update EIPS/eip-1633.md Co-authored-by: Micah Zoltu --- EIPS/eip-1633.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 66d996c598d9ce..aa858b4d05af78 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -20,7 +20,6 @@ The intention of this proposal, the Re-Fungible Token Standard, is to extend the Shared ownership occurs across many industries and for many reasons. As more assets are registered, regulated and/or represented by the ERC-721 Non-Fungible Token Standard there will be more instances where the need for shared ownership of these assets will arise. For example, ARTBLX Inc. is working towards facilitating a protocol for collective ownership of physical, digital and conceptual artworks. The fungible tokens created from this process will have a value attached to the non-fungible tokens which they represent. This will be useful for price discovery of the underlying asset, liquidity for shared owners and as a new class of asset which can be used as collateral for loans or other financial instruments like stable coins. Providing an interface to this special class of fungible tokens is necessary to allow third parties to recognize them as a special class of fungible token and to recognize when a non-fungible token is collectively owned. This might be useful in the case of a wallet who would want to utilize the metadata of the underlying NFT to show additional info next to an RFT, or on an exchange who might want to make that sort of info similarly available, or an NFT marketplace who may want to direct customers to a relevant exchange who wish to purchase shares in a NFT which is owned by an RFT. Anywhere an ERC-20 is applicable it would be useful for a user to know whether that token represents a shared NFT, and what attributes that NFT may have. ## Specification - At a minimum, third parties need two things: 1) to be able to distinguish re-fungible tokens from other token standards and 2) to determine when a non-fungible token is collectively owned. These two scenarios can be encountered from the perspective of initial contact with the non-fungible token or from the perspective of initial contact with the re-fungible token. #### Inital Contact with the Re-Fungible Token From 0d9e6a4c07855ceb41c9e510522de7125669bfed Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Wed, 6 Jan 2021 16:53:39 +0100 Subject: [PATCH 16/24] Update EIPS/eip-1633.md Co-authored-by: Micah Zoltu --- EIPS/eip-1633.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index aa858b4d05af78..684f172f9333e7 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -147,7 +147,6 @@ async function confirmRFT(web3) { } ``` ## Rationale - Most of the decisions made around the design of this standard were done in the hopes of keeping it as flexible as possible for as many use cases as possible. This includes making the standard 100% backwards compatible with ERC-20 Token Standard and able to interact with any previously deployed or future ERC-721 non-fungible token. This allows for each project to determine their own system for minting, burning and governing their re-fungible tokens depending on their specific use case. There are a number of other ERCs which have similarities to this proposal however they are often overly opinionated and restict many valid variations which could arise in different scenarios. Many of them break ERC-20 or ERC-721 in the process, or are at their core solving a different problem. We believe a token standard should cover only the required commonality between an otherwise diverse set of scenarios in order for them to behave as expected where necessary but allow them to achieve their individual goals elsewhere. Below are a list of the proposals considered due to some similarities as well as why they may not fulfill the requirements of this standard. From 2a9f423b9fd1e53ddac6ccc277b4db2fd49313b2 Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Wed, 6 Jan 2021 16:54:35 +0100 Subject: [PATCH 17/24] Update EIPS/eip-1633.md Co-authored-by: Micah Zoltu --- EIPS/eip-1633.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 684f172f9333e7..b4b59b5f3b8315 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -171,7 +171,6 @@ There are a number of other ERCs which have similarities to this proposal howeve * Primarily concerned with a different objective (correlating real world and on chain assets) ## Backwards Compatibility - The Re-Fungible Token Standard is 100% backwards compatible with ERC-20 Token Standard. It is a small extension to the original specification and meant to be further extended for more specific use cases. Keeping the standard compatible with ERC-20 is important to allow for this token to benefit from the ecosystem that has grown around supporting the ubiquitous ERC-20 Token Standard. The Re-Fungible Token Standard is intended to interact with the ERC-721 Non-Fungible Token Standard. It is kept purposefully agnostic to extensions beyond the standard in order to allow specific projects to design their own token relationships such as governance over, rights to or permissions on each non-fungible token relative to the respective re-fungible token owners. From cd1eaa5d931427f87bc74484dc8705f10b72497e Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Wed, 6 Jan 2021 16:55:02 +0100 Subject: [PATCH 18/24] Update EIPS/eip-1633.md Co-authored-by: Micah Zoltu --- EIPS/eip-1633.md | 1 - 1 file changed, 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index b4b59b5f3b8315..994987fe8e07b0 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -176,7 +176,6 @@ The Re-Fungible Token Standard is 100% backwards compatible with ERC-20 Token St The Re-Fungible Token Standard is intended to interact with the ERC-721 Non-Fungible Token Standard. It is kept purposefully agnostic to extensions beyond the standard in order to allow specific projects to design their own token relationships such as governance over, rights to or permissions on each non-fungible token relative to the respective re-fungible token owners. ## Implementation - ```solidity pragma solidity ^0.4.20; From df39bf34aec6ed10d44881fb923701be9e1b7a1e Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Wed, 6 Jan 2021 16:55:22 +0100 Subject: [PATCH 19/24] Update EIPS/eip-1633.md Co-authored-by: Micah Zoltu --- EIPS/eip-1633.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 994987fe8e07b0..54d46190de4da9 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -188,5 +188,8 @@ interface RFT /* is ERC20, ERC165 */ { } ``` +## Security Considerations +TBD + ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 82e50d759fff9d9b3d9dbb892f753aaaae1b7f92 Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Mon, 8 Mar 2021 13:08:49 +0100 Subject: [PATCH 20/24] Update EIPS/eip-1633.md Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com> --- EIPS/eip-1633.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 54d46190de4da9..922d44e60af416 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -163,7 +163,7 @@ There are a number of other ERCs which have similarities to this proposal howeve * Solves a different problem (multiple classes of ERC-20 in one contract) * [ERC-1528: Refungible ERC721 Asset with Fungible ERC20](https://github.com/ethereum/EIPs/issues/1528) * Combines ERC-20 and ERC-721 into a single contract - * Not ERC-721 backwards compatibile + * Not ERC-721 backwards compatible * Limits the types of assets which can become re-fungible * [ERC-1553: Asset Token Standard](https://github.com/ethereum/EIPs/issues/1553) * Standard for defining real world assets and ownership via ERC-20 From 5b54622934131805c83edc64c6b722c020687b42 Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Mon, 8 Mar 2021 13:09:10 +0100 Subject: [PATCH 21/24] Update EIPS/eip-1633.md Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com> --- EIPS/eip-1633.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 922d44e60af416..758296f6a13655 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -80,7 +80,7 @@ async function confirmRFT(web3) { } ``` -#### Inital Contact with the Non-Fungible Token +#### Initial Contact with the Non-Fungible Token When checking the owner of a specific non-fungible token it's important to be able to determine whether owner is in fact a re-fungible token contract. This is possible by utilizing ERC-165 Standard Interface Detection. In order to comply with that standard a contract must include the following getter function which returns `true` when passed the `bytes4` parameter `0x01ffc9a7`: ``` From bdd6a1e74c06a10e462f8b4f450c6121f04de110 Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Mon, 8 Mar 2021 13:09:19 +0100 Subject: [PATCH 22/24] Update EIPS/eip-1633.md Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com> --- EIPS/eip-1633.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 758296f6a13655..25255fc4e9f319 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -22,7 +22,7 @@ Shared ownership occurs across many industries and for many reasons. As more ass ## Specification At a minimum, third parties need two things: 1) to be able to distinguish re-fungible tokens from other token standards and 2) to determine when a non-fungible token is collectively owned. These two scenarios can be encountered from the perspective of initial contact with the non-fungible token or from the perspective of initial contact with the re-fungible token. -#### Inital Contact with the Re-Fungible Token +#### Initial Contact with the Re-Fungible Token In order for a third party to confirm which non-fungible token is owned by the re-fungible token there needs to be a pointer from the RFT contract to the NFT contract and the relevant token id. This is possible with two public getters named `parentToken()` and `parentTokenId()`. The first getter returns a variable of type `address` and designates the contract address of the Non-Fungible Token contract. The second getter returns a variable of type `uint256` and designates the token ID of the Non-Fungible Token. With these getters, the identity of the Non-Fungible Token can be determined. Below is an example of the Re-Fungible Token Standard interface that includes these getter functions: From e774215feea0d039ebb3b6b488b053e12d9318d9 Mon Sep 17 00:00:00 2001 From: billy rennekamp Date: Mon, 8 Mar 2021 13:12:45 +0100 Subject: [PATCH 23/24] Update eip-1633.md --- EIPS/eip-1633.md | 21 --------------------- 1 file changed, 21 deletions(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 25255fc4e9f319..e090a84857509e 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -149,27 +149,6 @@ async function confirmRFT(web3) { ## Rationale Most of the decisions made around the design of this standard were done in the hopes of keeping it as flexible as possible for as many use cases as possible. This includes making the standard 100% backwards compatible with ERC-20 Token Standard and able to interact with any previously deployed or future ERC-721 non-fungible token. This allows for each project to determine their own system for minting, burning and governing their re-fungible tokens depending on their specific use case. -There are a number of other ERCs which have similarities to this proposal however they are often overly opinionated and restict many valid variations which could arise in different scenarios. Many of them break ERC-20 or ERC-721 in the process, or are at their core solving a different problem. We believe a token standard should cover only the required commonality between an otherwise diverse set of scenarios in order for them to behave as expected where necessary but allow them to achieve their individual goals elsewhere. Below are a list of the proposals considered due to some similarities as well as why they may not fulfill the requirements of this standard. - -* [ERC-864: Divisible non-fungible tokens](https://github.com/ethereum/EIPs/issues/864) - * Proposes a replacement for ERC-20, not ERC-20 compatible - * Not a complete proposal -* [ERC-1155: Multi Token Standard](https://github.com/ethereum/EIPs/issues/1155) - * Combines ERC-20 and ERC-721 into a single contract - * Not ERC-20 backwards compatible -* [EIP-1178: Multi-class Token Standard](https://github.com/ethereum/EIPs/pull/1178) - * Solves a different problem (multiple classes of ERC-20 in one contract) -* [ERC-1410: Partially Fungible Token Standard](https://github.com/ethereum/EIPs/issues/1410) - * Solves a different problem (multiple classes of ERC-20 in one contract) -* [ERC-1528: Refungible ERC721 Asset with Fungible ERC20](https://github.com/ethereum/EIPs/issues/1528) - * Combines ERC-20 and ERC-721 into a single contract - * Not ERC-721 backwards compatible - * Limits the types of assets which can become re-fungible -* [ERC-1553: Asset Token Standard](https://github.com/ethereum/EIPs/issues/1553) - * Standard for defining real world assets and ownership via ERC-20 - * Only for real world assets - * Primarily concerned with a different objective (correlating real world and on chain assets) - ## Backwards Compatibility The Re-Fungible Token Standard is 100% backwards compatible with ERC-20 Token Standard. It is a small extension to the original specification and meant to be further extended for more specific use cases. Keeping the standard compatible with ERC-20 is important to allow for this token to benefit from the ecosystem that has grown around supporting the ubiquitous ERC-20 Token Standard. From ca266eea670c6dcaeb3949b9f6e7b5dc32847922 Mon Sep 17 00:00:00 2001 From: Micah Zoltu Date: Tue, 9 Mar 2021 19:33:14 +0800 Subject: [PATCH 24/24] Update EIPS/eip-1633.md Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com> --- EIPS/eip-1633.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index e090a84857509e..7fddba9bbff121 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -1,7 +1,7 @@ --- eip: 1633 title: Re-Fungible Token Standard (RFT) -author: Billy Rennekamp (@okwme), Dan Long (dan@artblx.com), Kiryl Yermakou (kiryl@artblx.com), Nate van der Ende (nate@artblx.com) +author: Billy Rennekamp (@okwme), Dan Long , Kiryl Yermakou , Nate van der Ende discussions-to: https://github.com/ethereum/EIPs/issues/1634 status: Draft type: Standards Track