Fund Vault Architecture
The Fund Vault is the core execution container of ZK OTC. It defines how capital is pooled, governed, executed, and accounted for—without exposing wallets, balances, or internal structure.
A Fund Vault is not a smart wallet. It is a governed, proof-driven state machine.
Architectural Objective
The Fund Vault architecture is designed to ensure that:
Capital is pooled without public balances
Actions are executed only through governance
LPs, managers, and signers remain anonymous
Internal accounting is verifiable but private
No single actor has unilateral control
The vault enforces rules first, execution second.
Core Components
The Fund Vault consists of the following architectural components:
1. Vault Identity
Each vault has a unique Fund Vault ID.
Used to scope governance, roles, and permissions
Bound to all proofs (membership, voting, execution)
Prevents cross-vault replay or authority leakage
The Vault ID is public. Everything associated with it is private by default.
2. Role & Permission Layer (Vault-Scoped)
Each vault defines its own role system, such as:
Fund Manager
Signer
LP
Auditor
Executor
Roles are:
Issued privately
Enforced via proof-of-role
Scoped strictly to the vault
There is no global role registry and no public role mapping.
3. Governance Binding
The vault is governance-bound.
All sensitive actions require:
A valid proposal
A finalized ZK DAO decision
Execution authorization via ZK multisig
The vault cannot:
Execute actions autonomously
Be drained by a manager
Bypass governance constraints
Governance defines what is allowed. The vault enforces how it is executed.
4. Private Treasury State
The vault maintains an internal treasury state that includes:
Asset balances
LP shares
Strategy allocations
Accrued fees
This state is:
Maintained off-chain or in ZK circuits
Updated through private settlement
Never published in raw form
On-chain observers cannot query vault balances.
5. Execution Constraint Engine
Each vault enforces execution constraints defined by governance.
Examples:
Maximum withdrawal per epoch
Strategy allocation caps
Allowed asset classes
Time-based execution windows
Constraints are:
Immutable per proposal
Checked at execution time
Enforced before settlement
Even authorized actions cannot exceed constraints.
6. Settlement Interface (ZK Pool)
The vault does not move assets directly.
Instead, it:
Interfaces with ZK Pools
Delegates settlement to private liquidity layers
Receives cryptographic confirmation of settlement
This prevents:
Address exposure
Route inference
Balance tracing
7. Accounting & NAV Engine
The vault supports private accounting via ZK circuits.
Capabilities include:
LP share accounting
Fee calculation
NAV computation
Performance aggregation
Outputs may include:
Aggregate NAV
Performance multipliers
Compliance proofs
Without revealing internal positions.
Vault Lifecycle
Vault is created with an initial role configuration
LPs deposit capital privately
Governance defines execution rules
Actions are proposed and approved
Execution is authorized via ZK multisig
Settlement occurs privately
Accounting state is updated
Proof receipts are emitted
Security Model
The Fund Vault architecture guarantees that:
Funds cannot move without governance approval
No single role can bypass constraints
Execution cannot occur outside defined scope
Vault state cannot be reconstructed externally
Security is enforced by:
Cryptographic proofs
Deterministic contracts
Layer isolation
What the Fund Vault Is Not
Not a public vault
Not a multisig wallet
Not a discretionary fund manager
Not a black-box custody service
It is a transparent-in-rules, opaque-in-state execution system.
Last updated