Upgradeability Design
Upgradeability Design
Transparent Proxy vs Static Vaults • Circuit Hash Commitments + Verifier Replacement
In privacy-preserving systems, upgradeability poses a paradox: how do you evolve cryptographic logic without undermining the very opacity the system is built to protect? SnarkSide's architecture embraces this tension, designing an upgrade path that preserves verifiability without transparency, and evolvability without central trust.
This section outlines the architectural commitments made to enable future upgrades—whether for performance, circuit changes, protocol governance, or ZK library migrations—while maintaining the cryptographic integrity of the system.
1. Transparent Proxy vs Static Vaults
Transparent Proxy Pattern
For most smart contracts, upgradeability is implemented through a proxy contract pattern (e.g., OpenZeppelin Transparent or UUPS Proxy). This allows the logic to be upgraded while keeping state storage in place.
SnarkSide's Application:
Matching relayer registry, verifier contract, and oracle handler use proxy-controlled entrypoints
Upgrade keys are timelocked, requiring a verifiable off-chain signature and mandatory delay before deployment
All upgradeable contracts emit upgrade commitments, including circuit hash and version tag
Static Vaults (Non-upgradeable)
However, vault state—the most sensitive user data—is handled differently.
SnarkSide’s vault architecture is non-upgradeable by design. Vault logic is implemented as a deterministic ZK circuit + Merkle commitment. Once deployed, vault behavior is immutable:
Circuit logic cannot be changed
Only new vaults can be created under new circuit versions
Vault state is tied to the circuit commitment hash (see below)
This ensures that no upgrade can alter or override live user positions or deposits.
2. Circuit Hash Commitments
Each ZK circuit used within SnarkSide—whether for trade intents, match proofs, liquidations, or vault transitions—is:
Compiled into R1CS
Prover-verified via Groth16
Hashed using SHA-256 to produce a circuit commitment hash
Use in Protocol:
All user interactions reference a circuit hash version, ensuring users always know what proving logic they are using
The verifier contract stores and validates these hashes before accepting any proof
Proofs with unregistered or outdated circuit hashes are rejected on-chain, even if valid
This creates a decentralized version-control mechanism, binding every interaction to a specific cryptographic schema.
3. Verifier Contract Replacement
Verifier contracts on Ethereum (and L2 equivalents) are the final gatekeepers for ZK proof validity. SnarkSide implements a verifier registry contract, responsible for:
Storing an append-only list of approved verifier addresses
Binding each verifier to a specific circuit hash
Mapping verifiers to their input/output calldata schema
Workflow:
A new circuit is audited and published
The circuit is deployed with a new Solidity verifier contract
Governance (or deferred upgrade key) submits the verifier with its hash to the registry
A mandatory audit delay is enforced before activation
Clients can now generate proofs using the new verifier
Constraints:
Verifiers can only be added, never replaced or removed
Each user vault stores the circuit hash it was initialized with
Batch matchers and liquidation engines are also version-bound
This ensures that no single upgrade can retroactively alter or compromise previous system state.
4. Roll-forward Migration Model
Since circuits cannot be hot-swapped for live vaults or intents, SnarkSide adopts a roll-forward migration approach:
Users may close a vault under an old circuit
Withdraw and re-initialize under a new circuit version
Migration tooling will allow seamless export/import with optional proof-of-state portability (e.g., proof of PnL consistency)
5. Upgrade Friction by Design
To prevent abuse of upgrade mechanisms, SnarkSide introduces intentional friction:
All verifier additions are delayed via on-chain timelocks
Governance votes (when enabled) must be MACI-compatible to prevent correlation
Upgrade keys are ephemeral and destroyed once zk-governance primitives are available
Circuit transitions must be approved by an external ZK audit council (Phase 2+)
These measures ensure that no single actor can rewrite the proving environment or manipulate logic retroactively.
Conclusion
SnarkSide's upgradeability strategy is based on a simple rule:
Privacy-preserving systems should be forward-flexible but backward-sealed.
With static vaults, circuit hash commitment layers, and a constrained proxy model, the protocol achieves upgradability without trust leakage. And by designing each circuit as its own versioned, verifiable object, SnarkSide ensures that every proof—from trade intent to vault settlement—is always provably valid and never silently altered.
Because in cryptographic systems, upgradeability is not about making change easy. It’s about making tampering impossible.
Last updated