Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
NFT royalties are secondary-sale payments designated for an NFT creator or another rights holder. On OpenSea, the feature is called creator earnings. A typical royalty might be 5% of a resale price, but the percentage is only one part of the system: the NFT contract may report the amount, while the marketplace or sale contract must actually send the money.
That distinction explains why royalties are not automatically guaranteed on every marketplace. The result depends on the NFT standard, the collection’s contract, the marketplace’s payment logic, and—where applicable—a transfer-enforcement system.
What an NFT royalty is
An NFT royalty is a percentage of the price paid when an NFT is resold. If an NFT sells for 1 ETH and the configured royalty is 5%, the designated recipient is entitled to 0.05 ETH, assuming the marketplace honors the royalty.
The recipient does not have to be the original artist’s personal wallet. It could be a creator, studio, rights holder, community treasury, or another address selected by the collection owner or contract administrator.
#1 Best Overall
| Term | Meaning |
|---|---|
| Royalty or creator earnings | A percentage of a secondary sale price designated for a creator or rights holder. |
| Royalty recipient | The wallet address that receives the royalty payment. |
| Sale price | The amount supplied to the royalty calculation, such as 1 ETH or 500 USDC. |
| Optional royalty | A payment the buyer or seller can decline, depending on the marketplace. |
| Enforced royalty | A payment condition supported by a marketplace or transfer-control system that can prevent or restrict a sale when the required payment is missing. |
How the payment flow works
An ordinary NFT transfer does not inherently mean that a sale occurred. The ERC-721 or ERC-1155 transfer function generally moves a token from one address to another; it does not automatically identify a price, calculate a percentage, and pay a creator.
The common flow is:
- A seller lists an NFT through a marketplace.
- A buyer accepts the listing and supplies the sale price in the marketplace’s supported currency.
- The sale mechanism obtains the collection’s royalty information, if available.
- It calculates the royalty from the supplied sale price.
- It sends the royalty amount to the configured recipient and sends the remaining amount to the seller, after any other applicable fees.
- The NFT is transferred to the buyer.
ERC-2981 standardizes the information lookup in step three. Its royaltyInfo(tokenId, salePrice) function returns two values: the recipient address and the royalty amount. It does not itself transfer funds. The marketplace or sale contract must implement the payment.
That is why the claim that “ERC-2981 sends royalties to the creator” is inaccurate. ERC-2981 is a royalty-information standard, not an enforcement or payment standard.
What ERC-2981 specifies
An ERC-2981-compatible contract reports a royalty as a percentage of the sale price passed to royaltyInfo(). The calculation must use the same currency unit as the sale price. For example:
- An ETH-denominated sale produces an ETH-denominated royalty.
- A USDC-denominated sale produces a USDC-denominated royalty.
- A contract should not assume every sale is paid in ETH.
The standard does not require an NFT to be ERC-721 or ERC-1155, although it is designed to work with both. A marketplace can detect support through ERC-165. The ERC-2981 interface identifier is:
0x2a55205aRoyalty rules may vary by token ID or by predictable contract state, such as transfer count or time-based conditions. They still need to represent a percentage of the supplied sale price rather than an unrelated fixed amount. Rounding is allowed when the percentage does not produce a whole number of the smallest currency unit.
A Solidity example with OpenZeppelin
OpenZeppelin Contracts 5.x provides an ERC2981 implementation. The import is:
Recommended Free Tools
import "@openzeppelin/contracts/token/common/ERC2981.sol";Its default fee denominator is 10,000, so royalty rates are normally expressed in basis points:
| Fee numerator | Royalty rate |
|---|---|
500 |
5% |
750 |
7.5% |
1000 |
10% |
The main configuration functions are:
_setDefaultRoyalty(address receiver, uint96 feeNumerator)
_setTokenRoyalty(uint256 tokenId, address receiver, uint96 feeNumerator)
_deleteDefaultRoyalty()
_resetTokenRoyalty(uint256 tokenId)
royaltyInfo(uint256 tokenId, uint256 salePrice)A default royalty applies across the collection. A token-specific royalty overrides that default for the selected token. Resetting the token-specific setting allows the token to use the default again.
OpenZeppelin rejects a zero address as the receiver and rejects a fee numerator greater than the fee denominator. Its implementation technically permits a 100% royalty. That would assign the entire sale price to the royalty recipient and leave zero for the seller, so marketplace code must not assume that a seller payment is always positive.
Why royalties are not automatically guaranteed
ERC-2981 can tell a marketplace what to pay, but a marketplace can choose not to use that information. A private wallet-to-wallet transfer is also not automatically a royalty-bearing sale. The token contract may see only a transfer, not an agreed price or a resale.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsThere are several separate questions to ask:
- Does the contract expose royalty information? If not, a marketplace may have no standardized rate to read.
- Does the marketplace read it? Support for ERC-2981 is a marketplace feature, not a consequence of deploying an NFT.
- Does the sale mechanism pay it? Reading a recipient and amount does not transfer the funds.
- Can the collection enforce payment? Transfer restrictions can impose conditions in supported marketplaces, but they are not universal across all marketplaces and transfer routes.
A royalty percentage written in collection metadata is therefore not the same thing as a contractual guarantee. Metadata can inform a marketplace, while enforcement requires code and a sale route that honors the rule.
OpenSea creator earnings
OpenSea currently calls royalties “creator earnings.” To configure them in OpenSea Studio:
- Open OpenSea Studio.
- Select the collection.
- Open Creator Earnings.
- Choose Add earnings payout address and percentage.
- Enter the payout address and percentage, then save the setting.
Only the collection owner can set creator earnings. OpenSea’s current maximum setting is 10%.
Optional versus enforced earnings on OpenSea
With optional earnings, the seller decides whether to pay the creator’s preferred amount. At checkout, the buyer or seller can see the setting, but the payment is not necessarily forced by the transfer.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →For an eligible enforced collection, the creator-earnings toggle is automatically on and greyed out at checkout. OpenSea uses ERC721-C or ERC1155-C compatibility together with Seaport v1.6 and Seaport Hooks to impose transfer conditions, such as requiring the creator payment before the NFT transfer proceeds.
OpenSea Studio collections deployed after April 2, 2024, at 10:00 a.m. PT may be eligible for enforcement. In the collection’s Creator Earnings tab, the owner can select Enforce earnings and approve the wallet signature request. A compatible custom ERC721-C or ERC1155-C contract can be configured through the same Studio section.
If Enforce earnings is missing, OpenSea says the contract is not compatible with the required ERC721-C or ERC1155-C system. Older OpenSea Studio collections deployed before that date and time have optional earnings only. A non-upgradeable custom contract that lacks the required compatibility also cannot simply be upgraded through the OpenSea interface.
To undo the setting, open Creator Earnings, choose Remove Enforcement, and approve the wallet request.
Free tools Windows power users keep installed
One-click scans. No signup required.
What OpenSea enforcement does—and does not—cover
OpenSea’s enforcement is not a universal blockchain rule. OpenSea says this method supports OpenSea and marketplaces powered by LimitBreak’s Payment Processor, including Magic Eden according to its current help documentation. A different marketplace needs its own compatible enforcement mechanism.
OpenSea also has an earnings-matching policy. For example, if a collection is configured for 5% on OpenSea but 3% elsewhere, OpenSea may reduce its earnings percentage to match the lower configured amount. The percentage shown in a marketplace should therefore be checked rather than assumed from the collection’s original setting.
Magic Eden and optional royalties
Magic Eden’s behavior depends on the blockchain and collection standard. On its Solana marketplace, the creator sets the royalty amount, and the amount is paid after a sale when the trader honors it or the collection’s metadata or enforcement requires it. The royalty percentage is displayed on the item page.
For Solana collections that have not adopted MIP-1, Magic Eden’s optional-royalties feature lets buyers choose:
- Full: 100% of the configured royalty
- Half: 50%
- None: 0%
The default is Full. This feature applies on the BUY side: the seller receives the list price minus Magic Eden’s platform fee, while the buyer pays the list price plus the selected royalty amount.
To change the preference, open a collection page, select the settings icon in the bottom-right corner, and choose None, Half, or Full under Royalty options. The selection remains the preference for future collections until changed.
Magic Eden says this optional-royalties feature does not apply to its Ethereum, Polygon, Base, or Bitcoin Ordinals marketplaces. Those marketplaces respect the royalties set by the collections. Its current help page also lists a 0% listing fee and a 2% marketplace fee on all transactions; those are marketplace fees, separate from creator royalties.
OpenSea contract-level enforcement for developers
Developers building an eligible custom contract need more than an ERC-2981 implementation. OpenSea documents an ICreatorToken interface containing:
interface ICreatorToken {
event TransferValidatorUpdated(address oldValidator, address newValidator);
function getTransferValidator() external view returns (address validator);
function getTransferValidationFunction() external view
returns (bytes4 functionSignature, bool isViewFunction);
function setTransferValidator(address validator) external;
}The contract must set StrictAuthorizedTransferSecurityRegistry as its transfer validator to become eligible for creator-earnings enforcement through Seaport. Any lists or security policies held by a previous validator need to be configured again on the new validator.
OpenSea documents validator signatures including:
validateTransfer(address caller, address from, address to, uint256 tokenId)
validateTransfer(address caller, address from, address to, uint256 tokenId, uint256 amount)
validateTransfer(address caller, address from, address to)
applyCollectionTransferPolicy(address caller, address from, address to)The token contract calls the applicable validator from its transfer hook, and getTransferValidationFunction() returns the matching selector. Seaport orders for configured creator tokens must use either FULL_RESTRICTED or PARTIAL_RESTRICTED order type and a SignedZone zone.
Common royalty mistakes
- Assuming every transfer is a sale: A gift, escrow movement, or wallet reorganization is not automatically a royalty event.
- Assuming ERC-2981 makes payment automatic: It only returns a recipient and amount.
- Using a fixed royalty amount: ERC-2981 calculations are based on the supplied sale price.
- Assuming ETH is always the payment currency: The royalty must use the sale’s currency or token unit.
- Confusing mint revenue with royalties: Royalties normally refer to secondary sales. Primary drops have separate economics; for example, OpenSea documents its drop fees separately from creator earnings.
- Expecting OpenSea enforcement everywhere: Enforcement depends on the marketplace and its supported payment or transfer-control system.
- Using an inaccessible payout wallet: Changing a payout address requires collection ownership or the relevant contract authority.
- Ignoring extreme rates: A 100% royalty is technically possible in OpenZeppelin’s implementation and can break sale logic that assumes money remains for the seller.
How to check a collection before buying or selling
- Look at the marketplace item or collection page for the displayed royalty or creator-earnings percentage.
- Check whether the marketplace labels the payment optional or enforced.
- Identify the sale currency. A royalty quoted for an ETH sale should not be casually applied to a USDC sale.
- For a contract-level review, inspect whether the contract supports ERC-2981 and query
royaltyInfo(tokenId, salePrice). - Do not treat the returned amount as proof that funds will be paid. Confirm that the marketplace’s sale mechanism actually honors it.
- If enforcement matters, verify the supported marketplace list and the collection’s transfer-validator or equivalent configuration.
FAQ
Are NFT royalties automatic?
No. ERC-2981 can report the royalty recipient and amount, but the marketplace or sale contract must send the payment. A transfer-control system may enforce payment on supported marketplaces, but enforcement is not universal.
Does ERC-2981 send money to the creator?
No. The contract’s royaltyInfo() function returns an address and calculated amount. The marketplace or other sale mechanism performs the actual payment.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Do royalties apply to every NFT transfer?
No. ERC-2981 is intended to describe royalties for sales. A private wallet-to-wallet transfer does not automatically include a royalty payment unless another enforcement mechanism controls it.
What is a normal NFT royalty percentage?
There is no universal rate. The collection sets its own percentage, subject to marketplace or contract limits. OpenSea’s current creator-earnings setting has a maximum of 10%.
Can NFT royalties be paid in USDC instead of ETH?
Yes, if the sale is denominated in USDC and the sale mechanism supports it. ERC-2981 requires the royalty calculation to use the same unit of exchange as the supplied sale price.
What is the difference between optional and enforced royalties?
With optional royalties, a marketplace participant can decline or reduce the preferred payment. Enforced royalties use marketplace or transfer-control rules that can condition or block a supported sale when the required payment is not made.
Can an NFT have a 100% royalty?
Technically, yes. OpenZeppelin’s ERC-2981 implementation permits a fee equal to the full denominator. The royalty recipient would receive the entire sale price, leaving nothing for the seller, so marketplace logic must handle that case.
The Bottom Line
NFT royalties are best understood as a coordinated payment rule, not an automatic property of every token transfer. ERC-2981 standardizes how a contract reports the recipient and percentage-based amount; the marketplace still has to pay it. Optional royalties depend on user choice, while enforced royalties depend on compatible transfer and sale infrastructure—and neither should be assumed to work across every marketplace.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
