NFT Royalties & Marketplaces: What Actually Happens

1) EIP-2981: Reporting Royalties

EIP-2981 adds a consistent interface for marketplaces to query “who gets paid and how much” for a specific sale price.
It does not perform any payment on its own, and it does not force secondary sales to route through a specific contract.
Marketplaces call your NFT contract to retrieve the preferred payout and then decide what to do.

// Minimal EIP-2981 interface (illustrative)
interface IERC2981 {
  function royaltyInfo(uint256 tokenId, uint256 salePrice)
    external view returns (address receiver, uint256 royaltyAmount);
}

// Example policy: 5% flat, same receiver for all tokens
function royaltyInfo(uint256 id, uint256 salePrice)
  public view returns (address recv, uint256 amt)
{
  recv = payoutAddress;               // could be a splitter contract
  amt  = (salePrice * 500) / 10_000;  // 500 bps = 5%
}

• Per-token logic: You can vary recipients and basis points by tokenId (e.g., 1/1 pieces vs editioned items).
• Currency-agnostic: The returned amount is denominated in the sale currency (ETH, WETH, or ERC-20 used by the venue).
• Split payouts: Route receiver to a splitter that fans out to collaborators; avoid doing multiple transfers inside royaltyInfo.
• Primary vs secondary: 2981 addresses secondary sales; your primary sale logic typically sits in your minting/exchange contract.

2) Enforcement Patterns

Enforcement is about making sure a transfer that changes economic ownership flows through logic that pays the creator.
Here are the main patterns you will see:

• Marketplace-level enforcement: The venue adds the royalty to the settlement at trade time.
  This is the most common approach for orderbook/AMM style markets that take custody (even briefly) or intermediate payment.
  Pros: simple for users; Cons: depends on venue policy; private over-the-counter transfers can bypass it.
• List-side enforcement: Listings are created via a smart contract that checks and routes a creator fee during fill.
  If the buyer fills elsewhere without that contract, the listing is not valid there. Pros: portable listings; Cons: still opt-in.
• On-chain exchange design: The collection provides/endorses a custom exchange (or module) where transfers happen only through code that pays fees.
  Often paired with operator restrictions (next section) so that setApprovalForAll only lets whitelisted markets move tokens.
• Transfer-time checks (hooks): A contract can restrict transferFrom unless certain conditions are met (e.g., a callpath or flag is set by a fee-paying exchange).
  This can be brittle with wallet UX and requires careful EIP-721/EIP-1155 compliance.
• Non-transferable or semi-transferable designs: For membership and access tokens, some teams use SBT-like or “bind-on-claim” patterns where there is no secondary market or it is highly constrained, making royalty questions moot.

Remember that private wallet-to-wallet transfers (gifts, OTC, escrowed swaps) do not have an on-chain notion of “sale price”.
Royalties are fundamentally tied to market settlement flows, not arbitrary transfers.

3) Operator Filters / Allowlists

The key lever creators control is who they approve to transfer tokens on their behalf.
By default, holders can grant setApprovalForAll(market, true) to any operator. Collections can ship logic that only
allows approvals for operators on a curated list (or blocks known bypass contracts). This nudges liquidity to venues that honor creator fees.

• Pros: Improves fee capture; reduces drive-by listings on zero-royalty venues.
• Cons: Fragments liquidity; can confuse users if their favorite marketplace is blocked; requires active curation and updates.
• UX note: Communicate clearly in your mint site and docs which marketplaces are supported and why.

// Conceptual allowlist check (illustrative)
// Called inside setApprovalForAll or a guard
require(isApprovedOperator[msg.sender][operator] || globalAllowlist[operator], "Operator not allowed");

4) Creator Playbook

Practical steps you can take from pre-mint to post-launch:

1. Decide your economic story up front: What is the primary revenue (mint price, allowlist, Dutch auction)?
   What secondary royalty (bps) aligns incentives without scaring traders? Publish the policy on your site and in metadata (as text, not binding).
2. Implement EIP-2981 cleanly: Keep math simple (basis points), route to a payout splitter (no reentrancy in callbacks), and allow a payout address update via secure governance in case your legal entity or revenue share changes.
3. Choose an operator strategy: Open (maximum reach) vs filtered (better fee capture). If filtered, provide a clear list and rationale, and a process for venues to apply for inclusion.
4. Consider your exchange path: If you expect most trades on a specific venue or your own marketplace, integrate directly and test end-to-end with staging orders, partial fills, and bundle sales.
5. Plan for creators’ splits and charities: Use a splitter contract so collaborators are paid programmatically. Avoid manual off-chain distributions that can drift over time.
6. Communications and analytics: Tell collectors which venues honor fees, where liquidity will be seeded, and how to verify they are paying the intended royalty. Track compliance and share periodic transparency reports.

5) Buyer Considerations

As a buyer, the total you pay is price + marketplace fee + royalty (if applied) + gas.
Two identical tokens can have different all-in costs across venues depending on policy and order type.

• Check the breakdown: Good UIs show creator royalty and marketplace fee lines before you sign.
• Listings vs OTC: Direct transfers or OTC swaps usually do not pay royalties. If supporting creators matters to you, prefer venues that include them.
• Beware “zero-fee” hype: Savings may reflect bypassing creator fees; liquidity and floor stability can suffer if creators pull support.
• Stolen-asset policies: Some markets block sales flagged as stolen; that can impact liquidity and price discovery in the short term.

6) Edge Cases & Gotchas

• Bundles and partial fills: If a bundle contains mixed royalty rates or receivers, marketplaces typically pro-rate at settlement. Test how your preferred venues handle this.
• Airdrops and free mints: Secondary royalties might be your primary monetization. Communicate this so traders understand the long-term plan.
• Wrapping and fractionals: If an NFT is wrapped (wNFT) or fractionalized, sales may occur in a derivative market that does not call your original 2981. Consider allowlists that block known wrapper contracts, or embrace wrapping with a revenue share agreement.
• Bridging and L2s: A bridge-side “mirror” contract on another chain must also implement 2981 or your royalty signal is lost. Coordinate with official bridge deployments; avoid unofficial mirrors minting look-alikes.
• Rounding and tiny sales: Very small sales can round a royalty to zero. If micro-pricing matters, consider a minimum absolute fee or adapt your exchange logic.
• Upgradability risk: If you use a proxy to change payout addresses or royalty math, guard it with role separation, timelocks, and public notices to avoid trust shocks.

7) Operational Tips & Monitoring

• Use pull-payments for splits: Many venues credit a balance and allow creators to withdraw; this avoids failed transfers if a receiver is a contract without a payable fallback.
• Track compliance: Index trades by marketplace and compare expected 2981 outputs vs actual payouts (on-chain logs where available). Publish monthly stats.
• Respond to policy shifts: Maintain your operator list and docs. If a venue changes enforcement, you may need to adapt quickly to protect your holders and revenue.
• Legal clarity: Royalties in smart contracts are business rules, not legal entitlements; disclosure and honest marketing reduce disputes.

Quick check

1. What does EIP-2981 actually standardize, and what does it not?
2. Name two ways a collection can increase the likelihood that royalties are paid.
3. Why can OTC transfers bypass royalties even if 2981 is implemented?
4. What is a downside of using strict operator allowlists?

Go deeper

• EIP-2981 — NFT Royalties
• OpenSea Docs
• Blur Docs

Next up: NFTs with utility : gaming items, identity, and access.

Next: Utility NFTs →