Blockchain Oracles: The Data Plumbing Behind DeFi and Onchain Finance

Blockchain oracles are systems that reliably bring external data, computation, and cross-chain messages into smart contracts, allowing onchain applications to interact with real-world prices, events, and infrastructure they cannot access on their own. In practice, oracles are the hidden plumbing of crypto: they secure trillions in onchain value, shape how DeFi liquidations and yields behave, and increasingly underpin the tokenization of real-world assets, AI, and institutional finance.

Why Oracles Matter In Crypto

From the outside, crypto often looks like it runs purely on code and cryptography. In reality, a huge portion of the system depends on offchain information: asset prices, interest rates, foreign exchange benchmarks, corporate actions, and even whether a centralized issuer actually holds the dollars or Treasuries it claims. Blockchains like Ethereum are deliberately isolated from the internet for security and consensus reasons, so they cannot natively fetch a price, call an API, or query a database. Oracles emerged as the bridge across this isolation gap, enabling smart contracts to ingest external data and execute conditional logic based on it, such as liquidating undercollateralized loans or paying out an insurance claim after a weather event.

As DeFi grew from a niche experiment to a system securing tens of billions of dollars, oracles quietly became systemic infrastructure. Lending markets, perpetual futures exchanges, stablecoins, and structured products depend on oracle feeds to define collateral values and margin thresholds. When oracles work well, they are practically invisible. When they fail or lag reality, they can trigger cascade liquidations, bad debt, or outright insolvency. Several high-profile incidents where MEV bots extracted millions during oracle delays, including a recent episode around volatility in a major DeFi governance token, reinforced how tightly protocol safety is bound to oracle behavior.

This centrality has sparked recurring debates about whether DeFi is truly “decentralized” if most major protocols rely on a small set of oracle providers and retain emergency admin powers to change feeds or pause markets. A recent wave of commentary arguing that “DeFi is dead” focused on precisely these dependencies: multisig-controlled oracles, privileged governance, and opaque upgrade paths that create offchain choke points. In response, new designs such as Frax’s Borrow Automated Market Maker (BAMM) and Ammalgam’s decentralized lending exchange aim to minimize or even remove oracle reliance altogether, using purely onchain pricing to drive lending and leverage.

At the same time, oracles themselves are evolving. Chainlink markets itself as the “industry-standard oracle platform” and has expanded from simple price feeds into hybrid smart contracts, cross-chain interoperability, and institutional integrations that aim to bring traditional capital markets onchain. Competing designs such as Curve’s AMM-based oracles, DIA’s multichain price infrastructure, RedStone’s RWA and restaking oracles, Api3’s OEV-capturing feeds, and Chaos Labs’ risk-oriented oracles show the breadth of approaches emerging. Beyond price data, projects like ORA’s onchain AI oracle demonstrate how machine learning outputs can be turned into verifiable onchain inputs, enabling AI-powered protocols to tap the same oracle model that transformed DeFi.

The result is a landscape where oracles are both a crucial enabling technology and a source of systemic risk. Understanding what they are, how they work, and how designs differ is now essential for anyone trying to assess the robustness of a DeFi protocol or the credibility of the broader onchain financial stack.

DAdvisoor

Mar 30, 2026

View article →

"A New DeFi Primitive, with No Oracles - Ammalgam" First time with Will, founder of Ammalgam!

Youtube • Mar 30, 2026

Top Comment

NicePick

Mar 30, 2026

No oracles is the headline but the real innovation is collapsing the lending/AMM separation. Every oracle-dependent protocol is one manipulation away from a bad debt event. Removing the oracle removes the attack surface. The question is whether AMM-derived pricing holds under stress. Liquidity always thins out exactly when you need it most.

What Is A Blockchain Oracle?

At a conceptual level, a blockchain oracle is a service that takes information or computation from outside a blockchain’s consensus and makes it available to smart contracts in a way that is as secure, verifiable, and tamper-resistant as possible. The phrase “outside consensus” covers a wide spectrum: prices from centralized and decentralized exchanges, macroeconomic indicators, IoT sensor data, legal events, proprietary indices, or the result of an offchain computation such as running a machine learning model. Because blockchains deliberately restrict direct network access, they rely on oracles as specialized middleware that fetches, validates, aggregates, and delivers such data onchain.

A crucial point is that an oracle is not a data source itself; it is an infrastructure layer that connects many data sources to many chains and applications. In the same way that an exchange is not a price index but rather a venue whose trades are inputs into indices, an oracle network ingests data from multiple upstream sources and transforms it into onchain feeds. This distinction matters because decentralization and robustness are achieved not simply by “having an oracle,” but by diversifying data providers, transport, and aggregation so that no single party can unilaterally manipulate the output.

Oracles are often categorized first by directionality. Inbound oracles bring data from the outside world into the chain. These include price feeds, weather data, or credit risk metrics used to trigger onchain behavior. Outbound oracles send data from the chain outwards, notifying traditional systems or payment rails that a certain condition has been met onchain, for example instructing a custodian to move assets after a smart contract event. Modern oracle platforms increasingly support both directions, enabling complex “hybrid” workflows that combine onchain logic and offchain actions.

Another useful classification is between data oracles and computation oracles. Data oracles focus on securely transporting factual information, such as asset prices or proof-of-reserves attestation, onto the chain. Computation oracles, by contrast, process inputs offchain in ways that would be too expensive or slow to perform within layer-1 gas limits, then provide the result to smart contracts with verifiability guarantees. Examples include zero-knowledge proof generation, advanced risk simulations, and AI inference, such as ORA’s onchain AI oracle that executes machine learning models via an optimistic machine learning (opML) framework and posts results on Ethereum.

Finally, oracles can be “single-source” or “networked.” A single-source oracle is essentially a trusted server or signer that publishes data onchain; this model is simple but centralizes power and introduces a single point of failure. Networked oracles, such as Chainlink, RedStone, DIA, Api3, and Chaos Oracles, coordinate many independent nodes that each fetch and report data, then aggregate their submissions into a final onchain value. Networked designs aim to align incentives such that nodes are rewarded for honest behavior and penalized (through slashing, reputation loss, or being dropped from the network) for manipulation or downtime.

Within DeFi and onchain finance, oracles are thus less a single tool and more an architectural pattern: a structured way of bridging the deterministic world of blockchains and the inherently messy, ambiguous world of offchain data and computation.

How Oracles Work Under The Hood

Underneath the abstractions, most decentralized oracle systems follow a broadly similar pipeline. First, there is a specification phase, where the data requirements and security model are defined. A protocol might request, for example, a USD price feed for ETH with updates at least every few minutes and more often when volatility breaches a threshold. They may specify which exchanges to include, how to weight them, which chains to publish to, and how much decentralization and economic security they require in the oracle network.

Next comes data acquisition. Oracle nodes source raw data from APIs, exchange order books, or onchain trading activity, depending on the oracle’s design. Chainlink price feeds, for instance, aggregate data from a curated set of premium data providers and trading venues. DIA positions itself as a “community-verified” oracle where data sources and feeds are transparent and auditable from source to chain, tailoring feeds to specific applications or new assets. RedStone emphasizes high-frequency data for EVM chains and rollups, including yield-bearing assets and liquid staking tokens, sourcing from both centralized and decentralized venues to reflect true market conditions.

The third step is aggregation and validation. Each oracle node submits its observed value, which is combined through statistical methods such as medians, trimmed means, or more sophisticated filters designed to exclude outliers and resist manipulation. Decentralized networks often include offchain aggregation rounds to reduce onchain gas costs, with only the aggregated result written onchain periodically. Some oracle designs, notably Curve’s AMM-based oracles, rely directly on onchain trading data within their pools: they compute a time-weighted average price from their own invariant over a rolling window, effectively turning the AMM into both a trading venue and a price oracle. This design couples market depth and pricing together in a way that can dampen sudden spikes and make short-term manipulation more expensive.

Once an aggregated value is ready, it must be delivered to the target chain(s). In a “push” model, oracle nodes or a designated aggregator proactively publish updated values to onchain contracts at regular intervals or when deviation thresholds are reached. In a “pull” model, the consuming contract triggers an oracle update as needed, often accepting some staleness in exchange for lower costs. Multi-chain oracle platforms must repeat this process across several networks, ensuring consistency while accommodating different block times, fee markets, and consensus properties.

Verification is the final layer. Smart contracts that consume oracle data need assurance that it came from an authentic, untampered feed. This is typically achieved either through direct calls into canonical oracle contracts maintained by the network, or via cryptographic signatures that contracts can verify onchain. Some oracles augment this with cryptoeconomic security: staking or restaking, where node operators pledge capital that can be slashed in case of provable misbehavior. RedStone’s restaking oracle, for instance, integrates with EigenLayer to tap into Ethereum’s existing cryptoeconomic security and align node incentives more tightly with correctness. Chaos Oracles unify price, risk, and proof-of-reserves data in a way that can be independently verified, strengthening the integrity of risk controls in protocols that rely on them.

Specialized oracle designs add further complexity. ORA’s onchain AI oracle uses an “optimistic” pattern, similar in spirit to optimistic rollups: offchain nodes run AI inference in response to onchain requests, post results, and allow a challenge period during which incorrect outputs can be disputed before acceptance. Proof-of-reserves oracles must not only fetch asset balances from custodians or chains, but also verify that these balances are not double-counted or encumbered. Risk oracles run scenario simulations rather than fetching raw prices, producing reserve adequacy or VaR-style metrics that inform protocol settings.

Despite this variety, two constraints are common. First, the oracle cannot itself dictate protocol behavior; it can only supply data and let smart contracts apply predetermined rules. Second, the oracle’s security guarantees will always be bounded by the weakest link in its data pipeline, node network, cryptoeconomic incentives, and governance. Understanding those links is key to assessing whether a given oracle setup is appropriate for a specific DeFi use case.

Major Oracle Designs And Providers

Chainlink And Hybrid Smart Contracts

Chainlink was among the earliest and remains the most widely integrated decentralized oracle network, securing the majority of DeFi’s total value locked according to its own materials. Its core product, Chainlink Data Feeds, provides price oracles for a broad range of assets across Ethereum and other EVM-compatible chains, as well as non-EVM networks. These feeds are maintained by networks of independent node operators sourcing data from multiple high-quality providers, with onchain reference contracts exposing the aggregated prices directly to user protocols.

Over time, Chainlink has expanded into what it calls “hybrid smart contracts,” in which onchain logic is combined with offchain oracle services that handle data connectivity, external computation, and cross-chain messaging. Products such as Chainlink Automation, Chainlink VRF (verifiable randomness), and Chainlink Functions are all manifestations of the same pattern: keep core consensus minimal onchain, but extend capabilities through oracle-mediated services. Chainlink’s cross-chain interoperability protocol (CCIP) applies this to messaging and token transfers, enabling onchain applications to communicate securely across multiple chains without relying solely on traditional bridges.

From an institutional perspective, Chainlink positions itself as the neutral middleware by which traditional financial infrastructure connects to public blockchains. Its educational materials emphasize support for real-world asset tokenization, compliance-oriented workflows, and privacy-preserving computation, arguing that oracles are “foundational” to the emerging onchain economy. Partnerships that integrate Chainlink’s oracle and cross-chain tools into institutional-grade networks, as well as pilots with legacy financial messaging systems to streamline corporate actions using decentralized oracles and AI, reflect an attempt to embed Chainlink at the center of the hybrid TradFi–DeFi transition.

This scale and ambition come with trade-offs. Chainlink’s network is decentralized relative to a single-source oracle, but still coordinated through a centralized team that curates nodes, configures feeds, and steers product direction. Access to premium data is a strength but also a cost factor. For many DeFi protocols, however, Chainlink’s perceived robustness and track record have made it the default choice, illustrating the powerful network effects that can accrue in oracle infrastructure.

Curve’s AMM-Based Oracles

Curve Finance is best known as a stablecoin-focused automated market maker, but its approach to oracles has become increasingly influential. Rather than relying on an external network of nodes to fetch prices, Curve’s pools derive time-weighted average prices directly from their own onchain trading activity and curve invariants. In effect, the AMM becomes its own oracle, with the pool’s state reflecting the consensus price over a recent window of trades.

