Execution Layer
The Execution Layer is responsible for enforcing approved decisions without exposing who approved them. It ensures that once a proposal passes governance, it can only be executed when the required number of authorized approvals are proven—without visible signatures or signer identities.
This layer replaces traditional multisig wallets with zero-knowledge–verified execution.
Purpose
In conventional systems:
Multisig signers are publicly known
Approval order and timing are visible
Internal authority structure can be inferred
Even when funds are secure, organizational intelligence is leaked.
The Execution Layer eliminates this leakage by enforcing execution through ZK multisig proofs rather than public signatures.
Design Goals
The Execution Layer is designed to:
Enforce execution thresholds (e.g., 3-of-5) privately
Prevent unauthorized or premature execution
Bind execution strictly to finalized proposals
Eliminate signer identity exposure
Support deterministic and auditable enforcement
ZK Multisig Model
Instead of submitting signatures, each signer submits a ZK multisig proof.
Each proof cryptographically demonstrates that:
The signer is a valid member of the authorized signer set
The signer approves a specific proposal
The approval is unique and non-replayable
No signer address, public key, or signature is revealed.
Execution Flow
1. Execution Request
An execution is triggered for a finalized proposal
The proposal ID and execution context are fixed
2. Proof Submission
Authorized signers independently submit ZK multisig proofs
Proofs are bound to:
Proposal ID
Fund ID
Execution epoch
3. Threshold Verification
The smart contract verifies:
Proof validity
Membership correctness
Threshold satisfaction (m/n)
Proofs are counted, not identities.
4. Execution Authorization
Once the threshold is met:
The proposal becomes executable
No further approvals are accepted
Replay is prevented
Threshold & Role Enforcement
Execution thresholds may vary by action type.
Examples:
Swap: 3-of-5 signers
Withdrawal: 2-of-3 managers
Strategy update: DAO-level vote required
All thresholds are enforced:
On-chain
Deterministically
Without exposing who approved
Anti-Replay & Safety Guarantees
The Execution Layer enforces strict safety rules:
Proofs are single-use
Execution contexts are immutable
Expired proposals cannot be executed
Duplicate proofs are rejected
Execution can occur once and only once per proposal.
Separation from Settlement
The Execution Layer does not move funds directly.
Its sole responsibility is to:
Confirm cryptographic authorization
Emit an execution authorization state
Actual asset movement is delegated to the Settlement Layer.
This separation ensures:
Clean security boundaries
Minimal attack surface
Clear audit semantics
Observability
Observers can verify:
A proposal was executed
The required threshold was met
Proofs were valid
They cannot infer:
Who approved
In what order approvals occurred
Internal signer structure
Why ZK Multisig Matters
ZK multisig provides:
Stronger privacy than traditional multisig
Equal or higher security guarantees
Resistance to social and targeted attacks
Institutional-grade confidentiality
The Execution Layer ensures that authority is enforced, but authority holders remain invisible.
Last updated