Architecture Overview
Specter is a data privacy protocol built as a sovereign blockchain. Its architecture is organized into three distinct layers: Consensus, Execution, and Data Protocol. Each layer has a well-defined responsibility, and together they provide a complete system for committing, proving, and revealing arbitrary data — without exposing that data to anyone except the intended recipient.
The protocol layer is data-agnostic by design. While the GHOST token demonstrates how private value transfer works on Specter, the same commit-reveal-prove architecture handles credentials, images, API keys, encrypted documents, and any other data that needs to be stored or transmitted privately on-chain.
Three-Layer Stack
Layer 1: Consensus (CometBFT)
The base layer is CometBFT v0.38.17, a Byzantine Fault Tolerant consensus engine. It provides:
- Immediate finality — blocks are final once committed. No confirmations needed. No reorganizations possible.
- BFT safety — the network remains correct as long as more than 2/3 of validators are honest. A block requires agreement from at least 2/3+ of the validator set.
- Proof-of-Stake — validators stake GHOST tokens and are subject to slashing for misbehavior (double-signing, extended downtime).
- ~2.5-second block times — tuned for interactive applications while maintaining consensus safety.
Layer 2: Execution (Cosmos SDK + EVM)
The execution layer combines the Cosmos SDK application framework with a full Ethereum Virtual Machine:
- Cosmos SDK v0.53.2 provides the module system, transaction routing, account model, governance, staking, and inter-blockchain communication (IBC).
- cosmos/evm v1.0.0-rc2 embeds a complete EVM inside the Cosmos application, enabling Solidity smart contracts to execute with full Ethereum compatibility.
- IBC (ibc-go v10) enables cross-chain communication with any IBC-compatible blockchain in the Cosmos ecosystem.
This dual execution model means Specter supports both native Cosmos SDK transactions (staking, governance, IBC transfers) and arbitrary EVM smart contract calls (Solidity, Vyper, or any EVM-compatible language).
Layer 3: Data Protocol (Ghost Protocol Contracts + ZK Circuits)
The application layer — the Ghost Protocol — consists of Solidity smart contracts deployed to the EVM and off-chain ZK circuits compiled with Circom. This layer implements:
- Commitment schemes using Poseidon hashing for both generic data and token-specific commitments
- Merkle tree management for efficient membership proofs over committed data
- Nullifier tracking for anti-replay protection without linking reveals to commits
- Groth16 ZK proof verification for on-chain validation of off-chain proofs
- Policy enforcement for programmable constraints on when and how data can be revealed
- Native token bridging via the ghostmint precompile for minting/burning GHOST through the privacy system
This layer is intentionally data-agnostic. The 4-input commitment variant (Poseidon4(secret, nullifierSecret, dataHash, blinding)) accepts any data hash — it does not care whether the underlying data is a credential, an image, an API key, or a message. The 7-input variant adds token-specific fields for the GHOST token use case.
Architecture Diagram
Key Modules
Cosmos SDK Modules
| Module | Role |
|---|---|
x/ghostmint | Custom module bridging EVM contracts to Cosmos x/bank for native GHOST minting/burning |
x/bank | Native token accounting, supply tracking, send/receive |
x/staking | Validator registration, delegation, reward distribution |
x/gov | On-chain governance proposals and voting |
cosmos/evm (vm) | Full EVM execution engine within Cosmos |
cosmos/evm (feemarket) | EIP-1559 dynamic fee market for gas pricing |
cosmos/evm (erc20) | ERC-20 token integration between Cosmos and EVM |
ibc (ibc-go v10) | Inter-Blockchain Communication for cross-chain data and asset transfer |
Smart Contracts (EVM Layer)
| Contract | Purpose |
|---|---|
CommitRevealVault | Orchestrates token privacy: commit (burn), reveal (mint), partial withdrawals |
OpenGhostVault | Orchestrates generic data privacy: commit any data hash, one-time reveal |
PersistentKeyVault | Reusable access to committed data via access proofs (no nullifier spent) |
CommitmentTree | Stores token commitment hashes, manages Merkle roots |
OpenCommitmentTree | Stores data commitment hashes, separate tree from tokens |
NullifierRegistry | Tracks spent nullifiers for token reveals |
OpenNullifierRegistry | Tracks spent nullifiers for data reveals and key revocations |
NativeAssetHandler | Authorized caller for ghostmint precompile; handles GHOST burn/mint |
ProofVerifier | On-chain Groth16 proof verification (generated by snarkjs) |
AssetGuard | Whitelist of authorized GhostERC20 tokens |
TimelockExpiry | Policy: time-window restrictions on reveals |
DestinationRestriction | Policy: recipient allowlists for reveals |
ThresholdWitness | Policy: M-of-N signature requirements for reveals |
ZK Circuits (Off-Chain)
| Circuit | Purpose |
|---|---|
redemption.circom | Proves valid token redemption: commitment preimage knowledge, Merkle membership, nullifier correctness, amount conservation, policy binding |
accessProof.circom | Proves valid persistent key access: commitment preimage knowledge, Merkle membership, access tag derivation (no nullifier spent) |
Design Principles
Data-first architecture. The protocol treats all data uniformly. Token privacy (GHOST) is one application built on the same cryptographic primitives that handle credential privacy, document privacy, or any other data type. The dataHash field in a 4-input commitment accepts any 254-bit value — the protocol imposes no schema or interpretation on the data.
On-chain verification, off-chain computation. All expensive operations — Poseidon hashing of multi-input commitments, Merkle proof construction, ZK proof generation — happen off-chain. The blockchain only verifies the compact Groth16 proof and enforces the nullifier/policy rules.
Separation of concerns. Consensus does not depend on privacy. Privacy does not depend on a specific token. The EVM layer does not depend on the data protocol. Each layer can be upgraded, extended, or replaced without affecting the others.
Supply conservation. For the GHOST token use case, the ghostmint module enforces a strict supply invariant: every burn during commit must have a corresponding mint during reveal. This is checked every block at the consensus level, independent of the smart contract layer.