This design has several consequences. Because the oracle view integrates over time rather than reflecting the instantaneous spot price of a low-liquidity swap, it is harder for an attacker to momentarily manipulate prices via a flash loan and then trigger mispriced liquidations elsewhere. LlamaRisk’s comparative analysis for Prisma, examining Curve’s oracle as an alternative to Chainlink for ETH liquid staking derivative tokens, concluded that implementing the Curve oracle would have reduced MEV extraction by bots and yielded better exchange rates for users during historical stress periods. By anchoring the oracle to sustained trading activity rather than isolated prints, the system dampens sudden spikes and makes manipulation more capital-intensive.

Curve’s oracle design nonetheless remains path-dependent on liquidity. If a pool becomes thin or imbalanced, its derived prices may diverge from broader markets. Moreover, AMM-based oracles are inherently asset-specific: they work where deep, well-designed pools exist, but are less suitable for niche tokens or non-tradable reference rates. For this reason, some protocols use Curve oracles as one input within a larger risk framework, while maintaining external oracles for assets that lack robust AMM markets.

Still, the idea that an onchain liquidity venue can simultaneously function as a price oracle has inspired designs beyond Curve. Frax’s BAMM extends the concept to lending, and Convergence Finance’s Tangent, described as an “exotic and LP-less DEX,” builds on Curve oracles to price more complex derivatives. Together, these experiments point toward a class of “oracle-minimized” designs where the trading engine and price discovery apparatus are tightly coupled onchain, reducing dependence on external feeds.

DIA, RedStone, Api3, And Modular Oracles

Beyond Chainlink and AMM-native designs, a diverse ecosystem of oracle providers has emerged, each emphasizing different trade-offs.

DIA presents itself as a trustless oracle hub where data feeds are customizable, auditable, and verifiable from source to chain. Rather than offering only standardized feeds, DIA encourages communities and protocols to define their own asset universes and data sources, which are then maintained transparently across multiple blockchains. This flexibility has made DIA a popular choice for projects seeking multichain pricing for niche or synthetic assets, parallel stablecoins, and cross-chain yield strategies, where bespoke configurations can unlock additional design space.

RedStone positions as a modular oracle optimized for high-frequency, diverse data feeds across EVM layer-1s, layer-2s, and rollup-as-a-service environments. It claims to have grown its total value secured from around 400 million dollars at the start of 2024 to roughly 4 billion dollars later that year, with over one hundred client protocols, driven by demand for specialized feeds covering yield-bearing assets, liquid staking, and restaking tokens. RedStone’s restaking oracle integrates with EigenLayer to inherit cryptoeconomic security from re-staked ETH, while its RWA oracle, built in partnership with Securitize, provides institutional-grade price feeds for tokenized funds such as Apollo’s ACRED and BlackRock’s BUIDL on Solana. This latter integration connects Solana developers with secure, composable price feeds for both traditional and crypto assets, unlocking nearly 4 billion dollars in liquidity and building rails for much larger flows of tokenized assets into DeFi.

Api3 takes yet another angle, promoting “first-party oracles” where data providers themselves run oracle nodes to deliver their data directly onchain, reducing intermediaries. A recent collaboration between Yearn and Api3 highlights another dimension: oracle extractable value. By designing oracles that can recapture liquidation-related value that would otherwise be captured solely by MEV searchers, Api3 enables protocols such as Yearn’s new OEV-boosted USDC vaults to return a portion of this value to depositors, enhancing yields during volatile periods. This approach reframes oracles not merely as data providers but as active participants in the value distribution of DeFi’s microstructure.

Together, DIA, RedStone, and Api3 exemplify a move toward more modular, customizable, and economically aligned oracles. Rather than a one-size-fits-all price feed, they offer specialized configurations tuned to particular assets, chains, and protocol needs, at the cost of a more complex design space that builders must learn to navigate.

Chaos Labs And Risk-Oriented Oracles

Chaos Labs is better known as a crypto risk management firm, but its Chaos Oracles product represents a distinct category: oracles purpose-built for real-time risk management. Chaos Oracles unify three data dimensions—price, risk, and proof-of-reserves—into a coherent framework designed for protocols that need continuous, independent reserve verification and stress-tested parameters. Rather than simply streaming spot prices, Chaos Oracles incorporate information about asset liquidity, concentration, and reserve backing, enabling DeFi protocols to make more informed decisions about collateral factors, leverage limits, and emergency responses.

This focus on robustness was tested when the Chaos Oracle Network reportedly faced an attempted attack that the firm characterized as potentially originating from a nation-state actor. According to Chaos Labs, the oracle infrastructure remained uncompromised, demonstrating resilience under a sophisticated assault, and the incident reinforced the importance of hardened, multi-layered security for oracles that guard systemic risk functions. In an environment where the economic stakes of DeFi are steadily increasing, the prospect of advanced persistent threats targeting oracle networks is no longer theoretical, and providers like Chaos Labs are positioning their infrastructure accordingly.

Chaos Oracles also illustrate a broader trend toward specialized oracle layers that serve specific protocol classes, such as delta-neutral stablecoins or complex derivatives. For instance, Ethena Labs’ adoption of Chaos Labs’ “Edge Proof” oracles for its USDe product exemplifies the desire for independent, real-time reserve verification that goes beyond simple proof-of-reserves snapshots and into continuous risk monitoring. In this model, oracles become the nerve endings of a protocol’s risk apparatus, rather than just a price ticker.

Emerging AI Oracles: ORA And Onchain Machine Learning

As AI-native crypto projects proliferate, from information markets like Kaito’s “InfoFi” model to AI-powered trading tools and recommendation engines, a new type of oracle is emerging: the AI oracle. Traditional oracles deliver data that is either factual or at least objectively measurable. AI outputs, by contrast, can be probabilistic, contextual, and difficult to verify directly. Turning them into robust onchain inputs requires new patterns.

ORA’s onchain AI oracle, implemented via the OAO repository on Ethereum, provides one example. The system uses an “optimistic machine learning” (opML) framework where user contracts initiate AI requests by calling the OAO oracle contract onchain, which in turn publishes these requests to offchain opML nodes. These nodes perform AI inference, such as running a machine learning model over a given input, and then upload the results back onchain. The architecture incorporates callback mechanisms and, in principle, dispute windows during which incorrect results can be challenged, drawing inspiration from optimistic rollup designs.

