Tokenized products regularly face the challenge of integrating external data into their smart contracts. Whether it’s for foreign exchange conversions, collateral pricing, interest rate fixings, or emerging use cases like repo valuations. In many early institutional implementations, the default approach has been for the operator to inject these values as static parameters through transaction inputs. While a part of the off-chain data sourcing may be automated, the on-chain representation remains static. The smart contract receives pre-computed values with no provenance, dynamic access to underlying data feeds, or capability to update these values autonomously. This happens during lifecycle transactions (such as rebalancing or coupon payments) or operational transactions (like subscriptions, redemptions, and settlements). While functional, this static parameter model generates significant operational risks and uncontrolled IP exposure, while compromising auditability, and creating regulatory vulnerabilities for institutional applications.

When operations teams use backend systems to push valuations on-chain through static parameters, whether for daily NAV updates, portfolio pricing, or repo transactions, the process creates operational risk points at every stage. In a repo transaction a single incorrect parameter can cascade through the entire lifecycle. If the backend system pulls the wrong security price, applies an incorrect interest rate, or experiences a data feed interruption, the smart contract executes with flawed inputs. For repos, this means miscalculated repayment amounts, incorrect collateral valuations, and potentially inappropriate margin calls. Similarly, a bad NAV update can trigger miscomputed fund values and requires painful reversals, or compensating trades that are difficult to execute cleanly once entitlements have changed hands across multiple counterparties.

It also compromises auditability because the contract state contains the value but not the full story of how it was produced. Take a stablecoin stress test such as the USDe depeg on October 10, 2025, if your pricing data references only one source while the market trades meaningfully differently elsewhere, you can end up allowing redemptions on terms that don’t reflect real market conditions. Later, when risk, audit, or regulators ask for accountability, relying on a single source or static oracle configuration prevents solid and well-founded justifications. That lack of provenance makes it difficult to reconstruct whether the valuation was consistent and whether any discretionary interventions were justified, documented, and applied consistently across venues.

Finally, static injection creates regulatory vulnerabilities because institutional applications typically need to demonstrate that valuations are based on licensed sources, with controls around conflicts of interest and governance. While traditional off-chain systems can provide demonstrability through documentation and audit trails, leveraging the immutability and auditability properties of blockchain infrastructure makes demonstrability a native by-product of the system itself. This approach significantly reduces compliance overhead, streamlines business workflows, and provides regulators with real-time, tamper-proof transparency into whether the pricing policy was followed, investors were treated fairly, and whether market abuse or selective treatment could have occurred.

Market integrity starts with market robustness

The Canton Network was designed for institutional finance with requirements for confidentiality, compliance, and scalability. However, if it were to use partially static pricing it would undermine these fundamental principles by breaking traceability, eliminating independent verification, and preventing real-time auditing. Beyond these governance and control issues, static pricing also creates two very practical blockers. First, regulated data is typically licensed with usage restrictions that require proper attribution, audit trails, and controls on redistribution, all requirements that static parameter injection cannot satisfy. Second, comprehensive market data is too large and frequently updated to be manually pushed on-chain transaction-by-transaction.

Therefore, using unregulated, and sometimes static data in smart contracts, even for simple daily updates, creates technical and regulatory vulnerabilities. Without source traceability, no regulator can independently verify the data used to calculate metrics, resulting in a loss of the ability to prove that prices come from a licensed and compliant provider.

the role of oracles

Oracles serve as the established infrastructure connecting off-ledger information to on-chain execution. They are by definition the mechanism that brings external data into smart contracts with clear provenance, validation processes, and ideally an audit trail. Where centralized data injection inserts a value with no independent proof and no way to monitor or challenge it over time, an oracle can provide an auditable bridge between real-world market conditions and on-chain execution. The critical differentiator is whether the oracle operates as a black box with aggregated, anonymized data sources, or distributes identified data sources with transparent provenance and compliant IP distribution that benefits both the data provider and the consumer. 

Oracle robustness is not a nice-to-have for institutional-grade market infrastructure but a prerequisite for basic market integrity. Recent real-world incidents have shown that when price oracles fail, the issues rarely remains localized and risk is mispriced across protocols, with positions liquidated (or not liquidated) on the wrong basis, and losses propagating in ways that look and feel like traditional systemic events. In many DeFi settings, the oracle effectively acts as the market’s reference truth, yet the path from raw market data to an on-chain price can be opaque, hard to audit in real time, and difficult to challenge ex post. That is precisely why institutions and regulators increasingly demand auditable data rails with named counterparties.

The USDe Depeg in October 2025 illustrates this point in a concrete way. With the system relying on a single source, the price used to evaluate collateral and trigger liquidations was not continuously and independently verifiable against live market conditions, which resulted in the creation of bad debt. The losses did not arise from normal market volatility alone, but from an oracle design choice that removed traceability and real-time auditability. More broadly, the entire xUSD/deUSD ecosystem collapse triggered $285 million in total debt exposure across DeFi protocols.

A transparent oracle framework with clear responsibility

Kaiko’s oracle on Canton addresses these issues by publishing a verifiable hash attestation and respecting intellectual property rights. Kaiko has built a complete oracle infrastructure on the Canton Network, the blockchain dedicated to institutional finance. With the company becoming a Super Validator of the network in June 2025, and playing a key role in its evolution, Kaiko has developed a dedicated data layer offering three main functionalities:

• secure data distribution
• improved readability and auditability
• advanced composability and workflow automation

Specifically, in September 2025, Kaiko launched the first real-time pricing application for Canton, a collaborative and auditable portfolio management tool used by the 5North fund and the broker QCP, enabling the proposal, approval, and immutable confirmation of trades. Kaiko provides bidirectional data connectivity for the Canton ecosystem, with Data On-Ramp enabling direct access to regulated and compliant market data, such as BMR-compliant reference rates, FCA-regulated NCFX FX benchmarks, mark-to-market valuation feeds, and even spot and derivatives prices. This layer utilizes DAML smart contracts, deployed on Canton, allowing data to be published at predefined frequencies via a specific module.

Unlike decentralized oracles designed for public blockchains, the Kaiko oracle on Canton meets the specific requirements of regulated financial markets by adopting a centralized and responsible approach. The Request-Response model enables clients to create paid requests on-ledger, which Kaiko fulfills off-chain before writing the validated response back on-ledger. Concretely, consumers create contracts containing their query parameters, and Kaiko automatically publishes a contract with the result along with a hash attestation. 

This architecture ensures that only one payload is published per request. Unlike static parameter injection, which breaks the chain of responsibility, the Kaiko oracle establishes a clear contractual framework with allocation of tasks and responsibilities, while also allowing the integration of data protected by a license and an access rights management system that respects the intellectual property of data providers.

Before Kaiko, blockchains like Canton faced a critical vulnerability where unregulated price feeds created single points of failure with no accountability, exposing protocols to manipulation and stale data. Kaiko’s oracle architecture closed this gap by introducing a transparent, auditable system where every data point carries verifiable provenance and every actor bears clear responsibility, transforming price feeds from a systemic risk into a trusted infrastructure layer.

Learn more about our Data On-Ramp and other oracle solutions