Real-World Assets

A real-world asset is a token plus a rich, structured record: an appraisal, a deed reference, a holder roster, a stream of readings. The engine adds a metadata plane on top of ERC721X and ERC1155X where that record is defined by configuration rather than custom code, and is immutable by system design.

Asset schemas: config, not code

An asset schema describes the fields an asset carries: their types, whether they are required, and the rules they must satisfy. You build a schema from a field palette (or fork a curated template), preview the compiled result, and publish it. There is no custom code to write or deploy for a new asset type.

Start from a platform template or build a palette of fields.
Compile-preview shows the result and whether it would pass the publish gate, without persisting.
Publish turns the draft into a fixed, versioned schema. A published version is frozen.

A token is then bound to a published schema version. Once bound, the token's metadata reads against that schema. To move a token to a later schema version, you go through an attested rebind, so a schema change is deliberate and recorded rather than silent.

flowchart TD
  A[Fork a curated template or build from the field palette] --> B[Compile preview, no write]
  B --> C[Publish: a frozen, versioned schema]
  C --> D[Bind the token to the published version]
  D --> E[Commit field values under each field's mutability rule]
  E --> F[Public resolver serves the tokenURI metadata]
  C -. a later version ships .-> G[Attested rebind ceremony]
  G --> D

Field mutability

Each field declares how it may change after it is first set. The engine enforces that rule on every write, through one ingestion path that every writer (operator edit, external attestation, automated feed) goes through.

Mutability	Behavior	Fits
`frozen`	Set once, then locked. A later change is rejected.	A deed reference, an issue date, a fixed identifier.
`versioned`	Each change appends a new version. Old versions remain readable.	An appraisal value, a status that updates over time.
`append-log`	Each write adds an entry to an append-only log. Nothing is overwritten.	An inspection history, a stream of facts or attestations.

A write is validated against the field's compiled schema fragment and its constraints before it commits. A value that fails validation, or a change to a frozen field, is rejected.

Not every field kind is written through the generic field-commit call. Media attachments and time-series data points each have their own dedicated write operation (a document confirm and an observation append, respectively); committing one through the generic path is rejected with a pointer to the correct operation. Per-holder position snapshots are not written at all: they are on-chain, rebuilt from the cap-table replay. Relationships to other tokens or holders do commit through the generic field path; the dedicated relationships surface is read-only.

Immutable by design

The record is immutable by system design, not by convention. A published schema version is frozen, a frozen field cannot be rewritten, and versioned and append-log history is never overwritten in place. The result is an asset record where the full history is reconstructable and tamper-evidence is built in. The provenance and reconciliation surfaces sit on top of this; see Provenance and Transparency.

The public resolver and tokenURI

The engine serves a public metadata document, the target a marketplace or explorer fetches off the token's tokenURI (and the per-instance uri for an ERC-1155 id). It needs no API key: the per-field public or gated policy is itself the access control.

The document carries the standard fields (name, description, image, attributes) at the top level, with the rich asset data nested underneath.
A gated field is projected only as a reference (a content hash and a document reference), never as the underlying bytes, so a private field stays private while still being verifiable.
It never returns not-found for a token that ever existed. A burned token returns its last record marked as burned.
When a token has no committed image and no collection-default image, and its schema's image field opts into generated placeholders, the resolver serves a deterministic, brand-aware placeholder image; otherwise the image field is omitted.

Beyond metadata, a real-world asset can carry a cap table, distributions, corporate actions, and holder eligibility. See Cap Tables and Distributions, Corporate Actions, and Holder Eligibility and Transfers. For the exact operations, see the interactive reference or the operations list.

Was this helpful?