Royalty enforcement (ERC-721C / ERC-1155C)

ABX royalties are ERC-2981: an on-chain rate and receiver that every marketplace can read (abx set-royalty changes them). Whether a marketplace honors that rate is its choice — ERC-2981 is a signal, not an enforcement mechanism. ERC-721C (and its ERC-1155 twin, ERC-1155C, for an edition) is the opt-in enforcement layer for creators who want one: the token checks every transfer against a validator contract, and sales that don't route through an authorized venue revert. Both standards enroll through the same --721c flag, the same validator registry, and the same permanence rule — a creator never has to know there are two.

The default is plain — 721 or 1155 — and that's the recommendation

An ABX token deploys plain (ERC-721, or ERC-1155 for an edition) unless you say otherwise. That is the more sovereign asset: no third-party contract sits on the transfer path, it trades on every marketplace and wallet-to-wallet, and there is nothing anyone — including you — can later switch off or misconfigure. A plain ABX token can never grow transfer restrictions: enrollment is decided at deploy and can't be retrofitted. That's a feature — a collector holding an unenrolled token knows it stays unrestricted forever.

ERC-721C/ERC-1155C is for creators who specifically want more control and royalty enforcement, and are willing to take the trade-offs knowingly. It is a transparent, deliberate opt-in — not a nudge.

The honest market picture

Be clear-eyed about what enforcement buys in 2026: royalty enforcement via ERC-721C effectively means OpenSea, plus venues built on Limit Break's Payment Processor. OpenSea's own help docs state that enabling enforcement limits sales to OpenSea and Payment-Processor venues. Magic Eden's EVM marketplace shut down in March 2026, and Blur never honored ERC-721C. So the real trade is: enforced royalties on OpenSea, in exchange for the token not trading on venues the validator doesn't authorize.

What enrolling does — and doesn't

Enrolling at deploy makes the token a creator token, permanently:

Transfers are validated. Every real transfer calls the configured validator; a policy violation reverts the transfer. On ERC-721C the call is a view, validateTransfer(caller, from, to, tokenId). On ERC-1155C it's the amount-aware, non-view twin, validateTransfer(caller, from, to, id, amount) — checked once per (id, amount) pair, so a single batch transfer of several ids makes several validator calls.
Mints and burns are never validated. Minting — including either fixed-price minter and any delegated minter — cannot be blocked by validator policy, no matter how the validator is configured.
Collectors can see it. An enrolled token advertises the creator-token interfaces via ERC-165 (0xad0d7f6c and the legacy 0xa07d229a — the same ids on both standards) and reports the ABX beacon extension (keccak256("abx.extension.creator-token"), version 1). An unenrolled token advertises neither — it is indistinguishable from a token deployed before creator-token support existed.
The owner manages the validator, never the enrollment. After deploy you can re-point the validator to a different contract, or suspend enforcement by setting it to zero — the token stays enrolled either way. There is no un-enroll: an enrolled token can always have enforcement turned back on by its owner, and a plain token can never gain it.
A validator must be a real contract. A non-zero validator with no code on the chain would silently enforce nothing, so both the deploy and every re-point refuse it (the contract reverts InvalidTransferValidator(); the CLI checks before any gas is spent).

The recommended configuration

So that a creator who wants enforcement makes exactly one decision, the toolkit ships one recommended validator per chain: OpenSea's StrictAuthorizedTransferSecurityRegistry (0xA000027A9B2802E1ddf7000061001e5c005A0000 on both shipped testnets) — the validator OpenSea's creator-fee-enforcement docs recommend, and the same registry for both standards. Under it, owner-initiated (wallet-to-wallet) transfers go through, and transfers initiated by a non-authorized operator revert. In practice: collectors can still send their tokens anywhere, but marketplace sales settle only through venues the registry authorizes.

Enroll at deploy

All three deploy commands take --721c (bare --721c means recommended) — on an edition (--copies), the same flag enrolls ERC-1155C instead:

abx deploy --image art.png --name "…" --symbol … --721c recommended
abx deploy-series --dir ./photos --name "…" --symbol … --721c recommended
abx deploy-code --script art.js --name "…" --symbol … --721c 0xYourValidator…
abx deploy --image art.png --copies open --name "…" --symbol … --721c recommended   # ERC-1155C

An explicit address is checksum-validated and checked for code on the target chain before anything is uploaded or signed. Enrolling prints one plain statement of what enforcement means; a deploy without --721c is byte-for-byte the plain deploy (ERC-721, or ERC-1155 on an edition). --721c none is refused: "enrolled but suspended" is not a deploy-time state — either enroll with a real validator, or leave the flag off.

Manage after deploy

abx state <collection>                                    # shows a "721C validator" row when enrolled
abx set-transfer-validator <collection> 0xNewValidator…   # re-point enforcement
abx set-transfer-validator <collection> none              # suspend (the token STAYS enrolled)
abx set-transfer-validator <collection> recommended       # the chain's recommended validator

set-transfer-validator is owner-only, runs on any signing lane, and accepts --dry-run. It refuses a collection that didn't enroll at deploy — enrollment can never be added to a live collection, on either standard. abx state shows the validator only for enrolled collections — labeled 721C validator on a 721 and 1155C validator on an edition (the detection is identical: both standards share the same ERC-165 id and getter); a suspended one reads suspended until a validator is set again. A plain collection shows nothing new.