> For the complete documentation index, see [llms.txt](https://docs.kpk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kpk.io/vaults/infrastructure/risk-framework.md). # Risk framework Risk curation is central to every KPK product. This page explains how assets and strategies are **evaluated, classified and monitored** so that each curated product rests on clear, data-driven risk assumptions. The framework 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, strategy or counterparty undergoes a structured review under our Due Diligence Framework, covering **more than 150 checks across 12 risk dimensions**: smart contract, upgradeability, governance, oracle, counterparty, market, liquidity, leverage and reflexivity, collateral, balance sheet, operational, and monitoring. {% 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. For stablecoin and wrapped-fiat collateral, Pharos Watch adds peg history, reserve composition, and executable DEX liquidity depth measured after concentration and stress discounts, which feeds directly into liquidity-based tiering and LLTV decisions. 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 %} {% step %} **Scored Outcome** Each dimension receives a severity score from 1 (minimal) to 5 (critical) with an explicit confidence level. The overall rating is the worst dimension score, not an average, so a single critical finding sets the profile. Scores are deliberately biased towards caution. A risk is judged by the harm it would cause rather than by an estimate of how likely it is, because probability is rarely knowable in DeFi and severity usually is. Where evidence is thin, the resulting low confidence counts against an asset rather than for it. Mitigants such as timelocks and audits are recorded as context but not netted off the score, so a well-managed risk still shows up as a real exposure. Findings are traced to primary sources, and every assessment is independently reviewed before it informs an allocation decision. Conclusions are one of four: proceed, proceed with conditions (e.g. a lower cap or tighter LLTV), defer pending specific open questions, or decline. {% endstep %} {% endstepper %} ## Tiering and allocation Once an asset or strategy clears due diligence, it is assigned a **risk tier**. Tiers are assigned per market rather than per asset in the abstract: the same collateral can sit in different tiers depending on the loan asset, LLTV, oracle route and liquidation venue it is paired with. Each tier corresponds to predefined **allocation rules,** which limit the product's exposure to that market. 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.
TierTypical CharacteristicsExamples
ADeep exit capacity, either as onchain liquidity (≥$50m, with ≥$10m executable at 2% slippage) or a primary redemption path with defined settlement mechanics and a transparent reserve; 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 recordHigh-liquidity LSTs with native redemption (e.g. wstETH), major wrapped BTC (e.g. WBTC, cbBTC), fully-backed fiat stablecoins (e.g. RLUSD)
BModerate liquidity, well-known protocols with some newer components, diversified oracle setupLRTs from established teams (e.g. weETH), LSTs with moderate liquidity (e.g. cbETH, rETH)
CLower liquidity or less battle-tested oracles, emerging protocols, moderate dependency complexityNewer LRTs, emerging yield-bearing stablecoins including those relying on issuer-run oracles (e.g. savUSD, sNUSD), or assets using alternative oracle setups (e.g. API3, RedStone Pull Oracles)
DExperimental or early-stage assets, limited liquidity, higher dependency or governance riskNiche or newly launched assets and strategies (e.g. srRoyUSDC)
> *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. Monitoring is designed as part of the assessment, not added afterwards. Each review ends in a monitoring plan derived from the risks it found: the specific events, admin calls and state thresholds that would signal a risk is materialising, each with a severity and a defined response. That plan is deployed directly into KPK's alerting stack, so the risks identified on paper are the risks watched in production. Observability is itself a scored dimension. Where a protocol's critical state transitions cannot be detected onchain, because contracts are unverified or material actions emit no events, that raises its risk score and can be enough to keep it out of a KPK product.
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, and watches for pause events on collateral tokens that could break redemption from the underlying. On the oracle side, KPK monitors 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: 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, peg and liquidity alerts from Pharos Watch, 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 [Automation](/vaults/infrastructure/automation.md) and 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. KPK's automated responses are graded to the severity and reversibility of the signal. A softer signal that may prove to be a false positive, for example a precautionary pause on a collateral asset, triggers a reversible soft shutdown that de-risks only the affected market and is unwound after human review once the team confirms the signal was benign, with no onchain cap change needed. Confirmed or terminal risk, and permanent offboarding, trigger a hard shutdown that zeroes the market's onchain caps and drains the position; re-enabling a market after a hard shutdown is a governance-class change that runs through the Curator Safe timelock and takes 3 days. Designing the soft path to be reversible lets KPK act on early signals while keeping the rest of the vault online. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.kpk.io/vaults/infrastructure/risk-framework.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.