-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
NFT and FT with Royalty Distribution System #3601
Comments
Since this is your first issue, we kindly remind you to check out EIP-1 for guidance. |
@PowerStream3604 |
I understand that distribution system is needed regardless of the situation(royalty). |
Still reading.... |
Hey, thanks @PowerStream3604 for bringing that up. as @lenifoti mentions this would be great to ensure compatibility with EIP-2981, but I think it does in principle. Else regarding the link between the NFT and the ERC20, there is another standard specifically addressing that : https://eips.ethereum.org/EIPS/eip-1633 Maybe this part could be reused ? |
Definitely, I also think that EIP-1633 can be reused as link between NFT and ERC-20. |
This standard could also be used without NFT being the owner of the ERC-20 contract. |
Small grain of salt here: I'm wondering if that needs an ERC, I would argue that no. ERC20 is an ERC, ERC721 is an ERC, ERC165 is an ERC, but combining the 3 in a dapp is just one business logic, we are not going to standardize all business logics. Uniswap V2 Pairs for example and not standardize in an ERC and they don't need to be. |
The focus of this proposal is not combining ERC 20, 721, 165 but utilizing them to distribute royalty fairly to token owners. |
@PowerStream3604 |
I like this idea. I've been searching for some form of ERC contract that would allow payment per month in an automatic fashion. Say for example you get your monthly salary and need to pay x companies (mortgage, phone contract, internet, ...). An ERC like this would allow that fairly easily. Or yearly payments. Ignore the fact that my example is moot as this idea would require very wide spread adoption in the entire economic system to do this. And that Ethereum natively doesn't support recurrent time based contract invocation... (There are solutions for that) But hey, it's fun to imagine how it could be done when tech and the world gets there. |
I was also looking for something like this. I am specing out a contract which would generate an NFT based on multiple content contributors that would be referenced in the tokenURL as meta-data. In our case, the royalty rate would be evenly distributed by the number of parties. But I didn't think assigning ERC-20 token for each NFT by the contract was right. The NFTs would be generated the same contract, but have different contributors and unique metadata (I believe ERC-721 can still be applied, but have been confused by the language around ERC-1155 as to whether I need to use that instead). |
Thanks, @poojaranjan |
I have implemented your approach into a test token of mine and it is working great for the most part. One issue I am having is that after buying and selling on open sea, some of the functions start returning errors. Is there another function other then _transfer we need? Possibly Atomic match? |
This is an ERC20 contract with additional features(FNFT with Royalty Distribution system), Or could be an atomic match triggering the matter. Since I don't see the implementation so this is all I can say. |
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
eip:
title: Fractional nft and FT with Royalty Distribution system
author: Yongjun Kim (@PowerStream3604)
discussions-to: https://ethereum-magicians.org/t/fnft-with-royalty-distribution-system/7150
status: Draft
type: Standards Track
category : ERC
created: 2021-06-01
requires : 20, 165, 721
Simple Summary
A ERC-20 contract becoming the owner of a nft token.
Fractionalizing the ownership of NFT into multiple ERC-20 tokens by making the ERC-20 contract as the owner of NFT.
Distributing the royalty(income) to the shareholders who own the specific ERC-20 token.
Abstract
The intention of this proposal is to extend the functionalities of ERC-20 to represent it as a share of nft and provide automated and trusted method to distribute royalty
to ERC-20 token holders.
Utilizing ERC-165 Standard Interface Detection, it detects if a ERC-20 token is representing the shared ownership of ERC-721 Non-Fungible Token.
ERC-165 implementation of this proposal makes it possible to verify from both contract and offchain level if it adheres to this proposal(standard).
This proposal makes small changes to existing ERC-20 Token Standard and ERC-721 Token Standard to support most of software working on top of this existing token standard.
By sending ether to the address of the ERC-20 Contract Address(owner of NFT) it will distribute the amount of ether per holders and keep it inside the chain.
Whenever the owner of the contract calls the function for withdrawing their proportion of royalty, they will receive the exact amount of compensation according to their amount
of share at that very moment of being compensated.
Motivation
It is evident that many industries need cryptographically verifiable method to represent shared ownership.
ERC-721 Non-Fungible Token standards are ubiquitously used to represent ownership of assets from digital assets such as Digital artworks, Game items(characters), Virtual real estate
to real-world assets such as Real estate, Artworks, Cars, etc.
As more assets are registered as ERC-721 Non-Fungible Token demands for fractional ownership will rise.
Fractional ownership does not only mean that we own a portion of assets.
But It also means that we need to obtain financial compensation whenever the asset is making profit through any kinds of financial activities.
For instance, token holders of NFT representing World Trade Center should receive monthly rent from tenants.
Token holders of NFT representing "Everydays-The First 5000 days" should receive advertisement charge, exhibition fees whenever their artwork is being used for financial activities.
It is crucial for smart-contract(verifable system) to implement this distribution system to prevent any kinds of fraud regarding royalty compensation. Following the fair royalty distribution system which works on top of completely verifable environment(blockchain) will the flourish the NFT market by giving back compensation to investors.
To make this possible this proposal implements a rule-of-reason logic to distribute income fairly to the holders.
In order to make this royalty-distribution-system work with little changes from the standard and comply with distribution logic, several math operations and mappings are additionally used.
By implementing this standard, wallets will be able to determine if a erc20 token is representing NFT and that means
everywhere that supports the ERC-20 and this proposal(standard) will support fractional NFT tokens.
Specification
Smart Contracts Implementing this Standard MUST implement all of the functions in BELOW
Smart contracts implementing the FNFT standard MUST implement the ERC-165
supportsInterface()
and MUST return the constant value
true
if0xdb453760
is passed through theinterfaceID
argument(1) Third parties need to distinguish Fractional-NFT from other token standards.
ERC-165 Standard Interface Detection
supportsInterface()
needs to be included to determine whether this contract supports this standard.In this proposal, we use
targetNFT()
to retrieve the contract address of NFT and the token ID of NFT,sendRoyalty()
to send royalty to token holders,withdrawRoyalty()
to withdraw royalty they received withsendRoyalty()
.(2) Third parties need to know the NFT contract address this FNFT is pointing to and the tokenID of the NFT.
This is the on-chain scenario:
off-chain scenario:
using ethers.js in javascript:
web3.js
Royalty-Distribution-Logic :
Although it is easy to abstractly say what to do in certain function, implementing rule-of-reason logic of distributing royalty needs much consideration.
There are some KEY PRINCIPLES that we have to comply with when designing this logic.
(1) Royalty must be distributed by the ratio of my current stake(share) on totalsupply.
(2) Royalty must be distributed by the ratio of royalty sent at the time compensated(given).
For instance, A owned 80% and B owned 20% of totalsupply in 2020 which is when 100ether was given as Royalty.
But, in 2021 B owns 80% and A owns 20% of totalsupply. Both of them didn't withdraw their royalty until now and no royalty was given in 2021. When A withdraws his royalty now which A should receive 80ethers since he owned 80% of totalsupply at the very moment of royalty given. When B withdraws his royalty he receives 20ethers since he owned 20% of totalsupply at the very moment the royalty was given. Only the ratio of my stake at the moment royalty is given needs to be the only factor that matters because the timing
of withdrawal totally depends on the owner's decision.
(3) Cannot withdraw Royalty you already did.
Rationale
The design of royalty receiver withdrawing their royalty was considered due to gas efficiency. If any of functions in this contract send ether to all of the holders whenever or regularly royalty is received, huge amount of gas consumption is inevitable.
In order to handle those issues, this standard(proposal) makes the withdrawer to do most of the calculation for his own withdrawal and
the sender to do the least as impossible.
Backwards Compatibility
This contract is compatible with the existing EIPs since it doesn't modify the existing specifications but just adds 3 functions to provide Royalty distribution systems.
Depending on the implementaion, data type, logic and additional validations and manipulations might be needed.
However, complying with the existing standards won't be an issue but additional gas might be needed for calling
functions
in this standard.
Reference Implementation
This is an implementation of some smart of FNFT contract.
It is an extension of ERC-20 Token Contract.
Security Considerations
There might be many flaws that might exist when implementing this standard since math operations and complex logic is underlying
the royalty distribution logic.
Major Security Risks To Consider
(1) Math operation in
withdrawRoyalty()
(2) Variables that holds the state of royalty should not be modified outside the contract
Usage
Although this standard is intended for NFTs. This can also be used for distributing royalty or compensation to ERC-20 token holders.
This standard is also applicable to be used solely for distributing compensation to ERC-20 token holders without any correlations with ERC-721(NFT);
Compatibility with EIP-2981
When complying with this standard I recommend people to ensure compatibility with EIP-2981
by adding
royaltyInfo()
and returning the information needed to compensation the creator of the asset whenever the asset is sold and resold.References
Copyright
Please cite this document as:
Kim yongjun "EIP-: NFT Royalty Distribution Standard" June 2021
The text was updated successfully, but these errors were encountered: