Oracles and Lending Protocols:
A Deep Dive into Robust Price Feeds and Kaskad’s future

Lending protocols in decentralized finance (DeFi) are like intricate machines, humming along to facilitate trustless borrowing and lending. At the heart of these machines lies a critical component: the oracle. Oracles are the eyes and ears of lending platforms, delivering real-time, reliable price data for assets used as collateral or borrowed. Without them, the entire system risks grinding to a halt—or worse, spiraling into chaos. In this post, we’ll explore why oracles are indispensable to lending protocols, outline our roadmap for building a robust oracle system for our platform, and explain why Kaspa’s blockDAG and parallel computing architecture position it to power the fastest, most resilient oracles in the long run.
Why Lending Protocols Need Oracles:
The Bedrock of Trustless Finance
Imagine you’re lending money to a friend, and they offer their vintage car as collateral. You’d need to know the car’s market value to decide how much you’re willing to lend and when to seize the car if they can’t repay. In DeFi, lending protocols face a similar challenge, but instead of cars, we’re dealing with volatile crypto assets. Oracles provide the real-time price data needed to value these assets accurately.

Here’s why oracles are non-negotiable for lending protocols:
Get started
Get started
Loan-to-Value (LTV) Ratios
Lending platforms calculate LTV ratios to determine how much a user can borrow against their collateral. For example, if a user deposits $100 worth of KAS and the protocol allows a 70% LTV, they can borrow up to $70. Oracles ensure the $100 valuation is current and trustworthy.
Borrowing Capacity
Accurate price feeds prevent users from overborrowing, which could destabilize the protocol. If an oracle reports an inflated collateral price, a user might borrow more than the collateral can cover, risking insolvency.
Liquidation Triggers
When collateral value drops below a certain threshold (the liquidation ratio), protocols must sell the collateral to recover the loaned amount. Oracles detect these price drops in real time, triggering liquidations to protect lenders from bad debt.
Risk Mitigation
Inaccurate or manipulated price data could lead to undercollateralized loans (where the loan exceeds the collateral’s value) or unfair liquidations (where users lose collateral prematurely). Decentralized oracles aggregate data from multiple sources, reducing the risk of manipulation or single-point failures.
Data integrity, by design
Fair price. Transparent risk. Smarter DeFi.
At Kaskad, oracles aren’t just about price feeds — they’re about trust. Every loan decision is backed by data you can verify, and liquidation rules you can understand. Because real DeFi means no surprises.
Our Oracle Roadmap
Building the best oracle
Our lending protocol is designed with decentralization and user sovereignty at its core. This philosophy shapes our approach to oracles, which we’re rolling out in phases, due to ongoing research, as well as the wait for Iqra to release a layer 2 on the Kaspa blockDag. Let’s break down our v1 oracle and our vision for the future.
Learn more about our Global Roadmap
Suggest a feature
check icon
2025
V1 Oracle: The start of the journey without SC’s

Many established lending protocols, like Aave, rely on a network of external liquidators—specialized actors who monitor loans and compete to liquidate undercollateralized positions in exchange for a fee, ensuring the protocol remains solvent. In the long run, we aim to adopt a similar decentralized liquidation model, leveraging Kaspa’s high-throughput blockDAG to enable efficient, on-chain monitoring and liquidation. 

For now, as we build traction, our v1 protocol handles liquidations by itself to mitigate bad debt swiftly. This approach has no impact on how users interact with or perceive their collateral—it’s simply a transparent, pragmatic mechanism to maintain stability while we scale, ensuring users’ assets are managed with the same care and security they expect. Here is how we will ensure liquidations :

  • Ensuring the security of loans and assuming risks: When a user deposits collateral, it’s held off-exchange to align with our decentralization ethos. Storing collateral on centralized exchanges exposes users to risks like exchange hacks or outages—something we categorically reject. Instead, our oracle monitors collateral prices in real time. If a loan’s LTV breaches the liquidation threshold, the protocol automatically flags the collateral for liquidation. The collateral is then sent to a carefully selected exchange (chosen based on liquidity, price competitiveness, and transaction speed) to be sold swiftly, minimizing bad debt and protecting the protocol from further price drops.
  • Why This Approach? This method ensures that the user funds are never compromised by defaulting to self custody. Kaskad will take the risk of slower liquidation processes in order to guarantee the safety of healthy loans. The protocol handles the sale of collateral transparently, and users are informed of the process upfront to avoid surprises.
  • A Robust v1 Oracle: Our v1 oracle aggregates price feeds from major exchanges, using a weighted median algorithm—similar to industry leaders like Chainlink, Pyth, and Flare. The weight on exchanges will be determined based on trading volume, liquidity, and reliability (criteria we’re finalizing). This allows us to filter out outliers and reduce the risk of manipulation. In another posts we will detail the limitations of such models in high-scale trestles environments.
SOON
Long-Term Vision: The Most Secure Oracle, Powered by Kaspa
Our ambition doesn’t stop at a solid v1 oracle. Thanks to a grant from the Kaspa Ecosystem Foundation (KEF), Eliott Mea has become a full time oracle researcher, under the direct supervision of Kaspa founder Yonatan Sompolinsky. This research will position our lending protocol as the first to deploy the most secure and decentralized oracle in DeFi. Not only will the theory of the oracle improve anything that has been seen so far in the market, but implemented on Kaspa’s unique blockDAG architecture will allow for unparalleled speed, scalability, and resilience.
Why Kaspa enables superior Oracles.
High Throughput for Real-Time Data
Oracles need to fetch and deliver price data from multiple sources (exchanges, APIs, etc.) with minimal latency. Kaspa’s blockDAG currently processes 1 block per second, with plans to scale to 10 or even 100 blocks per second. This means oracles can record and propagate price updates across the network almost instantly, ensuring lending protocols have up-to-the-second data for LTV calculations and liquidations. In contrast, slower blockchains like Bitcoin (1 block every 10 minutes) or Ethereum (1 block every 12 seconds) introduce delays that could lead to outdated price feeds and costly errors.
Parallel Processing for Robust Aggregation
Oracles aggregate data from multiple sources to compute a reliable price. This requires significant computational power, especially when handling high-frequency updates or large datasets. Kaspa’s parallel computing model, enabled by GHOSTDAG, allows nodes to process multiple blocks simultaneously without compromising consensus. For oracles, this means faster aggregation of price feeds, as nodes can validate and incorporate data from dozens of sources in parallel. The result is a more resilient oracle that can handle spikes in data volume without bottlenecks.
Scalability for Global Adoption
As DeFi grows, lending protocols will serve millions of users, requiring oracles to handle massive data throughput. Kaspa’s blockDAG scales linearly with network demand, unlike traditional blockchains where increasing block size or rate weakens security. This scalability ensures oracles can support a global network of lending platforms without sacrificing speed or decentralization.