Integrating AI in this way allows smart contracts to incorporate complex signals—such as sentiment analysis, anomaly detection, or personalized recommendations—without executing heavy computation onchain. It also aligns with a broader move to tokenize and reward attention and information, visible in projects that combine AI with token incentives to realign how digital influence is valued. In that context, AI oracles act as an interpretive layer: they translate raw data and engagement signals into onchain metrics that can drive token distribution or governance.

AI oracles are still nascent, and their security and reliability guarantees remain less mature than those of established price oracles. Nonetheless, as more economic value depends on AI-derived judgments, the same questions that shaped the price oracle debate—about decentralization, verifiability, and economic incentives—will increasingly apply to the AI-crypto intersection.

Comparative Landscape

The diversity of oracle approaches can be summarized schematically. The following table contrasts selected providers across a few dimensions, as described in their public materials.

While this table simplifies many nuances, it highlights the core point: “oracle” is an umbrella term for a wide variety of architectures, each with distinct strengths, weaknesses, and target use cases.

Danicjade

Apr 2, 2026

View article →

"DeFi is dead" debate resurfaces as researcher argues most protocols still rely on admin keys and multisigs

𝕏/@DefiIgnas • Apr 2, 2026

Top Comment

Danicjade

Apr 3, 2026

In my own honest take, maybe Defi is really dead and what we have now is SeeDefi

Oracles In DeFi: Core Use Cases

Lending And Borrowing

Lending markets are among the most oracle-dependent structures in DeFi. Protocols such as Aave, Compound, Morpho, and emerging platforms like Mutuum Finance allow users to deposit collateral and borrow other assets, with loan safety determined by the ratio of borrowed value to collateral value. The protocol itself does not know the “true” value of these assets; it relies on price oracles to translate token quantities into monetary values.

A lending protocol might, for instance, set a collateral factor of 75% for ETH, allowing borrowers to draw loans up to three-quarters of their collateral’s value. If ETH’s price falls, the oracle will eventually report a lower value, and if a borrower’s loan exceeds the safety threshold, the protocol will trigger liquidations. In this process, oracle timeliness and accuracy are critical. If the oracle lags during a rapid crash, undercollateralized positions may persist; if it overshoots or is manipulated downward, healthy borrowers may be liquidated unfairly.

Mutuum Finance’s planned launch, leveraging Chainlink oracles for pricing, exemplifies how deeply oracle choices are embedded in protocol architecture. By combining dual lending markets, community rewards, and Chainlink’s data feeds, Mutuum aims to expand borrowing options while relying on Chainlink’s perceived reliability to secure its collateral valuations. Similarly, Morpho’s new vaults curated by Yearn rely on Api3 oracles, with OEV-aware mechanisms that recapture value from liquidations and redirect it to depositors rather than external MEV bots. In this model, the oracle’s role extends beyond mere data provision into active participation in the protocol’s value distribution.

Frax’s BAMM pushes in the opposite direction, designing a lending primitive that eliminates external price oracles entirely. Instead of using an external feed to decide whether a loan is healthy, BAMM embeds borrowing inside an AMM whose pricing is determined by its own onchain reserves and invariant. This allows users to borrow and swap any token within the pool with fewer sudden liquidation risks, since the protocol’s notion of “price” is directly tied to its own liquidity state rather than an exogenous oracle. While this does not free users from market risk—if collateral value falls, their positions still deteriorate—it changes the mechanism by which that risk is transmitted, and avoids certain classes of oracle failure.

These contrasting approaches illustrate a spectrum. At one end, there are oracle-heavy designs that rely on external feeds for precise valuations across many assets. At the other, there are oracle-minimized designs that derive prices internally from liquidity pools. In between lie hybrid models, such as using AMM-based oracles for well-traded assets and external oracles for more esoteric ones, or layering risk oracles on top of price feeds to dynamically adjust collateral factors.

Perpetuals, Derivatives, And Onchain Leverage

Perpetual futures exchanges and options platforms are even more sensitive to oracle behavior, because they amplify small price moves through leverage. Onchain perpetual DEXs often quote their own mark prices but settle funding payments and liquidations based on an external oracle, such as a Chainlink or RedStone feed, to avoid being gamed by low-liquidity onchain order books.

For example, a trader might open a 10x long position on an onchain perps exchange. If the external oracle reports a 5% drop in the underlying asset’s price, the trader is liquidated, even if the DEX’s internal order book or AMM had not moved as much. This decoupling protects against manipulation of the DEX itself but makes the oracle a critical trust anchor. When oracle updates lag or diverge from global markets, funding payments and liquidations can become misaligned, leading to bad debt or windfall profits for arbitrageurs.

Recent research and benchmarking across multiple perpetual DEXs, covering their tech stacks, fee models, liquidity, and oracle choices, has underscored how varied oracle dependencies are. Some venues rely almost entirely on a single oracle provider for settlement, while others incorporate redundancy or AMM-based fallback mechanisms. New governance proposals, such as HIP-3 on Hyperliquid, are moving toward more programmatic management of oracles and value capture, embedding staking and slashing mechanisms that align oracle performance with community incentives.

The interaction between oracles and MEV is particularly acute in derivatives. MEV bots can reorder or insert transactions around oracle update blocks, exploiting the brief windows where oracle-reported prices diverge from public information. In one recent case, MEV actors reportedly extracted around three million dollars in bad debt as oracles lagged during volatility in a major token, highlighting that even without outright oracle manipulation, timing asymmetries can be harvested by sophisticated searchers. Studies like the FCA’s research note on maximal extractable value and oracles suggest that some MEV practices, such as intentionally reordering transactions to exploit pricing lags, would be considered manipulative or unlawful in traditional markets.

To mitigate these issues, some derivatives protocols are experimenting with more frequent updates, threshold-based triggers, and combinations of spot and index prices across multiple venues. Others are exploring “self-referential” onchain indices akin to Curve’s oracle, though applying this approach to leveraged derivatives without introducing new attack surfaces remains a complex design challenge.

Stablecoins And Parallel Currencies

Stablecoins are often described as “oracles in disguise.” Regardless of whether a stablecoin is backed by fiat reserves, crypto collateral, or algorithmic mechanisms, its peg to a target currency like the US dollar requires reliable information about asset values. If a crypto-backed stablecoin like DAI uses ETH and other tokens as collateral, the protocol must know in real time what those tokens are worth. That knowledge comes from price oracles.

