DEV Community: Mandie Brugman

Why Oracle Networks Feed Outside Data

Mandie Brugman — Wed, 09 Sep 2026 19:00:59 +0000

Oracle networks feed outside data because blockchains cannot safely query the outside world while their nodes are trying to reach the same result. The detail that makes this click is that an oracle does not make a smart contract less deterministic: it turns an external observation into an onchain fact first, so every node can execute against the same recorded input.

What counts as outside data?

Outside data is any information the contract cannot derive from its current chain state. That includes an ETH/USD price from exchanges, a weather measurement, a sports result, a payment confirmation, a reserve balance, or a message originating on another network. The useful term is not “real-world data” alone; the boundary is whether the information already exists in the ledger that will execute the contract.

An oracle is therefore an input system. It retrieves an observation, checks or combines it, and publishes a value that another contract can read. It does not magically prove that the observation is true. The application still has to decide which sources count, how fresh the answer must be, what quorum is sufficient, and what happens when the data is missing or disputed.

Why can’t a smart contract call an API?

A smart contract runs on many machines, and those machines must produce the same state transition from the same transaction. An ordinary API does not offer that guarantee. Its response can change between requests, depend on timing or location, disappear during an outage, or return different values to different callers. If one validator reads one price and another reads a slightly different price, consensus can fail.

Keeping external calls outside execution is a feature of deterministic blockchains, not an oversight. The chain first reaches consensus on a transaction that records the oracle’s answer. Later, every node can read that onchain answer from the same state. The cost is an additional trust and operating layer: someone must fetch the information, pay for publication, and remain available when the application needs it.

What actually moves through an oracle network?

The cleanest way to understand an oracle is to separate the asset from the message. In a lending market, for example, the oracle may report a collateral price while the collateral remains inside the lending contract. The oracle moves information; the application decides whether that information changes ownership or releases funds.

The request: a user or consuming contract sends an onchain message describing the data needed, often while paying gas.
The observation: independent oracle nodes query exchanges, APIs, databases, or other networks. No user asset needs to leave the application for this step.
The report: nodes compare their observations and produce an aggregated result. In a network using Offchain Reporting, much of that coordination happens offchain before a final report is signed.
The publication: a transmitter submits the report to the oracle contract. The oracle contract now holds the latest value or makes it available through a feed.
The action: the consuming contract reads the value and updates its own state. Only here might an asset be transferred, liquidated, minted, or released.

That sequence matters operationally. Oracle nodes generally do not custody the borrower’s collateral merely because they supplied its price. The user, escrow contract, or protocol treasury holds the asset; the oracle supplies the message that can change what the contract is permitted to do.

Why use a network instead of one data provider?

A single API creates a single point of failure and a simple manipulation target. A decentralized oracle network spreads the job across node operators and data sources, then uses aggregation to reduce the influence of one bad response. A median is useful for market prices because an extreme reading can be discarded without letting one node dictate the result.

That protection has limits. If the underlying exchanges are thin, the selected sources are correlated, the reporting quorum is too small, or the feed is stale, aggregation can produce a neatly signed wrong answer. The security of the application therefore includes the oracle configuration, source quality, update frequency, deviation threshold, and fallback behavior. A feed that is cheap and frequent may be the right choice for lending, while a slower and more carefully verified source may suit settlement.

Is every cross-chain message an oracle?

No. A bridge or messaging protocol usually proves or relays a state transition from another chain; an oracle imports an observation that is not natively available to the destination contract. The two can work together, but they solve different problems.

Polkadot Network’s XCM, for example, expresses cross-consensus instructions such as transferring an asset or calling a remote function. Celestia Network addresses data availability: whether published blob data can be retrieved and verified, not whether a sports result or exchange price is correct. Owlto Finance is concerned with routing and settling cross-chain asset transfers. None of those functions, by themselves, replaces an oracle’s job of turning an external fact into a usable contract input.

That distinction matters when a Manta bridge is used in a multichain flow: the bridge carries value and messages, while the oracle supplies a fact about the world or another system. The bridge-side mechanics are represented by Manta Bridge.

