Permission & Multisig Model
The Permission & Multisig Model defines how authority is enforced at execution time inside a Fund Vault—ensuring that no single actor can move capital, while never revealing who approved what.
This model is the final control layer before any fund action is executed.
Purpose
Private funds require strong guarantees that:
No individual can act unilaterally
Internal approvals cannot be bypassed
Authority structure cannot be inferred externally
Traditional multisigs fail this requirement because:
Signer addresses are public
Approval patterns are observable
Internal power distribution leaks over time
ZKFund replaces visible multisig logic with proof-based permission enforcement.
Permission Model Overview
Every sensitive action inside a Fund Vault requires explicit permission.
Permissions are defined by:
Role eligibility
Governance approval
Execution thresholds
Action-specific constraints
An action is permitted only if all conditions are proven, not asserted.
Multisig Without Signatures
ZKFund implements multisig through ZK approval proofs, not signatures.
Each approval proof demonstrates:
The approver holds the required role
The approver belongs to the authorized signer set
The approver approves a specific proposal
The approval has not been used before
No signer identity, address, or key is revealed.
Threshold Configuration
Thresholds are defined per action type and enforced deterministically.
Examples:
Swap execution: 3-of-5 signers
Capital withdrawal: 2-of-3 managers
Strategy update: DAO approval + 1 manager
Emergency action: elevated threshold
Threshold rules are:
Immutable per proposal
Publicly verifiable
Privately enforced
Observers know a threshold exists, not who satisfied it.
Permission Evaluation Flow
1. Action Request
A finalized proposal unlocks execution
Execution context is fixed and immutable
2. Proof Collection
Authorized approvers submit ZK approval proofs
Proofs are context-bound and non-replayable
3. Threshold Verification
The contract verifies:
Proof validity
Unique approvals
Threshold satisfaction
4. Execution Authorization
Once thresholds are met:
Execution is authorized exactly once
Further proofs are rejected
Separation of Approval and Execution
ZKFund separates who approves from who executes.
Approvers prove consent
Executors trigger execution
Executors have no authority to approve
This prevents:
Power concentration
Execution manipulation
Approval coercion
Action-Specific Permissions
Different actions require different permission models.
Examples:
LP withdrawal → LP proof + manager approval
Large swap → signer multisig + risk constraints
Role update → DAO vote + elevated threshold
Permissions are explicitly defined, never implicit.
Anti-Abuse Guarantees
The Permission & Multisig Model enforces:
Single-use approvals
Strict context binding
Time-bound execution
Non-bypassable thresholds
Even authorized actors cannot exceed their permissions.
Observability
Observers can verify:
That execution was authorized
That thresholds were satisfied
That rules were followed
They cannot infer:
Who approved
How many attempts were made
Internal approval dynamics
Last updated