Protocols that design “parallel stablecoins” pegged to alternative baskets or inflation-adjusted indices depend even more heavily on oracles. DIA’s multichain oracle infrastructure is particularly relevant here, as it enables projects to define and maintain complex price feeds spanning multiple chains and asset classes. A parallel stablecoin might, for instance, reference a weighted basket of fiat currencies, commodities, and crypto assets, all of which require reliable data sources and robust aggregation. DIA’s emphasis on transparency from source to chain aims to give users and auditors confidence that these composite indices reflect real-world conditions.

Oracle failures in stablecoin contexts can be especially damaging. If a stablecoin undervalues its collateral because of faulty price feeds, it may liquidate positions unnecessarily, eroding user trust. If it overvalues collateral, it may become under-reserved and risk a depeg. Proof-of-reserves oracles, which attest that centralized stablecoin issuers actually hold corresponding assets, add another layer: they must verify balances, detect double-counting, and respond to changes in custody structures. Risk-oriented oracle platforms like Chaos Oracles contribute here by monitoring reserve adequacy and concentration risk, offering a more nuanced view than simple one-to-one backing.

As more stablecoins branch into non-dollar pegs, yield-bearing wrappers, and cross-chain deployments, their oracle dependencies multiply. Each new chain, collateral type, and feature introduces additional assumptions about data fidelity and oracle liveness. For users, understanding which oracle designs back their chosen stablecoins—and how transparent, upgradable, or governed they are—becomes as important as knowing where reserves are held.

Real-World Assets And Tokenization

The recent boom in tokenized real-world assets (RWAs)—from tokenized Treasuries and money market funds to private credit and equity—has thrust oracles into a new spotlight. Unlike purely onchain assets, RWAs have offchain legal claims, custody, and market structures. Tokenized representations of them on chains like Ethereum or Solana are only as trustworthy as the oracle pathways that keep their onchain prices and status synchronized with offchain reality.

RedStone’s RWA oracle, launched on Solana in partnership with Securitize, is a case in point. By providing institutional-grade price feeds for tokenized assets managed by firms such as Apollo and BlackRock, RedStone connects nearly four billion dollars in tokenized funds to Solana’s DeFi ecosystem. The integration allows Solana-based protocols to treat these tokens as usable collateral, yield-bearing instruments, or components in structured products, with the assurance that their prices reflect underlying net asset values and market conditions. Without such oracles, RWA tokens would be risky to integrate, as protocols would have no reliable way to value them or respond to market changes.

Chainlink’s vision of oracles as the “missing link” to tokenization similarly emphasizes cross-chain data connectivity, integration with existing financial standards, and support for compliance and privacy. In this view, oracles are not only price pipes but also conduits for corporate actions, interest payments, and identity verification flows, allowing traditional financial workflows to be mirrored or even migrated onto blockchains. Enterprise-focused networks that incorporate oracle layers aim to create shared rails where tokenized assets, stablecoins, and digital identity solutions can interoperate securely, with oracles serving as the synchronization layer between legal and technical state.

DIA, Api3, and other oracles also play roles in RWA ecosystems by pricing less liquid instruments, such as private credit or emerging market bonds, where trade data is sparse and proprietary. Here, transparency about source data and methodology becomes even more important, because there may be no obvious “market price” to triangulate. The interplay between oracle providers, issuers like Securitize, and asset managers like Apollo or BlackRock underscores how RWA tokenization is as much about data plumbing as it is about smart contracts or user interfaces.

Risk Management And Proof-Of-Reserves

Beyond individual protocols, oracles are increasingly central to ecosystem-wide risk management. Proof-of-reserves oracles track whether centralized custodians and exchanges hold sufficient assets to back their tokens and liabilities. Risk oracles monitor collateral quality, liquidity, and concentration across multiple protocols and chains. Insurance protocols depend on oracles to determine whether predefined conditions for payouts have been met, such as a bridge hack or a stablecoin depeg.

Chaos Oracles exemplify this shift by combining price, risk, and proof-of-reserves data into a unified oracle product. Rather than focusing solely on reporting spot prices, Chaos Oracles feed DeFi protocols with signals about reserve adequacy and risk exposure, enabling them to adjust parameters such as collateral factors or issuance caps dynamically. When adopted by products like Ethena’s USDe, these oracles form the backbone of dynamic hedging strategies and reserve management, helping maintain delta-neutrality and solvency even under stress.

Some insurance-like products also incorporate multiple independent oracles to adjudicate claims. If one oracle reports a bridge exploit while another disputes it, governance processes can review evidence and decide, potentially using onchain dispute resolution. AI oracles may eventually contribute here as well, providing probabilistic assessments of complex situations such as regulatory changes or legal rulings that impact tokenized assets.

In all these cases, the line between “data feed” and “risk policy” begins to blur. Oracles become embedded in the risk management logic of protocols, shaping not only the detection of adverse events but also the prevention of excessive risk-taking. This deepens their systemic importance, while also raising questions about who controls oracle parameters and how transparent those controls are.

Oracle Risks: Failures, Attacks, And MEV

Price Manipulation And Flash Loan Attacks

Oracle manipulation has been one of the most damaging and persistent attack vectors in DeFi. The basic pattern is simple: an attacker borrows capital (often via a flash loan), uses it to move the price of an asset on a venue that an oracle references, then exploits the artificially inflated or depressed price in another protocol that depends on that oracle. After extracting value—typically by borrowing more than they should be allowed or liquidating others’ positions at an unfair rate—they repay the flash loan and pocket the difference.

Single-source oracles that depend on a single DEX’s price are particularly vulnerable. Even decentralized oracles can be attacked if they rely too heavily on easily manipulated venues or if their update mechanisms introduce exploitable lags. Flash loans amplify these opportunities by allowing attackers to access large amounts of capital without upfront collateral, increasing the scale of potential manipulation.

Time-weighted average price (TWAP) oracles and AMM-based designs like Curve’s were developed in part to mitigate this class of attack. By integrating price over a longer window and requiring sustained trading to move the reference price, they make one-block manipulation attacks far more expensive. LlamaRisk’s analysis of Curve’s oracle performance for ETH liquid staking derivatives found that its use would have reduced MEV extraction by bots and yielded more accurate prices during turbulent periods compared with alternative oracles. However, no design is entirely immune, especially if underlying liquidity thins or attack windows lengthen.