When is an oracle the right choice?

Use an oracle when a contract’s decision depends on information absent from its own chain, and when recording that information onchain is worth the extra cost and trust assumptions. Before choosing one, check:

What exact fact is needed, and who is qualified to observe it?
How fresh must the answer be before the contract refuses to act?
Can several independent sources and operators withstand one failure?
Does the application need scheduled updates, or can it request data only when a transaction arrives?
What happens to the asset if the oracle is delayed, unavailable, or challenged?

My working rule is simple: use the chain for ownership and final state, use an oracle for a missing observation, and keep the boundary explicit. The choice is justified when the external fact unlocks useful automation that the added latency, fees, and data risk are designed to support.

How Decentralized Storage References Files

Mandie Brugman — Wed, 09 Sep 2026 14:45:04 +0000

Decentralized storage references a file by a content-derived identifier, not by the server location that happens to deliver it. The useful result is a verifiable reference to a particular byte structure, but the common claim that “the same file always gets the same CID” is wrong.

What the reference actually names

In IPFS-style storage, a CID identifies the root block of a Merkle DAG. A large file is split into blocks, those blocks are linked into a UnixFS structure, and the root contains the information needed to reach the rest. The CID includes the hash, hash function, version, and codec needed to interpret that root.

That means the CID commits to more than the visible file contents. Change the chunk size, UnixFS importer, codec, directory metadata, or wrapping structure, and the root can change even when a media player would display the same bytes. Two uploads of “the same file” are therefore equal only if they use compatible encoding choices as well as identical content.

The hash is not a storage address in the ordinary sense. It does not say which machine holds the data. A node can retrieve the block from another peer, a gateway, or a persistence provider, then verify that the returned bytes produce the CID requested. Discovery and availability are separate problems from identification.

What you need before you start

You need a canonical representation and a persistence plan. Decide whether the reference should name raw bytes, a UnixFS file, a directory, or a manifest; fix the serialization and import settings; then record the resulting CID alongside the application data that points to it.

You also need to keep the blocks available. Pinning tells an IPFS node to retain the DAG, but a CID by itself does not guarantee that anyone will continue serving it. Filecoin deals, managed pinning services, and local replicas solve persistence in different ways, with different retrieval and operational costs. A gateway URL can make access easy, but it is only one delivery route for the underlying content-addressed object.

What you end up with

You end up with an immutable version reference and a verification rule. If a build manifest points to a CID, clients can fetch the object through different routes and reject altered data without trusting the route itself. The reference remains stable while the storage provider, gateway, or peer changes.

This makes release artifacts practical to distribute without asking every consumer to trust one origin. A frontend bundle, token-list snapshot, or NFT metadata directory can be published once, cached close to users, and checked against its CID. Updating it means publishing a new root and deliberately changing the reference; old versions do not silently mutate underneath existing consumers.

Where the choice changes

Content addressing is strongest when byte identity matters more than current state. A database row, account balance, order book, or permission list normally needs a mutable name that resolves to the latest value. Putting each update behind a new CID is possible, but then another system must maintain the pointer to the current CID.

That is the real comparison for an application such as Frax Swap: immutable references suit code, images, and auditable snapshots, while mutable state needs a controlled update path. The difference is clearer when comparing Frax Swap with a static artifact: one describes what is current, the other proves exactly which bytes were published.

Frax Dollar and the ERC-20 Standard illustrate why this distinction matters at the application boundary. A token contract exposes changing state through stable methods and addresses; decentralized storage can hold the versioned metadata, interface assets, or documentation those methods point toward. The Uniswap Protocol follows the same broad separation between addressable live state and supporting content, even though the execution layer and storage layer solve different problems.

When it does not apply

Do not use a CID as the primary handle for data that must be edited in place, revoked immediately, kept secret, or removed on request. Encryption can protect confidentiality, but it does not make deletion or revocation automatic. For those cases, use mutable application storage and treat decentralized storage as a versioned archive or distribution layer where that trade-off is acceptable.