The README is explicit that CreatorTokenTransferValidator is shared infrastructure used by the different creator-token implementations. That means the real comparison object is not only ERC721-C or ERC1155-C, but also the common policy registry they inherit from.
The validator contract header is unusually helpful because it spells out the policy menu directly: security levels, blacklist and whitelist control, receiver constraints, and authorizers. This is a transfer-admission registry, not merely a royalty-reporting helper.
The contract’s list model matters analytically. It tracks list owners, applied lists, and per-list account / codehash entries, which means transfer policy can be reused across collections and administratively reassigned.
The receiver-constraint variants are a useful reminder that the registry is broader than royalty enforcement alone. Higher security levels can restrict recipients to EOAs or to addresses without deployed code, which turns the validator into a general-purpose transfer-governance layer.
ERC1155C.sol makes the dependency concrete from the token side: the token advertises a transfer-validation function and routes transfer hooks through the validator path. That keeps the validator in the live execution path.
OpenSea’s creator-fee-enforcement docs show how order-side authorization plugs into the validator. SignedZone is assigned as an authorizer on a compatible validator and sets temporary approval state before and after fulfillment. That means marketplace execution depends on both token-side validator policy and order-side authorizer behavior.
Why it matters for the corpus
It gives the corpus a cleaner middle layer between token wrappers like ERC721-C and marketplace-side order authorizers like SignedZone.
It makes NFT creator-fee enforcement legible as configurable transfer policy rather than a vague claim that a collection has “enforced royalties.”
The key reusable question is whether practical control lives with token owners, list owners, validator maintainers, marketplace authorizers, or some combination of them.
Follow-up comparison threads
Compare CreatorTokenTransferValidator directly against Operator Filter Registry so shared blocklist publication and shared validator policy do not get flattened together.
Compare CreatorTokenTransferValidator directly against ERC721-C / ERC1155-C so token wrappers and the underlying shared policy engine stay separate.
Compare CreatorTokenTransferValidator directly against Seaport SignedZone so token-side validation, temporary order authorization, and marketplace API dependency do not get flattened into one generic royalty enforcement layer.