EIP-2981 — Simple and effective royalty standards for all
The backstory
It was back in late December 2017 that I wrote my first NFT smart contract. I had recently fallen down the Ethereum rabbithole 🐇, a move that swiftly led me to becoming fully immersed in Solidity and the world of NFTs. The following April we launched KnownOrigin, our first rough and ready NFT site.
It was back in late December 2017 that I wrote my first NFT smart contract. I had recently fallen down the Ethereum rabbithole 🐇, a move that swiftly led me to becoming fully immersed in Solidity and the world of NFTs. The following April we launched KnownOrigin, our first rough and ready NFT site.
The vast majority of royalty implementations are different and do not conform to a standard, this leads to centralisation of tokens and royalty payouts, typically only applied when resale happens on the originating platform.
This can also create an undesirable reliance on post-sale settlements in a non obvious or obscure way. Not fulfilling one of the original and best value propositions for NFTs.
Part of the beauty of NFTs is undoubtedly found in their interoperability. Yet without standardising royalties, it is my belief that tokens will remain siloed to marketplaces, in turn failing to realize one of the biggest selling points of the entire NFT proposition.
ERC721/1155 cannot easily enforce royalties themself due to various technical challenges which arise when doing so, however this does not mean standards are not required to plug the gap.
Now, thousands of NFT contracts coexist and the only interoperability part is ownership! Don’t get me wrong: that’s pretty wild and groundbreaking, but there are other aspects of the equation which require consideration too. It is also important to remember that ownership is not the same thing as royalties — they are two separate parts of the value proposition
And therein lies the rationale and motivation for EIP-2981…
EIP-2981 came to my attention in late 2020 via weekinethereumnews. It immediately caught my eye and after a quick initial read seemed to (largely) make sense.
I reached out to Zach (the original creator) from mintable and we started chatting.
Before further diving into the EIP and its rationale, I want to bring to attention all the amazing folks who got the standard to ‘final call’ and who I’ve chatted to over the last several months. In no specific order: Zach Burks, James Morgan (me), Blaine Malone, James Seibel, Simon Fremaux, Cliff Hall and Paul Ranford have all proved invaluable as peers, collaborators and contributors. A further mention also goes to those devs over at Rarible and OpenSea with whom I or others have discussed the project. There may also be others who have contributed to the EIP who I’ve neglected to list — rest assured your efforts were all greatly-appreciated 🙏. Along with technical analysis there are also several artists who joined the discussions and helped drive this forward — Lawrence Lee, Brad Ionson, the DADA community along with MOCDA and many others 🙏
So what is EIP-2981?
In a nutshell, EIP-2981 allows for a digital asset to present a simple, standardized and GAS efficient solution to any 3rd party about what are the expected, contractual royalties to be paid out. In essence, a focus on simplicity with an aim to help wider adoption from marketplaces.
interface IERC2981 { /// @notice Called with the sale price to determine how much royalty // is owed and to whom. /// @param _tokenId - the NFT asset queried for royalty information /// @param _salePrice - the sale price of the NFT asset specified by _tokenId /// @return receiver - address of who should be sent the royalty payment /// @return royaltyAmount - the royalty payment amount for _salePrice function royaltyInfo( uint256 _tokenId, uint256 _salePrice ) external view returns ( address receiver, uint256 royaltyAmount ); }Full gist
This is it, it’s super simple and should fit lots of use cases which can be built on-top of this simple building block.
For a given _tokenId and _salePrice, when requested provide a single royalty receiver address and the expected royaltyAmount to be paid.
I hope it becomes a key building block for future NFT innovation and I know some of the existing EIP contributors are already looking ahead to enhancements and additional layers such as global registries, complex payment schemes and governance options.
Some of the use-cases which I think would work well are;
• Atypical, fixed % royalties e.g. 12.5% of all sales go back to artists on KO
• Decaying royalties — this could be time based, ownership based or any other variants as sales reduce the number of times a NFT changes hands
• Dynamic royalties — changing over time or based on sale amount
• Upgradable royalties — allowing an entity or owner to modify any royalty
• Stepped royalties e.g. when sold for less than $100 don’t provide royalties
• Governed royalties — ownership of funds is dictated by a DAO, imagine that the receiver as a DAOs treasury …
• Collector and artists royalties could even use it, it’s not specific to a specific persona.
My point here is that it’s so simple it’s designed to be used as a small foundational block for more interesting advancements in the space. Or at least that’s how I view it!
The single receiver address is beneficial as it simplifies the interface design and creates a straight forward integration path for all implementers, hopefully meaning marketplaces are more likely to adopt. Royalties between many parties are still very possible and can be pushed higher up the stack, behind the single address without too much extra complexity. Although often primarily linked to creator royalties, you can still use the standard to enforce any type of royalties for any part of a digital asset potential owners or operators.
I believe that, as with the DeFi space in which the term “Money Legos” is bandied about, NFTs will also eventually have this concept in the form of “Creator Legos”. Essentially, building blocks for enabling digital things to exist in a truly digital nature, backed by provable trustless ownership, with a wide range of “plug and play” options to facilitate participation in a digitally native world.
Mint + burn, royalties, programmable items, composable assets, identity + ownership, media, token governance … the list goes on. The aforementioned are all primitives which standardisation would benefit heavily. Indeed, many of them currently have working groups and competing standards in the mix. A goal for KnownOrigin is to help facilitate these building blocks of the future via standardization and mass adoption.
But now what…
The road ahead…
Adoption is key to the success of any standard, this is why ERC-721/ERC-20 and ERC-1155 amongst others have had such widespread practical application. For all their warts (and they all have them) they have gained widespread and broad traction throughout Ethereum based networks. Tooling has been built, matured and advanced and entire ecosystems such as DeFi, CryptoArt and Gaming have emerged on-top of these networks.
Hopefully in the future EIP-2981 is a success, and will be used as a foundational building block and all marketplaces can start to use it.
However in reality, it isn’t that simple, marketplaces are not simple things to build and often lots of work goes into them. Migrating large pieces of software is tricky, building new software is costly and time consuming.
Also what happens to all those many hundreds of thousands of NFTs that are in existence today, don’t worry, it’s still early and there will be many millions more issued in the future.
The key is to recognise and encourage its wider adoption in all new and existing projects!
Social pressure can and should be applied to projects to support it, as previously seen with the emergency of royalties themselves, I believe the community has the power to make these changes a reality.
So please make some noise and shout about it!
KnownOrigin V3
We are nearing launch of the next iteration of KO, our third iteration and our 3rd year working with NFT’s so hopefully it will enable lots of exciting and rich possibilities for the community at large. Once audits are complete it will be open sourced for all.
We will be supporting EIP-2981 from day one of launch, along will multiple collaborators and two different types of royalty payment handler, plus a whole swathe of other bells and whistles. It’s been a long time in the works with huge effort from many people so I am keen to see it in action.
Anyway thanks for reading and I hope you also see the power of and possibilities of EIP-2981, spread the word … peace out ☮️ 🙌
James 🐝