Connecting Ethereum to the Real World: Oracles and Decentralized Storage

Disclaimer: This article is for informational and educational purposes only and simplifies underlying technical concepts for clarity. It is not financial, investment, legal, or security advice.

Ethereum oracles and decentralized storage solve two problems every real-world blockchain application runs into. Smart contracts can execute predefined rules on Ethereum, but their capabilities are limited to the information and state available on the blockchain.

Real-world applications often need external information, such as asset prices, weather conditions or event results. They may also need to store documents, images and other files that are too large or expensive to keep directly on Ethereum.

Consider a lending protocol that needs the current price of ETH to calculate collateral values. Or imagine an insurance application that automatically pays farmers when rainfall falls below an agreed threshold. Both applications depend on information that originates outside the blockchain.

Similarly, a tokenized real estate platform may need to associate a digital token with property photographs, valuation reports and legal documents without storing every file on Ethereum.

Two technologies help address these challenges:

• Oracles bring external information into a form that smart contracts can use.
• Decentralized storage provides ways to store and retrieve files outside the blockchain while maintaining references to that content.

Together, these technologies help Ethereum applications interact with real-world activities rather than operating entirely within the blockchain.

1. The Oracle Problem: Why Ethereum Needs External Information

Ethereum is designed so that participating nodes can independently execute transactions and verify the resulting state. They must follow the same rules and reach consistent results.

Imagine a smart contract that needs to check a weather website to determine whether it should pay an insurance claim.

If every Ethereum node independently accessed that website, different nodes might receive different results. The website could update between requests, become temporarily unavailable or return different information to different users. The network could no longer rely on that external request to produce a consistent execution result.

For this reason, smart contracts cannot directly browse the internet, query an external database or retrieve live information from a cryptocurrency exchange during execution.

Ethereum can access information already recorded on the blockchain, including account balances, smart contract state and data submitted through transactions. Information originating outside the blockchain must first be brought on-chain through an appropriate mechanism.

An oracle acts as a messenger that brings external information into the blockchain environment. However, the messenger's reliability matters because a smart contract can only make sound decisions if the information it receives is sufficiently accurate.

2. What Can Oracles Do?

Oracles can provide different types of information, depending on the application and the oracle system.

Chainlink, Pyth, Chronicle, RedStone and UMA are examples of oracle services, although their architectures and capabilities differ.

Two applications are worth looking at more closely: price feeds and randomness.

Price Feeds

Lending protocols need to know the value of collateral to determine how much users can borrow and whether their positions remain sufficiently collateralized.

For example, a protocol may allow a user to deposit ETH and borrow USDC against it. The protocol needs an ETH price to calculate the collateral's value and apply its borrowing limits. A reliable price feed is therefore an important component of the protocol's risk management.

Randomness

Randomness is more difficult to generate safely on a blockchain because transactions and contract execution must be verifiable. A poorly designed random-number mechanism could allow participants to predict or influence outcomes.

Oracle services can provide randomness through mechanisms that include cryptographic proofs, allowing smart contracts to verify that the result was generated according to the service's specified process.

What is randomness used for?

• Random NFT distribution: Imagine an NFT project distributing 1,000 different artwork designs to buyers. Randomness can determine which design each buyer receives, making the allocation harder to predict or manipulate.
• Blockchain games: A game might need to randomly determine whether a player receives a rare item, encounters a particular enemy, or wins a reward. Verifiable randomness can make these outcomes fairer.
• Lotteries and prize draws: A smart contract can select a winner from eligible participants using a random result. A reliable randomness mechanism helps prevent the organizer or participants from choosing a favorable outcome.
• Random selection in applications: Applications can use randomness to select jurors, reviewers or participants for certain tasks, assign game roles, or distribute opportunities among eligible users, depending on the protocol design.

3. How Does an Oracle Deliver Information to Ethereum?

Consider a lending protocol that needs the latest ETH/USD price. The process typically involves software operating outside Ethereum and smart contracts deployed on the blockchain. The simplified flow is:

Step 1: External Data Is Collected

Oracle nodes obtain information from external data providers, cryptocurrency exchanges or other market sources. Suppose three sources report the following ETH prices:

These figures are illustrative. Actual oracle systems may use different sources, validation procedures and aggregation methods.

