Development Phases
Specter's development follows a phased approach — each phase builds on the previous one's foundation, and no phase is activated until its prerequisites are met. This page describes each phase, its deliverables, and the dependencies between them.
Phase Overview
Phase 1: Testnet (Current)
Status: Active on specter-testnet-1
Phase 1 delivers the complete core protocol on a public testnet. All fundamental primitives are operational and available for developers, integrators, and auditors to test.
Deliverables
| Component | Description | Status |
|---|---|---|
| Ghost Protocol | Core commit/reveal (vanish/summon) with Groth16 ZK proofs and Poseidon commitments | Deployed |
| Phantom Keys | Bearer instrument key format — numeric encoding of commitment secrets | Deployed |
| Phantom Identity | Persistent anonymous identity via PNG bearer objects with split-key encryption | Deployed |
| Policy System | Programmable constraints on commit/reveal operations (time locks, amount limits, compliance hooks) | Deployed |
| Batch Operations | BatchCommitRevealVault for processing multiple commits/reveals in a single transaction | Deployed |
| Open Ghost Protocol | Third-party commitment capability — anyone can vanish data on behalf of another party | Deployed |
| Commitment Tree | On-chain Merkle tree with Poseidon node hashing and root history | Deployed |
| Nullifier Registry | Double-spend prevention via unique nullifier tracking | Deployed |
| Relayer Network | Root Updater, Commitment Relayer, Proof Relayer for light client support | Operational |
| Faucet | Testnet GHOST token distribution | Operational |
| Stealth Addresses | ERC-5564 compatible one-time recipient addresses via GhostStealthAnnouncer | Deployed |
What Phase 1 Validates
- End-to-end commit/reveal flow works with real ZK proofs on a live chain.
- Phantom Keys and Phantom Identities encode/decode correctly across clients.
- Policy enforcement correctly constrains operations.
- Batch operations maintain Merkle tree consistency.
- Relayer network handles real client traffic under load.
Phase 2: Pre-Mainnet
Status: Planned
Phase 2 is the hardening phase. No new features are added. The focus is entirely on security, correctness, and operational readiness.
Deliverables
| Component | Description | Dependency |
|---|---|---|
| Trusted Setup Ceremony | Multi-party computation (MPC) ceremony to generate production proving and verification keys. At least one honest participant ensures toxic waste is destroyed. | Finalized circuit design from Phase 1 |
| Audit Remediation | Fix all critical and high-severity findings from the smart contract, ZK circuit, scaling, and infrastructure audits. | Completed audit reports |
| Re-Audit | Independent verification that remediated issues are correctly resolved and no regressions introduced. | Completed remediation |
| Test Coverage Expansion | Comprehensive unit, integration, and property-based tests for all contracts and circuits. Target: >95% branch coverage for critical paths. | Stable codebase |
| Operational Runbooks | Documented procedures for validator onboarding, key rotation, incident response, and chain upgrades. | Infrastructure audit remediation |
Trusted Setup Ceremony Details
The trusted setup is the single most security-critical event in the protocol's lifecycle. It generates the cryptographic parameters (proving key, verification key) for the Groth16 circuits. The ceremony is structured as:
- Coordinator publishes the initial parameters.
- Participants (community members, researchers, organizations) each contribute randomness by applying a secret transformation to the parameters.
- Each participant's contribution is verified and the result is passed to the next participant.
- Each participant destroys their secret after contributing.
- The final parameters are published for public verification.
The security guarantee: as long as at least one participant honestly destroys their secret randomness, the toxic waste is unrecoverable and the parameters are safe. The ceremony will be open to public participation to maximize the number of independent contributors.
Why Phase 2 Blocks Mainnet
Without a production trusted setup, the current circuits use development-phase parameters where the toxic waste is known. This means proofs could theoretically be forged. This is acceptable for testnet (where tokens have no value) but is a hard blocker for mainnet.
Phase 3: Mainnet Launch
Status: Planned (post-Phase 2 completion)
Phase 3 is the public launch of the Specter mainnet with real economic value at stake.
Deliverables
| Component | Description | Dependency |
|---|---|---|
| Genesis Configuration | Initial validator set, token distribution, governance parameters | Phase 2 complete |
| Validator Onboarding | Documented process for validators to join the network, stake GHOST, and participate in consensus | Operational runbooks |
| Governance Activation | On-chain governance for protocol upgrades, parameter changes, and community proposals via Cosmos SDK gov module | Genesis configuration |
| Block Explorer | Public block explorer with privacy-aware transaction display (showing commitments/nullifiers without exposing linkability) | Deployed infrastructure |
| SDK Release | Stable client SDK for developers to integrate Specter's data privacy features into their applications | Tested API surface |
| Bug Bounty Program | Public reward program for responsibly disclosed vulnerabilities | Deployed mainnet |
Mainnet Launch Criteria
All of the following must be true before mainnet launch:
- Phase 2 trusted setup ceremony completed and verified
- All critical and high audit findings remediated and re-audited
- Testnet has operated for a sustained period without critical incidents
- At least N independent validators committed and operational
- Client SDK tested against production configuration
- Emergency upgrade procedure tested on testnet
Phase 4: Cross-Chain
Status: Research and development
Phase 4 extends Specter's data privacy guarantees across chain boundaries.
Deliverables
| Component | Description | Dependency |
|---|---|---|
| IBC Private Transfers | Vanish on source Cosmos chain, IBC packet carries commitment + proof, summon on Specter | IBC channel establishment, cross-chain proof format |
| Hyperlane Bridge Deployment | Production Hyperlane deployment with MultisigISM for Ethereum and L2 connectivity | MultisigISM validator set, bridge contract audits |
| Cross-Chain Vanish/Summon | Data vanished on one chain and summoned on another — full transaction graph breakage across chain boundaries | IBC private transfers + Hyperlane integration |
| Bridge Token Expansion | Support for additional bridged assets beyond gUSDC, gWETH, gLABS | HyperlaneTokenRegistry updates |
Cross-Chain Privacy Architecture
The key challenge is cross-chain Merkle root verification — the destination chain needs to verify that a commitment exists in the source chain's Merkle tree. This can be solved via:
- IBC light client proofs — verify the source chain's state root, then verify Merkle membership against it.
- Hyperlane ISM verification — the ISM attests that the commitment was valid on the source chain.
Phase 5: Advanced Scaling
Status: Research
Phase 5 addresses throughput and cost limitations for high-volume use cases.
Deliverables
| Component | Description | Dependency |
|---|---|---|
| Session Vaults | Time-bounded sessions with pre-authenticated access — reduces per-operation proof overhead | SessionVault audit remediation |
| Sharded Merkle Trees | Multiple parallel Merkle trees with a global nullifier registry — horizontal scaling of commitment throughput | ShardedTreeRegistry deployment |
| Runner Network | Decentralized network of proof generation nodes — replaces centralized relayer with permissionless infrastructure | RunnerRegistry, incentive model |
| Proof Aggregation | Verify one proof that attests to the validity of N proofs — amortizes verification cost across batch operations | Recursive proof research |
Scaling Targets
| Metric | Phase 1 (Testnet) | Phase 5 (Target) |
|---|---|---|
| Commits per block | ~10-50 | ~1,000+ |
| Proof generation time (server) | 2-5 seconds | Under 1 second (parallelized) |
| Merkle tree capacity | 2^20 leaves (~1M) | 2^20 per shard, unlimited shards |
| Verification cost per proof | ~200K gas | ~50K gas (aggregated) |
Sharded Tree Architecture
Each shard is an independent Merkle tree with its own root and leaf count. The ShardedTreeRegistry manages shard creation and assignment. The NullifierRegistry remains global — a nullifier spent in any shard cannot be reused in any other shard, preserving the double-spend guarantee across the entire system.
Phase Dependencies
Phases 4 and 5 can proceed in parallel after mainnet launch. Cross-chain operations may benefit from proof aggregation (Phase 5), but they are not strictly dependent — the initial cross-chain implementation can use individual proofs.