Of Oracles & RWA Headwinds

Tokenization of Real World Assets (RWA) is clearly on a tear, but will it be held back from true mass market adoption for lack of trusted information? A token says you own part of a building. But what if the roof starts leaking? Who reports it? Where does the report live? Who’s liable if nobody updates investors?

Traditional finance has reporting structures. And they still get things wrong sometimes or suffer from fraudulent claims. When we build an abstraction layer on top, we need a way to bridge a reporting information gap. Successful adoption here isn’t going to be about just splitting things into smaller pieces with tokens. Its time to look at why and suggest some solutions.

The idea for this post came out of a LinkedIn thread where Igor Samotesov talked about why trillions aren’t flowing quickly into onchain RWA instruments. Here are some more potential reasons and possible solutions.

TL;DR Version:

Essential Problem: RWA tokenization is not blocked because smart contracts are bad at holding tokens. The harder problem is real-world assets come with messy facts, changing conditions, legal rights, disclosure obligations, and asset-specific reporting practices. And blockchains being blind to the real world may be true enough, but also not a full blocking issue. The deeper reality is real-world assets are bundles of facts, rights, risks, reports, and more. A token can represent a claim on those things, but doesn’t magically make them simple. This is why some tokenization efforts struggle. They solve issuance mechanics before solving ongoing reporting, legal, and trust infrastructure. They may focus on chains and L1s and L2s and protocols and so on. Great. All necessary components. But it’s the more traditional legal nuts and bolts that matter even more now. Some seem to be maturing and accelerating here.

Traditional finance already has fragmented systems for managing reporting. Some are highly developed, like public-company financial reporting. Others are buried in PDFs, appraisals, servicing reports, private data rooms, spreadsheets and so on.

General Solution(s): RWA tokenization needs more than a better bridge between off-chain facts and on-chain state, not just “better oracles.” It needs better reporting taxonomies, attestations, canonical references, update standards, and more. This isn’t the glamorous part of the industry, but RWA needs more boring infrastructure plumbing. This isn’t about yet another protocol. It’s things like trusted custodian identity layers and clarity around regulatory issues. And these background parts need to be clear and become even more trusted than existing structures. This evolution may be an opportunity to fix existing flaws in traditional processes.

A useful RWA reporting framework probably needs layers. I’m not trying to sell the idea of one giant universal ontology that tries to describe every data element for every asset type in the world. The real world is too messy. The junk drawer always wins. But a layered taxonomy could help.

That’s the basics. If you want to go deeper? Read on…

Core Thesis: Expanded

RWA tokenization cannot scale only by improving token wrappers. It also needs standardized ways to represent, reference, update, and verify off-chain facts that give the token meaning. People know this already. And yet, we’re still missing major pieces of the trust chain. This doesn’t mean every fact must be onchain. Most probably shouldn’t be. Blockchains are not great databases for large document storage. They’re good at settlement, state transitions, permissions, and similar. They’re lousy for 90-page engineering reports and 400-line leases.

We may have some of the following parts, but we need at least these and likely more:

The token’s representation of ownership, economic exposure, or contractual rights.
The legal documents define what those rights actually mean.
The issuer or custodian maintains the canonical document repository.
Trusted professionals create reports: auditors, appraisers, etc.
Key facts from reports are summarized in standardized fields.
Fields are signed, attested, and may be oracle-published.
The blockchain stores a compressed reference: status flags, timestamps, signed attestations, document pointers, possibly more.
Smart contracts may use some of those facts.
The messier backup evidence remains off-chain, but traceable.
Legal enforcement still happens in the real world.

This all sounds more challenging than “put real estate on chain.” But it is probably closer to what widely adopted RWA infrastructure will actually require.

Taxonomy, Plus…

As much as we try to standardize contracts or processes for just about anything, there’s often exceptions.

Even so, there are often general structures by industry for data points that vary per deal type or reporting need. Public company information, for example, is well developed. And we can point to explanatory documents, such as an annual report. How do we do this for everything? Such as shared ownership of a local strip mall, a patent, a sports team, whatever. There’s likely a taxonomy of industries, followed by standard data points. Then we always have everybody’s favorite category of information called “Misc” that can be accommodated, (at least initially), by just accessing an external document. Trying to outright fix the entire junk drawer of unstructured information is likely overly ambitious.

