What RWAs Are Made Of: A Minimum RWA Architecture Map (Registry, Custody, Pricing, Settlement)

If we can’t point to a working registry, custody proof, a price reference, and a settlement/redemption path, we don’t yet have a reliable RWA—just a wrapper. The token (or any digital unit) can make ownership and transfers more traceable and programmable, but the system lives underneath.

Introduction

RWA stands for “Real-World Asset”: a unit that claims to be backed by something outside the digital system, such as a commodity, an invoice, or a security. What makes an RWA trustworthy is not the word “tokenized,” but a small set of operational components that produce auditable outputs.

In this article we use a minimum architecture map with four layers—registry, custody, pricing/data, and settlement/redemption—so our product, ops, and tech conversations become concrete. The goal is to be able to review any proposal quickly: What exists today, what is owned by whom, and what can be verified.

The problem

Most RWA conversations start with the interface: a smart contract, an app, or a tradable unit. That’s useful, because the interface is what users touch. Yet the real question is operational: How does the unit stay synchronized with real-world “in and out” events?

Without that synchronization, issuance can drift from actual backing, redemptions can become discretionary, and prices can become arbitrary. A minimum map helps us avoid building a beautiful interface on top of an unclear operating model.

Layer 1 — Registry: what exists, who owns it, what changed

The registry is the system of record that answers: “What is the backing asset, and what is the current state?” A blockchain can be part of the registry, but “registry” is broader than “on-chain.” It is whatever makes identity and history queryable.

Minimum deliverables a registry should produce

• Unique identifiers: IDs for the underlying asset (or batch/lot), and IDs for issued units. If units are fractional, the registry needs a clear rule for how fractions relate to the underlying.
• Lifecycle events: issuance, transfer, lock/pledge (if used), and cancellation/burn when units are redeemed or otherwise retired.
• Queryability: a consistent way to look up current outstanding supply, the mapping to backing, and key status flags (active, locked, redeemed, disputed).
• Audit trail: time-stamped records and an accountable operator for corrections.

Why this matters: registry clarity is what lets us reconcile “units outstanding” with “assets held” without relying on trust alone.

Layer 2 — Custody: what “proof of backing” means in operations

Custody is how the backing asset is actually held, controlled, and safeguarded. In some RWAs custody is physical (commodities), and in others it is legal/contractual (securities, receivables). Regardless of type, custody must be legible as an operating function.

Minimum deliverables custody should produce

• Custody policy: who can move the asset, under what approvals, and what happens in exceptional situations.
• Evidence of holding/control: documents, attestations, or operational records that can be matched to registry IDs.
• Reconciliation routine: a defined cadence and method to reconcile “what the registry says exists” with “what custody actually holds.”
• Exception handling: how shortages, damage, disputes, or failed transfers are recorded and escalated.

A useful way to phrase it: custody is where “backing” becomes more than a statement; it becomes a set of controls and records we can inspect.

Layer 3 — Pricing and data: reference prices, updates, and an audit trail

RWAs need pricing and reference data for basic user expectations: portfolio value, collateral checks, risk monitoring, and fair redemption terms. “Price” does not have to mean an always-on market price. It means a defined method and data source.

Minimum deliverables pricing/data should produce

• Reference source and methodology: where prices come from (market reference, evaluated price, last trade, etc.) and how it is computed.
• Update cadence: how often it updates and under what conditions it can be frozen or corrected.
• Versioned history: an audit trail of updates so later reviews can reconstruct what was known when.
• Integrity controls: roles and approvals for data changes; clear separation between the party benefiting from a price and the party publishing it.

When this layer is vague, disagreements move from “What is the current price?” to “Who gets to decide the price?”, which is rarely a good place to be.

Layer 4 — Settlement and redemption: getting in, getting out, and cancellation rules

Settlement is how units change hands with finality. Redemption is how we exit the RWA into the underlying asset (delivery) or into cash proceeds (cash-out), depending on the design. This layer is where operational promises become real user outcomes.

Minimum deliverables settlement/redemption should produce

