RWA Tokenization: A Mandate-Controlled Agent Architecture

14 minute read

RWA tokenization connects smart-contract execution to claims and controls that live outside the chain. A contract can prove that a mint function executed under its programmed rules. It cannot prove that the agent had legitimate business authority, that the reserve statement was accurate, or that the custodian still held the asset when minting occurred.

Those facts live across legal agreements, custody systems, oracle processes, approvals and enterprise controls. An RWA agent crosses all of them before it submits a transaction.

Consider a reserve-backed token. A custodian publishes a claim that EUR 1,000,000 is held. An issuance agent wants to mint 250,000 units. The transaction should proceed only if the claim is authentic and current, the issuer accepts that evidence source, the mandate permits this asset and amount, required roles approved the action, supply limits remain intact, and the wallet policy allows the exact contract call.

That sentence contains two separate questions:

1. Did trusted systems verify and authorize the evidence and action?
2. Is the real-world assertion true?

Cryptography can help answer the first. It cannot guarantee the second.

Model RWA tokenization as linked claims, not one prompt

The agent should not receive a PDF, reason about it in a chat window and call mint(). Break the flow into typed objects with explicit issuers and digests:

Asset Profile
  -> accepted evidence sources and issuance rules
Asset State Claim
  -> signed reserve observation
Mint Proposal
  -> requested asset, quantity and destination
Asset Mandate
  -> delegated one-time authority
Policy Decision
  -> deterministic allow or deny
Wallet Capability
  -> exact contract call, short expiry
On-chain Transaction
  -> execution and finality state
RWA Action Receipt
  -> linked evidence and outcome

The language model may help extract a reserve report or explain an exception. The final reserve value, evidence source, amount arithmetic and authorization decision should pass through deterministic validation.

Define the asset profile first

An asset profile tells the gateway which evidence and limits are acceptable for one tokenized product. The next object is product-neutral pseudodata, not a wire-compatible OATI RWA Profile. Production integrations must use the published versioned schema and proof fields.

{
  "asset_id": "oati:asset:issuer:eur-reserve-token",
  "asset_class": "reserve_backed",
  "token": {
    "chain_id": "eip155:1",
    "contract": "0x1234...abcd",
    "decimals": 6
  },
  "state_policy": {
    "required_claim_type": "reserve_balance",
    "accepted_issuers": ["oati:org:custodian-1"],
    "max_claim_age_seconds": 900,
    "unit": "EUR"
  },
  "issuance_policy": {
    "required_approval_roles": ["issuer_controller", "custody_verifier"],
    "maximum_supply": "5000000.000000",
    "reserve_ratio": "1.0"
  }
}

This is illustrative configuration. Real products may use NAV, collateral haircuts, share classes, settlement windows or several evidence sources. Those rules require product, legal, accounting and risk input. Do not encode them from a generic template and call the result compliant.

Version the profile. A mint decision must reference the exact policy version it used. If the issuer changes accepted custodians or reserve ratios, old approvals should not float into the new rules without review.

Make the state claim precise and modest

An Asset State Claim records what one issuer observed at a particular time. This shortened projection illustrates the semantics; it omits required fields from the normative OATI schema:

{
  "id": "oati:claim:custodian-1:reserve-20260810-0900",
  "asset_id": "oati:asset:issuer:eur-reserve-token",
  "claim_type": "reserve_balance",
  "value": "1000000.00",
  "unit": "EUR",
  "observed_at": "2026-08-10T09:00:00Z",
  "valid_until": "2026-08-10T09:15:00Z",
  "evidence": {
    "uri": "https://custodian.example/evidence/2026-08-10/0900",
    "digest": "sha256:b7c1..."
  },
  "issuer": "oati:org:custodian-1",
  "proof": { "...": "..." }
}

Verification can establish that the configured custodian signed the claim, that the bytes were not changed, and that the claim was inside its validity window. It cannot inspect the vault, guarantee title, resolve liens, or prove that an operator did not submit false data.

