Skip to main content

VEP-2981: NFT Royalty

VEP: 2981
author: Evgeny Shatalov <evgeny.a.shatalov@gmail.com>, Aleksei Kolchanov <a.kolchanov@numi.net>
status: Review
type: Contract
created: 2023-03-08
requires: TIP-6

Abstract​

This standard allows contracts, such as NFTs that support TIP-4.1, to signal a royalty amount to be paid to the NFT creator or rights holder every time the NFT is sold or 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 transfer mechanisms do not always imply a sale occurred. Marketplaces and individuals implement this standard by retrieving the royalty payment information with royaltyInfo(), which specifies how much to pay to which address for a given sale price.

Motivation​

The suggested standard adapts the Ethereum EIP-2981 standard to the Venom blockchain. Venom blockchain has distributed nature and supports TIP-4.1 standard for NFT and TIP-6.1 for interfaces. The standard must take into account this distributed nature and mentioned standards. This standard allows NFTs that support TIP-4.1 and other valuable contracts, to have a standardized way of signaling royalty information. More specifically, these contracts can now calculate a royalty amount to provide to the rightful recipient.

Royalty amounts are always a percentage of the sale price. If a marketplace chooses not to implement this VEP, then no funds will be paid for secondary sales. It is believed that the NFT marketplace ecosystem will voluntarily implement this royalty payment standard; in a bid to provide ongoing funding for artists/creators. 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 NFT creators from minting new and innovative tokens.

Enabling all NFT marketplaces to unify on a single royalty payment standard will benefit the entire NFT ecosystem.

While this standard focuses on NFTs and compatibility with the TIP-4.1 standard, VEP-2981 does not require compatibility with TIP-4.1 standard. Any other contract could integrate with VEP-2981 to return royalty payment information. VEP-2981 is, therefore, a universal royalty standard for many asset types.

Specification​

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

TIP-4.1 compliant contracts MAY implement this standard for royalties to provide a standard method of specifying royalty payment information.

Marketplaces that support this standard SHOULD implement some method of transferring royalties to the royalty recipient. The example of such implementation can be found in TIP-4.1 on visualization schemas (see transfers to the creator).

TIP-4.1 compliant contracts MAY implement this standard for collection contract and NFT contracts at the same time. Marketplaces that support this standard SHOULD prefer NFT contract royalty than collection contract royalty.

Marketplaces MUST pay the royalty in the same unit of exchange as that of the salePrice passed to royaltyInfo(). This is equivalent to saying that the salePrice parameter and the royaltyAmount return value MUST be denominated in the same monetary unit. For example, if the sale price is in Venom, then the royalty payment must also be paid in Venom, and if the sale price is in USDC, then the royalty payment must also be paid in USDC.

Implementers of this standard MUST calculate a percentage of the salePrice when calculating the royalty amount. Subsequent invocations of royaltyInfo() MAY return a different royaltyAmount. Though there are some important considerations for implementers if they choose to perform different percentage calculations between royaltyInfo() invocations.

The royaltyInfo() function is not aware of the unit of exchange for the sale and royalty payment. With that in mind, implementers MUST NOT return a fixed/constant royaltyAmount, wherein they’re ignoring the salePrice. For the same reason, implementers MUST NOT determine the royaltyAmount based on comparing the salePrice with constant numbers. In both cases, the royaltyInfo() function makes assumptions on the unit of exchange, which MUST be avoided.

The percentage value used must be independent of the sale price for reasons previously mentioned (i.e. if the percentage value 10%, then 10% MUST apply whether salePrice is 10, 10000 or 1234567890). If the royalty fee calculation results in a remainder, implementers MAY round up or round down to the nearest integer. For example, if the royalty fee is 10% and salePrice is 999, the implementer can return either 99 or 100 for royaltyAmount, both are valid.

The implementer MAY choose to change the percentage value based on other predictable variables that do not make assumptions about the unit of exchange. For example, the percentage value may drop linearly over time. An approach like this SHOULD NOT be based on variables that are unpredictable like 'block. timestamp', but instead on other more predictable state changes like now instruction. One more reasonable approach MAY use the number of transfers of an NFT to decide which percentage value is used to calculate the royaltyAmount. The idea is that the percentage value could decrease after each transfer of the NFT.

Marketplaces that support this standard SHOULD NOT send a zero-value transaction if the royaltyAmount returned is 0. This would waste gas and serves no useful purpose in this VEP.

Marketplaces that support this standard MUST pay royalties no matter where the sale occurred or in what currency, including on-chain sales, over-the-counter (OTC) sales and off-chain sales such as at auction houses. As royalty payments are voluntary, entities that respect this VEP must pay no matter where the sale occurred - a sale conducted outside of the blockchain is still a sale. The exact mechanism for paying and notifying the recipient will be defined in future VEPs.

Each TIP-4.1 compliant contracts that supports this standard MUST implement TIP-6.1 and the following interface:

    pragma ton-solidity >= 0.58.1;

    interface IRoyaltyInfo {
        /// @notice NFT royalty information
        /// @param salePrice the sale price of the NFT
        /// @return receiver address of who should be sent the royalty payment
        /// @return royaltyAmount - the royalty payment amount for salePrice
        function royaltyInfo(uint128 salePrice) external view responsible returns(address receiver, uint128 royaltyAmount);
    }

NOTE The TIP-6.1 identifier for this interface is 0x60970214.

Rationale​

Optional royalty payments​

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 transfer function, such as transfer() in TIP-4.1, 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/creators. NFT buyers will assess the royalty payment as a factor when making NFT purchasing decisions.

Simple royalty payments to a single address​

This VEP does not specify the manner of payment to the royalty recipient. Furthermore, it is impossible to fully know and efficiently implement all possible types of royalty payments logic. With that said, 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 processes. Attempting 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. This VEP should be considered a minimal, gas-efficient building block for further innovation in NFT and other assets royalty payments. Future VEPs can specify more details regarding payment transfer and notification.

Royalty payment percentage calculation​

This VEP mandates a percentage-based royalty fee model. It is likely that the most common case of percentage calculation will be where the royaltyAmount is always calculated from the salePrice using a fixed percent i.e. if the royalty fee is 10%, then a 10% royalty fee must apply whether salePrice is 10, 10000 or 1234567890.

Implementers can get creative with this percentage-based calculation but there are some important caveats to consider. Mainly, ensuring that the royaltyInfo() function is not aware of the unit of exchange and that unpredictable variables are avoided in the percentage calculation.

Unit-less royalty payment across all marketplaces, both on-chain and off-chain​

This VEP does not specify a currency or token used for sales and royalty payments. The same percentage-based royalty fee must be paid regardless of what currency, or token was used in the sale, paid in the same currency or token. This applies to sales in any location including on-chain sales, over-the-counter (OTC) sales, and off-chain sales using fiat currency such as at auction houses. As royalty payments are voluntary, entities that respect this VEP must pay no matter where the sale occurred - a sale outside of the blockchain is still a sale.

Universal Royalty Payments​

Although designed specifically with NFTs in mind, this standard does not require that a contract implementing VEP-2981 is compatible with TIP-4.1 standard. Any other contract could use this interface to return royalty payment information, provided that it is able to uniquely identify assets within the constraints of the interface. VEP-2981 is, therefore, a universal royalty standard for many other asset types.

Backwards compatibility​

This standard is compatible with the current TIP-4.1 standard.

Security considerations​

There are no security considerations related directly to the implementation of this standard.

Copyright and related rights waived via CC0.

References​