Regulators and researchers are increasingly scrutinizing these dynamics. The UK Financial Conduct Authority’s note on maximal extractable value (MEV) and oracles points out that some practices tolerated in crypto—such as preferential ordering of transactions around oracle updates to harvest arbitrage—would likely be considered manipulative or unlawful in traditional finance. While DeFi operates in a different legal context, the economic and ethical concerns are similar: when a small group of actors can reliably profit from oracle quirks at the expense of ordinary users, system legitimacy suffers.

Liveness Failures And Downtime

Oracle risks are not limited to malicious attacks or MEV; simple liveness failures can be equally damaging. If an oracle network goes down, becomes congested, or loses access to a key data source, its onchain feeds may stop updating. For a lending protocol, this can mean freezing liquidations or leaving positions undercollateralized. For a perpetual DEX, it can mean stale settlement prices and misaligned funding payments.

Cross-chain dependencies make this worse. The collapse of projects like Gesit Finance has been partially attributed to the inability of their oracles to correctly value assets bridged through compromised or degraded cross-chain systems. When Chainlink or other oracles are “blind” to the true state of bridged assets because they cannot easily verify underlying reserves or detect bridge failures, protocols that treat those wrapped assets as pristine collateral can be caught off guard.

Mitigating liveness risk often involves layered defenses: fallbacks to secondary oracles, circuit breakers that pause markets when feeds are stale or inconsistent, and governance processes that can rapidly replace failing oracles. However, these mechanisms themselves reintroduce centralization and governance risk, as someone must decide when to intervene and how to calibrate thresholds. Designing protocols that degrade gracefully when oracles malfunction—slowing down rather than catastrophically failing—is an active area of research and practice.

Governance And Admin-Key Risk

The “DeFi is dead” debate has drawn attention to the fact that many protocols’ oracle configurations are controlled by upgradeable contracts and multisig wallets operated by core teams or foundations. In some cases, a small group of signers can change an oracle source, switch to a backup, or manually set prices in emergencies. While these powers may be intended for good-faith crisis management, they create centralization vectors and implicit trust assumptions that users may not fully appreciate.

Oracle providers themselves often have similar control points. Chainlink’s team curates node sets and configures feed parameters. Smaller oracle networks may have de facto reliance on a core developer or a few operators. If governance over these parameters is not transparent or widely distributed, it contradicts the ethos of permissionless finance, even if the technical implementation is decentralized under the hood.

Institutional DeFi faces a particular tension here. Regulated entities may actually prefer a degree of centralized oversight to satisfy compliance requirements, while crypto-native users may prioritize censorship resistance and immutability. Some governance models, like Hyperliquid’s move toward “programmatic communalization” via HIP-3, seek to encode oracle and value capture decisions into transparent, onchain mechanisms where staking, slashing, and auction processes are collectively governed rather than curated. Whether such models can fully replace offchain discretion in practice remains to be seen.

Oracle Extractable Value (OEV) And MEV At The Oracle Layer

MEV is usually discussed in the context of block producers and searchers, but oracles themselves introduce a related concept: oracle extractable value (OEV). OEV arises when the entity that controls the timing or content of oracle updates can influence the value of subsequent transactions, such as liquidations or arbitrage trades.

Consider a lending protocol where many positions are teetering on the edge of liquidation based on the next price update. Whoever can trigger or sequence that update has an opportunity to profit from liquidating those positions or back-running trades. In traditional MEV, searchers compete to capture this value by manipulating transaction ordering. In OEV-aware designs, oracles and protocols intentionally recapture some of this value on behalf of users or governance.

Api3’s collaboration with Yearn illustrates this approach. By designing an oracle mechanism that routes liquidation-related value back into the protocol rather than leaving it entirely to external MEV bots, Yearn’s OEV-boosted vaults can enhance yields for depositors, especially during volatile periods when OEV is high. This reframes oracle design as a game-theoretic system where incentives for timely and honest updates are balanced against the desire to minimize extractive behavior by third parties.

The FCA’s note on MEV and oracles underscores how these issues intersect with regulatory concerns. If oracle operators or protocol insiders are perceived to be unfairly profiting from privileged access to update mechanisms, regulators may view this as akin to insider trading or market manipulation. Designing transparent, competitive, and user-aligned OEV redistribution mechanisms may thus be important not only for fairness but also for long-term regulatory compatibility.

Nation-State And Advanced Threats

As DeFi matures and the economic stakes rise, oracle networks become attractive targets not only for opportunistic hackers but also for more sophisticated actors, including, potentially, nation-states. The reported attempted attack on Chaos Labs’ oracle infrastructure, characterized by the firm as possibly originating from a nation-state actor, brought this prospect into sharper focus. According to Chaos Labs, the Chaos Oracle Network remained uncompromised, demonstrating the value of hardened security, layered defenses, and rigorous monitoring.

Advanced adversaries can attack oracles at multiple layers: DDoS-ing node operators, compromising data sources, infiltrating validator sets, or manipulating network conditions around update windows. They may also exploit legal and regulatory levers, pressuring centralized data providers to restrict access or alter terms in ways that weaken oracle networks. In a geopolitical landscape where financial infrastructure is increasingly weaponized, decentralized oracles could become both targets and tools.

This threat model reinforces the importance of diversity in oracle designs, decentralization of node operators, transparent processes for adding or removing nodes and data sources, and robust incident response. It also suggests that relying too heavily on a single oracle provider or architecture could create systemic fragility if that provider becomes a focal point of attack. From a resilience perspective, cultivating a rich ecosystem of interoperable, independently operated oracles may be as important as scaling any one network.

Oracle-Free Protocols And Design Experiments

The Concept Of Oracle-Free DeFi

In parallel to the evolution of more sophisticated oracle networks, a countercurrent in DeFi design argues that truly robust base-layer primitives should have zero external dependencies, including zero reliance on oracles. Authors from the venture firm Nascent, for instance, have argued that for a contract to qualify as a “primitive,” it must operate without governance, upgradeability, or oracles, relying solely on its own internal logic and onchain state. In this view, oracles are powerful but optional add-ons, best kept at the edges of the system rather than embedded in its most fundamental components.

