Standards and interfaces

ERC-721AC#

Collections launched through Unvault are deployed from an ERC-721AC implementation: ERC-721A batch minting combined with ERC-721C, the creator-token standard that routes transfers through a transfer validator. Marketplaces and tools that already support ERC-721C work with Unvault collections without changes.

Transfer validator#

Creator-token collections point at a transfer validator that decides which operators may move tokens. Unvault collections use the ecosystem-standard Limit Break validator (v5 at 0x721C008fdff27BF06E7E123956E2Fe03B63342e3, the same address on every EVM chain) with a policy that allows compliant marketplaces and the Unvault vault contract. The vault's lock and unlock transfers are allow-listed because no sale occurs.

Integrators building a marketplace route should use the validator's authorizer flow, the way a signed settlement zone does, rather than expecting plain transferFrom to succeed.

Creator earnings#

Creator earnings are configured on the collection and paid by the settlement contract. royaltyInfo (ERC-2981) is exposed for tools that read it; enforcement comes from the validator, not from ERC-2981 alone.

Metadata#

• Token metadata follows the ERC-721 JSON schema with the widely used attributes array (trait_type, value, optional display_type), so traits render correctly on Unvault and on other marketplaces.
• Contract-level metadata via ERC-7572 contractURI() (name, description, image, banner, external link).
• Metadata updates emit ERC-4906 MetadataUpdate / BatchMetadataUpdate so indexers refresh after reveals.
• Media and metadata should live on content-addressed storage (IPFS or Arweave).

Cross-chain#

Vaultable collections implement the cross-chain hooks described in How the vault works. The message payload carries the beneficial owner so that a stale owner on the destination chain cannot claim a released item.