Digital Assets

Discover published tokens and collections through source-backed public projections, verify exact-decimal supply and retained lifecycle evidence, and keep future issuance, trading, redemption, marketplace, payment, and delivery authority in their separate governed lifecycles.

BUSINESS CASES

Where this module fits

public token and digital-asset catalog discovery
canonical token details and collection membership
mint, lifecycle, provenance, and proof reconciliation
fungible, security-token, and collectible asset issuance
collection and asset publication
governed mint, burn, and supply reconciliation
marketplace listing and cancellation
ownership, provenance, and proof verification
Commerce-backed asset delivery reconciliation

PRIMARY CONSUMERS

Who integrates it

asset issuers
marketplaces
portfolio agents

PREREQUISITES

What must exist first

issuer, holder, seller, or separately governed compliance authority appropriate to the exact mutation
active network, asset, collection, authority, precision, cap, metadata, and compliance policy eligibility
fresh purpose-bound step-up and RFC 9421 request signature for consequential planned mutations
authoritative Commerce confirmation when payment or order evidence participates

RECOMMENDED WORKFLOW

Compose the module safely.

01
discover public collections and assets through GET /api/v2/asset-collections and GET /api/v2/assets, preserving cursors and exact decimal strings
02
resolve one canonical asset UUID, then reconcile detail, lifecycle history, retained proofs, and referenced mint evidence without inferring private holdings or authority
03
select the asset class, governing network, collection, authorities, precision, supply cap, metadata, and compliance policy
04
create a private canonical collection or asset draft and review its commitment before publication
05
publish collection and asset identities separately from minting, holdings, listings, payment, or delivery
06
apply mint, burn, listing, and cancellation commands only against freshly read version, supply, balance, reservation, and authority state
07
resolve payment and checkout facts from Commerce and reconcile delivery atomically; never accept caller-authored paid assertions

AGENT INTEGRATION

Machine-use boundaries

Use the implemented canonical asset, collection, history, proof, and mint-evidence reads for public token discovery; legacy /api/v2/tokens/* reads remain non-executable migration documentation.
A public asset record exposes identity, classification, exact supply projections, metadata commitments, and lifecycle timestamps—not current price, performance, buying power, holder ownership, reserve inventory, redemption eligibility, or trading authority.
Use asset_uuid and collection_uuid as stable identities. Symbols, names, category codes, media URIs, and display metadata are not globally unique and are never proof or authorization.
Differentiate draft creation, public metadata publication, supply issuance, holding ownership, market listing, payment, and delivery; no state implies another.
Preserve quantities, prices, balances, and supply as exact decimal strings and bind mutations to last-read versions and commitments.
Derive owner boundaries from the bearer and opaque owner-safe references; never send database IDs, vault selectors, private keys, seeds, MPC shares, signing nonces, or custody credentials.
Use canonical proof endpoints to verify commitments instead of trusting display fields, screenshots, caller-authored status, or legacy token and NFT payloads.
Treat /api/v2/tokens/mint and /api/v2/nft mutation paths as 501 compatibility markers. Follow their canonical migration guidance and call a replacement only when it appears in live OpenAPI.
A planned-profiled operation is reviewed documentation, not executable behavior. Re-fetch /api/v2/openapi.json before generating or releasing an integration.

Register only production-listed routes as executable tools, and re-fetch the deployed OpenAPI before generating or sending a request. Source-ready routes awaiting deployment are preparation references; planned contracts are non-executable.

MODULE CONTRACTS

Every mapped endpoint

Each operation states whether its request shape is authoritative in OpenAPI, reviewed as a planning profile, or intentionally left as an outline pending an owner schema.