Over the last 12 months, the non-fungible token (NFT) market has soared. We’ve seen our very own Nifty Gateway achieve [explosive growth](https://www.gemini.com/blog/the-explosive-rise-of-nifty-gateway-and-digital-art). With all this excitement, we’re eager to explore where the space is headed with a particular focus on what value an open royalty standard can bring to NFT creators. 

If you ask participants in the NFT ecosystem what they’re most excited about, you’ll likely hear various different responses, such as:

- Investing in a new asset class
- Being part of a community
- Opportunity to resell for profit
- The positive long term impact of NFT technology

However, a lingering promise since the inception of NFTs, is the idea that there is now *a new medium for creators to monetize their work*. More specifically, royalty payments can now be seamlessly facilitated through blockchain infrastructure. 

Creators have already been making use of the existing royalty payment solutions, and many have already been able to realize a newfound passive income stream. So, what’s the problem? 

__The NFT Royalty Landscape Today__

NFT standards ([ERC-721](https://eips.ethereum.org/EIPS/eip-721)/[ERC-1155](https://eips.ethereum.org/EIPS/eip-1155)) are built on [Ethereum](https://www.gemini.com/cryptopedia/ethereum-blockchain-smart-contracts-dapps). Broadly speaking, marketplaces transfer ownership of NFTs between collectors upon a sale. These transfer mechanisms are made *easy* because of the open standards that exist. These standards have facilitated the proliferation of many NFTs we see today, of course with the exception of some that predated their creation e.g. [CryptoPunks](https://www.larvalabs.com/cryptopunks), [CryptoKitties](https://www.cryptokitties.co/). 

At the time of this writing, an open royalty payment standard is not ubiquitous in the Ethereum ecosystem. Royalty information is siloed to marketplaces and generally not shared. This means that if an NFT is moved off a platform and then sold, the creator won’t receive the royalties that they’re entitled to. 

[EIP-2981](https://eips.ethereum.org/EIPS/eip-2981) is a standard that focuses on signalling to market participants the royalty payment information for a given NFT or set of NFTs. It allows for attaching royalty information to the token itself, thereby making use of a common data store and computation layer that *all* participants can access — the Ethereum blockchain. 

After nearly one year of [discussions](https://github.com/ethereum/EIPs/issues/2907), EIP-2981 was finalized on July 24, 2021. 

__How Does it Work?__

It’s pretty simple. The crux of the problem can be solved by overriding a single [Solidity](https://www.gemini.com/cryptopedia/search?query=Solidity) function in your smart contract.

```
/// @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
);
```

The general goal of EIP-2981 contributors is to provide a [gas](https://www.gemini.com/cryptopedia/search?query=gas)-efficient solution while avoiding restrictions on future royalty payment improvements. The simplicity of its design is intentional, with the aim to make adoption simple. As with any standard, adoption is key to its utility. 

In the usual case, for a given NFT *`_tokenId`* and *`_salePrice`*, the *`royaltyInfo`* function will perform a percentage calculation to produce the necessary (and undisputed) information to craft a royalty payment transaction. 

Notice how the function does not concern itself with currency. The existing standards for NFTs (ERC-721/1155) are currency agnostic. In fact, if we zoom out a little, NFT smart contracts aren't even aware of the concept of a "sale". When it comes to more abstract concepts like sales, it is the marketplaces that facilitate them. As a reminder, two key actions occur when a sale takes place:

1. A transfer of funds from the buyer to the seller 
2. A transfer of the NFT from the seller to the buyer

As far as the NFT smart contract is concerned, it can’t tell if an invocation of [`safeTransferFrom`](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md#specification) was a simple transfer of the NFT to another address or an actual sale event. This alone makes enforcing royalty payments on-chain challenging. Specifically when you’re conforming to existing standards that aren’t built with this in mind. 

It’s important for marketplaces supporting EIP-2981 to consider the currency that the NFT sale was denominated in. The royalty calculation should be in the same denomination. So, if an NFT was sold for 45×1018 [Wei](https://www.gemini.com/cryptopedia/glossary#wei) (45 Ether), then the *`royaltyAmount`* returned from the function would be in the expected denomination (Wei). With that in mind, let’s jog our memory on the fact that math in Solidity does not support fractions and suggest one possible workaround:

1. 2.5% of the *`_salePrice`* should be sent to the receiver, we know that 2.5% of 45 Ether is 1.125 Ether. However, Solidity will compute 1 Ether: `uint256 result = (uint256(45) * 250) / 10000;`

2. More precision is required, so we can convert Ether to Wei; 45 Ether is now 45×1018 Wei and Solidity will compute 1.125×1018 Wei or 1.125 Ether:
 `uint256 result = (45000000000000000000 * 250) / 10000;`

This highlights a potential pitfall that Solidity engineers should be no stranger to. That is, the *`_salePrice`* should be sent in the smallest denomination of the currency tendered. This reduces the likelihood of disputes with respect to how Solidity performs arithmetic operations. To further ensure that precision is kept, implementers should consider using basis points (bps). Notice how 2.5% is denoted as 250 bps and 100% is 10,000 bps. This common unit of measure for percentage interest rates in finance works well here. 

In addition to this, it’s advised to extensively unit test this function before deploying to production. Call sites invoking this function can also check that the *`royaltyAmount`* value that was calculated is sensible 
e.g. *`royaltyAmount < _salePrice`*.

![Blog inline - NFT Royalty Standard](//images.ctfassets.net/jg6lo9a2ukvr/2X6EoBafKOBBNtPiGUGhta/7066605b86e4e3fa2bd7d424bce4977b/Blog_inline_-_NFT_Royalty_Standard__1_.png)
*Image credit: [knownorigin](https://medium.com/knownorigin/eip-2981-simple-and-effective-royalty-standards-for-all-dbd0b761a0f0)*

__EIP-2981 in Action__

A nice example of EIP-2981 in action can be found at this [example implementation](https://github.com/dievardump/EIP2981-implementation). Here we can see royalties implemented on a *per token* basis. In contrast, we can also see globally applied royalties, where every token is associated with the *same* royalty information. This can be achieved relatively easily with some small tweaks to the smart contract.

The cryptocurrency space is known for pushing the boundaries and testing assumptions of existing systems. EIP-2981 is no exception — engineers and enthusiasts can get creative with how the *`royaltyInfo`* function is implemented. Some interesting approaches might include:

- __Fixed royalties__ — this is expected to be the common case where a static percentage is used for every sale.
- __Decaying royalties__ — reduce royalties owed for every transfer event of the NFT over time.
- __Multisig royalties__ — the receiver address could be a multisig smart contract. It may represent a DAO or some effort towards public goods funding.
- __Stepped royalties__ — don’t send royalties if the sale price is below a threshold.

Many contributors see this standard as a necessary building block towards a more open royalties system. For the most part, there's a particular focus on socially enforced royalties; a system where incentives between participants align such that leaving royalties unpaid is disincentivized. It’s a common belief that this approach could prove to be very resilient, and further reinforced by more transparency with respect to royalty payment obligations. 

__What Next?__

For EIP-2981 to become widely supported we must __raise awareness__. Gentle forces can be applied to marketplaces by artists who request it. In addition to this, marketplaces can also anticipate the demand and implement it sooner. 

All things considered, marketplaces will decide on a case-by-case basis whether to support the EIP-2981 standard. With some familiar names in the NFT landscape already supporting it, we’re optimistic others will follow.

We see this as an exciting development and one to keep a close eye on in the coming months. 

Onward and Upward!

Blaine Malone 
Staff Software Engineer, Research & Development (Co-author of EIP-2981)

*Decentralization and transparency are central to crypto's ethos. At Gemini, we want to contribute to greater understanding and knowledge around fast-paced technical developments in crypto and help further drive innovation in our industry. We are proud to publish technical content developed by our engineers as we build the future of crypto.*

Blaine Malone

ARTICOLI DI Blaine Malone

Exploring the NFT Royalty Standard (EIP-2981)

Un modo semplice e sicuro per acquistare e vendere criptovalute