Royalty Registry’s cleanest contribution is not transfer blocking or marketplace gating; it is a compatibility layer for royalty discovery. The official docs and README say the two goals are to make it easier for marketplaces to use the right onchain royalty configuration and to let older contracts add royalties after the fact.
The core registry mechanism is pointer-setting. getRoyaltyLookupAddress() returns either the token itself or an override address, and setRoyaltyLookupAddress() lets an authorized admin change that pointer. That means the key governance question is who gets to decide which contract speaks for a collection’s royalties.
The permission model is broader than just Ownable. overrideAllowed() checks a mix of Ownable, AccessControl, Manifold admin control, and some project-specific admin patterns, which makes the registry a governance-recognition layer as much as a technical helper.
The engine matters as much as the registry. RoyaltyEngineV1 detects or caches royalty specs and normalizes outputs across EIP-2981, Manifold, Rarible v1/v2, Foundation, SuperRare, Zora, Art Blocks, KnownOrigin-style overrides, royalty splitters, and fallback registry entries.
The launch post is a good historical anchor because it frames the problem as fragmented royalty formats plus legacy collections that only had marketplace-set royalties. The proposed solution was a shared royalty lookup and override system, not token-level transfer enforcement.
The project therefore occupies a different layer from later NFT-policy systems. Royalty Registry standardizes what royalty data should be read; it does not itself force a marketplace or transfer path to honor that data.
Why it matters for the corpus
Royalty Registry gives the corpus a clean baseline for royalty signaling and compatibility before the ecosystem moved toward operator filters, transfer validators, Seaport hooks, and authorizer zones.
It sharpens an important comparison: some NFT infrastructure tries to harmonize royalty lookup, while other infrastructure tries to control transfer admission. Those are different control planes and should not be flattened together.
The most reusable question it raises is where royalty authority actually sits: original token contract, override contract, shared engine support list, or marketplace policy.
Follow-up comparison threads
Compare Royalty Registry directly against Operator Filter Registry so royalty discovery and transfer blocking do not get flattened into one generic creator-fee enforcement bucket.
Compare Royalty Registry directly against ERC721-C / CreatorTokenTransferValidator so metadata-level royalty signaling, override governance, validator-driven transfer admission, and authorizer-based order fulfillment remain analytically distinct.