• Clear redemption path: what qualifies a holder to redeem, what steps exist, what timelines apply, and what fees or limits exist.
• Finality rules: what counts as “settled,” and how failures or reversals are handled.
• Cancellation/burn logic: once redemption happens, units must be retired in a way that is consistent with registry and custody updates.
• Dispute process: how contested redemptions, delivery issues, or mismatches are resolved and recorded.

A common success condition: issuance and cancellation stay synchronized with real-world deposits and withdrawals—not just with digital transfers.

Iran-native analogy: commodity depository receipts as a mental model

We don’t need to call everything “tokenization” to learn from systems that already made asset-backing operational. A practical analogy is the mechanism of commodity depository receipts in Iran, where a warehouse receipt can be converted into a tradable certificate/unit under a standardized custody-and-issuance workflow, enabling exchange trading.

This is helpful because it makes the four layers visible:

• A registry-like record of what was deposited and what certificates exist.
• Custody in designated warehouses with operational controls.
• Public market data pages that surface symbols and market data, functioning as a transparency layer for participants.
• Settlement and rules for conversion, trading, and ultimately exiting the position.

We can borrow the clarity of roles and outputs, without claiming that the conventional mechanism is itself tokenization.

A practical framework: the minimum one-page audit

When we evaluate an RWA proposal, we can keep it simple: each layer must have (1) an owner, (2) minimum outputs, and (3) a reconciliation link to the other layers.

A compact checklist we can use in meetings

1. Registry: What are the IDs? What events exist? Can we query outstanding units and status?
2. Custody: Who controls the backing? What evidence ties holdings to registry IDs? How often is it reconciled?
3. Pricing/data: What is the reference source and methodology? How often updates? Is there a history we can audit?
4. Settlement/redemption: What is the exit path? What is “final”? How are units cancelled after redemption?

If any layer cannot produce its minimum outputs, the right next step is not to add more token features. The right next step is to define that layer’s operating controls.

A simple example (hypothetical)

Assume we want an asset-backed unit for a commodity stored in a warehouse.

• Registry: each deposited batch gets an ID; issued units reference that ID; transfers are recorded; redeemed units are cancelled.
• Custody: the warehouse operator publishes holding evidence linked to batch IDs; movements require approvals; periodic reconciliations are logged.
• Pricing/data: the unit’s reference price is defined as a market reference or evaluated price updated daily; historical updates are stored.
• Settlement/redemption: a holder can redeem by submitting a request; after delivery (or cash-out), the corresponding units are cancelled and the registry status changes.

Notice what makes the unit credible: the tight loop between the four layers, not the complexity of the interface.

Risks and limitations

This four-layer map improves clarity and auditability, but it does not guarantee outcomes.

• No automatic liquidity: even with perfect architecture, market depth depends on participation and market structure.
• Operational risk remains real: custody errors, process failures, or disputes still need governance and controls.
• Data quality limits valuation: pricing sources can be delayed, thin, or method-dependent.
• Legal and compliance alignment matters: the strongest implementations align registry and settlement with enforceable contracts and compliance requirements.

Treat these as implementation considerations we plan for—ideally early—so the system’s strengths remain consistent under stress.

Conclusion

A trustworthy RWA is best understood as a four-layer system: registry, custody, pricing/data, and settlement/redemption. Each layer must produce auditable outputs, and the token is simply the interface that exposes these guarantees (or their absence).

When we map a proposal into these layers and ask for minimum deliverables, we replace jargon with verifiable operations. That is usually the fastest way to spot gaps before building—or before committing capital.

FAQ

1) Is a blockchain always required for the registry?
Not necessarily. A blockchain can strengthen traceability and shared visibility, but the core requirement is a queryable record with clear IDs, lifecycle events, and an audit trail.

2) What is the difference between registry and custody?
Registry records “what exists and what changed.” Custody controls “where the backing asset is and who can move it,” plus evidence and reconciliations.

3) Why separate pricing/data from settlement?
Because a unit can settle perfectly while being priced poorly, or be priced well but have an unclear exit path. Keeping them distinct makes responsibilities and audit points clearer.