Looksrare royalties depend on creator-fee settings even when ERC-2981 supplies a recipient

Creator-fee settings connect recipient information to settlement

The NFT contract or royalty registry identifies a potential recipient, while the exchange’s creator-fee manager determines the amount that settlement includes. These components answer different questions: who the collection designates, how the exchange calculates creator fees, and what the sale actually pays. A collection can publish royalty information even when an exchange applies no creator payment. NFT trading supplies the sale price that a royalty calculation needs; a transfer of NFT ownership alone supplies no such price.

Looksrare V2 separates the creator-fee manager from the core exchange. The exchange owner can replace that manager, so the available manager implementations do not establish which one governed a particular sale.

An unset creator-fee manager leaves the creator amount at zero in V2’s execution logic.

V2 removed the earlier creator rebate

The October 27, 2022 policy replaced default creator royalties with fee sharing, while allowing buyers to add an optional royalty payment. Under the new sale strategies, the creator allocation was 25% of the 2% total fee, equivalent to 0.5% of the sale price. Collections needed a receiving address through the royalty registry or ERC-2981 to receive that allocation. Without a recipient, the total protocol fee fell to 1.5%. These figures describe that historical arrangement.

V2 launched on April 6, 2023, with a 0.5% protocol fee and removed creator rebates at launch. V2’s documented fee configuration specifies a 0% creator fee. The older creator allocation and V2’s protocol fee therefore have different recipients despite sharing the same percentage.

What does ERC-2981 return for an NFT sale?

ERC-2981 returns a recipient address and a royalty amount for a particular token ID and sale price through royaltyInfo(tokenId, salePrice). The collection contract supplies the implementation. A direct lookup needs the collection’s contract address, the relevant token ID, and a price expressed in the sale currency’s units. The result identifies the address that the contract designates for that item and the amount that it requests for that price.

ERC-165 interface detection exposes ERC-2981 support through supportsInterface(0x2a55205a). The interface identifier describes a capability; it does not certify the returned address’s human identity.

The read function returns payment information without transferring money or recording a completed royalty payment.

Sale prices and royalty amounts share currency units

The sale price passed to ERC-2981 and the returned royalty amount use the same monetary unit, including its smallest-unit representation. The function receives an integer price without a currency address, so it cannot independently recognize the asset or its decimals. Software must retain that context when displaying the result. An amount expressed in the smallest units can look much larger than its human-readable equivalent. Converting the price before the lookup, then interpreting the response in a different unit, produces an incorrect payment figure.

For a percentage-based implementation, the royalty equals the supplied price multiplied by the applicable fraction, subject to integer rounding. ERC-2981 permits rounding upward or downward when division leaves a remainder.

Registry precedence can change the selected recipient

The recipient returned directly by an NFT contract can differ from the recipient that Looksrare’s full-royalties manager selects for a trade. CreatorFeeManagerWithRoyalties consults RoyaltyFeeRegistry before falling back to ERC-2981 when the registry returns no recipient. The registry describes collection-level royalty information, whereas an ERC-2981 implementation can vary its response by token ID. A nonzero registry recipient therefore changes which information this manager uses, even when the NFT also supports the standard.

View image file

The manager’s viewCreatorFeeInfo(collection, price, itemIds) exposes its resolved recipient and amount. A direct NFT lookup answers what the NFT contract requests; the manager lookup answers what that manager resolves. Neither read establishes that the exchange enabled the manager or transferred its calculated amount.

Full royalties and fixed rebates calculate different amounts

CreatorFeeManagerWithRoyalties uses the royalty amount that the registry or eligible ERC-2981 lookup returns. CreatorFeeManagerWithRebates uses recipient information to calculate a fixed rebate instead. In the rebate implementation, STANDARD_ROYALTY_FEE_BP equals 50 basis points, or 0.5% of the transaction price. Its ERC-2981 branch reads the recipient and ignores the royalty amount returned by the NFT. A collection’s requested percentage therefore does not determine the rebate calculation. Both implementations first consult the registry, but they use the resulting information differently. These contracts describe available calculation models. Their presence does not mean that the zero-creator-fee V2 configuration pays either amount.

Execution-time settings explain changing royalty responses

Royalty information can change between order creation and execution when the collection implementation or registry permits updates. ERC-2981 also allows token-specific royalty calculations, so querying a different token ID can produce a different answer. A current response cannot establish the recipient or amount that applied to an older trade. Historical contract reads use the state associated with their selected block; they require a provider that can serve that state.

Keep the collection, token ID, sale price, and block context together when comparing responses. Changes within a block can require closer examination of the transaction’s execution, because a block-level read is not a snapshot of every intermediate operation.

Signing an order does not freeze external royalty settings that its execution later consults.

Bundle compatibility follows the selected fee manager

A bundle’s royalty requirements depend on the manager that the exchange actually invokes, with different checks for full royalties and fixed rebates. For an ERC-2981 bundle, the full-royalties manager queries each included token ID using the same transaction price. It rejects a bundle when the returned recipients or amounts differ. A collection name alone therefore cannot establish compatibility; token-specific royalty settings can differ within the same collection.

The rebate manager checks recipient consistency in its ERC-2981 branch while ignoring returned royalty amounts. Its fixed calculation makes those requested amounts irrelevant to that check. Registry-backed collection information follows the registry branch instead. These are conditions of the respective manager implementations, not a rule that every V2 purchase universally invokes ERC-2981.

Creator-fee limits can stop a royalty-enabled trade

A nonzero creator fee must fit the exchange’s configured percentage limit, even when the royalty manager successfully resolves its recipient and amount. The full-royalties manager itself does not cap an unusually high returned fee. V2’s execution logic applies the separate maxCreatorFeeBp limit against the transaction price and reverts when the fee exceeds it. The exchange owner can update that setting, with a maximum permitted setting of 25% in this implementation.

That upper bound describes what the owner can configure; it does not establish the live cap or the collection’s royalty rate. A successful manager lookup can therefore accompany a trade that fails its exchange-level fee check. Setting a royalty recipient alone cannot bypass this limit.

Completed transfers establish the creator payment

A successful sale establishes a creator payout only when its execution actually sends the relevant currency to the selected royalty recipient. V2 emits trade events containing the collection, traded items, currency, recipient addresses, and fee amounts. An NFT transfer proves the ownership change, while payment records establish the movement of sale proceeds. Token payments require the correct token contract’s transfer records. Native currency movements require transaction execution details. For ETH sales, also check WETH (wrapped ETH) transfer records: if the ETH transfer fails within its gas limit, V2 sends the amount as WETH to the same recipient. The transaction’s outer destination can be the exchange rather than the eventual payee.

The V2 event arrays place the creator recipient at feeRecipients[1] and the creator amount at feeAmounts[1]. The exchange transfers that amount when it is nonzero. In a zero-creator-fee sale, feeAmounts[1] records zero.