Role System

The Role System defines how authority, responsibility, and access are structured inside a Fund Vault—without revealing who holds those roles.

In ZKFund, roles are governance primitives, not identity labels.


Purpose

A private fund requires:

  • Clear authority boundaries

  • Separation of duties

  • Enforceable permissions

But exposing role holders publicly:

  • Reveals internal structure

  • Creates attack targets

  • Enables inference of strategy and control

The Role System solves this by enforcing authority through proofs, not disclosure.


Role Design Principles

Roles in ZKFund are designed to be:

  • Explicit — every permission is defined

  • Scoped — roles apply only to a specific vault

  • Non-public — no on-chain role lists

  • Non-transferable — cannot be traded or delegated silently

  • Governance-controlled — roles exist only by DAO approval


Common Vault Roles

While each vault can define its own schema, common roles include:

Fund Manager

  • Proposes fund actions

  • Oversees strategy execution

  • Does not have unilateral execution power

Signer

  • Approves execution of actions

  • Participates in ZK multisig thresholds

  • Has no visibility into other signers

LP (Liquidity Provider)

  • Deposits capital

  • Holds private shares

  • Can request withdrawals via proof-of-share

Auditor

  • Has read access via selective disclosure

  • Cannot vote or execute by default

Executor

  • Triggers execution after authorization

  • Has no decision-making power


Role Capabilities

Each role is associated with a capability set.

Capabilities may include:

  • Create proposals

  • Vote on proposals

  • Approve execution

  • Trigger settlement

  • Request withdrawal

  • Access selective disclosures

Capabilities are enforced:

  • At proof verification time

  • Inside governance and execution circuits

  • Without revealing role holder identity


Role Issuance

Roles are issued through private credential assignment.

  • zkID credentials are bound to roles

  • Issuance requires governance approval

  • No public issuance events expose identities

This ensures:

  • No role inflation

  • No silent privilege escalation

  • No hidden authority creation


Multi-Role Participants

A single participant may hold multiple roles.

Examples:

  • Founder + Signer

  • Manager + LP

  • Board + Auditor

Role combinations are:

  • Privately enforced

  • Context-bound

  • Evaluated inside circuits

Observers cannot infer role overlap.


Role Revocation & Rotation

Roles can be:

  • Revoked

  • Rotated

  • Temporarily suspended

All role changes:

  • Require governance proposals

  • Produce proof receipts

  • Do not reveal identities

This enables safe operational hygiene without exposure.


Role Isolation Guarantees

The Role System guarantees that:

  • No action can be taken without the correct role

  • Roles cannot be forged

  • Permissions cannot be escalated

  • Authority cannot be inferred externally


Why Roles Matter More Than Tokens

Tokens represent economic weight. Roles represent operational authority.

ZKFund treats these separately to:

  • Avoid governance capture

  • Model real organizational structure

  • Preserve confidentiality


Relationship to Other Systems

The Role System integrates with:

  • Identity Layer (credential issuance)

  • Governance Layer (voting eligibility)

  • Execution Layer (approval authority)

  • Settlement Layer (action constraints)

It does not operate independently.


The Role System is what allows ZKFund to behave like a real private organization, not a public wallet collective.

Last updated