Oracle

Oracles provide the price feeds Kaskad uses to value collateral, calculate health factors, and trigger liquidations. Kaskad runs its own oracle system from day one rather than depending on third-party providers.

Architecture

The Kaskad Oracle is a TEE-backed (Trusted Execution Environment) multi-source price aggregation system. It consists of two components:

• kaskad-nuntius — a Rust binary that runs inside an AWS Nitro enclave, fetches prices from 15 exchange sources, aggregates them, and signs the result with a key that never leaves the enclave
• kaskad-nuntius-contracts — a set of EVM contracts that verify enclave attestations on-chain and accept signed price updates

Data sources

Price data is fetched from mutiple sources in real time: Binance, OKX, Bybit, Coinbase, Kraken, KuCoin, Gate.io, MEXC, Bitget, Bitfinex, Bitstamp, Crypto.com, HTX, etc.

Aggregation model

Aggregation is based on Eliott Méa's A Mathematical Framework for Price Oracles (KEF/Kaskad, 2026). Rather than averaging quoted last-trade prices, kaskad-nuntius reconstructs a Consolidated Order Book: every source's bid/ask depth is normalised onto a shared price grid and stacked into a single combined book. It then runs an arbitrage-exhaustion pass — matching off any crossed liquidity exactly as an arbitrageur would, level by level — leaving a residual book that satisfies the no-arbitrage condition. The fair price is the midpoint of that residual spread (its Chebyshev centre).

This design handles stale, lagging, or non-actionable feeds for free. A venue quoting a price no one would actually trade against will appear as crossed liquidity against the rest of the consolidated book, and the exhaustion pass simply matches it off before the midpoint is computed — there's no need for an ad-hoc "drop if the timestamp drifts" filter. In the full framework, this is the same mechanism the DAN (Decentralised Arbitrage Network) exploits: the instant a feed becomes non-actionable, profit-motivated arbitrageurs trade against it and collapse it back into line. Kaskad's enclave simulates that exhaustion deterministically on each snapshot rather than waiting for real bots to clear the crossings.

Source authenticity is enforced one layer up by the TEE itself: the TLS sessions to each exchange are opened from inside the Nitro enclave and are covered by the same attestation that signs the published price. The snapshot is bound to actual exchange responses, not to whatever an operator might claim was returned — which means source-corruption attacks reduce to compromising the exchange itself.

The key security property proven in the paper: moving the published fair price by any meaningful amount forces an attacker to perturb real depth across the combined book by a capital quantity that scales with both the size of the move and how thick the book already is. Because the cost is set by aggregate cross-venue depth, an attacker can't cheaply manipulate the feed by skewing a single exchange. For liquid assets, oracle manipulation is expensive by construction — and exactly how expensive is provable rather than asserted.

TEE trust model

The enclave signing key is generated inside the AWS Nitro enclave and never exported. The enclave produces an attestation document containing the PCR0 measurement (a hash of the enclave binary). Anyone can:

• Reproduce the enclave build and verify the PCR0 matches what is registered on-chain
• Verify that every price update signature was produced by a key bound to that PCR0

NitroAttestationVerifier.sol verifies the attestation on-chain and registers the enclave's signing address. KaskadPriceOracle.sol then accepts only price updates signed by a registered enclave address.

Update flow

Price updates are published every 30 seconds by default. A price update is also triggered on-demand when any user interacts with the protocol through KaskadRouter — this means liquidators and borrowers always operate on a fresh price, and the liveness of the oracle is not dependent on a single relayer process.

Signed price data is available via a VSOCK pull API for any consumer that needs it directly.

Circuit breaker

Each asset has a per-update price change cap (15% for liquid assets). After 4 hours of on-chain silence, the first post-outage update is allowed a wider deviation (30%) but requires 2× the normal source quorum to proceed.

Staleness is enforced by KaskadStalenessChecker, which implements Aave's IPriceOracleSentinel interface. Borrow and liquidation are blocked when any relevant asset's price feed is stale beyond maxStaleness (capped at 4 hours). Supply, repay, and withdraw are not gated by staleness.

On-chain contracts

Oracle's role in the protocol

Collateral valuation
The value of a user's collateral is calculated using oracle price feeds. This determines maximum borrowing power (LTV ratios) and current health factor.

Liquidation triggers
When oracle-reported prices cause a borrower's health factor to drop below 1.0, the position becomes eligible for liquidation. Liquidators interact through KaskadRouter, which refreshes the price inline — liquidations always execute against a current price.

Milestone validation
TVL milestones are validated using TWAL (Time-Weighted Average Liquidity). Oracle prices feed into health factor calculations that determine whether positions are genuinely collateralised or artificially inflated. Risk parameter calibration
LTV, liquidation threshold, and liquidation penalty are set per asset. Thinner markets with lower oracle manipulation cost receive more conservative parameters to ensure the attack is unprofitable even at launch liquidity levels.