Immutable Immutable routes NFT royalties and marketplace fees through order settlement
Immutable directs NFT royalties and marketplace fees to configured recipients when its Orderbook settles a trade. On Immutable Chain, collection royalty settings work alongside maker, taker and protocol fees. The payment breakdown determines what the seller receives and where the remaining trade payment goes.
Contents
Creator income and marketplace compensation
Creator royalties direct part of a secondary-sale payment to the recipient that the collection names. Marketplace fees compensate applications that create or fulfill orders. The protocol fee pays Immutable for its trading infrastructure. These allocations can coexist within a trade, although each follows its own configuration. A collection can choose whether to charge a royalty. Marketplace fee settings do not establish the creator's royalty terms, and a royalty setting does not determine a marketplace's compensation. The order carries the amounts and destinations that settlement needs.
| Fee component | Recipient and governing rule |
|---|---|
| Creator royalty | The collection's configured recipient; the Orderbook validates its royalty information for settlement. |
| Maker marketplace fee | The recipient configured when the originating marketplace submits the order. |
| Taker marketplace fee | The recipient configured by the marketplace that facilitates fulfillment. |
| Protocol fee | Immutable; the applicable protocol configuration determines the fee. |
The order connects fee rules with settlement
A signed order expresses the NFT and payment terms, while on-chain settlement executes the corresponding transfers. The collection supplies royalty information and marketplaces supply their fee allocations; Seaport provides the Orderbook's on-chain settlement mechanism. Sharing an order across participating storefronts preserves its originating maker fee. The application that fills the order can supply its own taker fee. This arrangement lets separate applications contribute to the same sale without assigning every payment to the storefront that displays it. Signing an order authorizes terms that a subsequent fulfillment transaction must satisfy; the signature itself does not transfer sale proceeds.
Royalty information comes from the collection
The NFT contract provides the royalty instructions that the trading system uses. An item's artwork or displayed collection name does not determine its payment destination.
The royalty query
ERC-2981 defines
royaltyInfo(tokenId, salePrice)
to return a royalty recipient and amount for the specified sale.
The function describes payment terms; settlement must perform the payment. This division explains why implementing the interface alone does not enforce royalties across every trading mechanism.
The amount for a sale
The calculation uses the supplied sale price and the collection's royalty logic. The query returns a royalty amount in the same currency unit as the supplied sale price. When an implementation uses basis points, 10,000 basis points represent the full calculation basis. Integer arithmetic can introduce rounding at the smallest currency unit. The contract's returned amount governs the royalty that the settlement integration evaluates, so a separately rounded display estimate can differ.
The payment destination
The returned recipient can be a wallet or a royalty splitter contract, and its address can differ from the seller's address. A splitter's distribution mechanism governs onward payments, so receipt by that contract does not confirm payment to its individual beneficiaries.
Operator restrictions support royalty enforcement
The Operator Allowlist restricts approval targets and transfer operators in collections that enforce it. The preset NFT contracts incorporate this control, while custom integrations must implement the required behavior. With the required owner approval, an allowed settlement contract can transfer the item through the supported trading mechanism. An unapproved contract can encounter a transfer restriction even when it understands the token standard. Compatibility therefore involves the collection's operator controls as well as its ERC-721 or ERC-1155 interface.
Royalty enforcement combines these transfer restrictions with validation of the trade's royalty terms. The allowlist controls operator permissions; it does not inspect artwork or certify an item's authenticity. A marketplace's ability to display a listing does not establish that its proposed settlement contract has permission to transfer the NFT.
Maker fees remain attached to the originating order
The marketplace that creates an order sets its maker fee when it submits the order. That fee remains attached when another participating marketplace fills the listing. The arrangement compensates the application that originated the trading opportunity, even when fulfillment occurs elsewhere. Once the marketplace submits the maker fee, changing that fee requires canceling and recreating the order. A different taker fee does not edit the maker fee that the existing order already carries.
The words maker and taker describe order activity, not permanent buyer and seller identities. A seller creates a listing, while a buyer creates a bid. The party that fulfills the existing order takes the other side.
Fulfillment supplies the applicable fee breakdown
Fulfillment preparation returns validated fee information for the transaction that the application intends to submit. Those amounts can differ from an earlier listing query. The royalty calculation undergoes another check. Applicable protocol settings can change the final breakdown.
The SDK's
fulfillOrder
operation returns the order information and required actions together with an expiration. That expiration concerns the prepared fulfillment authorization, not the NFT's lifetime or the original listing's expiration.
A fulfillment transaction using expired authorization fails on-chain. The application must request fresh fulfillment data. Reusing an earlier display amount does not refresh the authorization.
Marketplace interfaces should present the validated breakdown before authorization. A buyer's payment total and the seller's proceeds describe different amounts. The settlement transfers specify each recipient's allocation, so a label such as listing price needs context before it can explain either amount.
Partial fills require the full-order fee basis
ERC-1155 orders can support purchases of part of the listed quantity. For ERC-1155 partial fills, the Orderbook expects the taker fee input for the complete order and prorates it to the executed quantity. Reducing the input fee for the requested quantity before submission would apply the reduction twice. This affects marketplace compensation, even when the storefront displays an otherwise correct quantity and payment currency.
ERC-721 orders represent a unique NFT and do not support the same partial-fill behavior. For an ERC-1155 trade, the actual filled quantity determines the corresponding fee allocation. The remaining order quantity concerns later trades. A partial-fill payment record shows the proceeds corresponding to that execution.
A royalty splitter separates collection payment from distribution
A splitter allows a collection to direct its royalty to one contract that allocates funds among several recipients. The collection's royalty calculation determines the payment into that contract. The splitter's shares determine how its recipients divide those funds. Changing an internal share does not itself change the royalty percentage charged on a sale. The preset splitter accumulates receipts and distributes them through
releaseAll(). Settlement into the splitter and release to its beneficiaries can therefore occur in separate transactions. A balance in the splitter can consequently represent received royalties that recipients have not yet collected.
The preset royalty splitter distributes an ERC-20 token only if its token allowlist includes that token. A caller with release permission specifies the ERC-20 tokens to release by their contract addresses. The call also releases native currency; without ERC-20 addresses, it releases only native currency. An authorized allocation update changes the split that applies to unreleased funds. Releasing outstanding funds before an allocation change preserves the previous split for those payments.
Payment units and records determine the received amount
Orderbook fee entries use integer amounts in the payment currency's smallest unit. A human-readable decimal requires that currency's precision; interpreting a raw integer as a whole-token amount can materially misstate a fee. A marketplace that calculates a percentage fee must submit the resulting integer amount, not the percentage itself. The payment currency also identifies which balance a recipient receives. Gas sponsorship addresses execution costs under its own conditions; it does not define the creator royalty or the maker and taker allocations.
Successful settlement records establish the NFT transfer and associated payments. A signature establishes authorization, while a submitted transaction identifier does not establish whether settlement succeeded. For royalty accounting, the destination matters as much as the amount. The trade's royalty transfer into a splitter records payment to that contract. The subsequent distribution records establish the individual recipients' payouts. Order updates can arrive asynchronously after on-chain confirmation.
Legacy fee rules have a separate scope
Immutable X closed on 11 February 2026; its fee and recipient rules differed from the Immutable Chain Orderbook's rules. Its historical limits do not establish what the newer trading system supports. For an NFT on Immutable Chain, the applicable collection contract and settlement configuration determine royalty routing. If a payment record belongs to the closed network, its original trading rules govern the interpretation of that historical payment.
Frequently asked questions about Immutable
Can one marketplace receive both maker and taker fees?
One marketplace can receive both fees when it facilitates order creation and fulfillment and configures both allocations. The maker fee compensates its role in originating the order, while the taker fee compensates fulfillment. The shared storefront identity does not merge those fee categories or replace the collection's royalty.
Does moving an NFT between wallets automatically pay a creator royalty?
An ordinary NFT transfer does not automatically trigger a royalty through ERC-2981. The standard reports payment information for a supplied sale price and does not establish whether a transfer represents a sale. The collection's transfer permissions still apply, including operator restrictions where the contract enforces them.
Which currency does a creator receive from an NFT sale?
An ERC-2981 royalty uses the same currency unit as the sale price supplied to the royalty calculation. A royalty on an ERC-20 sale does not automatically convert into the network's native token. If the recipient is a splitter, its support for that payment token also governs onward distribution.
Is royalty information identical for every token in a collection?
Royalty terms can vary by token ID when the collection implements that behavior. ERC-2981 permits different calculations for individual tokens; it does not require every collection to offer them. The query for the relevant token and sale price establishes that token's royalty terms.
Who can inspect the recipients of a royalty split?
Anyone can inspect the recipient addresses and shares that the splitter stores on-chain. That public configuration describes the allocation between blockchain accounts. It does not, by itself, establish the legal names, email addresses or contractual rights of the people or organizations that control those accounts.
Are marketplace trading fees payable when settlement reverts?
A reverted on-chain trade rolls back the royalty and marketplace transfers attempted within that transaction. Network execution can still consume gas. A rejected wallet prompt and an included transaction that reverts are different events, so a purchase error alone does not establish whether an execution cost occurred.
Updated on