Governance & Upgrade Path
15. Governance & Upgrade Path
Why Governance Is Deferred
Privacy breaks via identity-linked votes • Temporarily centralized upgrade key design
SnarkSide was architected under the assumption that full-stack encryption introduces not only cryptographic complexity—but governance contradictions. Traditional on-chain governance depends on visibility: who voted, how much weight they carried, and what proposal was chosen. These mechanisms are inherently incompatible with the guarantees of privacy-preserving execution.
As such, SnarkSide is deliberately launching without any form of token-weighted, identity-linked, or address-based governance. Instead, it adopts a model of deferral + upgrade abstraction, where protocol mutation is held in reserve under strict security conditions until a viable cryptographic governance substrate exists.
1. Governance and Privacy: The Core Conflict
Governance mechanisms—especially those designed for DAOs or token-based systems—require transparency:
Identity (wallet or delegate)
Voting weights (token balance at snapshot)
Decision records (proposal outcome on-chain)
But SnarkSide’s design actively erases or obfuscates every one of these primitives:
Voter identity
Stealth addresses
Unlinkable to human agents
Voting weights
Nullifier-based vaults
No native token balance reading
Proposal history
No chain-visible intent
Can’t audit voter logs
Introducing governance here reintroduces metadata correlation, effectively negating the very design constraints that SnarkSide enforces elsewhere. In effect, “governance” becomes the leak.
2. Centralization via Upgrade Key: Acknowledged Design
The initial SnarkSide deployment uses a deferred governance key model. This means:
Core contracts (verifier, matching relay registry, intent resolver) are owned by a timelocked multisig
The key can be burned or rotated into a zk-rollup sequencer once secure coordination exists
Upgrade proposals are published off-chain and cryptographically signed using the $SNSD DAO’s key, with a public audit period before activation
This temporary centralization is a concession to reality:
ZK-based upgradability is not yet productionized
Verifier transitions and circuit migrations are high-risk
Governance frameworks like Governor Alpha or Snapshot are not anonymity-preserving
Instead of implementing an insecure or pseudonymous voting layer, we focus on immutability through default, minimal upgradability, and intentional friction.
3. Toward Anonymous Governance
We are actively tracking research into:
MACI (Minimal Anti-Collusion Infrastructure) for encrypted voting
Semaphore for nullifier-based voting with rate limits
zkDAO frameworks with commitment-phase + reveal-phase voting
Homomorphic encrypted tallying, preserving vote weights without leaks
Threshold FHE-based quorum aggregation
Once zk-governance reaches credible maturity, SnarkSide’s upgrade key will be:
Revoked from all human-controlled multisigs
Replaced with a cryptographic DAO layer
Subjected to enforced proposal liveness + verifiability constraints
4. Governance Roles: Long-Term Breakdown
Protocol Maintainer
Circuit patching, proof verifiers
Phase 1 (pre-mainnet)
Relayer Registry Manager
Onboard new matchers and proof providers
Phase 1
L2 Bridge Arbiter
Resolve cross-chain state disputes
Phase 2
zkDAO Core
Vote on system params (funding rate curves, intent TTL)
Phase 3+
Vault Parameter Council
Adjust leverage caps, margin buffers
Phase 3+
Conclusion
SnarkSide defers governance not because it rejects decentralization—but because it refuses to fake it. We do not believe you can have both full privacy and transparent token governance—not yet.
Until that paradox is resolved cryptographically, we choose privacy.
And we build with the conviction that real governance will emerge not from visibility, but from verifiability.
Last updated