New issue

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

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

Already on GitHub? Sign in to your account

ERC 1633 - Re-Fungible Token #1634

Open
okwme opened this Issue Dec 2, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@okwme
Copy link

okwme commented Dec 2, 2018


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: #1634
status: Draft
type: Standards Track
category: ERC
created: 2018-11-18
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

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

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

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:

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:

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:

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:

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:

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:

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.

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

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.

@sea51930

This comment has been minimized.

Copy link
Contributor

sea51930 commented Dec 2, 2018

@okwme

This comment has been minimized.

Copy link

okwme commented Dec 3, 2018

@sea51930, erc #864 is referenced in the section called Rationale. I don't see how #115 relates and #15285 doesn't exist.

@tlxsam

This comment has been minimized.

Copy link

tlxsam commented Dec 20, 2018

@okwme, can you please provide your thoughts on the following statements for #1528
Not ERC-721 backwards compatibile
Limits the types of assets which can become re-fungible
Thanks

@okwme

This comment has been minimized.

Copy link

okwme commented Jan 7, 2019

Hi @tlxsam,

My apologies, it appeared to me that your EIP combined ERC-721 and ERC-20 into one contract. I see now you were just re-writing much of the ERC-721 Standard right before re-writing much of the ERC-20 Standard, not suggesting they should be combined. I think it was the third section of management functions made me believe they were all meant to be in one contract.

After reviewing it again I see that our EIPs converge on the function getNFT() which is essentially the combination of parentToken() and parentTokenId(). I disagree with your suggestions of altering the ERC20 with the functions: holdersCount(), holderByIndex(uint256 _index), holders(uint256 _from, uint256 _to). I think there should be as minimal of an extension to the ERC-20 Standard as possible to ensure compatibility with existing systems and flexibility for individual use cases.

I'd also disagree with including the management functions as part of the spec, as this should be left up to specific projects whether or not they need/want these features. Including it as a suggestion could be helpful though. We also considered adding our implementation for this step as a suggestion but not as a requirement.

Once you remove all those other extensions to ERC-20, you're left with just getNFT() as the only addition to the original standard. This is fine except that when considering ERC-165, it becomes more likely for a collision with only one function name for the ID. We also considered combining the functions into one but it's not safe to assume any contract that has a getNFT() interface is also a Re-Fungible Token—especially when the function name is as generic as getNFT() or parentToken(). It becomes much safer to assume the contract is in fact a Re-Fungible Token if the interface is the combination of more than one function, as is the case in 1633 with parentToken() and parentTokenId(). In the same vein, adding an additional function that returns both would be an easy way to increase usability as well as 165 collision protection, I'll suggest this as an update!

I'd be happy to hear your thoughts on all of this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment