> 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/architecture-overview.md).
# Architecture overview
Funds use a hybrid architecture. Custody, permissions, share issuance, and valuation live **onchain**; indexing, APIs, user interfaces, and automation run **offchain** on top of that onchain state.
The onchain contract stack of a single fund (Onchain Investment Vehicle).
{% hint style="info" %}
Legacy terminology: older materials may refer to a fund as an **Onchain Investment Vehicle (OIV)**. It's the same underlying Funds infrastructure — the contracts repo is [`karpatkey/onchain-investment-vehicles`](https://github.com/karpatkey/onchain-investment-vehicles).
{% endhint %}
## Onchain components
Every fund is a stack of contracts deployed atomically by the [`KpkOivFactory`](/funds/infrastructure/deployment.md). A single fund spans one or more chains and is made up of:
* **Portfolio Safe** — the fund's vault. It holds all portfolio assets. Its **sole owner is the `Empty` contract** (`0xA470…4652`, deployed at the same address on every chain), so **no EOA or multisig can execute transactions on it directly**. Every action must flow through the Roles Modifiers.
* **Three Zodiac Roles Modifiers** — the programmable permission layer in front of the Safes:
* **Exec Roles Modifier** — the primary execution layer, enabled as a module on the Portfolio Safe and owned by the fund **admin** (a Security Council / governance Safe). It is the authoritative gatekeeper of Portfolio Safe execution.
* **Sub Roles Modifier** — a nested layer (avatar = Portfolio Safe, target = Exec Roles Modifier) used to route automated/bot transactions through the exec layer. Owned by the Manager Safe.
* **Manager Roles Modifier** — guards the Manager Safe's own actions (avatar & target = Manager Safe). Owned by the Manager Safe.
* **Manager Safe** — the operators' multisig. Fund managers sign here; it holds the `OPERATOR` role on the shares contract and is the fund's fee receiver.
* **`kpkShares` contract** — an [ERC-20 token](/funds/infrastructure/core-concepts/shares.md) that is both the fund's shares **and** the onchain interface for [subscriptions](/funds/infrastructure/core-concepts/subscriptions.md) and [redemptions](/funds/infrastructure/core-concepts/redemptions.md). It is a **UUPS proxy** backed by an **implementation deployed exclusively for that fund**, so upgrades are isolated. The shares token lives on **one chain** (typically mainnet); on other chains a fund deploys only the Safe + modifier stack.
* **NAV Calculator** (one per chain) — computes the USD value of the Portfolio Safe's portfolio on that chain. It reads balances through balance adapters and prices them through price feeds. See [Onchain Accounting](/funds/infrastructure/onchain-accounting.md).
{% hint style="info" %}
The `kpkShares` contract does **not** compute NAV. NAV is calculated onchain by the NAV Calculator; the resulting **share price** is submitted by an operator when settling requests (see [NAV](/funds/infrastructure/core-concepts/nav.md)).
{% endhint %}
### Multichain layout
A fund's **Portfolio Safe, Manager Safe, and Roles Modifiers share the same address on every chain** — a deterministic CREATE2 property of the factory. The shares token is deployed on a single chain. Assets held across chains are valued by each chain's NAV Calculator and summed off-chain into one global NAV.
## Offchain components
The offchain infrastructure complements the onchain system and supports data aggregation, user interfaces, and automated operations:
* **Data indexer** — tracks shares events and NAV values, indexes them, and denormalises the data into multiple formats consumed by the API and the web application.
* **JSON API** — exposes current and historical fund data (NAV, supply, positions, policies, user positions) for the web application and external integrations.
* **Web application** — lets users review performance and portfolio breakdowns, inspect approved policies, and create subscription and redemption requests through a simple interface.
* **Automated agents** — approve subscription and redemption requests without manual operator intervention, and help keep positions safe (for example, exiting compromised protocols during emergencies). They act through the Sub Roles Modifier, within the bounds set by onchain [policies](/funds/infrastructure/core-concepts/policies.md).
## Where to go next
{% content-ref url="/pages/RlzHVX2QoIhmGagfv12b" %}
[Fund deployment](/funds/infrastructure/deployment.md)
{% endcontent-ref %}
{% content-ref url="/pages/hIrBCMheMit82G3MiTCW" %}
[Core concepts](/funds/infrastructure/core-concepts.md)
{% endcontent-ref %}
---
# 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/funds/infrastructure/architecture-overview.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.