Step 2: The Oracle System Processes the Information

The oracle system processes the observations and, depending on its design, combines reports from multiple sources or independent operators. For this example, suppose the system takes the median of the three reports, which gives a price of $3,000.

The objective is to provide a reliable value rather than blindly accept an isolated observation that could be inaccurate or manipulated.

Step 3: A Transaction Brings the Information On-Chain

The oracle's off-chain software cannot directly change Ethereum's state. In a common push-based arrangement, an authorized transmitter submits an Ethereum transaction containing the price report to an oracle smart contract.

The transaction is signed and broadcast to Ethereum. Once included in a block, Ethereum executes the transaction and applies the contract's verification and update rules. This transaction consumes gas, just like other Ethereum transactions.

Step 4: The Oracle Contract Makes the Information Available

If the report satisfies the contract's requirements, the oracle contract updates the price information recorded in Ethereum's state. For example, the previous reported ETH price might be $2,950, while the latest reported price is $3,000.

Other smart contracts can now retrieve the latest available price through the oracle's interface.

Step 5: The Application Uses the Information

A lending protocol such as Aave can read the reported ETH price and use it to calculate collateral values. The protocol then applies its own rules to determine borrowing capacity or whether a position qualifies for liquidation.

The oracle supplies the price. The lending protocol makes the lending decision.

How Does the Smart Contract Know the Price Has Changed?

In a typical oracle price feed, the oracle system detects the price change, not the smart contract itself. Let's use Chainlink's ETH/USD price feed as an example.

1. The oracle monitors external prices. Oracle nodes collect ETH prices from external data sources, such as exchanges.
2. The oracle system checks whether an update is needed. It evaluates conditions such as whether the price has changed beyond a configured deviation threshold or whether the heartbeat interval has elapsed.
3. The oracle publishes an update. If the conditions are met, the oracle system arranges for a price report to be submitted to Ethereum.
4. The oracle contract updates its stored price. Once the update transaction executes successfully, the latest price becomes available on-chain.

Putting It Together

Imagine the following sequence:

1. ETH is priced at $3,000 on-chain.
2. The external market price rises to $3,040.
3. The oracle system detects that an update condition has been met.
4. An oracle transaction updates the on-chain price to $3,040.
5. A user submits a transaction to borrow USDC from Aave.
6. During execution, Aave reads the latest stored price of $3,040 and applies its collateral and borrowing rules.

4. How Often Does an Oracle Update Its Information?

Oracles do not necessarily submit a transaction every second. Frequent updates can be expensive, and different applications have different data requirements. Price feeds commonly use two types of update conditions.

• Deviation threshold: An update may be triggered when the reported price changes by a specified percentage relative to the previous report.
• Heartbeat: An update may be triggered when a configured time interval has elapsed, even if the price has not changed significantly.

Suppose a hypothetical ETH/USD feed uses a 1% deviation threshold and a one-hour heartbeat.

If ETH moves from $3,000 to $3,015, the price has changed by 0.5%. That movement alone would not cross the hypothetical threshold.

If ETH subsequently moves to $3,035, the change from $3,000 exceeds 1%, potentially triggering an update. The heartbeat provides another reason to update the feed when the configured interval expires.

Push-Based and Pull-Based Oracles

There are different ways to make external information available to a smart contract.

In a request-response arrangement, the external information generally arrives asynchronously. An ordinary smart contract cannot pause its execution while waiting for an internet request to finish.

1. Push-Based Oracle

Example: An oracle regularly updates Ethereum with the latest ETH/USD price, which a lending protocol such as Aave can use.

Which transactions occur on Ethereum?

• Transaction 1: The oracle submits a price update. This costs gas and changes the oracle contract's state.
• Transaction 2: The user interacts with Aave. Aave reads the stored price as part of this transaction. The read does not require a separate oracle transaction, although the overall Aave transaction consumes gas.

The price update may be triggered by a schedule or a rule, such as a sufficiently large price change.

2. Pull-Based Oracle

Example: A DeFi application needs the latest ETH/USD price at the exact moment a user borrows. Instead of relying only on a previously stored price, the user or application supplies a signed oracle report with the borrowing transaction.

Which transactions occur on Ethereum?