This distinction should appear in APIs and receipts. Use terms such as claim_issuer, observed_at and evidence_digest. Avoid names like verified_reserve_truth.

Oracle design sits outside the signature algorithm. You may need multiple attestations, direct system integrations, proof-of-reserve mechanisms, reconciliations, auditors or regulated reporting. Their reliability and legal meaning depend on the asset and jurisdiction.

Issue one-time authority for one mint

The Asset Mandate should narrow authority to the exact transaction:

{
  "id": "oati:mandate:issuer:mint-901",
  "agent_id": "oati:agent:issuer:mint-worker",
  "purpose": "reserve_backed_issuance",
  "actions": ["token.mint"],
  "resources": ["oati:asset:issuer:eur-reserve-token"],
  "destinations": ["eip155:1:0xabcd...9012"],
  "one_time": true,
  "expires_at": "2026-08-10T09:10:00Z",
  "extensions": {
    "rwa": {
      "operation": "mint",
      "asset_id": "oati:asset:issuer:eur-reserve-token",
      "state_claim_id": "oati:claim:custodian-1:reserve-20260810-0900",
      "max_quantity": "250000.000000",
      "required_approval_roles": ["issuer_controller", "custody_verifier"]
    }
  }
}

Bind the destination wallet, chain, contract, function selector, quantity and state claim into signed transaction context. If any value changes after approval, the digest changes and evaluation fails.

Do not give the agent a standing wallet key. A credential broker or wallet policy service should issue a short-lived capability for this exact call only after authorization. The agent receives a result or an opaque signing handle, not an exportable private key.

Evaluate supply and reserve with consistent units

Decimal and unit handling can quietly break issuance controls. Avoid binary floating-point arithmetic for token quantities and reserve values. Normalize units and use fixed-point decimal or integer base units.

function evaluateMint(input: MintContext): Decision {
  require(input.claim.assetId === input.profile.assetId)
  require(input.mandate.stateClaimId === input.claim.id)
  require(input.claim.claimType === input.profile.requiredClaimType)
  require(input.now <= input.claim.validUntil)
  require(input.acceptedClaimIssuers.has(input.claim.issuer))
  require(hasRequiredApprovals(input))
  require(input.quantity <= input.mandate.maxQuantity)

  const resultingSupply = addDecimal(input.currentSupply, input.quantity)
  require(resultingSupply <= input.profile.maximumSupply)

  const supportedSupply = divideDecimal(
    input.claim.value,
    input.profile.reserveRatio
  )
  require(resultingSupply <= supportedSupply)

  require(!input.usage.mandateConsumed)
  return allowWithReservation()
}

This simplified evaluator assumes the claim value and token supply share an agreed economic unit. Many assets do not. FX, NAV timing, haircuts, accrued interest and class-specific rights can make the conversion much more complicated. Those rules belong in a reviewed asset profile and deterministic implementation.

Current supply also needs an authoritative source and finality policy. Reading one blockchain node at an arbitrary block can give stale state. Record chain ID, block number, block hash and confirmation rule with the decision.

The evaluator result is not the reservation. Two different mandates can read the same supply, both pass and jointly exceed the cap. Before wallet execution, serialize issuance per asset or atomically reserve the proposed supply delta against an asset-level ledger. Keep a contract-level maximum-supply check as defense in depth where the token contract supports it.

UPDATE asset_issuance_capacity
SET reserved_supply = reserved_supply + $quantity
WHERE asset_id = $asset_id
  AND current_supply + reserved_supply + $quantity <= maximum_supply
  AND current_supply + reserved_supply + $quantity <= supported_supply;

Proceed only when that update and the one-time mandate reservation succeed in the same durable transaction. Reconcile the reserved supply after finality or a confirmed revert.

Reserve the mandate before wallet execution

A one-time mandate must survive concurrent calls. Two gateway replicas can both see consumed = false unless usage reservation is atomic.

UPDATE mandate_usage
SET state = 'reserved',
    transaction_id = $2,
    reserved_at = now()
WHERE mandate_id = $1
  AND state = 'available';

