NFT Royalties Setup on Magic Eden

Setup of NFT Royalties on Magic Eden

The royalty wars of 2022-2023 destroyed expectations of most NFT projects: Blur introduced optional royalties, trading volume fled OpenSea, and many collections lost the primary source of team income. Magic Eden went through several iterations of royalty policy. Now the situation has stabilized, but royalty setup is not one button—it's a set of decisions at the contract and platform level.

How Royalties Work Technically

EIP-2981—On-chain Standard

EIP-2981 adds a single function: royaltyInfo(uint256 tokenId, uint256 salePrice) returns (address receiver, uint256 royaltyAmount). The marketplace calls it before each transaction, gets the recipient address and amount.

This is an advisory standard—the marketplace can ignore the response. OpenSea, Magic Eden (in enforced mode), and LooksRare respect it for compatible collections. Blur—no, unless the contract uses transfer blocking.

Implementation via OpenZeppelin:

import "@openzeppelin/contracts/token/common/ERC2981.sol";

contract MyNFT is ERC721, ERC2981 {
    constructor() {
        // 5% royalties to team address
        _setDefaultRoyalty(teamAddress, 500); // 500 = 5% (basis points)
    }
}

Different tokenIds can have different royalties via _setTokenRoyalty(tokenId, receiver, feeNumerator).

Magic Eden: Ethereum vs Solana

On Ethereum, Magic Eden reads EIP-2981 and displays royalties in the UI. When creating a listing, the user sees that X% goes to the creator. Payment happens automatically through the marketplace contract on sale.

On Solana, the mechanics are different. Royalty is set in NFT metadata via the seller_fee_basis_points field (0-10000, where 10000 = 100%) and a creators array with each creator's shares. This is part of Metaplex Token Metadata standard. Magic Eden reads this data and pays royalties on sale through its program.

For Solana collections, royalty setup = correct metadata on mint. You can't change royalties post-mint (immutable metadata) or only via update authority if the collection is mutable.

Enforced Royalties vs Optional

The only technical way to force royalty payments is to restrict NFT transfers only through approved marketplaces. This is implemented via _beforeTokenTransfer hook: check that from or to is an approved operator from the allowlist.

Magic Eden supports such collections via its operator filter. OpenSea launched OperatorFilterRegistry in 2022, then abandoned it in 2023. The most current approach—custom allowlist of operators in the contract.

Tradeoff: strict royalty enforcement reduces liquidity (can't sell P2P) but guarantees team income. Without enforcement—royalties are optional and depend on marketplace goodwill.

Setup on Magic Eden

For Ethereum collections: A contract with EIC-2981 is automatically detected. In Magic Eden Creator Hub dashboard, specify the collection address and verify ownership via signature. Royalties are displayed from the contract.

For Solana collections: Via Metaplex Sugar CLI or manual setup: set sellerFeeBasisPoints and creators on deploy. Magic Eden verifies the collection through a submission system—a verified badge is needed for full royalty display.

Timeline Estimates

Setting up EIC-2981 in a new contract—several hours. Adding royalties to an existing contract without EIC-2981—only possible via upgrade (if upgradeable) or deploying a new contract with migration. Collection verification on Magic Eden—1-3 business days on their side.