Multi-Price Oracle System
Kamino’s most significant oracle architecture upgrade — the Multi-Price Oracle System — represents a fundamental shift in how the protocol sources and validates price data. Rather than selecting a single “best” price from one provider at any moment, the system aggregates pricing from all available high-quality oracle sources and continuously cross-validates them against each other in real time.No Single Point of Failure
Complete elimination of dependence on any individual data provider
Dynamic Price Selection
Automatically selects the freshest valid price across all providers at the moment of each transaction
Self-Healing
Automatic fallback during provider downtime or price deviation — no manual intervention required
Chainlink Data Streams
A key component of the Multi-Price Oracle System is the integration of Chainlink Data Streams — a pull-based, low-latency data delivery model from the industry’s most established oracle network. Unlike traditional push-based oracle feeds that update on fixed heartbeat intervals (and may be stale between heartbeats), Chainlink Data Streams deliver high-frequency market data that can be requested on-demand. This means the protocol can access the freshest available price at the exact moment it needs it — during liquidation checks, collateral valuations, and position adjustments. Before deployment, Chainlink Data Streams underwent extensive testing in Kamino’s mainnet testing environment for multiple weeks, running against existing price feeds. The testing demonstrated consistently strong results in both accuracy and latency, providing confidence for full production integration.For a detailed look at how Scope aggregates and validates prices from all providers including Chainlink Data Streams, see Scope Aggregator.
Evaluation Dimensions
Number of Price Sources
More independent price sources means more redundancy. If one feed fails, goes stale, or is manipulated, others continue to provide accurate prices. Kamino’s Scope oracle aggregator ingests from multiple providers simultaneously — but the number of providers that actually support a given asset varies. Major assets like SOL and USDC have feeds from Chainlink, Pyth, Switchboard, and Redstone. A newer or less liquid token might only have one or two providers. Fewer sources means less redundancy and higher oracle pricing risk.Types of Price Sources
Not all oracle feeds are equal. The assessment distinguishes between:- Decentralized oracle networks (Chainlink, Pyth) — many independent data providers aggregate prices, making manipulation extremely difficult. These are the highest-quality feeds.
- On-chain price feeds (Switchboard, AMM-derived) — prices derived from on-chain data. Generally reliable, but can be affected by on-chain liquidity dynamics.
- Centralized feeds — prices from a single provider or a small number of sources. Higher trust assumptions, higher risk.
Uptime and Freshness
Oracle feeds must update frequently enough that the price used by the protocol reflects current market conditions. A stale price — one that hasn’t updated for minutes during a volatile market — can cause the protocol to value collateral at an outdated price, delaying necessary liquidations. The assessment evaluates:- Update frequency: How often does each provider push new prices? Sub-second (Pyth pull-based) vs. heartbeat-based (Chainlink at fixed intervals)?
- Historical uptime: Has the feed experienced outages? How long were they? What was the market impact?
- Staleness thresholds: Scope enforces staleness checks — if a feed hasn’t updated within a configured interval, it’s flagged and alternatives are used.
Historical Accuracy
The assessment reviews whether the oracle has historically reported prices that align with actual market conditions. Persistent deviation between oracle-reported prices and verifiable market prices indicates feed quality issues. Cross-provider deviation is particularly informative: if Provider A consistently reports prices 0.5% different from Providers B and C, that pattern indicates a systematic issue with Provider A’s data sources or aggregation methodology.How Kamino Mitigates Oracle Pricing Risk
Beyond the assessment, Kamino’s oracle infrastructure applies several layers of protection to every price feed:Heuristic Validation Rules
Scope applies pre-validation rules before accepting any price update. These rules check for obvious anomalies — prices that are orders of magnitude different from the previous update, negative prices, or updates that arrive out of sequence.TWAP and EWMA Smoothing
Time Weighted Average Price and Exponentially Weighted Moving Average smoothing filters out short-term manipulation. Even if a single price update is manipulated (e.g., via a flash loan), the smoothed price barely moves because the manipulated datapoint is diluted across the time window.Price Bands for Pegged Assets
Stable and pegged assets have price bands — if the reported price falls outside the expected range (e.g., USDC outside ±1% of $1.00), it is rejected outright. This prevents flash crash exploits and feed malfunctions from affecting protocol operations.Multi-Provider Cross-Referencing
Scope cross-references prices from all available providers for each asset. If one provider reports a price that deviates significantly from the consensus, the anomalous feed is deprioritized and the protocol uses the validated price from other providers.How Oracle Risk Maps to Parameters
Assets with higher oracle pricing risk receive more conservative protocol parameters:| Oracle Quality | Typical Parameters |
|---|---|
| High (4+ providers, decentralized networks, sub-second freshness) | Higher Max LTV, lower borrow factor, general asset eligibility |
| Medium (2-3 providers, mixed feed types) | Moderate Max LTV, moderate borrow factor |
| Low (1 provider, centralized, limited history) | Lower Max LTV, higher borrow factor, potential isolation mode |
Ongoing Monitoring
Oracle quality is not static. Providers add and remove feeds, update frequencies change, and new providers enter the market. The risk framework continuously monitors:- Provider availability per asset (are all expected feeds active?)
- Feed freshness (are updates arriving on schedule?)
- Cross-provider deviation (are providers in agreement?)
- Staleness events (how often do feeds go stale, and for how long?)