By the way, I hate saying all of this. Because anyone involved with information architecture or taxonomy or ontology should be striving for cleanliness, right? But let’s be candid about history. Whether you look at book ISBN/book metadata drift, UPC/GS1/GTIN product codes for SKUs, customer data, product data, and perhaps especially web meta data formats, or whatever, we have messes. Ask anyone who works in these industries and has looked into datasets. We have field abuse everywhere. So maybe this time let’s admit there’s a “Misc” category and account for it. Again going to a post from Igor Samotesov he says, “RWA protocols cannot scale on analog disclaimers. They need Layer 0 – a Physical Validation Layer that translates structural reality into strict CapEx mathematics before a single token is minted.”

So where does such information live? Even as taxonomy is structured, we’d need a root of trust for the basics, and individual industry consortia could add their branches to it as necessary. Real estate needs lease rolls, occupancy, appraisals, environmental reports, insurance, title, etc. Commodities need custody, location, assay, weight, grade, warehouse receipts, insurance, movement history, etc. Private credit needs borrower data, collateral, covenants, payment status, delinquency, etc. And so on for every industry. You get the point. A layered taxonomy could help. At the root, there might be common concepts that apply across many RWA categories, then branches.

Oracles could follow these specs for standards and some compressed info could live onchain. As we know, blockchains are generally not good databases for larger scale info. Maybe most data doesn’t go onchain at all, but a trusted canonical reference for a Custodian goes there. In any case, the reference would include a link to the junk drawer docs, which could live with a Custodian or out in IPFS somewhere.

So taxonomy is necessary, but not sufficient. RWA needs taxonomy plus at least the following:

canonical source references
document custody
signed attestations
update frequency rules
material-event rules
identity and permissioning
jurisdictional mapping
investor access rights
machine-readable summaries
human-readable reports
dispute and correction mechanisms

Will this happen? Only if demand is there. It seems common sense that it’s necessary for mass adoption. Though we may have to see a forcing issue first. That is, if some folks get burned by fraud or incompetence, the industry response might need to be to get this sorted out. I’ve said we’re not likely to get past the junk drawer, but this is still an opportunity to clean up a lot of things.

Solution Space

Companies like Chainlink may talk about protocols for offchain reporting, but these are mechanisms for moving or verifying selected data points, not a full reporting taxonomy for what RWA asset classes should disclose. A useful RWA reporting system would need a root of trust for the basics. This does not necessarily mean one global body controls everything. That would be unrealistic and probably undesirable. But there needs to be some trusted way to know what type of asset is being represented, what reporting model applies, who is authorized to report on it, and where the canonical information lives.

Maybe it’s a layered standard. I’m not going to try to build an entire taxonomy right now, but here’s a suggestion for a base:

Asset category
Legal wrapper
Jurisdiction
Issuer
Custodian
Token standard
Investor eligibility
Transfer restrictions
Reporting obligations
Canonical document location
Attestation authorities

Industry consortia could add branches. It wouldn’t have to be a huge philosophical ontology project on day one. It could start with practical data basics investors need to know.

Oracles Are Bridges, Not Maps

Oracle plumbing is of course important. Oracles can bring off-chain data on-chain, or at least make selected off-chain data accessible to smart contracts. They can publish prices, attestations, proof-of-reserve data, and so on. But oracles are mostly bridge mechanisms. They don’t answer the question of what should be reported. And they shouldn’t have to care any more than an SMTP email protocol has to care what’s in a message. They’re transport layers.

Given that tech-oriented folks like to build tech oriented things and we needed this layer, it’s easy to see how it got started. But real people mostly don’t care about mechanisms. There’s a difference between transport and meaning. And it seems we could use more effort on the meaning.

For RWA, here’s a small starter list of the kinds of info that would need to be accounted for in a taxonomy or referenced documents.

