What real-world assets actually need from an oracle
Most RWA architectures start by asking how to get a price on-chain. That is the wrong first question. Price is the best-solved problem in the entire stack. The parts that break in production are attestation, permissioning and what happens when two sources disagree.
Price feeds are a solved problem
For liquid assets, decentralized price feeds are mature, battle-tested infrastructure. Aggregation, deviation thresholds and heartbeat updates are well understood, and the failure modes are documented. If your real-world asset is a treasury bill or a listed security, the price component is close to a commodity.
The difficulty begins the moment the asset is not continuously traded. A private credit position, an invoice, or a warehouse of physical goods has no tick. It has a periodic valuation produced by a party with a name and a legal obligation. That is a fundamentally different object to feed on-chain, and treating it like a price is where designs go wrong.
Attestation is the real primitive
What an RWA protocol actually needs is a signed claim: this entity asserts this fact at this time, and here is what happens if the assertion is wrong. That claim carries an identity, a timestamp, a scope, and crucially a liability. A price feed carries none of those.
If your oracle design cannot express "who said this, and what are they liable for", you do not have an RWA oracle. You have a number.
In practice this means three separate channels, not one:
- Valuation: the periodic mark, with its methodology recorded.
- Existence and custody: proof the asset is there and who holds it.
- Status: whether the asset is performing, in default, encumbered or redeemed.
Collapsing these into a single feed is the most common architectural mistake we see. They update on different schedules, come from different parties, and carry different consequences when wrong.
Permissioning cuts both ways
RWA protocols usually need transfer restrictions: jurisdiction, accreditation, sanctions screening. The instinct is to put that logic in the token. The problem is that permissioning state changes far more often than token logic should, and an address that was eligible this morning may not be this afternoon.
Treating eligibility as oracle-delivered state rather than contract logic keeps the token simple and makes the permission set auditable. It also means a compliance failure is a data problem you can correct, not a migration.
Plan for disagreement before you need to
Every serious RWA design eventually faces two sources reporting different facts. The valuation agent says the asset is performing; the servicer reports a missed payment. On-chain, both are signed claims from authorised parties.
Systems that have not designed for this halt, and halting a settlement layer is expensive. The alternative is to make disagreement a first-class state: the protocol can hold, restrict redemptions, and escalate to a defined resolution path, all without human intervention at 3am.
What we build
Xora Rails treats attestation, permissioning and dispute state as separate, independently-updatable channels from day one, delivered through Chainlink CCIP where cross-chain settlement is involved. The result is that institutions connect their existing reporting to a defined interface rather than commissioning a bespoke stack.
Working on real-world assets and want to compare notes? Get in touch.