On-Chain Royalties (EIP-2981) Flashcards

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

Answer: To automatically distribute royalties among multiple collaborators

Setting the receiver to a splitter contract lets a single royalty payment be divided among several beneficiaries.

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

Answer: Direct wallet-to-wallet transfers can avoid royalties entirely

Because EIP-2981 is not enforced at transfer, users can move NFTs directly without triggering any royalty.

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

Answer: Transfer-restricting allowlists like operator filters

Operator filter registries and transfer restrictions try to block non-royalty-honoring marketplaces, going beyond EIP-2981's signaling.

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

Answer: 0

A percentage of zero is zero, so a zero sale price yields a zero royalty amount.

Why should royaltyInfo be a view function?

Answer: So marketplaces can query royalties without sending a transaction

As a view function it can be called off-chain or in calls without gas cost, letting marketplaces read royalties freely.

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

Answer: During sale settlement to compute and route the royalty

Compliant marketplaces query royaltyInfo at sale time to determine how much to pay the receiver.

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

Answer: Royalty distribution could fail and potentially block the sale flow

A receiver that reverts when paid can cause the marketplace's payout step to fail, depending on its implementation.