On-Chain Royalties (EIP-2981) Flashcards

A developer is implementing EIP-2981 for an NFT collection. A marketplace needs to determine the royalty payment for a token with `tokenId` 789 that just sold for 10 ETH. Which function signature must the marketplace call on the NFT contract to get this information?

Answer: royaltyInfo(uint256 _tokenId, uint256 _salePrice) external view returns (address receiver, uint256 royaltyAmount)

EIP-2981 specifies a single, universal function, `royaltyInfo`, which takes the token ID and the total sale price as inputs. It returns the address that should receive the royalty and the absolute amount of the royalty to be paid.

What is the primary limitation of the EIP-2981 on-chain royalty standard?

Answer: It can only signal royalty information for a single recipient address.

The EIP-2981 standard, in its base form, only allows the `royaltyInfo` function to return a single `receiver` address. If royalties need to be split among multiple parties, this logic must be handled off-chain or by setting the receiver to a separate splitter contract, which adds complexity.

An NFT project implements EIP-2981, setting a 5% royalty. An owner sells one of the project's NFTs on a marketplace that has publicly stated it does not honor EIP-2981. What is the expected outcome for the creator regarding their royalty payment?

Answer: The creator will not receive a royalty payment because EIP-2981 is a signaling standard and relies on voluntary adoption by marketplaces.

EIP-2981 is a signaling mechanism, not an enforcement mechanism. The NFT contract advertises the royalty information, but it is entirely up to the marketplace to query this information and honor the payment. If a marketplace chooses not to implement the standard, no royalty will be paid.

When a marketplace calls the `royaltyInfo(tokenId, salePrice)` function, what is the expected format of the `royaltyAmount` that is returned?

Answer: An absolute monetary value in the same denomination as the `salePrice`.

The `royaltyAmount` returned by the `royaltyInfo` function is an absolute value, not a percentage. It is the marketplace's responsibility to calculate this amount based on the `salePrice`. The standard mandates that the `royaltyAmount` must be in the same currency or unit of exchange as the `salePrice` provided in the function call.

Which of the following describes a key design goal of the EIP-2981 standard?

Answer: To provide a minimal, gas-efficient, and standardized way for contracts to signal royalty information.

EIP-2981 was intentionally designed to be simple and gas-efficient. Its primary purpose is to create a universal interface for marketplaces to retrieve royalty information directly from the NFT contract, rather than enforcing the payment itself.

A developer wants to set different royalty percentages for different tokens within the same ERC-721 collection (e.g., rare tokens have a higher royalty). How can this be achieved while complying with EIP-2981?

Answer: By implementing logic within the `royaltyInfo` function that checks the `_tokenId` and calculates the `royaltyAmount` accordingly.

EIP-2981 is flexible. The `royaltyInfo` function receives the `_tokenId` as a parameter, allowing developers to implement custom logic. This can include looking up a specific royalty percentage for that token ID or applying different rules based on token traits, enabling per-token royalties within a single contract.