Role-Based Access Control
Role-Based Access Control is the mechanism that defines who can do what inside ZK DAO—without exposing who holds power.
In ZKFund, authority is assigned to roles, not wallets. Permissions are enforced through zero-knowledge proofs, not address checks.
Purpose
Wallet-based access control assumes:
Identity = address
Authority = balance
This model breaks down for:
Institutions and funds
Teams with internal hierarchies
Organizations requiring confidentiality
RBAC in ZKFund exists to:
Encode real organizational structure on-chain
Enforce permissions privately
Prevent authority leakage
Core Design Principles
RBAC in ZKFund is designed to be:
Role-centric, not identity-centric
Proof-based, not address-based
Composable across governance and execution
Invisible to external observers
Roles in ZKFund
Roles are logical permission sets bound to zkIDs.
Common roles include:
Founder – ultimate governance authority
Board – strategic decision makers
Signer – execution approvers
Fund Manager – operational controller
LP (Liquidity Provider) – capital contributor
Auditor – read-only / disclosure-gated access
Executor – triggers execution after authorization
Roles are:
Non-public
Non-enumerable
Fund-scoped or DAO-scoped
Role Assignment
Role assignment is governed by ZK DAO.
Roles can only be granted via governance-approved actions
Assignment proofs are issued privately
No on-chain mapping reveals role holders
Role changes (add/remove/update) follow the same proposal → vote → execute flow as any other sensitive action.
Permission Enforcement
Every sensitive action in ZKFund requires a proof-of-role.
Examples:
Creating a proposal → requires specific proposer role
Voting → requires governance role
Executing an action → requires signer role
Requesting withdrawal → requires LP role
Permissions are enforced:
Inside ZK circuits
At contract verification time
Without revealing role holder identity
Multi-Role Governance
ZKFund supports multi-role governance models.
Examples:
Board votes carry higher weight than contributors
Certain actions require mixed-role approval
Emergency actions require Founder + Board approval
Role logic is encoded in governance rules, not inferred from wallets.
Role Scope & Context Binding
Roles are:
Bound to a specific fund or DAO
Context-scoped to specific actions
Not transferable across contexts by default
This prevents:
Privilege escalation
Cross-fund authority reuse
Accidental permission leakage
Revocation & Rotation
RBAC supports:
Role revocation via governance
Signer rotation without exposure
Emergency removal under defined rules
All changes are:
Cryptographically enforced
Logged via proof receipts
Invisible at the identity level
Security Guarantees
RBAC guarantees that:
No action can be taken without the correct role
Roles cannot be forged
Permissions cannot be escalated silently
Authority remains hidden from observers
Last updated