# Risk framework

Robust risk curation is central to every KPK product. This page explains how assets and strategies are **evaluated, classified and monitored** to ensure that each curated product is built on clear, data-driven risk assumptions.

KPK’s risk framework ensures that risk is assessed holistically and continuously, allowing KPK to adapt to changing conditions while maintaining predictable, well-understood exposures across all curated products.

It combines structured due diligence, independent risk signals, allocation rules and real-time monitoring, and is applied to every asset or strategy considered for use as collateral or another core component within a KPK-curated product.

## Initial Due Diligence

Each asset, market or strategy undergoes a structured review under our Due Diligence Framework, which covers **over 65 data points** across four themes: **smart contract logic, external dependencies, governance controls, and market conditions.**

{% stepper %}
{% step %}
**Onchain Assessment**

The onchain review examines the design and behaviour of all relevant contracts and dependencies, including:

* Smart contract logic, upgradeability and access controls.
* Oracle mechanisms, staleness checks and manipulation vectors.
* External dependencies such as bridges or third-party contracts.
* Liquidity depth, peg mechanisms and historical behaviour.
  {% endstep %}

{% step %}
**Offchain Validation**

Complementing the onchain review, KPK conducts targeted offchain checks to identify governance, operational and legal risks, including:

* Governance structure and upgrade powers.
* Admin key security, timelocks and emergency procedures.
* Entity structure and operational resilience of the issuer or core contributors.
* Track record, historical incidents and response capabilities.
* External audits and relevant disclosures.
  {% endstep %}

{% step %}
**External Risk Signals**

KPK integrates **independent third-party risk assessments** into its curation process to complement internal reviews. Platforms such as Credora and Exponential provide additional scores on protocol health, collateral behaviour and systemic exposure.

These signals do not replace internal due diligence but act as a supplementary layer of risk intelligence, especially during the initial assessment and ongoing monitoring.
{% endstep %}
{% endstepper %}

## Tiering and Allocation

Once an asset or strategy passes the prior stage(s), it is assigned a **risk tier**. Each tier corresponds to predefined **allocation rules,** which limit the pool's exposure to that asset or strategy.

Risk tiering reflects factors such as liquidity depth, oracle design, protocol maturity, and dependency stack complexity. It is applied during **product creation** (e.g. for Gearbox Earn Pools) or **strategy selection** (e.g. Morpho or Euler vaults) to enforce diversification and risk-weighted exposure.

<table><thead><tr><th width="81.51171875">Tier</th><th>Typical Characteristics</th><th>Examples</th></tr></thead><tbody><tr><td>A</td><td>Deep onchain liquidity (≥$50m, with ≥$10m executable at 2% slippage), highly reliable oracles (e.g. Chainlink or RedStone feed with ≤1% deviation tolerance and ≤24h heartbeat), mature protocols (≥12 months operating history), clean recent operational track record</td><td>LSTs with high liquidity and native redemptions (e.g. wstETH)</td></tr><tr><td>B</td><td>Moderate liquidity, well-known protocols with some newer components, diversified oracle setup</td><td>LRTs from established teams, LSTs with moderate liquidity (e.g. cbETH, rETH), wrapped BTC</td></tr><tr><td>C</td><td>Lower liquidity or less battle-tested oracles, emerging protocols, moderate dependency complexity</td><td>Newer LRTs or assets using alternative oracle setups (e.g. API3, RedStone Pull Oracles)</td></tr><tr><td>D</td><td>Experimental or early-stage assets, limited liquidity, higher dependency or governance risk</td><td>Niche or newly launched assets and strategies</td></tr></tbody></table>

> *Risk tiers are indicative and may vary by product. Actual allocation limits are defined per product and tracked through change logs.*

## Monitoring and Response

Risk doesn’t end once an asset is listed. KPK continuously monitors both **onchain and offchain signals** to track evolving conditions and take action when needed.

<figure><img src="/files/5Oe0SmjiANl02h27s8tL" alt=""><figcaption></figcaption></figure>

Different approaches to monitoring are adopted for the different components of each curated product.

* **Collateral monitoring** covers the assets used as security against KPK's lending markets and the issuers and protocols that stand behind them, including their contracts, governance, oracles, and offchain operating reality. KPK tracks governance proposals and contract upgrades that may affect collateral safety, watches for pause events on collateral tokens that could break redemption from the underlying, monitors oracle staleness, compares oracle prices to reference venues to detect anomalies, and watches for ownership-transfer events on the price feeds themselves. Issuer- and protocol-level signals are also tracked, including legal-structure changes, multisignature activity, shifts in underlying strategy, and staking performance such as slashing events. Liquidity-depth drops on major DEX and CEX venues feed into the same monitoring loop. Exploit-detection coverage extends to contracts immediately adjacent to the collateral, such as redemption layers and custodial wrappers.
* **Protocol monitoring** covers the lending platform and its dependencies as code, including the contracts and governance KPK does not control. Governance proposals and timelock changes are scrutinised to catch hostile or rushed upgrades. Core contract upgrades, where the protocol exposes them, are tracked. Vault-infrastructure governance is also tracked, including multisigs that KPK participates in (e.g. the Gearbox Instance Owner multisig). Changes to admin keys or key control structures at the protocol level trigger alerts. Exploit-detection coverage extends to governance modules adjacent to the venue.
* **Strategy monitoring** covers the live state of KPK's strategy running on the platform, including utilisation, borrower behaviour, market depth, and KPK's own curator controls. KPK watches liquidation activity and borrower position health, market-level liquidity changes (a significant TVL drop in a market can prompt offboarding), curator concentration, and available withdrawal liquidity and borrow activity. For example, utilisation levels above 97% are flagged as potential withdrawal risk. KPK's own curator and agent permissions are strictly scoped through the Permissions Layer.

The diagram below illustrates how different risk categories map to concrete monitoring actions:

<picture><source srcset="/files/o11zV9zVAjNl8Lr9Q1Tz" media="(prefers-color-scheme: dark)"><img src="/files/NcEMmGcaRUoCDWgropwM" alt=""></picture>

Across all three categories, signals come from a mix of onchain monitoring, third-party risk providers, and offchain sources, including posts from security researchers and incident-response accounts on X triaged by the team.

**Response mechanisms** combine automated and manual layers. Risk alerts from providers like Hypernative and Cyvers, as well as internal monitors, flag anomalies in real time. Some signals trigger automated protective actions, typically executed within 1–2 Ethereum blocks (under 30 seconds) and scoped to the affected market or position so unaffected exposure continues to earn; other signals are continuously monitored and routed to human review when the appropriate response benefits from context that a deterministic agent cannot capture. The exact response architecture varies by venue and is documented in the individual protocol sections.

Protective measures such as pausing markets or tightening collateral parameters can be triggered automatically when monitored signals warrant, or executed by the Emergency Admin role when a human review takes the action. More complex situations, including multi-asset or governance-related incidents, are handled through structured manual reviews. Risk tiers or parameters are updated accordingly when material changes occur, and every action is recorded for full transparency.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.kpk.io/vaults/infrastructure/risk-framework.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.