ZK Multisig Execution

ZK Multisig Execution is the mechanism that turns a finalized governance decision into an enforceable action—without revealing who approved it, how approvals were coordinated, or how internal authority is structured.

It is the final governance gate before funds or state can be changed.


Purpose

Traditional multisig execution leaks critical information:

  • Public signer addresses

  • Approval order and timing

  • Internal power structure

  • Decision coordination patterns

For funds and DAOs, this creates:

  • Targeted attacks on signers

  • External pressure on key approvers

  • Long-term intelligence leakage

ZK Multisig Execution eliminates these risks by replacing signatures with zero-knowledge approval proofs.


Governance-Bound Execution

In ZKFund, execution is inseparable from governance.

An action can only be executed if:

  • A proposal has been finalized by ZK Voting

  • The proposal explicitly defines execution requirements

  • The required number of approvals is proven cryptographically

There is no “manual override” and no trusted executor.


ZK Multisig Approval Model

Each approval is represented by a ZK multisig proof.

A signer’s proof demonstrates:

  • Valid membership in the signer set

  • Authorization for the specific proposal

  • One-time approval for that execution context

What the proof does not reveal:

  • Signer identity

  • Wallet address

  • Approval timing relative to others

Approvals are counted, not identified.


Execution Thresholds

Execution thresholds are defined per proposal and enforced on-chain.

Examples:

  • 3-of-5 signers for swaps

  • 2-of-3 managers for withdrawals

  • DAO-level execution for critical parameters

Threshold rules are:

  • Immutable after proposal creation

  • Evaluated deterministically

  • Enforced without exposing signer composition


Execution Flow

1. Finalized Proposal

  • Governance produces a finalized state

  • Execution is unlocked but not yet permitted

2. Approval Proof Submission

  • Authorized signers submit ZK multisig proofs

  • Each proof is bound to:

    • Proposal ID

    • Fund ID

    • Execution epoch

3. Threshold Verification

  • The contract verifies:

    • Proof validity

    • Non-reuse of approvals

    • Satisfaction of m/n threshold

4. Execution Authorization

  • Once the threshold is met:

    • Execution becomes valid exactly once

    • Further approvals are rejected

    • Replay is impossible


Anti-Replay & Safety Guarantees

ZK Multisig Execution enforces:

  • Single-use approvals Proofs cannot be reused or replayed

  • Context binding Proofs are valid only for one proposal

  • Time constraints Expired proposals cannot be executed

  • Deterministic execution No ambiguity in when execution is allowed


Observability

What observers can verify:

  • The proposal was executed

  • The required threshold was met

  • All proofs were valid

What observers cannot infer:

  • Who approved

  • How many signers exist beyond the threshold

  • Internal approval structure


Why ZK Multisig Is Critical

Without ZK multisig:

  • Governance privacy leaks at execution

  • Signers become attack vectors

  • Internal structure becomes observable

ZK Multisig ensures that:

  • Authority is enforced

  • Power holders remain protected

  • Execution is final and irreversible


Relationship to Settlement

ZK Multisig does not move assets.

It produces a single outcome:

“This proposal is authorized to execute.”

Actual asset movement and state changes are handled by the Settlement Layer, under strict constraints defined by the proposal.

Last updated