Marketplace Royalty Standards (EIP-2981) Flashcards

An NFT marketplace is processing a sale and needs to determine if it should pay royalties for a given token. According to the EIP-2981 standard, what is the first step the marketplace's smart contract should take to check for royalty information?

Answer: Check if the token contract supports the EIP-2981 interface ID (0x2a55205a) via an ERC-165 check.

EIP-2981 is designed to be discoverable through the ERC-165 standard. Before calling `royaltyInfo`, a compliant marketplace should first call `supportsInterface(0x2a55205a)` on the NFT contract to confirm it implements the royalty standard, ensuring predictable behavior and preventing failed calls.

A developer implements the EIP-2981 `royaltyInfo` function for an NFT collection. For a token with ID `123`, a 5% royalty is due. If this token sells for 10 ETH, what should the `royaltyInfo(123, 10 ether)` function return?

Answer: A `receiver` address and a `royaltyAmount` of `0.5 ether`.

The `royaltyInfo` function takes the `_tokenId` and the `_salePrice` as arguments and must return two values: the `receiver` address and the calculated `royaltyAmount`. The `royaltyAmount` should be in the same denomination as the `_salePrice`, so for a 10 ETH sale with a 5% royalty, the amount is 0.5 ETH.

What is the core purpose of the EIP-2981 standard in the NFT ecosystem?

Answer: To provide a universal, on-chain method for signaling royalty information to any marketplace or participant.

EIP-2981's primary goal is to standardize how royalty information is communicated. It doesn't enforce payments but provides a single, queryable function (`royaltyInfo`) on the NFT contract itself, allowing any third party (like a marketplace) to retrieve the intended royalty recipient and amount for a given sale.

A digital art collective wants to release an NFT where the 10% royalty fee is split equally between the lead artist and a charity. How can this be achieved while remaining compliant with the EIP-2981 standard?

Answer: The `royaltyInfo` function should return the address of a separate payment splitter smart contract as the `receiver`.

EIP-2981 specifies that `royaltyInfo` must return a single `receiver` address. To handle splits, the standard practice is to deploy a separate payment splitter contract. The NFT's `royaltyInfo` function then returns the address of this splitter contract. The marketplace sends the full royalty amount to the splitter, which then handles the logic of distributing the funds to the multiple beneficiaries.

Which of the following statements accurately describes the role of marketplaces regarding EIP-2981?

Answer: EIP-2981 is a voluntary standard, and enforcement of the signaled royalties is a policy decision made by each individual marketplace.

EIP-2981 is a signaling mechanism, not an enforcement mechanism. The standard itself cannot force a marketplace to pay royalties. It simply provides the data. Whether a marketplace honors these on-chain royalties is a business and policy decision, leading to the current landscape where royalty enforcement varies across different platforms.

A developer is implementing EIP-2981 and sets a royalty of 2.5%. The `royaltyInfo` function is called with a `_salePrice` of 1,500 wei. Given that Solidity does not handle floating-point numbers, how should the `royaltyAmount` be calculated to avoid precision loss?

Answer: By calculating `(1500 * 250) / 10000` using basis points.

The common and recommended practice for handling percentage calculations in Solidity is to use basis points, where 1 basis point = 0.01%. Therefore, a 2.5% royalty is represented as 250 basis points. The calculation `(salePrice * 250) / 10000` correctly computes the royalty amount using integer arithmetic, minimizing precision loss.