• The oracle report is generated and delivered off-chain. That alone does not require an Ethereum transaction.
• Transaction 1: The borrowing transaction includes the signed report. The on-chain contract verifies it and uses the price during execution.

Unlike the push model, a separate transaction to update the oracle contract's stored price may not be needed. The exact design depends on the oracle protocol. Pyth is a widely used example of a pull-based oracle.

3. Request-Response Oracle

Example: A crop insurance contract needs rainfall data for a particular location and period to determine whether a farmer qualifies for a payout.

Which transactions occur on Ethereum?

• Transaction 1: The insurance contract records the data request. This changes on-chain state and costs gas.
• Off-chain activity: The oracle obtains the rainfall data.
• Transaction 2: The oracle submits the response. The contract processes the result and may execute the payout as part of this same transaction.

5. How Do Oracle Networks Maintain Reliability?

A single data provider would create a single point of failure. If that provider supplied an incorrect value, became unavailable or deliberately manipulated its report, every application relying on it could be affected. Oracle systems therefore use different safeguards to reduce the risk of incorrect information.

• Multiple data sources: Prices can be collected from several exchanges or independent providers rather than relying on a single market. This reduces dependence on one source, although multiple sources may still share weaknesses or experience similar market distortions.
• Multiple independent operators: Some oracle networks use multiple independent node operators to collect information and participate in producing a report. The resulting value may be determined using aggregation methods such as a median, reducing the influence of a small number of abnormal observations.
• Financial incentives: Some oracle designs use fees, staking arrangements or other economic incentives to encourage accurate reporting and discourage misconduct. The exact incentives and penalties depend on the system.
• Dispute mechanisms: Some oracle systems allow participants to challenge a reported answer and use a defined dispute-resolution process to settle disagreements. For example, UMA uses an optimistic oracle design in which assertions can be disputed and escalated to a resolution process.
• Safety limits: Applications can reject stale data, check that prices fall within plausible ranges or use time-weighted prices instead of relying on a single instantaneous market observation.

These measures can reduce risk, but they cannot eliminate every source of error.

6. Oracle Failures: What Happens When the Data Is Wrong?

Oracle failures demonstrate why reliable external information is essential. A smart contract can execute exactly as programmed and still produce a harmful outcome if its input is incorrect. This is often summarized as garbage in, garbage out.

Synthetix: An Incorrect Exchange Rate

In June 2019, Synthetix experienced an incident in which an external data provider intermittently reported the South Korean won exchange rate at approximately 1,000 times its correct value.

The oracle system failed to filter out the erroneous observation. An automated trading program detected the pricing error and executed trades that generated apparent profits exceeding $1 billion in less than an hour.

That figure represented reported trading profits in the system, not a confirmed equivalent cash loss. The trader agreed to reverse the trades in exchange for a bug bounty. The incident demonstrated how a single incorrect value can affect an entire application when its smart contracts trust that value.

Compound: A Sharp Price Discrepancy

In November 2020, DAI, a stablecoin designed to track the US dollar, briefly traded at approximately $1.30 on Coinbase Pro, a price source used by Compound's oracle at the time. The price movement contributed to liquidations of approximately $88.4 million worth of collateral.

The incident showed that oracle-related losses can occur even when a price comes from a legitimate exchange. A temporary market discrepancy can have serious consequences if a protocol relies too heavily on that price.

Mango Markets: Manipulating a Market Price

In October 2022, an attacker manipulated the market price of MNGO, the token used by Mango Markets, a trading and lending platform on Solana.

The attacker's trading activity caused the reported price to rise sharply. The inflated valuation made the attacker's positions appear more valuable, enabling the attacker to borrow and withdraw other assets against that apparent value.

The incident demonstrated how a relatively illiquid market can be manipulated when a protocol relies on prices that are vulnerable to trading activity.

bZx: Distorting Prices in Thin Markets

The bZx incidents in February 2020 demonstrated how flash loans and market-price manipulation could be combined to exploit DeFi systems.

In one incident, an attacker used borrowed funds to manipulate the price of a synthetic dollar token on markets used by bZx's pricing mechanism. The distorted valuation enabled the attacker to obtain more value from the protocol than would otherwise have been available.

The broader lesson is that a price observed on an exchange is not necessarily a reliable measure of an asset's underlying value, particularly when the market has limited liquidity.

