Fund Creation Flow

The Fund Creation Flow defines how a private fund vault is instantiated, configured, and secured before any capital or strategy is deployed.

This process ensures that privacy, governance, and execution constraints are in place from day one.

A fund cannot accept capital or execute actions until this flow is completed.


Design Principles

The fund creation process is designed to:

  • Establish governance authority before capital exists

  • Define roles and thresholds without exposing identities

  • Prevent retroactive rule changes

  • Ensure vault-level isolation

  • Minimize trust assumptions

Fund creation is configuration first, capital second.


Step 1. Vault Initialization

A new Fund Vault is initialized with:

  • A unique Fund Vault ID

  • A reference to the governing ZK DAO

  • Default governance parameters

  • Initial execution constraints

At this stage:

  • No capital exists in the vault

  • No roles are publicly visible

  • No execution is possible

The vault exists only as a governed container.


Step 2. Governance Binding

The vault is bound to a specific ZK DAO configuration.

This binding defines:

  • Which DAO governs the vault

  • Which governance rules apply

  • Which proposal types are allowed

  • Which execution thresholds are valid

Once bound:

  • Governance authority cannot be changed unilaterally

  • Any update requires DAO approval

This prevents silent takeover or reconfiguration.


Step 3. Role Definition

The creator defines the role schema for the vault.

Examples:

  • Fund Manager

  • Signer

  • LP

  • Auditor

  • Executor

For each role, the following are specified:

  • Permissions

  • Allowed actions

  • Voting or execution weight

  • Revocation rules

Roles are logical definitions, not identities.


Step 4. Initial Role Assignment

Initial role holders are assigned via private issuance.

  • zkID credentials are issued to role holders

  • Role membership is not published on-chain

  • Assignment proofs are stored privately

This step establishes authority without revealing who holds it.


Step 5. Execution Threshold Configuration

Execution thresholds are defined per action type.

Examples:

  • Swap: 3-of-5 signers

  • Withdrawal: 2-of-3 managers

  • Strategy update: DAO vote + 1 manager

Thresholds are:

  • Explicit

  • Immutable without governance

  • Enforced at execution time

This prevents discretionary execution.


Step 6. Treasury & Accounting Configuration

The vault configures:

  • Supported assets

  • Fee models

  • Accounting parameters

  • NAV computation rules

No balances are initialized yet.

Accounting logic exists before assets exist.


Step 7. Settlement Layer Binding

The vault is connected to:

  • One or more ZK Pools

  • Private settlement routes

  • Allowed liquidity venues

Settlement configuration ensures:

  • All future asset movements are private

  • No public treasury addresses are used


Step 8. Finalization & Activation

Once all configuration steps are complete:

  • The vault is marked as active

  • LP deposits are enabled

  • Proposal creation for fund actions is allowed

From this point forward:

  • All changes require governance

  • All actions require proofs

  • All execution is private


Why Creation Order Matters

If capital were deposited before governance:

  • Rules could be manipulated

  • LPs would bear hidden risk

  • Trust assumptions would increase

ZKFund enforces:

Rules first. Capital second. Execution last.


Security Guarantees at Creation

The Fund Creation Flow guarantees that:

  • No fund exists without governance

  • No capital exists without constraints

  • No authority exists without proof

  • No execution exists without approval

Last updated