> 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/architecture-overview.md).
# Overview
How a fund is built: an onchain Safe stack with tokenised shares, priced by onchain NAV, complemented by an offchain indexing and automation layer.
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/architecture/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), or by the fund's exec timelock when one is configured. 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/architecture/core-concepts/shares.md) that is both the fund's shares **and** the onchain interface for [subscriptions](/funds/infrastructure/architecture/core-concepts/subscriptions.md) and [redemptions](/funds/infrastructure/architecture/core-concepts/redemptions.md). It is a **UUPS proxy**. Funds deployed on the current ([salt v4](/funds/infrastructure/architecture/deployment/deployment-addresses.md)) factory share one `kpkShares` implementation per chain; earlier funds each have their own. Either way upgrades are isolated, because each proxy controls its own implementation pointer. The shares token lives on the fund's declared **shares chains** (often just one) at the same address on each; 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/architecture/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/architecture/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 only on the fund's shares chains, at one address. Assets held across chains are valued by each chain's NAV Calculator and summed offchain 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/architecture/core-concepts/policies.md).
## Where to go next
{% content-ref url="/pages/RlzHVX2QoIhmGagfv12b" %}
[Fund deployment](/funds/infrastructure/architecture/deployment.md)
{% endcontent-ref %}
{% content-ref url="/pages/hIrBCMheMit82G3MiTCW" %}
[Core concepts](/funds/infrastructure/architecture/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 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/architecture/architecture-overview.md?ask=&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.