Which facts become onchain state?
Which facts remain off-chain?
Who is authorized to attest to each fact?
What is the required update frequency?
Where do source documents live?
Who can access them?
What happens if a report is late?
What happens if an attestation is wrong?
What happens if the asset is impaired?
What happens if the token and the legal record disagree?
What counts as a material change? (This one might be especially challenging given there may be judgement involved in such things.)

Oracles can transmit info. But they don’t answer any of these things in and of themselves.

Maybe a “TruthSayer Custodian” Model?

We have Custodians for the assets. Maybe we need similar to be Custodians of information.

Such a service could maintain things like:

asset reporting schemas
industry-specific reporting templates
document repositories
signed attestations
hash registries
oracle adapters
report update schedules
material-event logs
investor disclosure portals
AI summaries of messy documents
exception flags
legal-document references
compliance mappings
onchain state feeds

The raw data should probably not live onchain at all. Instead, the blockchain might include a trusted canonical reference to the current reporting package. Whether these are traditional URL addresses, CIDs (Content Identifier) within the IPFS world, or something else doesn’t really matter. What matters is that they’re there, reliable and persistent. This would give the token a verifiable connection to the current state of the asset without pretending the blockchain itself has inspected a roof or checked that a plot of land has a building vs a vacant lot.

Would this be a company? The obvious challenge is business model. Or is it more like open-source plumbing that becomes valuable only when adopted by issuers, custodians, platforms, and investors?

Existing Tokenization Cottage Industry

The tokenization stack playbook is becoming clearer. And we have more companies in the RWA tokenization space. (RWA Directory, RWA Platforms) However, it still looks like they can all take us there, but then what?

As in a past article, I’ll rely once again on one of the many depictions from Tahir Nadeem Chaudhry. This is a repeat from an earlier post, but bears a re-look in this context. It seems like Step 6, Compliance & Risk Management remains a challenge in an ongoing way.

Remaining Issues

What happens after the token exists? Who updates the asset status? Who tells investors the roof is leaking? Where does the updated report live? What if the report changes the valuation? What if the custodian changes? And so on.

Real world legal rights are still everything. A token doesn’t have value just because it exists. It’s valuable because it represents some enforceable claim. That claim may be ownership, redemption, revenue share, debt repayment, or something else. The exact legal relationship matters and that needs to be represented. It’s great that global regulatory clarity has been coming fast this past year, especially in the U.S. There’s a saying some crypto purists like that says, “Code is Law.” Well, it’s not. Law is Law. Yes, yes, code can control some transactions in a decentralized blockchain and you can call it self-sovereign if you want, regardless of jurisdictional law. That doesn’t make it law. Code is still just an automated execution mechanism. And the name “smart contract” notwithstanding, such things are not necessarily legal contracts. In contract law, a legal contract requires an offer, acceptance, consideration, and mutual intent. Most smart contracts are just software scripts running on a distributed state machine. If the code says one thing (e.g., a bug transfers a tokenized house to the wrong address) but the county land registry and a judge say another, the judge will win. The sheriff will physically enforce the judge’s order, not the smart contract’s state. These contracts are not smart. They are rigid, literal, and completely lacking in human judgment or contextual awareness. So any data they may act on must be clearly documented.

Meanwhile, there’s Privacy and Transparency. Investors may want transparency. Issuers may need confidentiality. Regulators may need access. Others may have privacy rights. Zero knowledge proofs may be useful in some cases. But sometimes things might be simpler. For example, ownership can be tokenized onchain and identity still maintained in an issuer’s private systems. There should be nothing wrong with this with private attestations and auditing. Or rather, an investor can decide if it’s ok or not. The point is, there’s likely ok solutions here already.

Wrapping Up

RWA tokenization remains a major financial infrastructure trend at present. There are real advantages in programmable settlement, faster transfer, fractional access, automated compliance, composability, and potentially better transparency. Plus all the other goodness that’s getting sold in terms of what might be possible.

But the hard part is not simply creating tokens. The hard part is connecting those tokens to messy off-chain reality in a way institutions, regulators, courts, and investors can actually rely on. We’re still missing some of these pieces in terms of reporting. Until some of these questions have standard answers, tokenized assets may continue to grow, but the biggest pools of capital may keep moving cautiously.