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

Before clear information was available regarding the release timeline of Kaspa’s smart contract layer on its L2s, our team began exploring how Kaskad might handle liquidations autonomously. We took inspiration from established protocols like Aave, which rely on external liquidators competing to secure undercollateralized loans. While our long-term goal was always to launch and adopt a decentralized liquidation model leveraging Kaspa’s high-throughput blockDAG and upcoming Layer 2 infrastructure, this early phase gave us space to test core assumptions.

‍
During Q2 2025, we developed and tested a V1 oracle and liquidation engine, built entirely off-chain. This internal prototype was never exposed to users, it was a controlled environment designed to observe how the protocol would behave under liquidation stress. The system was built to flag undercollateralized loans, simulate asset liquidation flows, and benchmark price responsiveness using our own weighted median price feed system.

‍
This phase gave us a pragmatic foundation. It helped us understand how asset volatility, price feeds, and transaction latency might impact liquidation integrity in a live setting. Just as importantly, it allowed us to shape the user experience we envisioned by refining how borrowers and lenders would interact with the protocol under real conditions. By simulating failure paths early, we gained confidence in designing a decentralized model that could scale securely on-chain once smart contracts were available.

‍
Here’s a recap of how we simulated liquidations during this exploratory phase:
‍

• Ensuring loan security while assuming protocol-side responsibility: In the absence of smart contracts, we simulated a system where Kaskad would temporarily hold user collateral off-exchange while preserving decentralization principles. Rather than depending on centralized platforms to custody or liquidate assets, we built an internal oracle that monitored real-time market prices. If a loan’s LTV crossed the liquidation threshold, the system would flag it and simulate the transfer of collateral to a designated exchange, chosen based on liquidity, transaction speed, and price competitiveness.
  This process helped us identify the operational and design risks involved in safeguarding user funds while working within the limited, early-stage pre-decentralization the protocol offered at the time.
• Why simulate this approach? Our aim was to avoid relying on self-custody or manual liquidations. Even in this early test environment, we wanted to protect user funds through automated, rule-based liquidation logic. Running this off-chain gave us visibility into timing, risk exposure, and alert mechanisms. It also helped validate how transparent, pre-defined liquidation flows could support trust and protocol stability.
• Building a robust oracle prototype: Our internal V1 oracle aggregated price feeds from major exchanges using a weighted median model. We explored methodologies used by leaders like Chainlink, Pyth, and Flare, but tailored the system to Kaspa's needs. Feed weighting was based on liquidity, volume, and exchange reliability. This allowed us to reduce the impact of outliers and test how price manipulation resistance could be improved in future on-chain versions.
  In later stages, we’ll share a deeper breakdown of oracle performance under high-volatility test conditions and explain what’s next, as we’re transitioning to an on-chain model using Kaspa’s L2.