What Do These Incidents Teach Us?

The appropriate safeguards depend on the application, but they may include independent data sources, aggregation, freshness checks, price-deviation limits and careful consideration of market liquidity.

7. Decentralized Storage: Why Not Store Everything on Ethereum?

Oracles address the problem of external information. A separate challenge arises when applications need to store documents, photographs, videos or other large files.

Storing large files directly on Ethereum is generally expensive. Blockchain data must be processed and maintained by network participants, and writing new data to Ethereum consumes gas.

Ethereum is therefore better suited to recording important state, such as token ownership and contract rules, than to storing high-resolution photographs, lengthy legal agreements or videos. An application can instead store files outside Ethereum and keep a reference to the relevant content on-chain.

Decentralized storage systems provide ways to distribute files across independent computers or storage providers rather than relying exclusively on a single company's server.

Why Not Use an Ordinary Server?

A conventional cloud service or company server can be a practical way to store files. However, it introduces dependence on the organization operating that service. The company may change or delete the files, discontinue the service or cease operating.

This can create a problem for blockchain assets. An NFT might remain recorded on Ethereum even after the image referenced by the NFT disappears from the company's server. The token still exists, but its associated content may no longer be available.

Decentralized storage can reduce dependence on a single provider, although it does not automatically guarantee that files will remain available forever.

8. How Does IPFS Work?

IPFS, the InterPlanetary File System, is a protocol for addressing and retrieving content across a peer-to-peer network. Its central concept is content addressing.

This makes it possible to retrieve the same content from different computers that have a copy available. The simplified flow is:

Step 1: Upload the File

Suppose an organization uploads a document to an IPFS-connected storage service.

Step 2: Obtain the Content Identifier

The file receives a CID that identifies the content through IPFS's content-addressing system. The CID is not the file itself. It is a reference that can be used to locate and verify the corresponding content.

Step 3: Make the File Available

Other computers that have the content can provide it to someone requesting it. For continued availability, someone must maintain a copy. This can be done through pinning services or other storage arrangements.

Step 4: Record a Reference on Ethereum

A smart contract or token metadata record can store the CID or a reference to metadata containing the CID. The blockchain therefore records which content is associated with the relevant asset without storing the entire file.

Step 5: Retrieve and Verify the Content

An application can use the CID to retrieve the file. Because IPFS uses content addressing, any change to the file produces a different CID. This helps users verify that the retrieved content corresponds to the referenced content rather than silently accepting a different file at the same identifier.

However, a CID does not prove that a document is legally authentic or factually correct. It establishes a content reference, not the truth of the information contained in the file.

9. Other Decentralized Storage Networks

These systems have different architectures and guarantees. They should not be treated as interchangeable, and long-term availability depends on the particular network and storage arrangements.

A Real Estate Tokenization Example

Consider a company that tokenizes a real estate investment. The tokens represent investors' interests in the investment, while supporting documents include property photographs, valuation reports and legal agreements.

The company can store these files using a decentralized storage system and associate their CIDs with the token's metadata. When an investor views the token in an application, the application retrieves the metadata reference and uses it to access the associated documents. Meanwhile, Ethereum records the token ownership and executes the relevant smart contract rules.

This separates the ownership record from the supporting files. The documents do not need to be stored directly on Ethereum, but their content can be referenced and checked against the recorded identifiers.

10. What Should Be Stored On-Chain and Off-Chain?

Not all information belongs in the same place. The decision should consider security, cost, privacy, availability and how frequently the information changes.

An Important Privacy Consideration

Ethereum and public IPFS content should not be treated as private storage.

Publishing personal information on a public blockchain or public storage network can create serious privacy problems. Data may be replicated, difficult or impossible to remove, and accessible to anyone who can retrieve it. This matters for applications handling investor information, customer records, financial statements or legal documents.

For tokenized financial products, sensitive documents should generally remain in an appropriately controlled storage system. If a public blockchain needs to reference a document, the application should consider whether it can use a non-sensitive identifier or a suitable cryptographic commitment instead of publishing the document itself.

11. Putting It All Together: An Automated Crop Insurance Application

