Free NFT Development On-Chain Royalties (EIP-2981) Questions and Answers 1 — Questions and Answers
Question 1: 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?
- royaltyInfo(uint256 _tokenId, uint256 _salePrice) external view returns (address receiver, uint256 royaltyAmount) (Correct answer)
- getRoyalty(uint256 _tokenId) external view returns (address receiver, uint256 percentage)
- calculateRoyalty(uint256 _tokenId, uint256 _salePrice, address _currency) external view returns (uint256 royaltyAmount)
- onSale(uint256 _tokenId, uint256 _salePrice) external payable
Correct 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.
Question 2: What is the primary limitation of the EIP-2981 on-chain royalty standard?
- It only supports royalty payments in Ether (ETH).
- It can only signal royalty information for a single recipient address. (Correct answer)
- It is incompatible with the ERC-1155 multi-token standard.
- It requires an excessively high amount of gas to calculate royalties.
Correct 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.
Question 3: 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?
- The transaction will fail because the marketplace contract does not support the required royalty interface.
- The creator will automatically receive 5% of the sale price, as the logic is enforced by the token's smart contract.
- The creator will not receive a royalty payment because EIP-2981 is a signaling standard and relies on voluntary adoption by marketplaces. (Correct answer)
- The marketplace is required to pay the royalty, but the creator must submit an off-chain claim to receive it.
Correct 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.
Question 4: When a marketplace calls the `royaltyInfo(tokenId, salePrice)` function, what is the expected format of the `royaltyAmount` that is returned?
- A percentage value, represented as a whole number (e.g., 5 for 5%).
- A basis points value (e.g., 500 for 5%).
- An absolute monetary value in the same denomination as the `salePrice`. (Correct answer)
- A struct containing the amount and the currency type (e.g., ETH, USDC).
Correct 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.
Question 5: Which of the following describes a key design goal of the EIP-2981 standard?
- To create a complex on-chain system for enforcing royalty payments across all transfers.
- To provide a minimal, gas-efficient, and standardized way for contracts to signal royalty information. (Correct answer)
- To replace the `transferFrom` function with a new version that automatically splits funds.
- To establish a centralized registry where all NFT royalty information must be stored.
Correct 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.
Question 6: 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?
- This is not possible, as EIP-2981 only allows for a single, contract-wide royalty percentage.
- By deploying a separate EIP-2981 extension contract for each royalty tier.
- By implementing logic within the `royaltyInfo` function that checks the `_tokenId` and calculates the `royaltyAmount` accordingly. (Correct answer)
- By using the `setApprovalForAll` function to specify royalty information for each token.
Correct 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.
Free NFT Development On-Chain Royalties (EIP-2981) Questions and Answers 1
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?
What Practice Test Geeks adds beyond an AI chat for NFT
An AI chatbot can quiz you, but it can't reproduce the exam conditions or keep your record. Here you get:
- A timed, full-length NFT mock exam — 50 questions in 60 minutes with a 70% pass mark, modeled on the official exam's question count and time limit, followed by a score report broken down by exam domain.
- A fixed NFT question bank: the same test every attempt, so your score is comparable from one try to the next instead of changing with every regenerated quiz.
- Progress saved on your device: completed tests, scores and missed questions stay in My Progress, so you can retake only what you got wrong.
- A printable NFT cheat sheet you can print or save as a PDF.
- NFT flashcards built from the same question bank.