ArchitecturePhysical Assets (RWA)
Designing oracles for real-world asset tokens: who signs the data and how it is checked
A real-world asset token cannot see its asset. Everything it knows about value, backing, payments and defaults arrives from off-chain parties, so the design question is less about oracle technology than about who signs each data point, how the contract checks it and what happens when it is late or wrong. This page sets out a data inventory, the main oracle patterns, the safeguards to build in and how the design should respond to common failures.
On this page
- Why an RWA token is only as good as its off-chain data
- Data inventory: what each feed carries and who should sign it
- How a signed NAV update reaches holders
- Choosing an oracle pattern for each data point
- Safeguards to build into the contract and the feed
- Corporate actions, distributions and the evidence trail
- Failure scenarios and how the design should respond
- Questions and answers
- Sources
Why an RWA token is only as good as its off-chain data
Contracts and token services enforce rules exactly, but only on the information they are given. A tokenised fund prices subscriptions at the net asset value it receives. A tokenised bond pays coupons to the holders recorded on the date it is told is the record date. A gold-backed token stays credible only while someone reports that the gold is still in the vault. If that information is late, wrong or forged, the token executes the wrong outcome with perfect precision.
This sets a hard limit on what tokenisation can promise. A token cannot prove that an asset exists, is worth what is claimed or is free of other claims. Those facts rest on administrators, custodians, auditors and appraisers, and on their records. Oracle design is the work of bringing their statements on-chain so that each one is attributable, checkable and correctable.
Data inventory: what each feed carries and who should sign it
| Data point | Accountable signer | Typical rhythm | What the token does with it |
|---|---|---|---|
| Net asset value (NAV) | Fund administrator, under the manager's valuation policy | Each dealing day for liquid funds; monthly or quarterly for many private funds | Prices subscriptions and redemptions; shown to holders |
| Appraisal or valuation | Independent valuer or appraiser | Each valuation cycle, or on a trigger event | Updates reported value and loan-to-value checks |
| Market price | Price source or oracle network, for liquid reference assets | Continuous or on demand | Collateral checks and reference pricing |
| Reserve or custody statement | Custodian, with periodic independent attestation | Set by the backing promise made to holders | Confirms backing; pauses issuance if short |
| Corporate action | Issuer, agent or registrar | Per event | Sets record dates, entitlements and payment amounts |
| Payment confirmation | Paying agent or bank | Per payment | Marks distributions paid and triggers reconciliation |
| Default or credit event | Trustee, servicer or calculation agent | On occurrence | Freezes transfers or changes payment priority as the documents require |
Rhythms are common patterns, not rules; the offering documents set the actual schedule for each asset.
Choosing an oracle pattern for each data point
Most RWA programmes combine patterns, one per data type, chosen by who is accountable and how often the value changes.
- If
The value comes from one accountable institution on a schedule, such as NAV from an administrator or a valuation from an appraiser.
ThenUse signed push updates: the institution, or a service acting for it, posts signed values the contract verifies against a registered key.
Accountability stays with the party legally responsible for the figure.
- If
The value is needed at the moment of a transaction and changes continuously, such as a market reference price.
ThenUse a pull model, where the transaction carries a recent signed price that the contract checks before executing.
It avoids paying to update a value on-chain when nobody is using it.
- If
The asset is liquid and widely traded.
ThenTake the reference price from a decentralised oracle network that aggregates independent sources.
Aggregation reduces dependence on any single source where a genuine market price exists.
- If
Holders are promised that tokens are fully backed by reserves or custody holdings.
ThenPublish a custodian-signed reserve feed, verified periodically by an independent attestation, and pause issuance automatically if reserves fall below supply.
A backing claim is credible only if the token reacts when the backing changes.
- If
The asset is illiquid, such as property or private credit.
ThenAvoid public price feeds; rely on signed valuations and display their date prominently.
A feed that looks live implies a market price that does not exist.
Safeguards to build into the contract and the feed
Corporate actions, distributions and the evidence trail
Distributions need a sequence of data rather than one value: declaration, record date, entitlement per token, payment and confirmation. The issuer or its agent declares the event, the token logic snapshots holders at the record date, the paying agent confirms payment and reconciliation marks each entitlement settled. Each step should be a signed message from the responsible party, so a missing confirmation is visible rather than assumed.
An update is only as trustworthy as the document behind it. Anchoring a hash of each source document, such as the administrator's NAV statement or the custodian's holdings report, to a consensus log gives auditors and holders a time-stamped way to confirm that the on-chain figure matches the evidence that existed then. On Hedera this is a natural job for the Hedera Consensus Service, with the documents themselves kept off-chain under the institution's control1.
Failure scenarios and how the design should respond
NAV arrives late
Early signalNo update inside the staleness window before a dealing cut-off.
MitigationPause subscriptions and redemptions automatically, tell holders why and resume only on a fresh signed value; never fall back silently to the previous NAV.
Valuation disputed
Early signalA holder, lender or auditor challenges a published appraisal.
MitigationFollow the dispute process in the documents, flag the value as contested on-chain and in reporting, and record any correction as a new signed update referencing the old one.
Custodian error
Early signalA reserve statement is restated or an attestation finds a shortfall.
MitigationStop new issuance through the reserve check, publish the restated figure with its evidence and follow the remediation the documents require.
Signer key compromised
Early signalUpdates arrive that the institution did not authorise, or deviation checks trip unexpectedly.
MitigationRevoke the key in the signer registry, pause dependent actions and replay verified updates from the evidence trail.
Questions and answers
Can a public price feed work for illiquid assets?
Rarely. Public price feeds aggregate trades or quotes from active markets, and property, private credit or unlisted shares do not have them. A feed that looks live for an asset valued quarterly implies precision that does not exist. Illiquid assets are better served by signed valuations from an accountable valuer or administrator, displayed with their date, plus safeguards that pause actions when those valuations go stale.
How often should NAV update on-chain?
As often as the fund calculates it, and no more. The on-chain NAV should mirror the dealing and valuation schedule in the fund's documents, whether that is each dealing day or a monthly or quarterly cycle. Updating more often with estimates creates two competing prices. If intraday indications are useful, publish them as clearly labelled estimates, separate from the official NAV used for dealing.
Who is liable for wrong data in an RWA token?
Liability follows legal and contractual roles, not the technology. An administrator that miscalculates NAV, a custodian that misreports holdings or a valuer that issues a negligent appraisal stays responsible under its agreements and the applicable law. The oracle design should make that accountability provable: every value signed by the responsible party, linked to its source document, with corrections recorded. Contracts with oracle or attestation providers should spell out their own responsibilities.
Do we need a decentralised oracle network at all?
Only for data with a genuine market that benefits from several independent sources, such as a reference price for a liquid asset. Most RWA data, including NAV, valuations, custody statements and corporate actions, comes from one accountable institution, so the right pattern is a signed attestation from that institution. Putting a network in front of a single source does not make the source more reliable.