Opensea royalties depend on seller choices and collection enforcement
Opensea royalties are optional unless the creator has enabled supported enforcement for the collection. The marketplace calls these payments creator earnings. With optional earnings, the NFT owner decides whether to include them when listing an item or accepting an offer. Enforced earnings require a compatible contract and an active enforcement configuration. A preferred percentage alone does not prove a payment is compulsory. When a sale includes earnings, the creator's share comes from the item price the buyer pays. Enforcement can restrict resale venues to integrations able to satisfy the collection's transfer rules.
Optional earnings and enforced collection sales
A collection's active enforcement state determines whether a seller can adjust creator earnings or must include the required payment in a sale. Contract eligibility and enabled enforcement describe different states. A compatible collection can have enforcement switched off.
Seller-selected earnings
Optional earnings let the seller include the creator's preferred share when creating a listing or accepting an offer. The seller can adjust that percentage. These collections have no enforced minimum creator earnings percentage. The collection's preferred rate expresses a request; the actual sale terms determine the payment.
Enforced earnings
Enforced collections require the configured earnings through their supported sale mechanism. The earnings toggle appears on and unavailable for editing. Checkout reflects the enforced share. A seller cannot remove it using the optional-earnings control.
Which collections support enforced creator earnings?
Collections support this enforcement method when their NFT contracts provide compatible transfer-validation functionality and their owners configure the required enforcement settings.
Studio deployment cutoff
Studio collections deployed after 10:00am PT on April 2, 2024 support the enforcement option. Earlier Studio deployments support optional earnings without that retroactive enforcement option. The deployment cutoff concerns this contract configuration, not the date somebody later lists an NFT for resale.
Custom contract compatibility
Compatible custom ERC721-C and ERC1155-C contracts can support enforced earnings. Their owners must configure enforcement after deployment. An existing custom contract can acquire compatible functionality through an upgrade only if its architecture and permissions actually support that upgrade.
An immutable incompatible contract cannot gain transfer-validation functionality through a collection-page edit. Changing the displayed earnings percentage changes the requested payment, not the contract's capabilities. Upgrade work must preserve the existing contract's storage layout and authorization rules.
ERC-2981 royalty amounts and recipients
ERC-2981 gives compatible applications a standard way to obtain an NFT's royalty amount and recipient for a specified sale price.
ERC-2981 supplies royalty payment information without enforcing the payment.
Its royaltyInfo() function returns a recipient address and an amount. An application honoring the royalty must arrange its payment.
A contract can expose collection-wide royalty information or different information for individual token identifiers, depending on its implementation. The standard does not give every collection owner an editing interface. Royalty support also does not establish the marketplace's enforcement state. Transfer restrictions require additional contract behavior beyond returning an amount and address.
Transfer validation through Seaport
Seaport supports enforced earnings by connecting compatible NFT transfers to a validator and an authorization tied to the sale's payment terms.
Seaport 1.6 introduced hooks used by this integration. A configured NFT transfer validator can reject a transfer lacking the required authorization. The sale integration supplies that authorization through a zone, a contract responsible for checking restricted order conditions.
The supported integration authorizes a particular operator, a token identifier or a token identifier with a specified quantity, depending on the contract's validation function. The NFT checks the validator during transfer. This ties permission to the relevant transfer instead of granting unrestricted permission to every sale involving the collection.
Custom integrations must construct compatible orders and provide the required authorization data. Ordinary token approvals do not satisfy these additional conditions. A rejected transfer does not complete the intended royalty-paying sale. Removing the creator payment from an order cannot satisfy an active enforcement configuration requiring that payment.
The royalty share within a sale price
A percentage-based royalty uses the sale price, so selling below the original purchase price can still produce creator earnings for the recipient.
Creator payments and seller proceeds
The royalty amount equals the relevant sale price multiplied by the applicable royalty fraction. The seller's purchase cost does not enter that calculation. For an included creator payment, the buyer pays the item price and part of that price goes to the royalty recipient. The seller's net proceeds also reflect any marketplace deductions.
Marketplace charges and gas
The marketplace's service fee and blockchain gas pay different recipients and cover different functions. Gas pays for transaction processing; it does not replace creator earnings. A sale's fee breakdown shows its payment allocation. A marketplace-fee waiver does not, by itself, establish a royalty exemption.
Restoring omitted earnings in an unsigned listing
A seller can restore omitted optional earnings by adjusting an unsigned listing draft before authorizing its proposed sale terms.
In this hypothetical example, a seller prepares a listing for 73 units of its sale currency. The collection has optional earnings, the intended creator share is 4.6% and the currency supports three decimal places. The seller notices earnings are off before signing.
The seller turns earnings on and sets the intended percentage. Multiplying 73 by 0.046 gives 3.358 units for the creator. The remaining 69.642 units precede any marketplace deductions. A sale breakdown showing that creator share confirms the draft now includes the intended payment.
This correction changes the proposed allocation without submitting a sale or altering the collection contract. A completed sale must execute those terms before the creator receives funds. If the collection has enforced earnings, the locked control removes this optional choice. An already signed order falls outside this draft-only correction.
Royalty recipients and completed sale payments
Royalties go to the payout recipient specified in the completed sale, which may differ from the wallet selling the NFT or managing the collection.
Seaport orders describe required assets and their recipients. Those terms direct settlement transfers, including royalty payments the sale includes. Signing a listing authorizes terms without distributing sale funds. A sale transaction identifier also needs its successful execution status before it establishes completed payment.
Payment records identify the recipient, asset and transferred amount. An NFT ownership change alone supplies none of those monetary details. A creator's preferred earnings setting can explain the intended allocation, while the settled sale records establish the allocation it actually executed.
Marketplace compatibility and validator changes
Enforcement narrows resale compatibility to supported settlement integrations, so another marketplace must support the collection's transfer rules before its sales can succeed.
This enforcement method supports sales through the marketplace's compatible Seaport integration and other venues powered by Limit Break's Payment Processor. Other venues can require their own earnings configuration. An NFT appearing in another marketplace's catalogue does not establish that its sale integration can satisfy the active validator.
Changing transfer validators also affects existing custom allowlists and security policies. When switching to the supported enforcement validator, the owner must reconfigure relevant rules from the previous validator. Those policies do not automatically carry over merely because the NFT remains in the same collection.
A collection-wide validator change affects transfer permissions for its NFTs. A seller selecting optional earnings changes that sale's payment allocation. The collection owner controls the contract configuration; a resale holder cannot obtain those powers merely by owning one NFT.
The end of Operator Filter enforcement
The marketplace's earlier royalty rules used an Operator Filter to restrict venues without creator-fee support. The Operator Filter stopped blocking marketplaces on August 31, 2023. The announced legacy enforcement period for existing filtered collections and existing non-Ethereum collections ran through February 29, 2024. Later ERC721-C compatibility introduced a separate enforcement mechanism. A collection's present configuration determines its treatment; an old enforcement label cannot establish what a new sale requires.
Mint proceeds and transfers between wallets
A primary mint pays for a newly created NFT, while resale royalties allocate part of a later sale to the creator's payout recipient.
Studio drop payouts and resale earnings use separate settings. Drop Earnings directs proceeds from mint sales after the applicable primary-sale fee. Creator Earnings controls the collection's resale earnings settings. Setting a mint payout address does not automatically establish enforced royalties for later sales.
A gift or movement between the same owner's wallets can change which wallet holds the NFT without creating sale proceeds. ERC-2981 does not determine whether a transfer represents a sale. The NFT contract's transfer restrictions still govern whether a proposed transfer can execute. Royalty information alone neither creates a sale price nor guarantees an unrestricted transfer.
Opensea royalties - your questions answered
-
Can a collection collaborator edit the royalty recipient?
- A collection collaborator cannot edit creator earnings recipient addresses or percentages in Studio. Collaborator access permits other collection-setting changes, but it does not confer these earnings controls.
-
Does paying NFT royalties give me copyright ownership?
- Paying creator earnings does not automatically transfer copyright in the NFT's artwork. The creator's or seller's applicable terms determine the rights a buyer receives, including any commercial-use permission. The royalty percentage does not measure or define the scope of those rights.
-
How can unequal royalty settings across marketplaces affect creator earnings?
- Earnings matching can reduce the platform's royalty percentage when a creator's contract requires a higher share there than on other marketplaces. The policy concerns unequal earnings requirements across venues. Configuring the same percentage across those venues avoids that particular mismatch; it does not establish universal enforcement.
-
Is creator earnings enforcement removable after activation?
- A collection owner can remove supported enforcement through the Remove Enforcement control in Studio's Creator Earnings settings. The owner must approve the request. For the transaction-building API, the caller's wallet must own the contract onchain. The API returns transactions for the owner to sign and submit. Those transactions remove the validator only once they are mined and execute successfully.
-
Must an ERC-2981 royalty use the sale's payment currency?
- An ERC-2981 royalty must use the same unit of exchange as the sale price supplied to the royalty calculation. The returned amount shares that denomination. The standard does not prescribe a particular cryptocurrency, and converting the amount into another currency would change the payment it specifies.
-
Can ERC-2981 royalties reach several recipients through a receiving contract?
- An ERC-2981 recipient can be a receiving contract handling further payment splitting. The standard returns one recipient address and leaves distribution among beneficiaries to that recipient's implementation. Receipt by the contract does not establish onward payments to beneficiaries.
-
When do very small ERC-2981 royalties round up or down?
- ERC-2981 permits an implementation to round a fractional royalty calculation up or down to an integer amount. That integer uses the same units as the supplied sale price. The contract's calculation determines its rounding behavior; the standard does not prescribe a universal direction.