Magiceden
Magiceden royalties follow buyer preferences only where collection rules permit them
Magiceden royalties pay creators on NFT resales, with buyer choice available for eligible Solana collections. Full, Half and None describe how much of the creator-set royalty a buyer elects to pay. Collection enforcement can remove that choice. A royalty percentage in metadata specifies a requested payment; the NFT standard and trading program determine how the sale handles it. The creator royalty is separate from marketplace fees and network charges, so its setting governs only part of the purchase cost.
Key takeaway: Choosing None on an eligible purchase removes the voluntary creator payment while marketplace and network charges retain their separate rules.
Optional payments and collection eligibility
Royalty choice applies only when the collection and purchase path permit reductions; enforced rules can override a buyer’s saved preference even when other collections allow that setting. The item detail page displays the creator-set rate. Optional controls concern eligible Solana buying activity. The Ethereum Virtual Machine (EVM) and Bitcoin marketplaces have closed, while the Solana marketplace remains supported. Older cross-chain royalty descriptions therefore describe purchase routes no longer available through the marketplace. Eligibility belongs to the selected NFT and sale method, not simply the account setting.
What does full mean for the royalty amount?
Full means 100% of the creator-set royalty, Half means 50% and None means no voluntary royalty payment on an eligible purchase. The creator’s rate supplies the percentage of the NFT sale price. The selected share scales that royalty. Full does not mean paying the sale price again. When price and rate stay unchanged, Half reduces the royalty component by half. A higher sale price increases the royalty before rounding when the rate and selected share remain positive and unchanged. Marketplace charges and network fees retain their separate rules.
A listed purchase from preference to settlement
A buyer choosing Half for an eligible listed NFT with a nonzero royalty reduces the calculated royalty component while leaving the agreed listing price unchanged. Consider that preference change with the NFT price and creator rate held constant. Collection enforcement must permit the reduction before the comparison applies. The purchase preview connects the selected share to the intended charge. Successful settlement establishes what the recipients actually receive.
| Purchase stage | Royalty and payment details | Expected result | Possible mismatch |
|---|---|---|---|
| Review the NFT | Item rate and collection rules | Optional choice or required payment becomes clear | A saved preference conflicts with enforcement |
| Set a permitted preference | Full changed to Half | The voluntary royalty component decreases | Half is mistaken for half the NFT price |
| Review the purchase total | NFT price, royalty and applicable charges | The preview identifies the intended wallet payment | Other charges are mistaken for royalties |
| Authorize and submit | Purchase transaction with the applicable royalty | The wallet submits the signed purchase | A signature is mistaken for completed settlement |
| Reconcile settlement | Successful transaction and recipient transfers | Ownership and credited payments establish the outcome | The quote is mistaken for an individual creator’s receipt |
Halving the royalty does not guarantee a fixed reduction in the wallet’s total debit if other charges change. A successful transaction can distribute the royalty across several configured addresses, so one recipient’s credit can be smaller than the total royalty. Match payments to those recipients and their shares. A deposit into bidding escrow alone establishes funding, without proving that an NFT resale or royalty distribution occurred.
Transfer restrictions and royalty enforcement
For standard Token Metadata NFTs, recording a royalty rate in metadata does not enforce its payment. A trading program may honor the rate voluntarily.
MIP-1 collections exclude optional royalties under the marketplace’s collection policy.
Programmable NFTs, or pNFTs, let creators restrict which programs may transfer an asset. Their token accounts remain frozen outside authorized Token Metadata operations. A royalty-focused rule set can exclude trading programs that do not honor creator payments. Compatibility then depends on those permissions. Owners also need the authorization layer to permit their transfers. The program handles its temporary thaw and refreeze within the same operation, without requiring separate transactions for those internal changes.
Metaplex Core handles royalties through a Royalties plugin. It records the rate and recipient shares, with optional program allowlists or denylists. An allowlist permits listed programs; a denylist excludes specified programs. A configuration without transfer restrictions leaves royalties advisory. An asset-level royalty plugin can override a collection-level plugin. That makes the individual asset’s configuration relevant even when a collection has a general royalty policy.
Support for transfer restrictions does not mean every asset uses them; enforcement follows the actual rules attached to the selected asset.
Offer amounts and pool quotes
An item offer can show less than the entered amount because its display accounts for royalty and maker-fee deductions. The Include All Fees control changes whether the offer display includes charges. Read the royalty line alongside that setting to distinguish the entered budget from the displayed offer price. A bid funded through escrow still has its own terms. The shared funding balance does not identify the royalty an accepted sale will distribute.
Collection offers incorporate the selected royalty preference where reductions are allowed. In automated market maker (AMM) trades, the MMM program takes the royalty input from the pool configuration when the pool buys and from transaction inputs when it sells. The token type can override that input. MMM applies the full creator-set rate to pNFT trades. For Open Creator Protocol (OCP) assets, it applies the prescribed royalty, including a dynamic royalty when the policy configures one.
An AMM quote also reflects the pool’s pricing curve and applicable trading fees. The creator royalty forms one component of the effective price. A different quote alone does not identify a changed royalty: the NFT price or another charge may have moved. Pool purchases and pool sales have different payment directions, so an ordinary listing calculation cannot describe every pool trade.
Creator receipts and payout limits
Creator receipts follow the applicable royalty amount and recipient allocation, while the seller’s proceeds follow the sale method’s own fee treatment. The NFT owner selling an item and the creator receiving royalties can be different parties. Token Metadata creator shares specify how marketplaces divide royalties among the configured creator addresses. A share describes a portion of the royalty pool, not an additional royalty charged separately against the full sale price.
Small payments can encounter program-specific limits. MMM’s SOL royalty routine can skip a creator payment if the recipient’s resulting balance would not exceed Solana’s rent-exempt minimum. Its integer divisions discard fractions of a lamport, the smallest SOL unit. These conditions affect actual credits, so a displayed collection rate alone cannot establish each recipient’s receipt. The completed transaction’s transfers distinguish the calculated royalty from the amount an address received.
A creator considering stronger transfer restrictions must weigh royalty compliance against the trading programs the asset will permit.
Magiceden royalties questions, answered
Does a saved royalty preference carry over to another eligible collection?
A saved preference applies to future eligible collections until the buyer changes it through the collection settings. The saved choice remains subject to the next collection’s enforcement rules. A stored None or Half preference therefore does not establish that every subsequent purchase can reduce the creator payment.
Can paying the full royalty unlock collection benefits?
Full royalty payment can qualify for benefits only when a creator offers benefits tied to that payment. The royalty setting itself does not promise extra utility. Any benefit comes from the collection’s particular terms, and its eligibility conditions remain separate from the percentage used to calculate the creator payment.
When do creators receive royalties from an accepted NFT offer?
The sale program distributes applicable royalties when the accepted offer settles, subject to its payout conditions. Creating or funding an offer does not complete that sale. The transaction’s recipient transfers establish the credited amounts.
Do royalty payments transfer copyright in the NFT artwork?
A royalty payment does not itself transfer copyright in the artwork. Buying the NFT gives the purchaser ownership of the token’s electronic record; ownership of intellectual property requires an express grant in the purchase terms. The amount paid as a resale royalty does not determine the scope of that grant.
How can a creator change the royalty rate after minting?
Royalty updates require the authority and update permissions appropriate to the NFT standard. For Token Metadata assets, an authorized update can change the rate while the metadata remains mutable. For Metaplex Core, the relevant authority can update the Royalties plugin. Buying an NFT does not automatically grant control over its creator royalty configuration.
Does a verified creator entry prove royalties are enforced?
A verified creator entry in Token Metadata proves that the creator signed to verify that entry. It does not prove a trading program must collect royalties. Creator verification, recipient shares and transfer restrictions describe different properties. Enforcement requires the applicable asset rules and sale program to support the required payment.
What happens to royalties if a purchase transaction fails?
A failed Solana purchase transaction rolls back its NFT sale and royalty transfers. Solana still charges network transaction fees when execution fails. A wallet debit caused by that fee does not establish a creator receipt. A transaction signature alone does not prove the purchase succeeded.