> 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/mechanics.md). # Mechanics What a KPK Fund is made of, how subscriptions and redemptions work, how a Fund is priced, what it can charge, and who controls it. A KPK Fund is a set of smart contracts that holds assets, runs a strategy within onchain limits, and issues shares to its holders. This page explains how the pieces fit together without going into code. The [Architecture](/funds/infrastructure/architecture.md) section covers every contract in detail. ### The building blocks


Portfolio Safe	Holds the Fund's assets. It has no human signers, so nobody can move assets from it directly.
Roles Modifiers	The permission layer in front of the Portfolio Safe. Every transaction has to match a pre-approved policy.
Manager Safe	The multisig KPK's operators use to run the Fund and settle requests.
Shares token	An ERC-20 token representing a holder's share of the Fund. It is also where subscriptions and redemptions are requested.
NAV Calculator	Values everything the Fund holds, onchain, one contract per chain.

A Fund's onchain contract stack: a Portfolio Safe holding assets behind three Zodiac Roles Modifiers, a Manager Safe for operators, and a shares token. — The onchain contracts behind a single Fund.

### Policies: what a Fund can do A Fund's mandate is written into its Roles Modifiers as policies. Each policy allows a specific contract, function and set of parameters, for example supplying an asset to a named lending market. Anything outside the policies is blocked by the contracts themselves, whoever sends it. KPK's operators and automation agents work inside these limits. Agents handle routine tasks such as settling requests, rebalancing and exiting positions in an emergency, but they can only execute actions the policies allow. See [Policies](/funds/infrastructure/architecture/core-concepts/policies.md). ### Subscribing and redeeming Funds don't take direct deposits. Every entry and exit is a request that KPK settles in batches, so the Fund can manage liquidity and price every request the same way. {% stepper %} {% step %} **Request** To subscribe, a holder sends an approved asset (for example USDC) to the shares contract with a subscription request. To redeem, they send shares with a redemption request. The assets or shares are held in escrow inside the contract until the request is settled. {% endstep %} {% step %} **Settlement** KPK settles pending requests at the current share price. Subscribers receive newly issued shares and their assets move to the Portfolio Safe. Redeemers' shares are burned and they receive the redemption asset. {% endstep %} {% step %} **Rejection, expiry or cancellation** A request can be rejected, and one left unsettled for 7 days expires. Either way the escrowed assets or shares go back to the holder. A holder can also cancel a pending request once its cancellation window opens. {% endstep %} {% endstepper %} Every request carries a minimum amount out, so a holder never receives fewer shares or assets than they agreed to. See [Subscriptions](/funds/infrastructure/architecture/core-concepts/subscriptions.md) and [Redemptions](/funds/infrastructure/architecture/core-concepts/redemptions.md). ### Pricing A Fund is priced on its Net Asset Value (NAV): the value of everything it holds, minus any debt. The NAV Calculator reads each position onchain and values it with an independent price feed, such as Chainlink. Where a Fund holds assets on several chains, the values are added up into one NAV. The share price is the NAV divided by the number of shares. Three safeguards protect it: * A settlement price that moves more than 30% from the previous one is rejected onchain. * A stale price feed flags the NAV reading as unreliable. * A price feed that diverges from independent monitor feeds raises an alert. See [NAV](/funds/infrastructure/architecture/core-concepts/nav.md) and [Onchain Accounting](/funds/infrastructure/architecture/onchain-accounting.md). ### Fees A Fund can charge up to three fees, each capped onchain at 20%: * **Management fee**, accruing over time on the Fund's shares. * **Performance fee**, charged only on gains above the previous high point of the share price (the high-water mark). * **Redemption fee**, taken from the shares being redeemed. Fees are paid in shares to the Fund's fee receiver. Each Fund page lists the fees that apply. See [Fees](/funds/infrastructure/architecture/core-concepts/fees.md). ### Governance and security * **No direct access to assets.** The Portfolio Safe's only owner is a keyless contract, so assets can only move through the Roles Modifiers. * **Separate governance.** The Fund's permissions are owned by a governance multisig, KPK's Security Council for most Funds, rather than by the operators who run the Fund day to day. * **Timelocks.** Where a Fund has a timelock, changes to its permissions are queued onchain and take effect only after the delay. * **Isolation.** Each Fund has its own contracts. A change or upgrade to one Fund never affects another. Each Fund page lists its own Safes, signer thresholds and timelock. See [Roles and operators](/funds/infrastructure/architecture/core-concepts/roles-and-operators.md). ### Multichain Funds A Fund can hold assets on more than one EVM chain. Its Safes and Roles Modifiers have the same addresses on every chain, so assets moved between chains stay inside the Fund. While a transfer between chains is in progress, the assets are not counted on either chain, so requests are settled only once the transfer has arrived. See [Bridging](/funds/infrastructure/architecture/core-concepts/bridging.md). ### Beyond the contracts Alongside the onchain contracts, KPK runs: * **The KPK app**, where holders follow performance, inspect a Fund's policies, and create subscription and redemption requests. * **An indexer and API**, serving current and historical Fund data to the app and to integrators. * **Automation agents**, which settle requests and keep positions within their risk limits, always within the Fund's policies. --- # 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/mechanics.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.