Proceed only if one row changed. If wallet submission becomes uncertain, keep the mandate reserved until the transaction is reconciled. Releasing it immediately can create a second mint.

The on-chain transaction hash is not necessarily a final result. Track submission, inclusion, confirmation, reorganization and finality according to the chain and product policy.

AUTHORIZED -> RESERVED -> SIGNED -> SUBMITTED
                                  -> INCLUDED
                                  -> FINALIZED
                                  -> REVERTED
                                  -> UNCERTAIN

If a transaction is replaced, link the replacement hash. If a reorganization removes it, append a new outcome record. Do not rewrite the original evidence.

Test substitution and stale-evidence attacks

The useful test suite attacks every link:

Also test malicious but correctly signed evidence. The cryptographic verifier should accept the signature while a higher-level control detects inconsistency through another source or reconciliation. This test prevents teams from treating signature validity as truth.

Legal, custody and oracle dependencies are part of the system

An RWA architecture can be technically coherent and still fail as a product or legal arrangement.

Before production use, teams need jurisdiction-specific answers about what the token represents, who holds legal title, which entity may issue or redeem, what investor restrictions apply, how insolvency is handled, and which records control when systems disagree. Custody and wallet operations need their own key-management, approval, recovery and incident controls.

Oracle or attestation governance needs named accountable parties, data provenance, correction rules and dispute procedures. If the reserve source publishes a wrong figure, a perfectly signed claim only proves who made the statement.

This article does not establish regulatory compliance, asset ownership, bankruptcy remoteness or the legal effect of a receipt. Those depend on the product, contracts and jurisdictions.

Receipts should preserve the boundary of proof

An RWA Action Receipt can bind:

• agent, accountable organization and mandate
• asset profile and policy version
• state claim ID, issuer and evidence digest
• approval identities and roles
• requested quantity, destination and transaction digest
• supply observation and block reference
• wallet policy decision
• transaction hash and finality state
• timestamps and one-time consumption

The wording matters. A receipt can say that the gateway verified a current claim from an accepted issuer and enforced the configured mint limits. It should not say that the underlying reserve was unquestionably present.

A later redemption, correction or reserve restatement should create linked evidence. Tamper-evident history is more useful than a single record that always displays the newest interpretation.

Related engineering guides

• Constrain specialized workers with non-amplifying delegation in multi-agent systems.
• Preserve reserve and execution claims with signed receipts beyond ordinary audit logs.

What OATI supports today

The OATI developer preview includes an RWA controlled-mint profile, Asset State Claim and Asset Mandate examples, deterministic reserve, approval, quantity and maximum-supply checks, signed context binding, one-time consumption, substitution-resistance vectors and a local sandbox simulation. These are developer and reference capabilities.

Production RWA deployment still requires authoritative evidence sources, custody and wallet controls, jurisdiction-specific legal and compliance review, and a complete evidence and dispute path. The independent cryptographic and protocol review is also open. OATI should not be described as proving legal ownership or the truth of an external claim.

Implementation checklist

• Define one versioned asset profile per product and share class.
• Name accepted claim types, issuers, units and freshness limits.
• Bind each claim to evidence digests and observation times.
• Keep verification claims narrower than real-world truth claims.
• Issue one-time mandates for exact asset, amount and destination.
• Bind chain, contract, function, quantity, claim and approvals.
• Use fixed-point or integer arithmetic with explicit units.
• Read supply from a defined block and finality policy.
• Reserve one-time authority and asset-level issuance capacity atomically before wallet execution.
• Broker an exact, short-lived wallet capability.
• Track submitted, included, finalized, reverted and uncertain states.
• Reconcile ambiguous submissions before permitting another mint.
• Test stale evidence, substitution, replay and concurrent use.
• Append correction and finality records rather than mutating history.
• Complete legal, custody, oracle and dispute design for each jurisdiction.

The contract call is the last step. The harder engineering work is proving that a specific agent, acting for an accountable organization, had narrow authority to make that call against a specific body of evidence. Even then, the evidence remains a claim about the world, not the world itself.