ERC2981 - Let royaltyFraction (royalty fee) accessible for each tokens

🧐 Motivation I want to display the royalty percentage/fee (royaltyFraction) on NFTs that are listed on my marketplace app. I want my users to be acknowledged for the price cuts.

📝 Details The royalty fraction information is already recorded in a struct for each tokens’ with royalty set inside the ERC2981.sol. I want to access that information and show it on my marketplace app. Currently, I have modified the royaltyInfo function to return the royaltyFraction like this:

/**
     * @inheritdoc IERC2981
     */
    function royaltyInfo(uint256 _tokenId, uint256 _salePrice) public view virtual override returns (address, uint256, uint96) {
        RoyaltyInfo memory royalty = _tokenRoyaltyInfo[_tokenId];

        if (royalty.receiver == address(0)) {
            royalty = _defaultRoyaltyInfo;
        }

        uint256 royaltyAmount = (_salePrice * royalty.royaltyFraction) / _feeDenominator();

        return (royalty.receiver, royaltyAmount, royalty.royaltyFraction);
    }

I have also modified the related function inside the IERC2981 to return the royaltyInfo as follows:

interface IERC2981 is IERC165 {
    /**
     * @dev Returns how much royalty is owed and to whom, based on a sale price that may be denominated in any unit of
     * exchange. The royalty amount is denominated and should be paid in that same unit of exchange.
     */
    function royaltyInfo(uint256 tokenId, uint256 salePrice)
        external
        view
        returns (address receiver, uint256 royaltyAmount, uint96 royaltyFraction);
}

There could be a better way to achieve this. Please let us access royaltyFraction so users of my marketplace can also see the royalty fee (royaltyFraction) information.

[Amxx]

• For your first and second paragraphs: I cannot make a gas cost comparison but calling royaltyInfo for each NFT listed on my marketplace with a dummy sale price will also run some calculations (like royalty amount) that I don’t need and thus I believe this would cause unnecessary gas consumption. This is mainly what I am trying to get away from.

I am going to assume you are building a website marketplace. Something similar to OpenSea. You did not say it clearly, but I guess the most logical “marketplace” case.

Calling the royaltyInfo for each NFT might indeed be a pain, but that is the design of the ERC that each NFT can have a different fee. The good thing here is that if a backend server or a website front does this call, the call is free (as far as gas is concerned). You don’t pay gas when you want to check the state of the blockchain.

Now you can use the existing royaltyInfo() function with a dummy price … or you could call another non standard function … in both cases the cost will be the same.

The difference in gas cost is for whoever is going to deploy the contract. The more features there are, the most expensive it is, so you definitely don’t want to deploy features that you don’t need.

• For the 3rd paragraph: I don’t understand how adding a getter would break the interoperability since any other marketplace implementing the ERC2981 (or anything with EIP2981) would work just fine. Additionally, the ERC2981.sol already has functions that were not specially defined within the EIP-2981 and it is OK since ERC2981.sol follows the “The key words “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.” And I (as a junior) believe adding a getter for the percentage would break any of these.

I was probably not clear to what I’m meaning by interoperability here. Its true that adding an additional function will not remove anything from the contract. Contracts would remain ERC2981 compliant, so that is not the issue.

My concern is with your marketplace relying on a specific function being present. By doing so, you are not making your marketplace ERC2981 compliant, and you will incorrectly interact with contracts that are “only” ERC2981. IMO it would be better if your marketplace doesn’t make any assumptions about the contract interface beyond what is standardized in ERCs.

[DoDzilla-ai]

• For your first and second paragraphs: I cannot make a gas cost comparison but calling royaltyInfo for each NFT listed on my marketplace with a dummy sale price will also run some calculations (like royalty amount) that I don’t need and thus I believe this would cause unnecessary gas consumption. This is mainly what I am trying to get away from.
• For the 3rd paragraph: I don’t understand how adding a getter would break the interoperability since any other marketplace implementing the ERC2981 (or anything with EIP2981) would work just fine. Additionally, the ERC2981.sol already has functions that were not specially defined within the EIP-2981 and it is OK since ERC2981.sol follows the “The key words “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.” And I (as a junior) believe adding a getter for the percentage would break any of these.

With the addition of a simple getter, marketplaces would be able to display the royalty percentage (for sellers and buyers) without additional gas consumption of royalty amount calculation and it would be much more clean from the perspective of developers.

Sorry If am missing something with my logic.