Scaling Strategy
Specter's scaling strategy is a four-phase roadmap for increasing data throughput without compromising the protocol's privacy guarantees. Each phase is additive -- earlier phases remain active as later phases are deployed. The chain itself remains the settlement backbone; scaling happens at the execution and coordination layers.
The Scaling Problem
The base CommitRevealVault processes one commit or one reveal per transaction. Each reveal requires an on-chain Groth16 proof verification, Merkle root check, nullifier registration, and policy enforcement. At ~2.5-second block times with a 25 million gas limit per block, this creates a practical throughput ceiling for high-volume applications.
The scaling roadmap addresses this by progressively reducing the per-operation overhead and parallelizing commitment storage.
Four-Phase Roadmap
Phase Summary
| Phase | Contract | Key Capability | Throughput Multiplier |
|---|---|---|---|
| 1. Batch Operations | BatchCommitRevealVault | 50 commits or reveals per transaction | ~50x per transaction |
| 2. Session Vaults | SessionVault | Agent executes hundreds of operations, settles in batches | ~100-500x per session |
| 3. Sharded Trees | ShardedTreeRegistry | Multiple parallel Merkle trees (e.g., 16 shards = 16M capacity) | Linear with shard count |
| 4. Runner Network | RunnerRegistry | Decentralized operators manage shards independently | Self-scaling with demand |
Additive Design
Each phase builds on the previous phases rather than replacing them:
- Phase 1 deploys alongside the base
CommitRevealVaultwith its own CommitmentTree and NullifierRegistry. The original vault continues to operate unchanged. - Phase 2 uses the batch infrastructure from Phase 1 for settlement but adds session management, budgets, and dispute resolution.
- Phase 3 multiplies the Phase 1 infrastructure -- each shard is a standard CommitmentTree + NullifierRegistry pair, deployed N times.
- Phase 4 decentralizes the management of Phase 3 shards -- runners stake GHOST, get assigned shards, and run their own proof generation and root updates.
A user can choose which phase of infrastructure to interact with based on their needs. Simple one-off private transfers use the base vault. High-throughput applications use batch operations. Agent-based workflows use session vaults. The protocol supports all modes simultaneously.
Data-Agnostic Scaling
The scaling infrastructure is not limited to token operations. Batch commits work for any data type committed to the Merkle tree -- credential batches, bulk document sealing, mass API key issuance. The BatchCommitRevealVault processes the same 7-input Poseidon commitments as the base vault, and the sharded tree registry is agnostic to what the commitment hashes represent.
Detailed Phase Documentation
- Batch Operations -- Phase 1 implementation details
- Session Vaults -- Phase 2 implementation details
- Sharded Merkle Trees -- Phase 3 and Phase 4 implementation details