# Royalties ## 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: ``` Sale Price │ ├─► Platform Fee (Fractal Visions) — basis points configured at marketplace init │ ├─► Royalty Recipients (from Royalty Engine) — amounts returned by getRoyalty() │ └─► Seller — remainder after platform fee and royalties ``` 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).* --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.fractalvisions.io/fveco/fractal-pod/royalties.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.