FV Points Season 3
Collect FV
Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Royalties

How creator royalties work for our marketplace

Royalty Enforcement on the Fractal Visions Marketplace

Contract: thirdweb MarketplaceV3 deployed across 7 networks Architecture: Modular, upgradeable marketplace with on-chain royalty enforcement

Deployed Contracts

Fractal Visions operates a unified marketplace infrastructure across the Superchain and beyond. Each network has its own independent MarketplaceV3 deployment sharing identical contract logic, royalty enforcement, and permission structure.

Network
Chain Type
Contract Address

OP Mainnet

Superchain (L2)

0xb44AD68858205d419DA2e7e92e46419677bAE23B

Base

Superchain (L2)

0xc2401A735c670EfF7bFBeb82334c82847d851aA9

Shape

Superchain (L2)

0xf7d1E404395b521dD2Fd0bd9b86e66dbb155772d

Superseed

Superchain (L2)

0x4b8f39dC42cfAf241C6B46c451D261482A59F964

Soneium

Superchain (L2)

0xF87f5313E830d8E2670898e231D8701532b1eB09

Unichain

Superchain (L2)

0x29C372D9D51f75f6D53ffD942E0edc1497D518ae

Ethereum Mainnet

L1

0xe521B6Fe60D725A78fe0277330619264dB3B6870

All deployments are verified instances of the same MarketplaceV3 contract (Solidity ^0.8.0, compiled with v0.8.23+commit.f704f362, optimized). Each is deployed as a minimal proxy against the same implementation logic, and all share the same royalty enforcement mechanism described in this document.

Overview

Royalties on Fractal Visions are not optional or advisory they are enforced at the contract level on every completed sale, including secondary market transactions. The mechanism works through a multi-layered lookup system that honors royalty information from a wide variety of NFT contract standards, including collections deployed through third-party platforms like Manifold.

The Royalty Engine: How It Works

At the heart of the royalty system is a component called the Royalty Engine, integrated through the RoyaltyPaymentsLogic extension inherited by MarketplaceV3. This engine implements IRoyaltyEngineV1, an interface originally developed by Manifold (the same team behind Manifold Studio). Because Fractal Visions uses the Manifold Royalty Engine under the hood, it is natively compatible with royalty configurations set in Manifold-deployed contracts on any chain.

When a sale settles whether through a direct listing or an auction the marketplace contract calls the Royalty Engine with three pieces of information:

  1. The NFT contract address (e.g., a Manifold ERC-721, a thirdweb Drop, a custom FV contract)

  2. The token ID of the specific piece sold

  3. The sale value (the final price in the native currency or ERC-20 payment token)

The engine responds with two arrays: a list of recipient addresses and the corresponding amounts each recipient should receive. The marketplace then distributes those amounts atomically as part of the settlement transaction, before remitting the remainder to the seller.

Royalty Standard Detection

The Royalty Engine uses a tiered lookup to find the correct royalty information for any given token. It checks the NFT contract for the following standards, in order of priority:

  1. ERC-2981 - The Ethereum standard for on-chain royalty info (royaltyInfo(tokenId, salePrice)). This is the most universal standard. Any collection implementing ERC-2981 whether deployed on thirdweb, Manifold, or any other platform will have its royalties read and honored automatically.

  2. Manifold royalty interfaces - The engine also understands Manifold's proprietary royalty patterns, including the getRoyalties() function used in ERC721CreatorCore contracts. Manifold collections have their royalty percentage and recipient read directly from the original contract, regardless of which chain the sale occurs on.

  3. Rarible and Foundation royalty patterns - Older royalty standards introduced by Rarible and Foundation are also supported, providing broad backward compatibility across the NFT ecosystem.

  4. Fallback / no royalty - If none of these interfaces are detected, the engine returns zero recipients and zero amounts. No royalty is paid, but the sale proceeds normally.

Payment Flow on a Sale

When a buyer purchases a listed NFT or a winning bidder claims an auction, the settlement logic executes the following payment distribution in a single atomic transaction:

This happens entirely on-chain, in one transaction. There is no manual step, no off-chain royalty promise, and no mechanism for the buyer or seller to bypass it. If the Royalty Engine returns a recipient and an amount, those funds are transferred before the seller receives anything.

