A standardized way to handle royalty payments for ERC-721 tokens, including publicly viewable royalty information and notification using a royalty payment event.
This standard extends the [ERC-721 specification](./eip-721.md) to enable setting a royalty amount paid to the NFT creator or rights holder every time an NFT is sold and re-sold. This is intended for NFT marketplaces that want to support the ongoing funding of artists and other NFT creators. The royalty payment must be voluntary as required by the EIP-721 standard, as `transferFrom()` includes NFT transfers between wallets, and executing `transferFrom()` does not always imply a sale occurred. Marketplaces and individuals implement this standard by retrieving the royalty payment information with `royaltyInfo()`, paying the proper royalty amount to the royalty recipient address, and calling `onRoyaltiesReceived()` to notify the NFT contract of the royalty payment. Payments are simple and sent only to a single address. This ERC should be considered a minimal, gas-efficient building block for further innovation in NFT royalty payments.
There are many marketplaces for NFTs with multiple unique royalty payment implementations that are not easily compatible or usable by other marketplaces. Just like the early days of ERC-20 tokens, ERC-721 marketplace smart contracts are varied by ecosystem and not standardized. This EIP enables all marketplaces to pay the royalties that NFT creators specify and are entitled to, enabling accurate royalty payments regardless of which marketplace the NFT is sold or re-sold at.
Many of the largest ERC-721 marketplaces have implemented royalty payments that are incompatible with other platforms and therefore make it much harder to enforce when the NFT is sold on another marketplace, not fulfilling the potential of any implemented royalty system. This standard is a way to implement royalties that can be accepted across any type of NFT marketplace. This minimalist proposal allows for standardized royalties to be accepted on all marketplaces - leaving the actual funds transfer up to the marketplace itself, and only providing a means to fetch the royalty amounts and an event to be emitted when the transfer has happened.
This standard extends the [ERC-721 specification](./eip-721.md) to enable setting a royalty amount paid to the NFT creator or rights holder every time an NFT is sold and re-sold. If a marketplace chooses *not* to implement this EIP, then obviously no funds are paid for secondary sales. But as most NFT marketplaces have developed some unique royalty system themselves - and all of them are singular and only work within their own contracts - there should be an accepted standard for paying royalties, if the creator chooses to set royalties on their NFTs. We believe the NFT marketplace ecosystem will voluntarily implement royalty payments to provide ongoing funding for artists and other creators, and NFT buyers will assess the royalty payment as a factor when making NFT purchasing decisions.
Without an agreed royalty payment standard, the NFT ecosystem will lack an effective means to collect royalties across all marketplaces and artists and other creators will not receive ongoing funding. This will hamper the growth and adoption of NFTs and demotivate artists and other NFT creators from minting new and innovative tokens.
*"Yes we have royalties, but if your NFT is sold on another marketplace, we cannot provide royalties" ... "But can't I sell my NFT anywhere with a click of my wallet?" ... "Yes... but we don't have a standard for royalties so you'll lose out."*
**ERC-721 compliant contracts MAY implement this ERC for royalties to provide a standard method of accepting royalty payments and receiving royalty information.**
The `amount` returned by `royaltyInfo()`**MUST** be a percentage fixed point with a scaling factor of 100000 `(X/100000)` - such as "500000" - for 5% (i.e. 5 decimals). This is **REQUIRED** to maintain uniformity across the standard. The max and min values would be 10000000 (100%) and 1 (0.00001%). This fits snugly into the `uint24` type to minimize storage costs, and can easily be cast to other `uint` types as needed (i.e. `uint256(0x1234)`).
Marketplaces that support this standard **MUST** call the `onRoyaltiesReceived()` function on the NFT contract after sending a payment, which will automatically emit the `RoyaltiesReceived` event.
Implementers of this standard **MUST** emit the `RoyaltiesReceived` event when `onRoyaltiesReceived()` is called. Implementers may do any other logic inside of this call, provided the `RoyaltiesReceived` event is emitted.
Implementers of this standard **MUST** have all of the following events and functions:
It is impossible to know which NFT transfers are the result of sales, and which are merely wallets moving or consolidating their NFTs. Therefore, we cannot force every `transferFrom()` call to involve a royalty payment, as not every transfer is a sale that would require such payment. We believe the NFT marketplace ecosystem will voluntarily implement this royalty payment standard to provide ongoing funding for artists and other creators, and NFT buyers will assess the royalty payment percentage as a factor when making NFT purchasing decisions.
### Simple royalty payments to a single address
It is impossible to fully know and efficiently implement all possible types of royalty payments and logic, so it is on the royalty payment receiver to implement all additional complexity and logic for fee splitting, multiple receivers, taxes, accounting, etc. in their own receiving contract or off-chain. If we attempted to do this as part of this standard, it would dramatically increase the implementation complexity, increase gas costs, and could not possibly cover every potential use-case. Therefore, implementers desiring more complex royalty payment logic should create their own smart contract that implements their own requirements upon the receipt of ETH or ERC20 tokens and / or the execution of `onRoyaltiesReceived()`. This ERC should be considered a minimal, gas-efficient building block for further innovation in NFT royalty payments.
Having the flexibility to set any percentage a creator likes is important - although the reality of having users want a 0.00000000001% fee is not very likely. Instead the value can be limited to 5 decimal places with the lowest percentage being 0.00001% and the cap at 100%. It also allows us to store the value in a `uint24`, reducing storage costs.
### Emitting event for payment on the NFT contract itself
Choosing to emit an event for payment is important as each NFT contract is standalone, and while a marketplace contract can emit events that an NFT is sold, the royalty recipient might not be aware or watching the marketplace for a secondary sale of their NFT and therefore would never know they received a payment except for having an increased amount of ETH or ERC20 tokens in their wallet randomly. Watching for a royalty event only on the contract of the NFT being sold is an easy way for the recipient to check on payments received by their secondary sales without needing to watch every marketplace contract in existence.
### Structure of the RoyaltiesReceived event
The `RoyaltiesReceived` event will help future-proof this standard and allow potential enhancements in future EIPs.
`royaltyRecipient` allows multiple royalty recipients to exist in the same ERC-721 contract, and indexing it allows a receiver to track payments to themselves easily.
`buyer` enables tracking specific buyers of NFTs for analytics purposes.
`tokenId` allows easy tracking of specific NFT sales.
`metadata` helps more advanced use-cases, perhaps described in future EIPs. `onRoyaltiesReceived()` is assumed to be called within the same transaction of the royalty payment, making the knowledge of the transaction hash and total amount of the sale easy to know. But if there are many small sales, sending many tiny transfers of ERC-20 tokens and calling `onRoyaltiesReceived()` for each could get expensive. This field could potentially enable a batched payment standard (monthly, quarterly, etc.), with some sort of data stored here that helps identify which sales this payment was for.