Consider an insurance application that provides crop insurance to farmers in a region affected by drought. The policy states that the farmer will receive a payout if rainfall during a specified period falls below an agreed threshold.

The application needs to manage payments, evaluate weather conditions and provide access to the policy documents. Each component has a distinct role.

Step 1: The Policy Is Created

The insurer defines the policy conditions in an insurance smart contract. These conditions specify the rainfall threshold, observation period and payout amount.

The full policy document can be stored in an appropriate storage system, with a reference or cryptographic fingerprint recorded on-chain. Because the policy contains the farmer's personal details, it should be kept in controlled or encrypted storage rather than published openly on a public network such as IPFS.

Step 2: The Farmer Purchases the Policy

The farmer uses a wallet to interact with the application and submits the required payment. The smart contract records the relevant policy state and holds or manages the funds according to its rules.

Step 3: The Oracle Obtains Weather Information

A weather oracle retrieves rainfall information from suitable external data sources. The oracle processes the information according to its design and submits the relevant report to Ethereum through an authorized mechanism.

Step 4: The Insurance Contract Evaluates the Condition

The insurance smart contract reads the reported rainfall information and compares it with the conditions specified in the policy.

For example, suppose the policy promises a payout if total rainfall during a defined period is below 50 millimeters. If the oracle reports rainfall of 35 millimeters for the specified period, the contract can evaluate whether the policy's payout condition has been satisfied.

This assumes that the oracle report is valid, covers the correct location and period, and uses the measurement method specified by the policy.

Step 5: The Payout Is Executed

If the conditions are satisfied and the contract has sufficient funds, the smart contract can automatically transfer the agreed payout in a supported token, such as a stablecoin. The farmer does not necessarily need to submit a separate claim or wait for a manual assessment.

Step 6: The Farmer Accesses the Policy Document

The farmer can retrieve the policy document through the application using its storage reference. The application accesses the file from the relevant storage system rather than retrieving the entire document from Ethereum.

How the Components Work Together

The oracle supplies the external weather data, the smart contract applies the policy rules, a storage system holds the supporting document, and the wallet allows the farmer to interact with the application.

12. Choosing the Right External Data and Storage

For businesses building Ethereum applications, these decisions should be treated as part of the product and risk design rather than as purely technical details.

Choosing an Oracle

If the application depends on external information, the oracle is one of its important infrastructure providers. Consider the following questions:

• Does the oracle use multiple independent data sources and operators?
• How does it handle incorrect, stale or missing information?
• What happens if a price moves sharply or a source becomes unavailable?
• Can the application pause or limit activity when the data appears unreliable?
• Is the source appropriate for the specific information required?

Some businesses may choose to publish their own data, such as a gold vault providing information about its reserves. This is possible, but users must then rely on that business to report the information honestly and accurately.

Choosing Storage

Storage decisions should reflect the nature of the information. Public files that benefit from content verification may be appropriate for decentralized storage. Sensitive information should be kept in suitable controlled systems. Large files that change frequently may be more practical to maintain in conventional cloud storage.

The objective is not to decentralize every component regardless of cost or suitability. It is to choose the right architecture for the data and the application.

13. Conclusion

Ethereum smart contracts can execute predefined rules, maintain ownership records and interact with other contracts. However, real-world applications also need reliable ways to obtain external information and store supporting files.

Oracles bring information such as asset prices, weather observations and event results into a form that smart contracts can use. Decentralized storage systems such as IPFS, Filecoin and Arweave provide ways to store and retrieve files outside Ethereum while allowing applications to maintain references to that content.

The crop insurance example shows how these technologies can work together: an oracle supplies rainfall data, a smart contract evaluates the policy conditions, a stablecoin provides the payout, and a controlled storage system holds the full policy document, with only its fingerprint recorded on-chain. The real estate example demonstrates a related application in tokenization, where Ethereum records ownership while external storage holds the supporting documents and photographs.

Both technologies introduce their own dependencies. Oracle data may be incorrect or manipulated, while stored files may become unavailable or expose information that should have remained private.

The important design decision is determining which information belongs on the blockchain, which information must come from outside it, and which files should be stored elsewhere.

Ethereum provides the environment for recording state and executing rules. Oracles connect those rules to external information, while decentralized storage makes supporting content accessible without requiring every file to live on-chain.

Key Takeaways