Summary: Royalty Registry is best understood not as a generic NFT-royalties helper site, but as an onchain compatibility layer that decides which contract should speak for a collection’s royalty policy and then normalizes the answer across multiple royalty formats. Its core mechanism has two parts: a registry that lets eligible collection admins point a token contract at a separate royalty-lookup contract, and a royalty engine that detects or caches the royalty spec used at that lookup address and returns a normalized recipient-and-amount output. That makes it a useful comparison class for Operator Filter Registry and ERC721-C: Royalty Registry does not try to block transfers or force marketplace behavior; it standardizes royalty discovery and gives legacy collections an override path, which means the real control surface sits in override authority, supported-spec inclusion, fallback behavior, and marketplace willingness to honor the engine’s result.
What it does:
Lets a collection use its own token contract as the royalty source or point the ecosystem at a separate override contract through setRoyaltyLookupAddress
Gives older collections that launched before onchain royalty standards a way to add royalty data without redeploying the original NFT contract
Normalizes royalty lookups across several supported standards and project-specific formats through a shared RoyaltyEngine
Detects and caches the royalty spec used by a token’s chosen royalty-lookup address to reduce future lookup cost
Supports split-recipient outputs and multiple royalty recipients instead of flattening everything to a single address
Ships a public UI and public deployments so marketplaces and collectors can inspect royalty configuration and override state on multiple chains
Key claims:
The official README is unusually explicit about the design goal: the registry exists both to support backwards compatibility for collections that did not originally implement royalties and to provide a common interface across prominent royalty standards. That means the project belongs in a narrower royalty-discovery / compatibility bucket, not in the same bucket as transfer-blocking or fee-enforcement systems.
RoyaltyRegistry.sol makes the governance surface clear. The central function is not “enforce royalties,” but setRoyaltyLookupAddress, which changes which contract the ecosystem should consult. Practical power therefore sits with whoever is allowed to set or change that pointer.
The permission model is broader than simple Ownable. The registry checks several admin paths, including Ownable, AccessControl, Manifold AdminControl, and some project-specific admin patterns. That is analytically useful because it shows how a supposedly neutral compatibility layer still needs an opinionated governance-recognition policy.
The engine is doing more than EIP-2981 passthrough. The README and RoyaltyEngineV1.sol show explicit support for multiple royalty formats including EIP-2981, Rarible, Foundation, Manifold, SuperRare, Zora, Art Blocks, KnownOrigin-style overrides, and fallback registries. That makes the engine a live normalization layer, not just a directory.
The engine’s spec cache matters because it creates a shared notion of what kind of royalty system a collection is using, and therefore where integration complexity sits. Marketplaces can query one engine output, but the engine itself silently absorbs the format-fragmentation underneath.
The original launch post is a helpful historical baseline: it frames the main problem as fragmented royalty specs plus older collections that only had offchain marketplace royalty settings. Royalty Registry’s answer was discovery and override standardization, not transfer admission control.
That distinction is why Royalty Registry is useful in the active corpus. It gives a clean mechanism page for royalty signaling and lookup before the ecosystem shifted toward stricter operator filters, validator registries, hooks, and authorizer zones.
Whitepaper: No canonical standalone whitepaper surfaced in this pass. The strongest primary materials were the official README, Manifold documentation, the original launch post, and the RoyaltyRegistry.sol / RoyaltyEngineV1.sol contracts collected in ../whitepapers/royalty-registry-primary-sources-2026-05-11.md.