# 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](/vault-overview). The message payload carries the beneficial owner so that a stale owner on the destination chain cannot claim a released item.