Identity Layer

The Identity Layer is the foundation of ZKFund. It defines who is allowed to participate, in what capacity, and under which constraints—without revealing identities, wallet addresses, or persistent identifiers.

This layer enables authorization without identity disclosure.


Purpose

The Identity Layer exists to solve a core contradiction in on-chain systems:

Governance requires authorization, but authorization does not require identification.

ZKFund separates permission from identity, allowing participants to prove they are authorized without revealing who they are.


Design Goals

The Identity Layer is designed to:

  • Enable role-based access control without public role lists

  • Prevent Sybil attacks in anonymous governance

  • Avoid persistent identity linkage across actions

  • Support selective disclosure when required

  • Remain composable with governance and execution layers


Core Components

1. zkID (Zero-Knowledge Identity) A zkID is a cryptographic credential representing membership in a specific fund or DAO.

Key properties:

  • Not a wallet address

  • Not a username or DID

  • Not publicly enumerable

  • Not linkable across actions by default

A zkID allows statements such as:

“I am a valid member of Fund X” without revealing any other information.


2. Role Credentials

Roles are encoded as attributes bound to a zkID.

Examples:

  • Founder

  • Board

  • Signer

  • LP

  • Auditor

  • Executor

Role credentials enable proofs like:

“I am authorized to vote on this proposal” “I am part of the signer set for this fund”

No public mapping between roles and identities exists on-chain.


3. Membership Proofs (Proof-of-Role)

When interacting with the system, participants generate membership proofs.

Each proof verifies:

  • Membership validity

  • Role authorization

  • Context binding (fund ID, proposal ID, action type)

These proofs are:

  • Non-transferable

  • Non-replayable

  • Scoped to a specific action or session


4. Session-Based Authorization

To prevent linkage across actions, ZKFund uses ephemeral session keys.

  • Session keys are generated per voting period or execution context

  • They cannot be reused across proposals

  • They prevent correlation of multiple actions to the same participant

This ensures strong unlinkability even for active participants.


Sybil Resistance

The Identity Layer enforces Sybil resistance without revealing identity by:

  • Binding zkIDs to controlled issuance processes

  • Requiring economic stake or governance approval for membership

  • Limiting role-sensitive actions to provable credentials

Sybil resistance is enforced cryptographically and economically, not socially.


Selective Disclosure

While privacy is the default, the Identity Layer supports selective disclosure.

Under governance control, a zkID holder may prove:

  • Jurisdictional compliance

  • Membership duration

  • Role history

Without revealing:

  • Wallet addresses

  • Transaction history

  • Other fund memberships

Selective disclosure is optional and rule-bound.


Security Guarantees

The Identity Layer guarantees that:

  • Unauthorized participants cannot interact with governance

  • Roles cannot be forged or escalated

  • Membership proofs cannot be replayed

  • Identity correlation across actions is minimized


What the Identity Layer Does Not Do

  • It does not manage assets

  • It does not execute transactions

  • It does not store personal data

  • It does not expose public member registries


Why Identity Comes First

Every other layer in ZKFund depends on the Identity Layer.

Without it:

  • Governance cannot be enforced privately

  • Multisig execution cannot be anonymous

  • LP privacy cannot be preserved

  • Compliance becomes invasive

The Identity Layer ensures that authorization is absolute, while identity remains hidden.

Last updated