Sign up for Free Kaiko Research
Deep Dive: Institutional Blockchain Oracles
What is a blockchain oracle, and how does it work?
As blockchains are closed systems by design, smart contracts have no native ability to access critical off-chain data, such as the price of an asset, the NAV of a fund, or the exchange rate of a currency pair. This severely restricts their utility as they can only act on data that already exists within their own environment. A blockchain oracle solves this challenge by sourcing, verifying, and delivering real-world data onto a blockchain in a form that smart contracts can read and act upon. Without this mechanism, on-chain logic remains disconnected from the economic conditions it is designed to represent.
The oracle occupies a critical position in the tech stack, sitting at the boundary between the off-chain world where data originates, and the on-chain environment where it is consumed. How reliably it crosses that boundary, and with what level of accountability, determines whether the smart contracts built on top of it can be trusted.
The data source matters as much as the oracle design
When it comes to deploying a data oracle, conversations often focus on whether to use a centralized or decentralized oracle, how many nodes it uses, and how it resolves disputes between them. These considerations are important, but only focus on the delivery layer, rather than the data source. Decentralized oracles that aggregate data from multiple low-quality or unverifiable sources do not produce high-quality output. The integrity of any oracle is reliant on the quality of data flowing through it, and if that data cannot be audited, reconstructed, or attributed to verified venues, then all the architecture delivers is the appearance of rigour, without any real substance.
For the likes of tokenization infrastructure operating in regulated markets, this distinction has significant consequences. Tokenized funds require accurate and auditable NAV data on-chain, while collateral management systems require price feeds that can be verified and reconstructed if challenged.
It is easy to see how damaging a single unverified price can be in these ecosystems when automated actions such as liquidations are triggered by oracle-sourced prices. Every assumption behind those prices carries forward into the outcome, including which exchanges contributed, how venues were weighted, and how outliers were handled. Where those assumptions are opaque or unaccountable, the risk extends well beyond any single transaction, embedding uncertainty into every layer of the system built on top of it.
Despite the problems this approach creates, it’s the way in which most decentralized oracle providers operate, and this is an active barrier to institutional adoption.
How decentralized oracle networks (DONs) create a black box architecture problem
Most oracle networks in DeFi take a simple, yet flawed systematic approach. Smart contracts receive price feeds from Decentralized Oracle Networks (DONs), which aggregate data from multiple oracle nodes. Each node, in turn, pulls data from third-party data aggregators, who have collected information from exchanges using proprietary, undisclosed methodologies.
This creates a system that’s ultimately built on opaque data, as showcased in the visual below:
The opacity of this system creates a replicability challenge. While the oracle nodes that participated in a given feed on-chain can be verified, the data aggregators each node streams from remain completely opaque. As a result, it’s impossible to reconstruct the prices generated, and this is particularly problematic when those prices are used to trigger actions such as liquidations. If the exchanges that contributed to the calculation can’t be verified, and the methodology used to normalize outliers or weight venues can’t be audited, it produces a system that compounds opacity at each layer and creates a system of unverified trust.
This has direct consequences for anyone attempting to build a financial product on top of such infrastructure. A fund, for example, has an obligation to its end users to explain how prices were derived, why decisions were made, and how they led to a given outcome. If the product builder or issuer is unable to explain the calculations involved because the data pipeline cannot be interrogated or reproduced, then there is no basis on which an end user can assess, challenge, or trust the result.
When automated actions like liquidations are taken based on this faulty infrastructure, they can have significant consequences on investors and the wider market…
The consequences of blockchain oracle failures
Opacity in data sourcing creates vulnerabilities, and these are often leveraged by bad actors and criminal entities. Here’s a few examples of how the weaknesses of oracles sourcing data through decentralized oracle networks have been manipulated:
Synthetix (2019)
What happened:
A single off-chain data feed reported the Korean Won at 1,000x its real value. The oracle had no fallback to catch the error, and the corrupted price was accepted as truth.
The consequences:
An arbitrage bot spotted the discrepancy and exploited it instantly, extracting over $1 billion in profit before the error was identified and stopped.
Compound Finance (2020)
What happened:
Compound’s DAI/USDC market relied entirely on a single exchange (Coinbase Pro) for its price data. When that price was manipulated by 30%, the oracle had no alternative sources to cross-reference.
The consequences:
The corrupted price data triggered $90 million in wrongful liquidations, closing out positions that, under accurate market conditions, would have remained solvent.
Mango Markets (2022)
What happened:
Attackers used coordinated trading to artificially inflate the price of the thinly traded MNGO token. With low liquidity, it was easy to move the price without much capital.
The consequences:
The manipulated price was used to borrow against inflated collateral, draining $117 million from the protocol before the relevant parties could intervene.
Balancer (2025)
What happened:
Oracle prices failed to accurately reflect what was actually happening in the market, creating a gap between what the protocol believed assets were worth and their real exchange rates.
The consequences:
Arbitrageurs exploited that gap, draining $128 million from Balancer pools before the pricing discrepancy was resolved.
The underlying issue: Decentralized Oracles
These incidents highlight two fundamental flaws in traditional decentralized blockchain oracle architectures:
1. Flawed Oracle Pricing Triggers Protocol-Wide Cascading Failures
A protocol can execute exactly as designed, yet if the underlying price data is inaccurate, attackers can exploit the gap between reported and real market conditions to drain millions in minutes.
- A Lack of Accountability
When anonymous oracle nodes provide faulty data, causing millions in losses, there is no legal entity to pursue, a dispute resolution process, or means of regulatory recourse.
In instances where the origin of a price cannot be established, its legitimacy cannot be verified until after the damage has already occurred. In traditional finance, data providers offer contractual frameworks and defined liability structures to address these vulnerabilities.
For institutional participants operating under fiduciary obligations, infrastructure that lacks clear accountability is fundamentally incompatible with their regulatory and governance requirements.
Solving the challenge: The role of oracles in the future of institutional finance
The failures outlined above showcase the full nature of the threat opacity poses and highlight the barriers that currently prevent institutional participation. If the system remains unclear on where prices came from, how they were calculated, and who is accountable when something goes wrong, then institutions will not engage. As a result, proper data governance has to be sorted, and this is where blockchain oracles need to adopt direct source architecture.
What is direct source architecture?
Direct source architecture is a data infrastructure model in which market data is collected and normalized directly from exchanges, without passing through intermediary aggregators that apply proprietary methods before it reaches its destination.
In practice, this means every data point traces back to a specific trade, on a specific venue, collected via a direct API or WebSocket connection. The underlying information remains unaltered throughout the collection process.
Exchange coverage is governed by a documented due diligence framework, where, before being included in any calculation, venues are vetted across criteria, including:
- Regulatory standing
- KYC/AML practices
- Trading rules
- Data quality
Rates calculated within this architecture use an outlier-resistant methodology, dividing the calculation window into equal partitions and applying a volume-weighted median to each, before producing a final time-weighted average price. The result is a price that can be accurately reconstructed at any point in time, using the underlying trades that contributed to it, on the exchanges that generated them.
As the provider holds licensed redistribution agreements with each exchange, the data carries a strong legal basis for use in regulated financial products. Combined with compliance under the EU Benchmark Regulation (BMR) and IOSCO principles for financial benchmarks, direct source architecture means that accountability, methodology, and data attribution are documented at every layer.
This is the approach Kaiko uses for its own oracle operations and why institutional financial organizations work with us to distribute their data on-chain.
For recent examples, see:
Building on regulatory compliance
To meet the standards required for institutional adoption, regulatory compliance must be part of an oracle’s foundation.
The benchmarks that underpin traditional financial markets require transparent methodologies, documented source selection criteria, independent audits, and clear vendor accountability. As financial products move on-chain, these standards for the data infrastructure that prices them will need to be replicated.
For tokenized real-world assets in particular, the expectation is clear that on-chain valuations should meet the same standards as their off-chain equivalents. Anything less creates a compliance gap that institutional participants, and their regulators, will not accept.
Auditability across layers
An effective institutional oracle should provide full transparency at every layer after an event. At each stage, any participant should be able to answer 3 questions:
- What data was requested?
- What was delivered?
- Where did it come from?
As every rate is independently verified against a regulated data source before it reaches the chain, and every on-chain delivery is recorded on an immutable ledger, these questions can be answered at any point in time, regardless of which delivery model is in use. The audit trail is complete whether data arrives continuously via a pipeline or on-demand in response to a contract query. This is the standard institutional risk committees require before they can rely on on-chain infrastructure for consequential decisions.
Scaling without compounding complexity
Multi-chain oracle architectures that rely on decentralized node networks face a structural scaling issue. Every new asset on each new chain requires its own dedicated oracle deployment, multiplying operational overhead, node diversity requirements, and verification bottlenecks with each addition.
A direct connection to a single, high-quality data provider sidesteps this entirely. Data arrives already normalized and standardized at the source. New exchanges or assets added to the provider’s infrastructure become immediately available to all participants, without additional integration work.
On-chain finance depends entirely on the quality of the data infrastructure beneath it, and that infrastructure is only as reliable as the accountability structures that govern it.
Blockchain oracles are the mechanism by which the on-chain environment connects to the economic reality it is built to reflect. When that mechanism is opaque, data sources cannot be identified, methodologies cannot be audited, and no entity is contractually liable for what reaches the chain, the risk does not stay contained within the oracle. It spreads through every smart contract, automated action, and financial product built on top of it.
The institutions that will participate meaningfully in on-chain finance will be those that insist on the same standards of data governance, auditability, and regulatory compliance on-chain that they already apply off-chain.
How direct source oracles are powering institutional finance
Blockchain oracles contribute and enable a diverse range of real-world applications across the institutional finance ecosystem. By connecting off-chain data to the chain, new opportunities emerge that take full advantage of blockchain technologies’ unique characteristics.
On-Chain Perpetual Futures & Derivatives Trading
Powers perpetual futures markets with manipulation-resistant price feeds and secure, centralized oracle infrastructure.
Tokenized Indices
Consolidates distribution, entitlement management, and fee optimization with a blockchain-agnostic solution enabling on-chain issued or operated index-based financial assets.
Post-Trade Processes On-Chain
Facilitates automated, transparent collateral workflows by providing institutional-grade Crypto, Equities, Fixed Income, Commodities, and FX marks.
Tokenized Asset Pricing & Valuation
Delivers accurate, auditable pricing for tokenized securities, funds, and real-world assets to meet regulatory valuation standards and investor reporting requirements.
Treasury & Collateral Management
Enables real-time mark-to-market calculations for crypto, fixed income, and FX collateral, optimizing capital efficiency and meeting margin requirements across traditional and digital assets.
Fund Operations & NAV Calculation
Automates 24/7 fund administration with daily NAV calculations, AUM tracking, and inventory management powered by compliant, audit-ready data infrastructure.
Structured Products Pricing
Enables institutional-grade valuation of complex derivatives and structured products with transparent, replicable pricing methodologies and real-time risk indicators.
Bond Issuance & Corporate Actions
Digitizes fixed-income workflows, including coupon calculations and corporate action management on public and private blockchain networks.
What to look for when choosing an institutional-grade oracle
Most blockchain oracle infrastructure is designed for permissionless DeFi environments, but to effectively enable institutional participation and use cases, they need to meet a very different set of criteria.
Contractual Accountability
What:
The oracle should operate within a defined contractual framework that allocates tasks, responsibilities, and liabilities according to financial markets best practice. If there is no contract, there is no accountability.
Why it matters:
Decentralized oracle networks are designed to distribute trust across nodes precisely because no single participant is willing to accept accountability. Without that ownership, financial market participants, market infrastructures, or data vendors cannot engage. The contractual framework ensures there is an entity to hold responsible in the event that something goes wrong.
Data source transparency and auditability
What:
At all times, it should be possible to identify which data sources contributed to a given output, understand the methodology used to weight venues and normalise outliers, and reconstruct any prices generated.
Why it matters:
Decentralized oracle networks can verify which nodes participated in producing a feed, but the data aggregators each node streams from remain completely opaque. As a result, the calculation can’t be reconstructed, and the exchanges that contributed to it can’t be verified. This is problematic when that output is used to trigger automated actions like liquidations, and creates a major operational gap.
Support for licensed and proprietary data
What:
The oracle should be capable of delivering both open data and licensed data, including highly granular market data, indices, rates, implied volatility, FX rates, and interest rates, under appropriate access rights management.
Why it matters:
Decentralized oracle networks are architected around open data. This is a function of its permissionless design, e.g. you cannot enforce licensing or access controls in a system where any node can read and redistribute data freely. For institutions operating in capital markets, the most valuable data in decision-making is private and licensed. An oracle that cannot deliver it on-chain, while delivering that privacy and offering the correct access rights without breaching vendor agreements, is not a viable infrastructure choice for serious financial applications.
Financial-grade infrastructure and operational standards
What:
The oracle provider should operate to financial markets and ITC best practices in connectivity and data management, with recognized certifications such as SOC 1 & SOC 2, and the ability to support staged delivery environments for clients with structured deployment requirements.
Why it matters:
Decentralized oracle networks are not built to the operational standards that financial institutions require, namely guaranteed uptime commitments, enterprise connectivity, staged release cycles, and infrastructure audited against recognized security frameworks. Plugging financial-grade applications into infrastructure that is not designed for financial-grade operations introduces operational risk that no amount of node decentralisation can mitigate.
Protocol agnosticism
What:
The oracle should be capable of delivering data across permissionless L1 and L2 blockchains as well as private distributed ledger technology (DLT) networks, without requiring separate integrations or compromising data consistency across chains.
Why it matters:
Regulated institutions do not operate exclusively on public blockchains. Private DLTs remain a primary infrastructure choice for many financial market applications, and the tokenisation landscape will involve both permissioned and permissionless environments running in parallel. An oracle that is native to one ecosystem but cannot serve the other forces institutions to manage fragmented data infrastructure, which recreates the exact reconciliation problem that on-chain data delivery is supposed to solve.
Pitfalls to avoid when choosing an institutional-grade oracle
Don’t assume DeFi-grade infrastructure is sufficient for institutional use
Decentralized oracle networks were engineered for censorship resistance in permissionless environments, a complete contrast to the needs of regulated financial institutions. Contractual accountability, licensed data access, and operational standards audited against recognized frameworks are all mandatory in institutional-grade oracle infrastructure.
Evaluate the delivery mechanism instead of the data source
Opaque upstream aggregators sitting behind sophisticated node infrastructure produce unverifiable outputs regardless of how effectively the delivery layer is built. Scrutinise where data originates and whether every contributing source can be identified and reconstructed before evaluating how it travels on-chain.
Don’t treat coverage breadth as a proxy for data quality
Update frequency, venue selection methodology, outlier handling, and the provenance of underlying sources determine whether a price feed is usable in a regulated financial context. Keep in mind, coverage statistics are only a marketing number. They tell you how many assets an oracle touches, not how accurately or accountably any of them are priced.
If you’re looking for Chainlink alternatives, or a provider who can offer an institutional-grade oracle for your regulated financial products, our approach to building oracle infrastructure puts verification before delivery, with contractual accountability at every layer.
Learn more at onchain.kaiko.com