Importing Collections from Manifold and Other Platforms

When an artist has an existing collection on Manifold (on Ethereum Mainnet or any Superchain network) and wants to list pieces on Fractal Visions, the royalty flow is automatic:

  • The artist grants the relevant Fractal Visions marketplace contract permission to transfer their NFTs (via standard ERC-721/1155 approval and, if required, ASSET_ROLE allowlisting).

  • When a listing is created, the NFT contract address and token ID are registered.

  • When a sale settles, the Royalty Engine queries the original Manifold contract for royalty info not any wrapper or intermediary. Because Manifold contracts implement both ERC-2981 and Manifold's own royalty interface, the engine finds the royalty configuration the artist set up in Manifold Studio and applies it directly.

The artist does not need to re-enter royalty information anywhere in the Fractal Visions marketplace. Their royalty settings live in their original smart contract and are read trustlessly at the point of sale.

The same applies to any other platform that deploys ERC-2981-compliant contracts thirdweb Drops, custom ERC-721 implementations, SuperRare, and so on.

Permissions and Asset Allowlisting

The marketplace uses two role-based access control mechanisms relevant to how external collections are onboarded:

LISTER_ROLE controls who can create listings and auctions. When held by address(0), the marketplace is open to any wallet. When specific addresses are added, only those wallets can list.

ASSET_ROLE controls which NFT contracts are permitted for listing. When a Manifold or other third-party collection is granted this role, the marketplace signals that this contract is trusted for listings. The royalty lookup still runs against the original contract at point of sale regardless the role governs permission to list, not royalty configuration.

An important detail: adding a contract to ASSET_ROLE does not override or modify its royalty settings. The Royalty Engine reads directly from the NFT contract's on-chain state. Royalties cannot be suppressed or altered through the permissions system.

Admin Controls

The marketplace admin (DEFAULT_ADMIN_ROLE) on each deployment has the ability to:

  • Update the Royalty Engine address via setRoyaltyEngine() allowing the engine to be upgraded if a newer version is deployed, without redeploying the marketplace contract.

  • Set the platform fee percentage and recipient address via setPlatformFeeInfo().

  • Grant or revoke LISTER_ROLE and ASSET_ROLE for specific addresses or contracts.

  • Upgrade contract extensions via EXTENSION_ROLE (the contract follows the EIP-7504 dynamic contracts pattern).

The admin cannot override or suppress royalties for a specific collection. The royalty lookup is an inherent part of the settlement logic, not a configurable on/off toggle.

Cross-Chain Consistency

When a deterministic smart contract with the same address is deployed across multiple networks the royalties remain the same.

Because each network deployment uses identical contract logic, the royalty behavior is consistent regardless of which chain a sale occurs on:

  • A collection minted on OP Mainnet and listed on the Base deployment will have its royalties read from the original contract at settlement time.

  • A NFT collection on Ethereum Mainnet listed on the Soneium deployment will have its royalties read from the Ethereum Mainnet contract.

  • Artists set royalties once, in their original contract, and those royalties are enforced on every Fractal Visions deployment across all supported networks.

There is no need for artists to re-register or re-configure royalties per chain.

Summary

Feature
Detail

Royalty enforcement

Automatic, on-chain, enforced at settlement

Standards supported

ERC-2981 (primary), Manifold, Rarible, Foundation

Manifold compatibility

Native Manifold Royalty Engine is the underlying lookup mechanism

Imported collections

Royalties read from original contract; no re-configuration needed

Royalty bypass

Not possible by buyers, sellers, or marketplace admin

Settlement order

Platform fee → royalty recipients → seller

Royalty engine upgradeability

Yes, via setRoyaltyEngine() (admin only, per deployment)

Networks supported

OP Mainnet, Base, Shape, Superseed, Soneium, Unichain, Ethereum

Cross-chain royalty reads

Engine queries the collection's origin contract directly

Documentation reflects verified MarketplaceV3 deployments across all Fractal Visions supported networks. All contracts share identical royalty logic derived from the thirdweb MarketplaceV3 implementation with RoyaltyPaymentsLogic (IRoyaltyEngineV1 by manifold.xyz).

PreviousPoliciesNextRewards

Last updated

Was this helpful?