What is ERC-2981?
NFT royalties as a discovery signal, not an enforcement mechanism.
ERC-2981 is the NFT royalty standard most marketplaces know how to ask for. It answers one question: if this token sells for this price, who should receive royalties and how much?
on this page
The standard, in one card.
- Standard
- ERC-2981 / EIP-2981
- Core function
- royaltyInfo(tokenId, salePrice)
- Detection
- ERC-165 interface ID
- Canonical spec
- eips.ethereum.org / EIP-2981
The origin story.#
NFT royalties were originally marketplace-specific. ERC-2981 standardized the read path so contracts could publish royalty information without every marketplace inventing a custom adapter.
What ERC-2981 actually is.#
function royaltyInfo(uint256 tokenId, uint256 salePrice) external view returns (address receiver, uint256 royaltyAmount);
royaltyInfo tokenId · salePrice receiver · royaltyAmount royaltyInfo takes a tokenId and salePrice, then returns a receiver and royaltyAmount. The contract can compute that amount however it wants, as long as it returns the amount in the same unit as the sale price.
What's broken about ERC-2981.#
The standard deliberately does not enforce royalties. That keeps transfers simple and composable, but it means royalty payment is a marketplace or sale-contract policy choice.
-
Royalties are signaled, not enforced.#
The standard returns a suggested receiver and amount. It does not force marketplaces, private transfers, or escrow contracts to pay that amount.
ERC-2981royaltyInfo(...)policymarketplace enforcesworkarounds tried- marketplace policy
- transfer validators
- allowlists
- custom sale contracts
-
It does not define royalty metadata.#
ERC-2981 returns payment data. It does not define creator profiles, license text, splits metadata, or rich attribution fields.
ERC-2981receiver + amountLSP4typed metadata keysworkarounds tried- off-chain metadata
- custom split contracts
- marketplace pages
-
It depends on marketplace behavior.#
A standard royalty function only helps if buyers and marketplaces route through software that calls it and honors the result.
NFT salemarketplace decidesaccount stackexplicit permission / sale flowworkarounds tried- operator filters
- creator-enforced marketplaces
- legal terms
LUKSO designed it differently.#
LUKSO's metadata and profile standards make creator and asset information richer than one royalty function. Royalty payment still needs application policy, but the identity and metadata substrate is less ad hoc.
- LSP4 Digital Asset Metadata A typed metadata layer that can carry richer asset and creator data alongside royalty signaling.
- LSP8 Identifiable Digital Asset NFT-like identifiable assets with typed per-token data.
- LSP3 Profile Metadata Creator and holder identities can be Universal Profiles with first-class metadata.
ERC-2981 vs LSP4+LSP8 in one table.#
| row | ERC-2981 | LSP metadata and asset stack |
|---|---|---|
| purpose | royalty discovery | asset and creator metadata substrate |
| enforces payment | no | no by itself; app policy required |
| data shape | receiver + amount | typed metadata keys |
| asset fit | NFT royalty-aware marketplaces | LSP8 assets and Universal Profiles |
FAQ.#
-
Does ERC-2981 enforce NFT royalties? #
No. It standardizes royalty discovery. Marketplaces and sale contracts still decide whether to pay the returned royalty.
-
What does royaltyInfo return? #
It returns a receiver address and a royalty amount for a given tokenId and salePrice.
-
Does ERC-2981 only work with ERC-721? #
No. It can be used by NFT-style contracts generally, and it is detected through ERC-165.