RoyaltyInfo Interface

The RoyaltyInfo Interface is a technical specification defined by the Ethereum Request for Comment 2981 (ERC-2981) standard. It provides a single, universal function, royaltyInfo(uint256 _tokenId, uint256 _salePrice), that returns the recipient address and royalty amount for a given token and sale price. This allows any marketplace or decentralized application (dApp) to query an NFT contract directly to discover and enforce creator royalties in a consistent manner, moving away from fragmented, off-chain metadata or platform-specific implementations.

Prior to ERC-2981, there was no reliable, on-chain method for smart contracts to declare royalty information. Creators relied on marketplaces voluntarily honoring off-chain data or implementing proprietary, non-interoperable solutions. The RoyaltyInfo Interface solves this by embedding the royalty logic directly into the NFT's smart contract. When a secondary sale occurs on a compliant marketplace, the platform can call the royaltyInfo function, receive the payment details, and automatically route the specified percentage to the creator's wallet as part of the transaction.

Implementing the interface involves overriding the royaltyInfo function within an NFT contract, such as one based on ERC-721 or ERC-1155. The function's logic determines how royalties are calculated—typically a percentage of the _salePrice—and who receives them. This can be a fixed address, a payment splitter contract for multiple recipients, or even dynamic logic based on the _tokenId. The returned royalty amount must be denominated in the same base unit as the sale price (e.g., wei for ETH).

For developers and marketplace builders, supporting the RoyaltyInfo Interface is crucial for interoperability. Major marketplaces like OpenSea and LooksRare recognize ERC-2981, allowing creators to be compensated automatically across platforms. It represents a significant shift toward programmable creator economies, ensuring that royalty enforcement is not a policy choice of a centralized platform but a verifiable property of the digital asset itself, executable by any compliant smart contract.

Defined by the ERC-2981 standard, the RoyaltyInfo interface provides a single, mandatory function: royaltyInfo(uint256 tokenId, uint256 salePrice). This function returns two critical pieces of information: the recipient address where royalty payments should be sent and the royalty amount to be paid, calculated from the provided salePrice. By standardizing this lookup, any marketplace, aggregator, or smart contract can query an NFT contract to discover and respect its royalty policy, moving away from fragile off-chain metadata or platform-specific configurations.

The core mechanism involves a simple calculation performed inside the royaltyInfo function. When a secondary sale occurs, the marketplace calls this function, passing the specific tokenId and the final salePrice. The contract's internal logic then determines the payout, typically by applying a fixed percentage (e.g., 5%) or a custom rule defined per token or collection. The returned royaltyAmount is usually calculated as (salePrice * royaltyFraction) / 10000, where the fraction is expressed in basis points (e.g., 500 for 5%). This amount is then transferred directly to the receiver address as part of the sale transaction.

Implementing the interface correctly is crucial for interoperability. A well-formed RoyaltyInfo function must handle two key scenarios: returning valid data for tokens that support royalties and reverting or returning zero values for tokens that do not. Developers often extend this by adding administrative functions—like setRoyaltyInfo—to allow the royalty recipient or rate to be updated, though these are not part of the core interface. This design ensures backward compatibility, as wallets and marketplaces that do not support ERC-2981 can simply ignore the function without breaking the NFT.

The widespread adoption of RoyaltyInfo has significantly impacted the NFT ecosystem. It provides a trust-minimized and composable method for enforcing creator economics, reducing reliance on individual marketplace policies. Major platforms like OpenSea and LooksRare have integrated support, automatically routing payments based on the on-chain data. However, its effectiveness ultimately depends on marketplace compliance, as the standard is a specification for information, not a mechanism that can force payment on non-compliant platforms or peer-to-peer transfers.

The core of any royalty implementation is the RoyaltyInfo interface, a standardized function signature that marketplaces and other contracts call to retrieve payment details. Its canonical form, as defined by standards like EIP-2981, is function royaltyInfo(uint256 tokenId, uint256 salePrice) external view returns (address receiver, uint256 royaltyAmount). This function takes the token's ID and its sale price as inputs and returns the address to receive the royalty and the calculated royalty amount. This simple, predictable interface is what allows decentralized exchanges and NFT marketplaces to automatically discover and pay royalties without prior configuration.

A basic implementation of this interface involves storing the royalty recipient and basis points (where 100 basis points equals 1%) within the contract. For example, a contract might store address private _royaltyRecipient and uint96 private _royaltyBasisPoints. The royaltyInfo function would then calculate the amount by performing the operation (salePrice * _royaltyBasisPoints) / 10000 and return this value alongside the recipient's address. This fixed-percentage model is common, but the interface allows for more complex logic, such as tiered royalties or dynamic recipient addresses based on the tokenId.

Implementing RoyaltyInfo correctly is critical for interoperability. Major marketplaces like OpenSea and LooksRare query this function. A common practice is to have the function revert or return zero values for tokens where royalties are not applicable, providing clear on-chain signaling. Developers must also consider gas efficiency, as this function is called during sales transactions. More advanced implementations may use bit packing to store the recipient and basis points in a single storage slot or employ upgradeable proxy patterns to allow royalty parameters to be adjusted post-deployment, balancing immutability with practical business needs.

The RoyaltyInfo interface is a function signature, royaltyInfo(uint256 tokenId, uint256 salePrice), that returns a recipient address and a royalty amount. This simple, gas-efficient design allows any marketplace or smart contract to query an NFT contract to determine where and how much to pay in royalties for a secondary sale. By standardizing this single function, ERC-2981 creates a predictable, on-chain mechanism for royalty enforcement that is independent of any specific marketplace's implementation.

Prior to ERC-2981, royalty payment was a fragmented landscape where each marketplace implemented its own proprietary system, often relying on off-chain metadata. This led to inconsistencies, missed payments, and forced creators to manually register their works on each platform. The RoyaltyInfo interface solves this by moving the royalty logic directly into the NFT's smart contract, making it a verifiable and immutable part of the token itself. This shift represents a fundamental evolution from platform-dependent policies to contract-enforced creator rights.

The interface's parameters are intentionally generic. The tokenId allows for per-token royalty configurations (e.g., different royalties for different pieces in a collection), while the salePrice enables the calculation of a royalty amount as a percentage of the current transaction. The function returns two values: the receiver address (which can be a simple EOA, a multi-sig wallet, or a complex payment splitter contract) and the royaltyAmount (typically calculated as (salePrice * royaltyBasisPoints) / 10000). This flexibility supports a wide range of business models and payout structures.

Widespread adoption of the RoyaltyInfo interface by marketplaces and NFT projects has established it as the de facto standard for on-chain royalties. Its success has also spurred further innovation in the broader royalty landscape, including the development of more complex modular royalty systems (like EIP-6110), which can delegate logic to separate contracts, and the integration of royalty enforcement directly into core token standards like ERC-721C. The interface remains the foundational layer upon which these more advanced systems are built.