Threat Model
This page defines the adversary classes Specter's data privacy protocol is designed to resist, what the protocol protects against, what it does not protect against, and how multiple defense layers compose to provide depth.
A threat model is not marketing. It is a precise enumeration of what an attacker can and cannot do. Understanding the boundaries of the protocol's guarantees is essential for users, integrators, and auditors.
Adversary Classes
1. Network Observer
Capabilities: Can see all on-chain data — every transaction, every block, every state change. Can run a full node. Can query any RPC endpoint. Can monitor the mempool.
Examples: Blockchain analytics firms, chain indexers, curious validators, any user running a full node.
This is the most common adversary. Every public blockchain assumes network observers exist. The Ghost Protocol is primarily designed to defeat this adversary class.
2. Malicious Validator
Capabilities: Everything a network observer can do, plus the ability to censor transactions (refuse to include them in blocks) and reorder transactions within a block they propose. Cannot forge transactions or alter protocol rules (the rest of the validator set enforces consensus).
Examples: A compromised validator operator, a validator coerced by a state actor.
With CometBFT consensus, a single malicious validator has limited power — they can only censor/reorder during blocks they propose. Sustained censorship requires control of >1/3 of the validator set (liveness failure) or >2/3 (safety failure, which implies consensus corruption).
3. Compromised Relayer
Capabilities: Full access to the relayer infrastructure — can read all inputs and outputs, modify code, log all requests. Can refuse to serve requests (denial-of-service).
Examples: A hacked relayer server, a malicious relayer operator.
See the Relayer Network page for detailed analysis. The critical property: relayers perform computation on derived values only and cannot extract raw secrets, redirect value, or link commits to reveals.
4. Quantum Adversary
Capabilities: Access to a cryptographically relevant quantum computer capable of running Shor's algorithm on elliptic curve discrete logarithms and Grover's algorithm on symmetric primitives.
Examples: Future state actors, advanced research labs. Not currently practical (estimated 10-20+ years for cryptographically relevant quantum computers).
This adversary can break BN254 elliptic curve security (Groth16 proofs, ECDH key agreement) but not symmetric primitives at 128-bit security (Keccak-256, AES-256 under Grover's provide 128-bit post-quantum security).
What Specter Protects Against
Transaction Linkability
Threat: An observer tries to determine which Summon (reveal) corresponds to which Vanish (commit).
Defense: The Vanish operation inserts a Poseidon commitment into a Merkle tree. The Summon operation generates a Groth16 ZK proof that the prover knows the preimage of some commitment in the tree — without revealing which one. The nullifier (derived from nullifierSecret) is unrelated to the commitment hash. There is no on-chain data connecting a specific Vanish to a specific Summon.
An observer sees N commits and M reveals but cannot determine the mapping between them. The anonymity set is the full set of commitments in the Merkle tree.
Data Content Disclosure
Threat: An observer tries to determine what data was committed.
Defense: The commitment is Poseidon4(secret, nullifierSecret, dataHash, blinding) or the 7-input token variant. The Poseidon hash is a one-way function — given the commitment, the observer cannot recover the inputs. The blinding factor ensures that even identical data produces different commitments (semantic security).
Recipient Disclosure
Threat: An observer tries to determine who originally committed the data being revealed.
Defense: The ZK proof demonstrates knowledge of a valid commitment preimage and Merkle membership. It does not identify the committer — only that the prover knows the secret values. The proof's public inputs are the Merkle root, the nullifier, and the data hash (or token details). None of these link to the committer's identity.
Front-Running
Threat: An observer sees a pending Summon transaction in the mempool and submits their own transaction to claim the value first.
Defense: The recipient address is bound into the ZK proof as a public input. The on-chain verifier checks that the proof was generated for the specific recipient address in the transaction. A front-runner cannot reuse the proof for a different address — the proof would fail verification.
Double-Spending
Threat: A user tries to reveal the same commitment twice.
Defense: Every Summon operation records a nullifier derived from nullifierSecret. The NullifierRegistry contract enforces that each nullifier can only be used once. A second reveal attempt with the same commitment preimage produces the same nullifier, which is rejected.
Commitment Forgery
Threat: An attacker tries to generate a valid ZK proof for a commitment they did not create.
Defense: The Groth16 proof requires knowledge of the full commitment preimage (secret, nullifierSecret, dataHash, blinding). Without these values, the attacker cannot generate a satisfying witness. Groth16 soundness guarantees that no polynomial-time adversary can produce a valid proof without a valid witness (under the knowledge-of-exponent assumption).
What Specter Does NOT Protect Against
Timing Analysis
Threat: An observer correlates the timing of Vanish and Summon operations. If Alice vanishes 100 GHOST at 3:01 PM and Bob summons 100 GHOST at 3:02 PM, and no other operations occurred in between, the link is probabilistically obvious.
Mitigation (partial): The relayer network introduces some timing decoupling — light clients submit through relayers, which batch and delay submissions. However, this is not a guaranteed defense. A sophisticated adversary with full mempool visibility can still perform timing analysis.
Recommendation: Users should wait for the anonymity set to grow before summoning. The more commits that occur between a vanish and summon, the larger the anonymity set and the weaker the timing correlation.
Metadata Leakage
Threat: An observer correlates IP addresses, browser fingerprints, or network metadata to link commits and reveals.
Mitigation (none at protocol level): Specter is a data protocol, not a network anonymity system. It does not provide IP obfuscation, traffic analysis resistance, or metadata protection. Users who require metadata privacy should use Tor, VPNs, or other network-level anonymity tools.
Side-Channel Attacks on Client Devices
Threat: Malware on the user's device reads the Phantom Key, seed, or private key material from memory, disk, or clipboard.
Mitigation (none at protocol level): Client-side security is outside the protocol's scope. Specter provides passphrase encryption (AES-256-GCM with PBKDF2 key derivation) for stored secrets, but this does not defend against an attacker with code execution on the device.
Social Engineering
Threat: An attacker convinces a user to reveal their Phantom Key, share their Phantom Identity PNG, or submit a transaction to a malicious contract.
Mitigation (none at protocol level): Social engineering is a human problem, not a cryptographic one. User education and UX design (e.g., warnings before sharing bearer instruments) are the appropriate mitigations.
Anonymity Set Size
Threat: If the anonymity set (total number of commitments in the Merkle tree) is small, statistical analysis can narrow the possible commit-reveal links even without breaking cryptography.
Mitigation (partial): The anonymity set grows over time as more users commit data. Batch operations and the Open Ghost Protocol (allowing third parties to commit on behalf of others) accelerate anonymity set growth. However, in early network stages, the anonymity set may be small enough for probabilistic deanonymization.
Global Passive Adversary with Auxiliary Information
Threat: An adversary who observes all on-chain data AND has off-chain auxiliary information (e.g., knows Alice received exactly 47.3 GHOST from an exchange at a specific time) can potentially link commits to real-world identities.
Mitigation (partial): Fixed denominations (when used), time delays, and large anonymity sets reduce the effectiveness of auxiliary information. But they do not eliminate the risk entirely.
Defense-in-Depth Layers
Specter's security is not a single mechanism but a composition of independent layers. Compromise of one layer does not necessarily compromise the system:
| Layer | Protects Against | Failure Mode |
|---|---|---|
| ZK Proofs (Groth16) | Linkability, data disclosure, identity disclosure | Broken if BN254 discrete log is solved or trusted setup is compromised |
| On-Chain Verification | Invalid proofs, double-spending, unauthorized reveals | Broken if smart contract has a bug (mitigated by audits) |
| Quantum Commitments | Future quantum adversaries breaking BN254 | Provides 128-bit post-quantum security via Keccak-256 |
| Policy Enforcement | Unauthorized access patterns, compliance violations | Broken if policy contract logic has a bug |
No single point of failure compromises all layers simultaneously. A quantum computer breaks Layer 1 but not Layer 3. A smart contract bug in the policy system affects Layer 4 but not Layers 1-3. This layered approach ensures the protocol degrades gracefully rather than catastrophically.