Architecture Overview
Specter is a vertically integrated system spanning from low-level cryptographic circuits to end-user mobile applications. This page presents the full architecture, layer by layer.
System Diagram
Layer Breakdown
1. Blockchain Layer
Specter runs on a Cosmos SDK application chain with an embedded EVM. CometBFT provides Byzantine Fault Tolerant consensus with approximately 5-second block finality.
| Component | Role |
|---|---|
| CometBFT | Consensus engine. Orders transactions, produces blocks, provides BFT guarantees (tolerates up to 1/3 Byzantine validators). |
| Cosmos SDK | Application framework. Manages state, module system, transaction routing, IBC compatibility. |
| EVM | Ethereum-compatible execution environment. Runs Solidity smart contracts. Full EVM opcode support. |
x/ghostmint module | Custom Cosmos SDK module exposing an EVM precompile at address 0x0808. Bridges EVM contract calls to Cosmos x/bank for native token mint/burn. |
x/bank | Standard Cosmos banking module. Manages all native token balances, transfers, supply tracking. |
x/staking | Proof-of-Stake validator management, delegation, unbonding. |
x/gov | On-chain governance for protocol upgrades and parameter changes. |
x/distribution | Distributes staking rewards and commission to validators and delegators. |
x/slashing | Penalizes validators for downtime or double-signing. |
x/evidence | Accepts and processes evidence of validator misbehavior. |
Chain identity:
- Chain ID:
5446 - Native denomination:
aghost(18 decimals, displayed asGHOST) - Bech32 prefix:
umbra
2. Smart Contract Layer
All privacy logic lives in Solidity smart contracts deployed to Specter's EVM. The contracts follow a modular architecture where CommitRevealVault acts as the central orchestrator.
Core Contracts
| Contract | Purpose |
|---|---|
| CommitRevealVault | Orchestrator. Entry point for all commit and reveal operations. Coordinates calls to all other contracts. Manages commitment metadata, quantum commitments, and phantom key generation. |
| CommitmentTree | On-chain Merkle tree storing Poseidon hash commitments. Supports incremental insertion. The root is used in ZK proofs to demonstrate membership. |
| NullifierRegistry | Tracks spent nullifiers to prevent double-reveals. Each valid reveal consumes a nullifier; attempting to reuse one reverts the transaction. |
| ProofVerifier | Verifies Groth16 zero-knowledge proofs on-chain. Validates that the prover knows a valid leaf in the Merkle tree without revealing which leaf. |
| AssetGuard | Policy enforcement engine. Before a reveal completes, AssetGuard queries registered policy contracts to determine whether the operation is permitted. |
| NativeAssetHandler | The sole contract authorized to call the ghostmint precompile at 0x0808. Handles minting fresh GHOST on reveal and burning GHOST on commit. |
| GhostERC20Factory | Factory contract for deploying wrapped ERC-20 tokens that integrate with the commit/reveal pipeline. Allows any ERC-20 to participate in Ghost Protocol. |
Extended Contracts
| Contract | Purpose |
|---|---|
| OpenGhostVault | Privacy vault for arbitrary data (not just tokens). Users commit encrypted data on-chain and reveal access to it later, enabling secret sharing, private messaging, and confidential document storage. |
| PersistentKeyVault | Manages reusable phantom keys. Instead of generating a one-time key per commitment, users can maintain persistent keys that work across multiple commit/reveal cycles. Useful for recurring private interactions. |
| Policy contracts | Pluggable modules registered with AssetGuard. Examples include sanctions screening, time-lock enforcement, amount caps, and geographic restrictions. Each policy contract implements a standard interface and is invoked at reveal time. |
3. Cryptography
Specter uses a carefully selected cryptographic stack optimized for both ZK circuit efficiency and on-chain verification cost.
Poseidon Hash
Poseidon is an arithmetic-friendly hash function designed for use inside ZK circuits. Unlike Keccak256 or SHA-256, Poseidon operates natively over prime fields, making it orders of magnitude cheaper to prove in a SNARK circuit.
Specter uses three Poseidon variants:
| Variant | Inputs | Usage |
|---|---|---|
| Poseidon2 | 2 | Merkle tree internal node hashing (left child + right child) |
| Poseidon4 | 4 | Intermediate commitment construction |
| Poseidon7 | 7 | Full commitment hash: Poseidon7(secret, nullifier, assetId, amount, chainId, phantom, aux) |
Groth16 on BN254
Zero-knowledge proofs are generated using the Groth16 proving system over the BN254 (alt_bn128) elliptic curve. This combination was chosen because:
- BN254 has native EVM precompile support (
ecAdd,ecMul,ecPairingat addresses0x06,0x07,0x08), making on-chain verification gas-efficient. - Groth16 produces constant-size proofs (~128 bytes) with fast verification time.
- The trusted setup is circuit-specific; Specter's circuits have completed their setup ceremonies.
Keccak256 Quantum Defense
Each commitment includes a secondary keccak256 hash stored alongside the Poseidon commitment. At reveal time, the prover must supply the keccak256 preimage, which is verified on-chain. This provides a defense layer against future quantum attacks on the BN254 curve:
- If BN254 is broken, an attacker could forge Groth16 proofs but would still need to supply a valid keccak256 preimage.
- Keccak256 is a symmetric primitive resistant to Grover's algorithm (with sufficient output length).
SP1 zkVM (Planned)
Future iterations will integrate Succinct's SP1 zkVM for post-quantum proof generation. SP1 allows writing proof logic in Rust, compiled to a RISC-V target, and verified on-chain. This path enables migration away from BN254 to post-quantum-secure proof systems without rewriting circuit logic.
4. Relayer Infrastructure
Specter runs 11 Node.js services deployed on DigitalOcean, managed by PM2 process manager, and fronted by a Caddy reverse proxy for automatic TLS.
| Service | Role |
|---|---|
| Commitment Relayer | Accepts commitment data from clients (especially mobile), computes server-side Poseidon hashes when the client cannot, and submits commit transactions to the chain. |
| Proof Relayer | Generates Groth16 ZK proofs on behalf of constrained clients (mobile devices, low-power hardware). Runs the prover with the user's secret inputs and returns the proof. |
| Root Updater | Watches the CommitmentTree contract for new insertions and keeps the cached Merkle root synchronized. Ensures proofs reference a current, valid root. |
| Reveal Relayer | Submits reveal transactions to the chain on behalf of users. This allows users to reveal without needing GHOST for gas (the relayer pays gas and is reimbursed from the revealed amount). |
| Bridge Relayer | Monitors Hyperlane message passing between Specter and external chains (Ethereum, Base, Arbitrum). Relays cross-chain commitment and reveal messages. |
| Gas Relayer | Provides gas sponsorship for new users. Sends small amounts of GHOST to new addresses so they can submit their first transactions. |
| Status Relayer | Tracks the status of pending commits and reveals. Provides a query API so clients can poll for confirmation. |
| Card Relayer | Handles NFC card interactions. Validates NTAG 424 DNA signatures, maps card UIDs to commitments, and processes card-bound reveals. |
| Cross-Chain Relayer | Manages the Hyperlane integration for multi-chain Ghost Protocol operations. Coordinates asset locking on source chains and minting on Specter. |
| Indexer | Indexes on-chain events (commitments, reveals, nullifiers, policy actions) into a queryable database for fast client lookups. |
| Health Monitor | Monitors all other relayer services, chain RPC endpoints, and contract state. Alerts on failures. |
5. Client Layer
Web Application
- Stack: React + Vite + TypeScript
- Capabilities: Full commit/reveal flow, in-browser Poseidon hashing, in-browser Groth16 proof generation (via WASM), wallet connection (MetaMask, WalletConnect), NFC card management.
- Proof generation: The webapp can generate proofs entirely client-side using a WASM build of the Groth16 prover. This means the user's secret inputs never leave the browser.
Mobile Application
- Stack: React Native + Expo + TypeScript
- Capabilities: Commit and reveal flows, NFC card reading/writing, QR code scanning for phantom keys.
- Proof generation: Mobile devices typically offload proof generation to the Proof Relayer due to memory and compute constraints. The secret inputs are sent over TLS to the relayer, which generates the proof and returns it.
NFC Cards (NTAG 424 DNA)
- Hardware: NXP NTAG 424 DNA chips with SUN (Secure Unique NFC) authentication.
- Usage: Each card stores a phantom key bound to a specific commitment. Tapping the card reads the key and initiates a reveal flow. The card's cryptographic signature ensures the tap is authentic and the card has not been cloned.
- Use case: Cash-like bearer instruments. Whoever holds the physical card can reveal the committed value.
6. External Chain Integration
Specter connects to external EVM chains via Hyperlane, a modular interoperability protocol.
| Chain | Integration |
|---|---|
| Ethereum | Lock tokens on Ethereum, commit equivalent value on Specter. Reveal on Specter, unlock on Ethereum. |
| Base | Same pattern as Ethereum. Optimized for lower-cost L2 operations. |
| Arbitrum | Same pattern as Ethereum. Optimized for lower-cost L2 operations. |
The cross-chain flow allows users to privately transfer value originating from any supported chain without the source or destination being linkable.
Next Steps
- System Components — detailed data flow for commit and reveal operations
- Cosmos-EVM Integration — deep dive into the ghostmint precompile and why Specter needs its own L1