Architecture

Kaskad is organized as a four-layer protocol stack. Each layer has a clearly defined role, and the layers interact through deterministic smart-contract interfaces.

Layer 1 — Execution Layer: Igra Network

Igra is an EVM-compatible Layer 2 network anchored to the Kaspa L1 blockDAG. It provides the smart contract execution environment where all Kaskad operations run.

Key properties:

Full EVM compatibility — standard Solidity tooling, wallets, and libraries work out of the box
Sequenced on Kaspa L1 — transactions are ordered and settled against Kaspa's proof-of-work security
Fast settlement with low fees — benefits from Kaspa's 10 blocks-per-second throughput
Inherits Kaspa's security assumptions — PoW Nakamoto consensus via the GHOSTDAG protocol

Igra gives Kaskad access to the Ethereum developer ecosystem (tooling, auditors, composability patterns) while settling on a fundamentally different consensus layer.

Layer 2 — Lending Core

The lending engine is adapted from one of the most battle-tested and widely audited money-market architectures in production DeFi — compatible with established lending frameworks that have been stress-tested across billions of dollars in TVL on multiple chains.

What this layer handles:

Liquidity pool management (deposits and withdrawals)
Borrow and repayment accounting
Interest rate calculations (variable rates based on utilization)
Collateralization checks
Liquidation execution

Why this approach: Using a proven, extensively audited lending architecture minimizes implementation risk. The core lending mechanics — interest accrual, health factor calculations, liquidation logic — are well-understood and have been validated across years of production use. Kaskad's innovations sit on top of this foundation, not in place of it.

Layer 3 — Kaskad Protocol Modules

This is where Kaskad's custom logic lives. These are additional smart contracts that define protocol-specific behavior on top of the lending core.

Incentives Module

Manages epoch-based emission distributions, supplier and borrower reward allocations, utilization-weighted rewards, and anti-gaming eligibility rules.

Treasury Routing

Handles protocol fee collection and enforces the immutable 65/35 split between the DAO Treasury and Operational Treasury. All resource flows are deterministic and on-chain.

Milestones Module

Defines participation thresholds and TVL-based milestones that trigger additional incentive allocations. Uses TWAL/TWAP validation to prevent wash-trading and artificial TVL inflation.

Bounded Governance Module

Encodes parameter ranges at deployment. Manages proposal creation, snapshot-based voting, timelocks, and challenge windows. Ensures all governance actions stay within predefined safety bounds.

Oracle Integration

Provides price feeds for collateral valuation and liquidation triggers. Launches with enhanced existing oracle infrastructure, with a roadmap to a trustless, Kaspa-aligned oracle system (V2).

Layer 4 — Governance Layer

The governance layer defines who can participate in protocol decisions and how voting power is calculated.

Eligibility requires both:

An active liquidity position — the voter must be actively supplying or borrowing on Kaskad
Staked $KSKD — tokens staked in the governance contract as a coordination signal

Voting power is calculated as a combination of TVL contribution (time-weighted and uptime-adjusted) and loyalty score (cumulative voting history, which never decays). Voting is snapshot-based to prevent flash-loan attacks.

Governance can adjust operational parameters — emission splits, risk thresholds, incentive calibration — but only within the fixed ranges defined at deployment. It cannot modify core safeguards, access user funds, or bypass treasury routing rules.

Full governance details

How the Layers Interact

┌──────────────────────────────────────────────┐
│           Layer 4: Governance                │
│   Participation-based voting, bounded scope  │
├──────────────────────────────────────────────┤
│       Layer 3: Kaskad Protocol Modules       │
│  Incentives · Treasury · Milestones          │
│  Bounded Governance · Oracle Integration     │
├──────────────────────────────────────────────┤
│         Layer 2: Lending Core                │
│   Pools, Rates, Interest, Liquidations       │
├──────────────────────────────────────────────┤
│       Layer 1: Execution Layer               │
│   Igra L2 (EVM) ← anchored → Kaspa L1 (PoW)│
└──────────────────────────────────────────────┘

Each layer depends on the one below it and is constrained by the one above it. The lending core handles financial logic; the protocol modules add Kaskad-specific rules; governance tunes parameters within the modules' bounds; and all of it executes on Igra with Kaspa settlement.

On this page