Part 2 of 6 in “Real World Assets (RWA), Meet Real World Lies (RWL): Knowing What You Own in the Tokenized World,” a series about what tokenized assets represent, how information about them reaches the blockchain, and why none of this eliminates the need for trust.
Part 1 asked what kind of thing is being tokenized. Once we know that, we still need information about it: how much gold is in the vault, who owns the building, whether the aircraft was inspected, whether the borrower is paying. That is where the oracle problem begins.
What Is an Oracle?
A blockchain can evaluate information already available within its own system. It can determine whether a wallet controls a token, verify signatures, deal with consensus rules, and usually, It can follow instructions written into a smart contract.
What it can’t do on its own is look outside the network. It can’t inspect a building, call a tenant, count inventory, check a bank balance, read an aircraft maintenance logbook, or decide whether a painting is authentic. An oracle is the mechanism used to bring outside information into the blockchain environment.
That sounds straightforward enough. Retrieve the information, put it into the right format, and deliver it where the smart contract or token holder can use it. There’s several companies that do it. But there are at least two very different problems hiding inside that process.
The first is technical. Can the information be gathered, formatted, transmitted, and delivered reliably? The second is much harder. Was the information true in the first place? There’s an ever fuller treatment of this issue in Of Oracles & RWA Headwinds.
The Bank for International Settlements’ discussion of the oracle problem points to the basic tension. Systems designed to reduce reliance on trusted intermediaries still need outside parties when smart contracts depend on real-world information. The oracle may solve the problem of getting information onto the blockchain. It doesn’t necessarily solve the problem of whether the information deserves to be believed.
Before the Oracle, Someone Has to Define the Data
Every industry has its own measurements, definitions, reporting practices, and arguments about what matters. Public-company reporting is comparatively mature. Investors expect to find revenue, earnings, margins, cash flow, debt, and other familiar figures. Those figures aren’t naturally standardized. Decades of accounting standards, securities regulation, auditing practices, reporting rules, and data systems sit behind them.
The SEC’s Inline XBRL program allows financial information to be presented in a document that’s both human-readable and machine-readable. The tags don’t merely identify a number. They can connect it to a reporting period, accounting concept, units, and other context. Financial messaging has standards such as ISO 20022, which includes a common modeling approach, data dictionary, and business-process framework. Supply chains can use GS1 EPCIS and its Core Business Vocabulary to communicate what happened to an object, where and when it happened, and why. Commercial real estate has common measurements and reporting practices. OSCRE International maintains an open Industry Data Model covering the real-estate asset lifecycle, while the National Council of Real Estate Investment Fiduciaries, or NCREIF, develops data, performance-measurement, benchmarking, and reporting standards for institutional property investments. Even there, however, standards must cover a complicated asset lifecycle involving leases, valuations, operating costs, capital improvements, financing, occupancy, ownership structures, and local property records.
Move beyond mature financial markets and institutional real estate, and the data becomes much less standardized. What should be reported about an aircraft? A warehouse full of copper? A vineyard? A piece of industrial machinery? A painting? Who defines the required fields? Who updates them? How often? And what happens when the owner would prefer that one of those fields remain blank? In a lot of these areas, there’s some de facto practices. For example, used cars, boats, airplanes often have standard sets of fields and types of things that are expressed. But none of these are necessarily official or standard for the purposes of defining what would be needed as reporting elements for investments.
Before an oracle can deliver RWA data, somebody has to decide what the data is supposed to mean. Not to mention, who is vouching for it’s validity.
All of that took a lot of work. The standards had to be developed, debated, documented, revised, adopted, and connected to the systems people actually use. And that’s for established fields with large institutions, regulators, professional organizations, and decades of experience.
What about everything else?
Who decides which fields are required? How often should they be updated? Which definitions should be used? What happens when the owner would rather leave one of them blank?
There are common practices in many of these markets. Cars, aircraft, boats, buildings, and industrial equipment are routinely described using familiar sets of fields. But a familiar sales listing isn’t the same thing as a complete reporting standard for an investment. Before an oracle can deliver RWA information, somebody has to decide what the information is supposed to mean.
Then somebody has to stand behind it.
Right now? This is – my opinion – practically nowhere. Yes, there’s some de facto standards I suppose. Often those fields used in sales efforts and such. But for this sort of thing? There’s maybe some industry consortia out there in some categories. But not for everything getting a token slapped on it.
Taxonomy of Oracle Data
We’ve established the obvious… Different assets require different information. Still, much of the information falls into several recurring categories.
These categories describe the data needed to understand and evaluate the thing. They don’t tell us whether the data is true. That comes later.
BIS, (Bank for International Settlements) sums this all up nicely in “The oracle problem and the future of DeFi” “While introducing some degree of centralisation in oracles might boost efficiency, it also means adding trusted parties to a system designed to be trustless. As a result, crypto-based DeFi is likely to remain the preserve of crypto assets only, rather than being used for real-world assets.”
1. Identity and Reference Data
The first question is basic. What exact is the asset?
It might include:
- Asset type
- Serial number or registration number
- Legal description
- Manufacturer and model
- Location
- Date created, built, issued, or acquired
- Unit of measurement
- Relevant registry identifiers
This sounds simple, but even identity can become complicated. A building may include land, structures, equipment, leases, development rights, and separately owned improvements. A commodity token may represent a specific numbered bar, a share of a pooled inventory, or merely an obligation to deliver an equivalent quantity. It’s kind of like, I could have a singular and wholly unique original painting, or a print of it. Those prints might be signed or not. They could be numbered limited editions, signed or not.
Before asking whether the data is accurate, we first need agreement about exactly which thing the data describes.
2. Ownership and Legal-Status Data
This describes the legal relationships around the asset.
It might include:
- Legal owner
- Beneficial owner
- Custodian
- Token issuer
- Liens and other secured claims
- Mortgages
- Restrictions on transfer
- Pending litigation
- Bankruptcy status
- Insurance coverage
- Permits and licenses
For tokenized assets, this category is critical. A token may appear in a wallet, but the important questions remain off-chain. Does the token holder own the asset? Shares in the entity that owns it? A debt claim? A custodial receipt? A contractual right to some future payment? And which record wins if the blockchain and the legally recognized registry disagree?
3. Quantity, Location, and Custody Data
This is especially important for commodities and stored physical assets.
It might include:
- Quantity held
- Units and weight
- Purity, grade, or specification
- Storage location
- Custodian identity
- Segregated or pooled status
- Inventory movements
- Deposits and withdrawals
- Amount committed to other obligations
- Amount available for redemption
An oracle may accurately report that a custodian submitted an inventory figure of 10,000 ounces. That is not quite the same thing as independently establishing that 10,000 ounces exist, are unencumbered, and are available to token holders.
Even so-called proof-of-reserve systems still depend on data entering from custodians, auditors, banks, exchanges, or other off-chain sources. They can make reserve information more visible and can connect that information to on-chain controls. They do not eliminate the need to establish that the reported reserve information is true.
4. Physical Condition and Operational Data
This category describes the current state of the thing.
It might include:
- Condition
- Age
- Usage
- Maintenance history
- Inspection results
- Damage
- Repairs
- Remaining useful life
- Production output
- Downtime
- Occupancy or utilization
Some of this can come from sensors. Some comes from inspections. Some comes from maintenance systems. Some is entered manually by the same people whose compensation may depend on the answer.
A sensor may accurately report a temperature. That does not prove it was attached to the correct container. A maintenance database may show that an inspection was completed. That does not prove the inspection was performed competently. A property system may report 95 percent occupancy. That does not tell us whether the tenants are current on rent or whether side agreements materially changed the leases.
The data can be technically precise while still being economically misleading.
5. Financial and Performance Data
This describes how the asset or the business around it is performing.
It might include:
- Revenue
- Expenses
- Net operating income
- Rent collections
- Loan payments
- Delinquencies
- Production volume
- Royalties
- Distributions
- Cash reserves
- Capital expenditures
- Debt-service coverage
- Defaults
For public securities, much of this information fits within mature reporting frameworks. For private businesses, individual properties, equipment leases, receivables, and other bespoke assets, reporting may be less frequent, less consistent, and less independently reviewed.
Even familiar metrics can become slippery. Does “occupancy” mean leased space or physically occupied space? Does “revenue” mean billed revenue, collected revenue, or accrued revenue? Are repair costs treated as operating expenses or capital improvements?
A standardized field name does not guarantee a standardized calculation.
6. Market and Valuation Data
This describes what the asset may be worth.
It might include:
- Current market price
- Recent transaction prices
- Appraised value
- Comparable sales
- Bid and ask data
- Discount rates
- Capitalization rates
- Estimated liquidation value
- Model-derived value
This category is easiest when the asset trades frequently in a deep market. A widely traded stock or commodity can have an observable market price updated throughout the day.
A unique office building, aircraft, painting, or piece of industrial equipment does not. Its value may depend on an appraisal, a valuation model, a small number of comparable transactions, or simply the price one buyer is willing to pay.
Putting the appraisal on-chain does not turn the appraisal into an objective fact.
7. Compliance, Certification, and Event Data
This category describes whether important requirements have been met and whether important events have occurred.
It might include:
- Regulatory approvals
- Safety certifications
- Environmental compliance
- Tax status
- Inspection deadlines
- Lease renewals or terminations
- Insurance lapses
- Defaults
- Seizures
- Fires, floods, or other damage
- Product recalls
- Legal judgments
- Changes in control
These data points are often binary and consequential. A permit is valid or it is not. A loan is in default or it is not. Insurance coverage exists or it does not.
Unfortunately, they may also be delayed, disputed, jurisdiction-specific, or buried in systems that do not communicate with one another.
The Second Taxonomy: Where Did the Data Come From?
The type of data is only half the question. We also need to classify its provenance.
A useful hierarchy might look something like this:
- Directly observed data, generated by a market, instrument, sensor, or transaction system
- Authoritative registry data, obtained from a government, court, title system, depository, or regulated recordkeeper
- Independent attestation, supplied by an auditor, inspector, appraiser, laboratory, or other third party
- Counterparty-reported data, submitted by an owner, issuer, borrower, custodian, property manager, or operator
- Derived data, calculated from other inputs using a formula, estimate, model, or judgment
None of these categories is automatically trustworthy or untrustworthy. Sensors fail. Registries contain errors. Auditors miss things. Owners lie. Models make bad assumptions. But they do not deserve identical levels of confidence.
Every oracle data point should ideally carry information about:
- Who originated it
- Who transmitted it
- Who verified it
- When it was observed
- When it was last updated
- What definition was used
- Whether it was measured, reported, attested, or calculated
- Whether conflicting sources exist
- What level of confidence should be assigned to it
Without that context, the oracle is mostly delivering numbers without explaining what kind of numbers they are.
Standardization Is Not Verification
Standards can help tremendously. They can define fields, units, formulas, identifiers, timestamps, and message formats. They can make information easier to compare, exchange, and process automatically.
But standards cannot make someone fill in a field honestly. This is the distinction that gets lost in a lot of oracle discussions. The technical oracle problem is that a blockchain cannot independently access external information and therefore needs an outside mechanism to deliver it.
The deeper problem is that a smart contract will act on the information it receives whether that information is accurate or not.
BIS researchers describe this directly: smart contracts can execute based on externally supplied information regardless of its accuracy. So yes, we need better RWA data taxonomies. We need industry vocabularies, standard definitions, reporting schedules, source labels, and confidence indicators. But once all of that exists, we will still have the original problem. A perfectly functioning oracle can deliver a false occupancy number, a fabricated invoice, an inflated appraisal, or a nonexistent warehouse full of gold with extraordinary speed and technical precision. An oracle can prove what it was told. It cannot, by itself, prove that what it was told was true.
Wrapping Up
Part 1 classified the underlying asset or right. This article classified the information needed to describe and evaluate it. The first taxonomy asked “What kind of thing is being tokenized?” This one asks “What do we need to know about it?” And also, “Where does this information come from?”
Next in the series, Part 3 moves from the data problem to the human problem. Because even a perfectly functioning oracle still depends on someone reporting the underlying reality honestly.
See Also
- BIS, “The Oracle Problem and the Future of DeFi”: Explains why smart contracts require external data sources and why improving oracle infrastructure does not necessarily guarantee that the information supplied to the blockchain is accurate.
- Chainlink, “Smart Contracts and External Data: The Complete Guide”: Provides a practical overview of how oracles retrieve, format, verify, and deliver data from APIs, sensors, enterprise systems, and other off-chain sources.
- W3C, “PROV-DM: The PROV Data Model”: Defines a domain-independent framework for recording where data came from, who or what produced it, and which processes transformed it.
- SEC, “Inline XBRL”: Shows how standardized tags can make corporate financial reports simultaneously human-readable and machine-readable while retaining context about individual data points.
- IFRS Foundation, “IFRS Accounting Taxonomy”: Provides standardized, machine-readable elements for financial statements prepared under IFRS Accounting Standards, illustrating the extensive taxonomy required for comparable financial reporting.
- EDM Council, “Financial Industry Business Ontology”: Defines financial concepts, instruments, organizations, contracts, and their relationships so that data can carry a consistent meaning across systems.
- ISO 20022, “ISO 20022”: Describes the common modeling methodology, business vocabulary, and message framework used to standardize information exchanged by financial institutions.
- GS1, “EPCIS and Core Business Vocabulary”: Establishes a common language for reporting supply-chain events, including what happened to an object, where and when it happened, and why.
- OSCRE, “Introducing the Industry Data Model”: Presents an integrated real-estate data model covering assets, leases, transactions, operations, and other stages of the property lifecycle.
- NCREIF and PREA, “Real Estate Reporting Standards”: Develops standardized reporting and performance practices intended to improve consistency, transparency, and comparability across institutional real-estate investments.
AI Disclosure: I used AI to help with these articles. The concepts are mine. The opinions and assertions are mine; though of course not necessarily unique. The drafts are mine. AI is used for spell/grammar check and sometimes to fill out a few example bullet points I may have missed, and – just as with search – find relevant references. Any additional claims that an AI may insert are manually checked and edited by me. All reference sources are manually checked by me. (Most were actually known prior to draft and may have even be the inspiration behind some articles.) Perhaps obviously, I’ll also use AI tools to generate graphics.