The rationale is twofold. First, removing oracle dependencies eliminates an entire class of risks: manipulation, downtime, and governance capture. Second, oracle-free designs often align more closely with the trust-minimized ethos of blockchains, where users can verify protocol behavior entirely from onchain data. At the same time, oracle-free protocols are necessarily limited in what they can do, because they cannot reference external prices or events. They must derive all their “knowledge” from onchain liquidity and flows.

Designers are therefore exploring ways to push the boundary of what is possible with purely onchain information, especially in lending, leverage, and derivatives. AMM-based pricing, internal stable references (such as using LP shares as the unit of account), and reflexive interest rate curves all feature prominently in this exploration. The goal is not to eliminate oracles from the ecosystem entirely, but to minimize their footprint in the most systemic components.

Frax’s Borrow Automated Market Maker (BAMM)

Frax Finance’s Borrow Automated Market Maker (BAMM) is a high-profile attempt to reimagine lending without external price oracles. Rather than maintaining separate lending pools and using oracles to value collateral, BAMM embeds borrowing and lending directly into an AMM. Users deposit assets into a pool and can borrow against their positions by moving along the AMM curve, with the pool’s reserve ratios implicitly determining borrowing power and interest rates.

Because the AMM’s pricing is determined purely by onchain balances and a mathematical invariant, there is no need for an external USD or ETH reference price to judge whether a position is undercollateralized. If the pool’s composition shifts unfavorably, the AMM’s prices adjust automatically, and the protocol can use those internal prices to govern borrowing and repayment conditions. Frax emphasizes that this design avoids sudden oracle-driven liquidations, offering “pure onchain borrowing inside an AMM” where leverage is accessible for any token without oracles or permissions.

BAMM does not remove market risk; it transforms it. Users are still exposed to the relative value of assets in the pool, and extreme moves can still erode collateral value. But the path by which risk manifests is different: rather than an external oracle marking collateral to market against some reference currency, the AMM itself encodes the economic relationships among assets. This can make the system more predictable for participants who understand the invariant, but also more complex to reason about for casual users.

From an ecosystem perspective, BAMM highlights how intertwined oracles and AMMs have become. Where early DeFi treated AMMs as price discovery engines and oracles as external data pipes, BAMM collapses the distinction. Its success or failure will shape how far future lending designs push in the direction of oracle-independence.

Ammalgam And The Decentralized Lending Exchange

Ammalgam is another experiment in oracle-free leverage, proposing an entirely new primitive it calls a Decentralized Lending Exchange (DLEX). The core idea is to combine the simplicity of an AMM like Uniswap v2 with the power of leveraged lending, without relying on external oracles, permissions, or dependencies. In this model, LPs can earn yields up to an advertised sixty percent higher than in traditional designs, and traders can access leverage without the usual oracle-driven liquidation mechanics.

Crucially, Ammalgam’s designers argue that this oracle-free architecture addresses DeFi’s “persistent vulnerability” to oracle failures and manipulation. By grounding all pricing and leverage decisions in onchain liquidity and trades, they aim to remove a major external attack surface and governance dependency. Like BAMM, Ammalgam does not claim to eliminate risk but rather to confine it within the protocol’s own onchain logic.

Whether the DLEX model can scale, maintain deep liquidity, and remain robust under extreme market conditions remains to be seen. However, its emergence underscores a pattern: as the costs and complexities of oracle-based designs become more apparent, especially in the context of MEV, OEV, and governance, more projects are revisiting minimalist architectures that push oracles to the periphery.

Trade-Offs And The Limits Of Oracle-Free Design

While oracle-free protocols are intellectually appealing and may be appropriate for certain primitives, there are clear limits to what they can achieve. Any design that aims to reference real-world prices, legal events, or offchain reserves must, by definition, rely on some oracle or trusted bridge. Real-world assets, fiat-pegged stablecoins, and cross-chain token representations cannot be fully understood from onchain data alone.

Moreover, oracle-free designs often trade off expressiveness for robustness. They may support fewer asset types, require more complex understanding from users, and be less intuitive than protocols that define collateralization in familiar currency terms. For many users and institutions, the ability to denominate risk and return in offchain units like USD or yield curves is a requirement, not a luxury.

The emerging landscape is therefore likely to be heterogenous. Oracle-free or oracle-minimized designs like BAMM and Ammalgam may serve as core primitives in certain niches, providing resilient, self-contained building blocks. On top of these, oracle-dependent layers will handle RWAs, cross-chain flows, and complex derivatives that necessarily rely on external information. The challenge for builders and users will be to understand which layer they are operating in and what trust assumptions it entails.

0xpmm.eth

Dec 1, 2025

View article →

HIP-3 marks Hyperliquid’s shift toward “programmatic communalization,” moving the platform from a curated venue to a fully open financial layer where staking, slashing, Dutch auctions, oracles, and value capture are all governed by the community.

𝕏/@Lemniscap • Dec 1, 2025

Onchain AI, Attention Tokens, And Next-Gen Oracles

The convergence of AI and crypto introduces new roles for oracles beyond traditional price feeds. Projects that tokenize attention and information, such as those promising rewards for meaningful engagement rather than vanity metrics, require reliable ways to measure, interpret, and verify user behavior across platforms. AI models are natural candidates for this interpretive role, but their outputs are not trivially verifiable onchain.

AI oracles like ORA’s OAO framework represent one attempt to bridge this gap. By enabling smart contracts to request AI inference on specific inputs—such as evaluating the quality of a piece of content or detecting sybil behavior—and receive results onchain via an optimistic protocol, AI oracles can turn subjective or probabilistic judgments into actionable onchain data. Combined with token incentives, this allows for more sophisticated reward schemes that go beyond simple countable metrics like likes or retweets.

In parallel, AI-powered information platforms like Kaito’s “InfoFi” aim to reward users for contributing high-signal information and engagement, using AI to score content quality and relevance. Oracles in such systems might not only carry price data but also the outputs of AI ranking models, reputation scores, and risk assessments. As these tokens integrate with broader DeFi, the boundary between “data oracle” and “AI oracle” will blur.

This raises new questions. How can AI oracle outputs be audited or challenged if they are inherently probabilistic? What happens when different AI oracles disagree about a classification? Can we design cryptoeconomic incentives that encourage accurate AI outputs but discourage bias or censorship? While these questions are still open, the basic pattern is familiar: offchain computation (AI models) producing data that onchain applications depend on, mediated by oracles that must be robust, transparent, and well-incentivized.

