> 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/funds/infrastructure/investment-framework.md).

# Investment framework

How KPK decides what a Fund can hold: market-regime analysis, a layered assessment of collateral, protocols and chains, and a composite rating that sets allocation limits.

Every KPK Fund follows the same investment framework. It decides which assets, protocols and chains a Fund may use, and how much it may allocate to each. Each Fund page then lists the constraints specific to that Fund, such as its collateral, venues and leverage band.

The framework works alongside KPK's [Risk Framework](https://docs.kpk.io/vaults/infrastructure/risk-framework), which covers due diligence on individual assets and venues: more than 150 checks across 12 risk dimensions.

### Market regime

KPK classifies the market into distinct risk regimes using a model that combines technical and fundamental inputs:

* Macro variables, such as interest-rate expectations from the US Treasury yield curve and changes in aggregate liquidity from M2 data.
* Market sentiment, based on momentum in crypto and traditional equity markets.
* DeFi rate dynamics, decomposed into ETH price volatility, supply-rate volatility and leverage indicators.

The current regime is compared with historical data on DeFi rates and risk premiums. The result sets each Fund's risk tolerance: how much leverage it can use, how concentrated it can be, and how much risk it can take per protocol.

### Layered assessment

Every allocation is assessed on three layers.

{% stepper %}
{% step %}
**Collateral**

The underlying asset, whichever protocol it is used on:

* Smart-contract design and technology risk.
* Governance structure and stakeholder incentives.
* Collateral quality, including default and depeg risk.
* Liquidity mechanisms and historical behaviour.
  {% endstep %}

{% step %}
**Protocol**

The application the Fund uses to access a market or strategy:

* Architecture, including composability, timelocks and emergency procedures.
* Vault or market design.
* Oracle mechanisms.
* Governance.
* External audits and security reviews.
  {% endstep %}

{% step %}
**Chain**

Funds operate on EVM-compatible chains only. Each chain is assessed on:

* Network security and consensus.
* Validator concentration.
* Historical uptime and incident record.
* Reliance on centralised infrastructure.
* Bridge design and cross-chain dependencies.
  {% endstep %}
  {% endstepper %}

### Allocation rules

Collateral and protocol assessments each produce a rating. The two are combined into a composite rating for every collateral and protocol pair, which sets the allowed allocation range, position size, leverage and exposure limits.

Chains work as a whitelist: a chain is either approved or not, and a Fund cannot allocate to a protocol on a chain that isn't approved.

Leverage is used only where the current market regime and the assessment allow it. A Fund may also take part in private transactions within its approved protocol universe, provided the counterparty meets KPK's internal risk standards.

### Onchain enforcement

The framework is enforced onchain. Each Fund's permitted actions are encoded as [policies](/funds/infrastructure/architecture/core-concepts/policies.md) in its Roles Modifiers, so the Manager Safe and KPK's automation agents can only call the contracts, functions and parameters the Fund's mandate allows.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.kpk.io/funds/infrastructure/investment-framework.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.