> 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/deployment.md).

# Fund deployment

Funds are not deployed by hand. A single onchain factory, **`KpkOivFactory`**, assembles the entire contract stack — Safes, Roles Modifiers, and the shares token — in one transaction, fully wired and with ownership already transferred to the right parties.

<figure><img src="/files/xM0uZKxber2y7b73MTOx" alt="KpkOivFactory deploying the seven-contract fund stack in a single transaction."><figcaption><p>A single <code>deployOiv</code> call produces all seven contracts of a fund.</p></figcaption></figure>

## The factory

`KpkOivFactory` is already deployed at the **same address on every supported chain**. It has two permissionless entry points; only its infrastructure setters are restricted to the factory owner.

| Entry point                | Deploys                                                                                                                   | Used for                                                    |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
| `deployStack(StackConfig)` | The **5-contract operational stack**: Portfolio Safe, Manager Safe, and the three Roles Modifiers.                        | Sidechains — extending an existing fund to another chain.   |
| `deployOiv(OivConfig)`     | The **same 5-contract stack plus** a per-fund `kpkShares` implementation and its ERC-1967 UUPS proxy (7 contracts total). | The chain where the shares token lives (typically mainnet). |

### What `deployOiv` produces

{% stepper %}
{% step %}
**Portfolio Safe** — holds fund assets; sole owner is the `Empty` contract, so it can only be driven through the Roles Modifiers.
{% endstep %}

{% step %}
**Manager Safe** — operators' multisig; granted the `OPERATOR` role on the shares token.
{% endstep %}

{% step %}
**Exec / Sub / Manager Roles Modifiers** — the permission layer (see [Roles and operators](/funds/infrastructure/core-concepts/roles-and-operators.md)). The exec modifier is owned by `admin`; the sub and manager modifiers are owned by the Manager Safe.
{% endstep %}

{% step %}
**`kpkShares` implementation** — deployed fresh for this fund so its upgrade surface is isolated.
{% endstep %}

{% step %}
**`kpkShares` proxy** — the fund's ERC-20 shares token. Investors hold this. The factory initializes it, registers any additional assets, grants the Portfolio Safe → proxy allowances needed for redemptions, wires the Manager Safe as `OPERATOR`, hands `DEFAULT_ADMIN_ROLE` to `admin`, and renounces its own roles.
{% endstep %}
{% endstepper %}

The deploying account **retains no privileged role** afterward — all authority sits with `admin` and the Manager Safe configured at deploy time.

## Deterministic, cross-chain addresses

A single `salt` drives every CREATE2 deployment, with the caller's address mixed in to prevent salt-squatting. The consequence is the **cross-chain invariant**:

> For the same `(caller, salt)` on the same factory, `deployStack` and `deployOiv` produce **identical** Portfolio Safe, Manager Safe, and Roles Modifier addresses on **every** chain.

That is what lets a fund run `deployOiv` on mainnet and `deployStack` on each sidechain while keeping a **single Portfolio Safe address everywhere**. Two view functions return the addresses a deployment would produce, without sending a transaction:

* `predictStackAddresses(StackConfig, caller)` → the 5 stack addresses.
* `predictOivAddresses(OivConfig, caller)` → all 7 addresses.

{% hint style="info" %}
The same deployer account must be used across all chains to keep addresses identical.
{% endhint %}

Running `deployStack` on each sidechain by hand is optional: the **`CcipOivDeployer`** orchestrator does the whole fan-out from a **single mainnet transaction** over Chainlink CCIP, keeping the same addresses everywhere. See [Cross-chain deployment (CCIP)](/funds/infrastructure/deployment/cross-chain-deployment.md).

## Configuration

`deployOiv` takes an `OivConfig`. The shares parameters mirror the fund's economic settings (see [Fees](/funds/infrastructure/core-concepts/fees.md) and [Subscriptions](/funds/infrastructure/core-concepts/subscriptions.md)); fee rates are in **basis points** (100 bps = 1%), TTLs in **seconds**.

```solidity
struct OivConfig {
    SafeConfig managerSafe;              // operator multisig: owners + threshold
    uint256 salt;                        // drives all deterministic addresses
    address admin;                       // exec-modifier owner + DEFAULT_ADMIN_ROLE on shares
    KpkShares.ConstructorParams sharesParams;  // name, symbol, base asset, fees, TTLs, fee receiver
    AssetConfig[] additionalAssets;      // extra deposit/redemption assets beyond the base asset
}

struct KpkShares.ConstructorParams {
    address asset;                  // base asset (e.g. USDC) — auto-flagged isFeeModuleAsset = true
    address admin;                  // ignored; overridden by OivConfig.admin
    string  name;                   // share token name
    string  symbol;                 // share token symbol
    address safe;                   // ignored; overridden with the deployed Portfolio Safe
    uint64  subscriptionRequestTtl; // ≤ 7 days
    uint64  redemptionRequestTtl;   // ≤ 7 days
    address feeReceiver;            // receives management/performance/redemption fee shares
    uint256 managementFeeRate;      // bps, ≤ 2000
    uint256 redemptionFeeRate;      // bps, ≤ 2000
    address performanceFeeModule;   // WatermarkFee module, or address(0) to disable
    uint256 performanceFeeRate;     // bps, ≤ 2000
}
```

The factory validates the config before deploying (non-empty/duplicate-free Manager Safe owners, valid threshold, non-zero `admin` and base asset, no duplicate additional assets, required shares params set).

## Addresses

`KpkOivFactory`, `KpkSharesDeployer`, the `CcipOivDeployer` orchestrator, and the `Empty` contract are deployed at the **same address on every supported chain** (19 chains):

| Contract                       | Address                                      |
| ------------------------------ | -------------------------------------------- |
| `KpkOivFactory`                | `0xbafbca1804B6e46D4c54Cac0A0273F5B2A8F677F` |
| `KpkSharesDeployer`            | `0xea084E763F8535CBe28759b990F963BeDf60be9a` |
| `CcipOivDeployer`              | `0x6F2A3D35Ff275d6B76dB47eFB0Da1b2358daf11b` |
| `Empty` (Portfolio Safe owner) | `0xA4703438f8cc4fc2C2503a7e43935Da16BA74652` |

The full list of chains and ownership is on the [Deployment addresses](/funds/infrastructure/deployment/deployment-addresses.md) page. Per-fund addresses are listed on each fund's **Policies and addresses** page (for example, [USD Alpha](/funds/funds/usd-alpha/policies-and-addresses.md)).

{% hint style="warning" %}
**Trust assumptions.** The factory **owner** controls all infrastructure setters (Safe singleton, Zodiac mastercopy, shares deployer, …) **with no timelock**, so it must be a governance multisig or `TimelockController` — never an EOA. For a given fund, the **Manager Safe owners** receive ownership of the sub and manager Roles Modifiers, so they must be trusted at the same operational level as `admin`; the exec Roles Modifier (owned by `admin`) remains the authoritative gatekeeper of Portfolio Safe execution.
{% endhint %}


---

# 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/deployment.md?ask=<question>&goal=<endgoal>
```

`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.