As with price oracles in early DeFi, the first wave of AI oracles will likely be imperfect but generative. Over time, competition and hard-earned experience with failures will refine architectures, just as the move from single-source price feeds to decentralized oracle networks did in DeFi.

Multichain And Cross-Chain Oracle Challenges

The shift from a single-chain world dominated by Ethereum to a multichain, multi-rollup ecosystem has multiplied the complexity of oracle design. A protocol deployed across Ethereum mainnet, several layer-2 rollups, and alternative L1s like Solana and Cosmos must decide how to maintain consistent, timely oracle feeds across these heterogeneous environments.

Cross-chain oracle platforms like Chainlink, DIA, RedStone, and others have responded by deploying node networks on multiple chains and using cross-chain messaging to keep feeds aligned. Chainlink’s CCIP is explicitly geared toward secure cross-chain communication, allowing contracts on different chains to reference shared data or coordinate state transitions. DIA emphasizes multichain price feeds that can be audited across networks, while RedStone has expanded from EVM environments to Solana, providing consistent RWA pricing across very different execution environments.

However, new risks arise. Cross-chain messaging introduces additional trust assumptions and failure modes. If a bridge between two chains is compromised or congested, oracle updates may be delayed or blocked, leading to inconsistencies in how protocols on different chains interpret asset values. Multi-chain deployments also make MEV and OEV more complex: searchers may exploit timing differences between chains, while oracle providers must decide where and how frequently to update.

Oracle designs that rely on onchain liquidity, such as Curve’s AMM-based oracles, face their own multichain challenges. Liquidity may be deep on one chain but shallow on another, leading to divergent oracle quality. Protocols that treat assets bridged from one chain to another as fungible may assume consistent oracle behavior that does not exist in practice, as seen in cases where wrapped or bridged assets were mispriced due to oracle blind spots.

One emerging pattern is to separate “global” reference prices from “local” risk parameters. A protocol might use a global price oracle that aggregates data across chains and venues, while calibrating collateral factors per chain based on local liquidity and oracle reliability. Another approach is to treat each chain’s protocol instance as semi-autonomous, with its own oracle configuration and governance, even if high-level parameters are harmonized.

Ultimately, the multichain era reinforces two themes. First, diversity of oracle providers and designs is a strength, as it reduces correlated failure risk. Second, transparency about oracle setups—what data they use, how often they update, who governs them—is indispensable for users and integrators trying to reason about cross-chain risk.

How To Evaluate Oracles As A User Or Builder

For most users, oracle infrastructure is invisible until something goes wrong. Yet understanding basic aspects of a protocol’s oracle setup can dramatically improve one’s ability to assess risk.

A first question is what kind of oracle the protocol uses: a single-source feed, a decentralized oracle network, an AMM-based TWAP, or a custom configuration from providers like DIA, RedStone, or Api3. Single-source oracles may be acceptable for low-stakes applications but are generally unsuitable for securing large amounts of value. Networked oracles with multiple independent node operators, transparent data sources, and documented aggregation logic offer stronger guarantees.

Next is governance. Who can change the oracle configuration? Is it controlled by immutable code, onchain governance, or a multisig? Can the protocol team pause or override the oracle in emergencies? While some degree of emergency control may be pragmatic, users should be aware of these powers and how they are exercised.

Economic security is also key. Do oracle node operators stake or restake tokens that can be slashed for misbehavior, as with RedStone’s EigenLayer integration? Are there mechanisms to recapture OEV and distribute it to users, as in Api3-powered vaults? Are there clear incentives for nodes to remain online and honest?

From a builder’s perspective, the evaluation expands further. They must consider latency requirements, gas costs, multichain support, asset coverage (especially for RWAs or niche tokens), and regulatory considerations if they serve institutional users. They may combine multiple oracles for redundancy, use AMM-based oracles for certain assets, and integrate risk oracles like Chaos Oracles for reserve monitoring. They must also design protocol-level protections—such as rate limits, circuit breakers, and conservative collateral factors—that assume oracles may fail or be manipulated.

Finally, both users and builders should treat oracle transparency as a non-negotiable. Providers that document their data sources, aggregation methods, node sets, and governance processes make it possible for outsiders to conduct independent assessments. Projects that are opaque about their oracle setups, or that rely on ad hoc, manually updated feeds, introduce hidden risks that can crystallize suddenly.

Outlook

Oracles began as a narrow answer to a simple question: how can a smart contract know the price of an asset? In less than a decade, they have evolved into a sprawling infrastructure layer that underpins DeFi, stablecoins, RWAs, cross-chain messaging, AI integration, and institutional onchain finance. As the boundary between onchain and offchain systems blurs, oracles are becoming the connective tissue that binds them, translating facts, prices, computations, and even AI judgments into verifiable inputs that code can act on.

The trajectory ahead appears two-pronged. On one side, oracle networks like Chainlink, DIA, RedStone, Api3, and Chaos Labs will likely continue to grow in sophistication and scale, securing ever larger pools of value across more chains and asset classes, and embedding themselves more deeply into institutional workflows. On the other, design experiments like Frax’s BAMM and Ammalgam’s DLEX will push the frontier of what can be achieved with oracle-free or oracle-minimized architectures, seeking base-layer primitives that are more self-contained and resilient to external failures.

The tension between these approaches is not a zero-sum conflict, but rather a creative dialectic that is likely to produce a richer, more layered ecosystem. Oracle-heavy and oracle-free designs will coexist, each serving different needs and risk tolerances. AI oracles will open new domains where machine learning outputs influence onchain behavior, bringing with them fresh challenges around verifiability and bias. Nation-state-level threats, regulatory scrutiny of MEV and OEV, and the proliferation of cross-chain deployments will keep security and governance concerns at the forefront.

For market participants, the key will be to stop treating oracles as invisible infrastructure and start viewing them as core components whose design and governance deserve as much attention as tokenomics or front-end UX. As tokenized assets proliferate, AI systems go onchain, and institutional capital flows into hybrid TradFi–DeFi structures, the soundness of the oracle layer will increasingly determine whether crypto’s promise of transparent, programmable finance is realized—or undermined.