Bounded Governance
Bounded governance is Kaskad's core governance innovation. Every adjustable protocol parameter operates within a hard-coded range set at deployment. Governance participants can tune values within these ranges, but they can never push any parameter below its safety floor or above its ceiling.
This design prevents governance capture, hostile takeovers, and the kind of catastrophic parameter changes that have damaged other DeFi protocols.
How It Works
At deployment, each adjustable parameter is assigned:
- A default value — the initial setting
- An adjustable range — how far governance can move the value in either direction
- A hard floor (or ceiling) — the absolute limit that can never be breached
Governance proposals can change parameters within these bounds. Any proposal that attempts to set a value outside the permitted range is rejected at the contract level — it is not a matter of social consensus or multisig intervention.
Bounded Parameters
| Parameter | Default | Adjustable Range | Hard Floor / Ceiling |
|---|---|---|---|
| Supplier minimum deposit | $100 | ±15% | $100 (cannot go below) |
| Supplier uptime requirement | 90% | ±2.5% | 80% minimum |
| Borrower LTV | 70% | ±5% | 15% minimum |
| Borrower uptime requirement | 50% | ±5–10% | 50% minimum |
| Emission split (Supply / Borrow) | 50/50 | 40–60% | Bounded range |
| Unused emission reallocation | — | 35–65% | Between Incentives and Supply Adjustment |
| Kaspa Core Funding | 5% | Up to 7.5% | 5% minimum |
What Governance Cannot Do
Bounded governance explicitly prevents the following actions, regardless of quorum or vote outcome:
- Disable liquidations — the liquidation mechanism is immutable
- Remove over-collateralization — borrowers must always post collateral above the minimum threshold
- Mint additional tokens — the 1B $KSKD supply is fixed at deployment
- Withdraw user funds — governance has no access to user deposits
- Bypass treasury routing — the 65/35 fee split is hard-coded and immutable
- Reduce parameters below safety floors — contract-enforced minimums cannot be overridden
Eligibility
Participating in governance requires both of the following:
-
An active liquidity position. The voter must be actively supplying or borrowing on Kaskad, maintained throughout the current epoch and meeting minimum thresholds.
-
Staked $KSKD. Tokens must be staked in the governance contract. Staking serves as a coordination signal — it does not generate yield.
This dual requirement ensures that governance power is held by users who have real economic exposure to the protocol's health, not by passive token holders or speculative voters.
Voting Power
Voting power is calculated using the following formula:
VS = TVL_score(t) + Loyalty_score(Σ)TVL Score reflects the voter's proportional liquidity contribution, weighted by:
- Amount supplied or borrowed
- Duration of the position
- Uptime during the epoch
Loyalty Score reflects long-term governance participation:
- Share of staked $KSKD
- Cumulative votes cast across all previous epochs
- Loyalty score never decays — early and consistent participants retain influence
Voting is snapshot-based: voting power is locked at the moment a proposal is created. This prevents flash-loan attacks and last-minute position changes from influencing outcomes.
Proposal Lifecycle
- Creation — An eligible voter submits a proposal to change one or more bounded parameters
- Snapshot — Voting power is locked for all eligible participants at the moment of proposal creation
- Voting period — Participants cast votes (for / against) during the defined window
- Timelock — If the proposal passes, a minimum 48-hour timelock begins before execution
- Challenge window — During a 24-hour window within the timelock, the proposal can be challenged if it violates safety bounds
- Execution — If unchallenged and valid, the parameter change is applied automatically on-chain
Anti-Capture Safeguards
Kaskad's governance model includes multiple layers of protection against hostile capture:
- Time-weighted voting — long-term participants have proportionally more influence than recent entrants
- Snapshot-based power — prevents flash voting via borrowed tokens or flash loans
- Timelocks + challenge windows — no changes can take effect instantly; the community has time to react
- Bounded parameters — even a successful hostile proposal cannot breach safety floors
- Quorum requirements — 60% quorum required; supermajority needed for major changes (e.g., treasury allocations)
The combination of these safeguards means that even in a worst-case governance attack scenario, the protocol's core safety properties remain intact.