Oracles: how a physical asset reaches the blockchain

Imagine a token that represents a fraction of gold bars kept in a vault. The smart contract should only allow new tokens to be created if there is matching gold. But the contract has no eyes. It does not visit the vault, does not read the custodian’s statement and does not know today’s gold price.

Someone has to tell it. That someone is the oracle. This article explains how oracles work, what kinds of real-world asset data they carry and why they are one of the most underestimated risk layers in tokenization. The role of code in real-world assets is covered in smart contracts applied to real-world assets; here the focus is the bridge between the physical world and the network.

Why the blockchain needs oracles

A smart contract is a program that runs on the blockchain. According to the US standards institute (NIST), it must be deterministic: given the same input, every computer on the network has to reach the same result. That is why the contract cannot fetch data from the internet on its own; the information has to be delivered to it as a parameter. NIST calls any use of data from outside the system itself an oracle (NIST, NISTIR 8202, 2018).

The Ethereum documentation defines oracles as applications that fetch, verify and transmit external information to smart contracts (ethereum.org, Oracles). Without them, a contract only knows what is already on its own network: balances, transactions and the state of other contracts.

The oracle problem

The blockchain is good at one thing: preventing a record from being changed without leaving a trace. It does not know whether the record is true.

NIST sums up the point: the network can record data entered by people or by sensors, but there may be no way of knowing whether it reflects what happened in the real world. A sensor can fail. A person can record something false, by mistake or on purpose. The document’s example is direct: if someone pays in cryptocurrency for a physical object, the network has no way of knowing whether the object was shipped without relying on a sensor or an outside person.

This is the oracle problem. In tokenized assets it is central, because the token’s value depends precisely on facts that happen off the network.

What real-world asset data crosses the bridge

In a tokenized real-world asset, the oracle can carry several kinds of information. The examples below are general categories, not a description of a specific project:

Type of data	Example	Who usually knows
Existence and reserves	Amount of gold in the vault, account balance	Custodian, auditor
Value	Fund share value, reference price	Administrator, pricing provider
Payment events	Rent received, installment paid	Issuer, bank, administrator
Legal events	Court freeze, transfer of ownership	Public registries, issuer
Physical state	Temperature of a shipment, energy consumption	Sensors

For each row, the question is the same: does the information come from whoever produces it or from whoever has an interest in it?

Proof of reserve: what it shows and what it does not

A common use of oracles in backed assets is proof of reserve: data published on the blockchain stating how much reserve exists for the tokens issued. The contract can, for example, block new issuance if the reported reserve falls below the total number of tokens.

The documentation of Chainlink, a company that operates an oracle network cited as an example by the Ethereum documentation itself, describes three possible origins for this data (Chainlink, SmartData):

• Third party: an auditor or accounting firm checks the reserves and reports a number.
• Custodian: the data comes directly from the bank or custodian holding the assets.
• Self-reported: the data comes from a system maintained by the token issuer itself.

For the self-reported case, the documentation itself warns that the company is not responsible for the accuracy of the reserve data reported by the issuer and that users should make their own assessment of the issuer’s risk.

In the newsroom’s assessment, this illustrates the limit of proof of reserve: it is only as reliable as whoever reports the number. A self-reported reserve, published on a blockchain, is still a statement by the issuer. And knowing that an asset exists does not, by itself, tell you whether there are debts or liens on it.

Centralized or decentralized

The Ethereum documentation separates two designs:

• Centralized oracle: a single entity controls the data. It is simple, but it becomes a single point of failure. If the entity makes a mistake, is attacked or goes offline, the contract receives wrong data or no data at all.
• Decentralized oracle: several participants query sources and reach a consensus. Comparing sources reduces the risk of invalid data, and incentive mechanisms reward those who report correctly and penalize those who deviate.

Decentralization does not solve everything. A study by the Bank for International Settlements (BIS) points out that pursuing full decentralization requires complex consensus protocols that reduce efficiency, and that introducing some degree of centralization means placing trusted parties in a system designed to do without trust. The authors concluded that crypto-based decentralized finance tends to remain confined to crypto assets, without easily extending to real-world assets (BIS, Bulletin 76, September 2023).

For physical assets, there is an additional limit: often only one source truly knows the fact, such as the vault’s custodian or the property registry office. Having ten nodes repeat the same source does not make the data any truer.

The risks regulators point to

The Financial Stability Board (FSB) devotes a section of its 2024 report to oracles (FSB, October 2024). The main points:

• Oracles can make it harder to correctly assess the price and quality of tokenized assets.
• The rules that apply to data providers in traditional markets may not fully cover oracles, or oracles may operate in breach of those rules.
• Oracles can be vulnerable to attacks and manipulation that exploit code flaws.
• In decentralized arrangements, there may be no one responsible for assessing the reliability of the information the contract uses.

The FSB also notes that programmed contracts can trigger automatic liquidations based on prices reported by oracles. Wrong data, in this case, does not sit idle: it becomes immediate action.

The International Organization of Securities Commissions (IOSCO), in a November 2025 report, goes in the same direction: when a contract depends on external data brought in by oracles, there is exposure to a single point of failure or corruption, with oracles that may be subject to manipulation, fraud or control by unknown parties that are not audited or assessed by third parties (IOSCO, 2025).

Questions to ask about a project’s oracle

• What outside data does the contract use? Price, reserves, payments, legal events?
• Who is the source of each piece of data? An independent auditor, a regulated custodian or the issuer itself?
• Is the oracle centralized or decentralized? If centralized, who operates it?
• How often is the data updated, and what does the contract do if updates stop?
• Is there an audit of the oracle and the source, or only of the contract?
• Who is legally liable if the data is wrong and causes a loss?

These questions complement the checklist in how to analyze the risks of a tokenization project. As with any risky investment, it is possible to lose the entire amount invested, including through the failure of a data source.

Key takeaways

• A smart contract only knows what someone tells it. In a tokenized asset, the oracle is the bridge between the physical fact and the code.
• The blockchain protects data against alteration once recorded, but does not check whether it is true. Trust shifts to whoever feeds the oracle.
• When evaluating a project, find out who the source of each piece of data is and who is liable if it gets it wrong. Data self-reported by the issuer, even when published on-chain, is still the issuer’s statement.