NFT On-Chain Royalties (EIP-2981) 4

Question 1

Why might a developer prefer a payment-splitter contract as the EIP-2981 receiver?

Accepted Answer

To automatically distribute royalties among multiple collaborators

Answer

To bypass marketplace fees

Answer

To increase the royalty percentage over time

Answer

To hide the royalty from buyers

Question 2

What is a key limitation of EIP-2981 regarding peer-to-peer transfers?

Accepted Answer

Direct wallet-to-wallet transfers can avoid royalties entirely

Answer

It charges royalties even on gifts

Answer

It blocks all transfers

Answer

It doubles royalties on resale

Question 3

Which approach attempts stronger royalty enforcement than EIP-2981 alone?

Accepted Answer

Transfer-restricting allowlists like operator filters

Answer

Increasing the fee denominator

Answer

Using ERC-20 instead of ERC-721

Answer

Disabling supportsInterface

Question 4

If royaltyInfo is called with a salePrice of 0, what royaltyAmount results with a percentage-based implementation?

Accepted Answer

0

Answer

The full default fee

Answer

It reverts

Answer

The denominator value

Question 5

Why should royaltyInfo be a view function?

Accepted Answer

So marketplaces can query royalties without sending a transaction

Answer

To allow it to modify state cheaply

Answer

Because it mints tokens

Answer

To emit events

Question 6

A marketplace honoring EIP-2981 typically calls royaltyInfo at what point?

Accepted Answer

During sale settlement to compute and route the royalty

Answer

Only at mint time

Answer

When the NFT is burned

Answer

Never; it guesses the amount

Question 7

What risk arises if the royalty receiver is set to a contract that reverts on payment?

Accepted Answer

Royalty distribution could fail and potentially block the sale flow

Answer

The royalty silently becomes zero

Answer

The buyer is refunded twice

Answer

The NFT is burned