Skip to main content

Ghost Protocol

Ghost Protocol is the core innovation at the heart of Specter. It is a general-purpose commit/reveal privacy primitive — a cryptographic building block that makes any on-chain data private by default.

This is an important distinction. Ghost Protocol is not a mixer. It is not a shielded transaction scheme. It is not limited to tokens. It is privacy infrastructure — a foundation that developers use to build any private application they can imagine.

The Envelope Analogy​

The simplest way to understand Ghost Protocol is to think about envelopes.

Commit (Vanish). You take a piece of data — tokens, a secret, a vote, a credential, a sealed bid — and place it inside a cryptographic envelope. The envelope is sealed with a unique hash that acts as a fingerprint: it proves the envelope exists and has specific contents, but reveals nothing about what is inside. The chain stores only this fingerprint. Your original data is gone from the public ledger.

Reveal (Summon). Later, when you need to prove something about your data, you do not open the envelope. Instead, you generate a zero-knowledge proof — a mathematical demonstration that you know exactly what is inside, without ever showing it. The chain verifies your proof, confirms you have not used this envelope before, and grants you access to what you committed. The data is never exposed.

Your Phantom Key is the credential that ties you to your envelope. It is a bearer credential — whoever holds it can generate the proof needed to reveal. No accounts, no addresses, no on-chain identity required.

Not Just Tokens​

Most privacy solutions focus on one thing: hiding who sent money to whom. Ghost Protocol does that, but it does much more.

Because the commit/reveal pattern works with any data, Ghost Protocol enables:

  • Private token transfers — commit tokens, reveal them to a new address with no link to the sender.
  • Sealed-bid auctions — commit bids that no one can see until the reveal phase.
  • Anonymous credentials — commit a proof of identity or qualification, reveal it on demand without exposing the underlying data.
  • Private voting — commit votes that cannot be observed or influenced before the counting phase.
  • Confidential documents — commit document hashes for timestamping and verification without revealing contents.
  • Secret sharing — commit secrets that can be selectively revealed to authorized parties.

The same primitive, the same proof system, the same Phantom Key abstraction — applied to an unlimited range of use cases. This is what makes Ghost Protocol infrastructure rather than a tool.

How It Works​

Ghost Protocol's cryptography is built on two proven components: Poseidon hashing for commitments and Groth16 zero-knowledge proofs for verification.

Commitments: Poseidon7​

When you commit data through Ghost Protocol, the system generates a commitment hash using Poseidon7 — a Poseidon hash function configured with 7 inputs:

  1. The Phantom Key secret (your private credential)
  2. A nullifier secret (used later to derive the nullifier and prevent double-reveal)
  3. A token identifier (identifies which token is being committed)
  4. The amount being committed
  5. A random blinding factor (ensures uniqueness)
  6. A policy address (optional, for programmable rules)
  7. A policy parameters hash (optional, encodes the policy's specific conditions)

The 7-input design is deliberate. By including the policy binding directly in the hash, Ghost Protocol ensures that the rules governing a commitment are cryptographically locked at commit time. No one — not even the committer — can change the policy after the fact.

Poseidon was chosen specifically because it is ZK-friendly: it requires far fewer constraints inside a zero-knowledge proof circuit than traditional hash functions like SHA-256 or keccak256. This translates directly to smaller proofs and lower verification costs.

Proofs: Groth16​

When you reveal a commitment, the system generates a Groth16 zero-knowledge proof — a succinct, non-interactive proof that demonstrates:

  1. You know the original data that was committed
  2. The commitment exists in the on-chain Merkle tree
  3. The nullifier you are presenting is correctly derived from your commitment
  4. The policy conditions (if any) are satisfied

Every Groth16 proof in Ghost Protocol is exactly 256 bytes with 8 public inputs, regardless of the complexity of the underlying data. This constant size is a critical property: it means verification cost is predictable (approximately 220,000 gas) and the proof reveals nothing about what was committed — whether it was 1 GHOST or 1 million, a simple transfer or a complex policy-bound credential.

Nullifiers: Preventing Double-Reveal​

Each commitment has a unique nullifier — a value derived from the commitment's secrets that is published at reveal time. The chain maintains a set of all used nullifiers. If a nullifier has been seen before, the reveal is rejected.

This mechanism prevents double-spending (for tokens) and double-use (for credentials) without revealing which commitment is being spent. The nullifier is mathematically linked to the commitment but cannot be traced back to it — only the holder of the Phantom Key can compute the correct nullifier.

Quantum Safety: keccak256 Layer​

Ghost Protocol includes a quantum-safe keccak256 layer as an additional defense. At commit time, a quantum secret is generated and its keccak256 hash is stored on-chain. At reveal time, the preimage must be provided and verified. This ensures that even if future quantum computers could break the elliptic curve cryptography underlying Groth16, the keccak256 hash provides an independent barrier that quantum algorithms cannot efficiently attack.

The Transaction Lifecycle​

Here is the complete flow of a Ghost Protocol transaction, from commit to reveal:

Commit Phase (Vanish):

  1. The user selects the data or tokens to commit, along with any optional policy rules.
  2. The client application generates the necessary secrets and computes the Poseidon7 commitment hash.
  3. A quantum secret is generated and hashed with keccak256.
  4. The commitment hash (and quantum hash) are submitted to the chain. If tokens are involved, they are burned via the ghostmint precompile.
  5. The commitment is inserted into the on-chain Merkle tree.
  6. The user receives a Phantom Key — a bearer credential containing all the secrets needed to later reveal.

Reveal Phase (Summon):

  1. The user loads their Phantom Key into the client application.
  2. The client builds a Merkle inclusion proof showing the commitment exists in the tree.
  3. A Groth16 zero-knowledge proof is generated with 8 public inputs, proving knowledge of the commitment without revealing it.
  4. The proof, nullifier, and quantum preimage are submitted to the chain.
  5. The chain verifies the ZK proof (constant 256 bytes, approximately 220,000 gas).
  6. The chain verifies the quantum preimage against the stored keccak256 hash.
  7. If a policy is bound, the chain enforces it.
  8. The nullifier is recorded to prevent future reuse.
  9. Tokens are minted to the recipient (or access is granted, depending on the use case).

Three Generations of Innovation​

Ghost Protocol has evolved through three major iterations, each expanding what is possible:

Generation 1: Basic Commit/Reveal​

The foundation. Users can commit data or tokens and reveal them later with a zero-knowledge proof. This alone provides unlinkability — the reveal cannot be traced back to the commit. It is the core primitive that everything else builds on.

Generation 2: Programmable Policies (v4.4)​

Commitments gain the ability to carry rules that execute at reveal time. A policy might enforce:

  • Time locks — the commitment cannot be revealed before a certain block or timestamp.
  • Recipient restrictions — only a specific address (or set of addresses) can reveal.
  • Minimum hold periods — tokens must remain committed for a minimum duration.
  • Compliance hooks — external verification (like KYC attestation) can be required at reveal.
  • Conditional logic — arbitrary conditions evaluated at reveal time.

Because the policy binding is included in the Poseidon7 hash, policies are tamper-proof. They cannot be modified after commitment. This makes Ghost Protocol suitable for regulated environments, escrow arrangements, and any scenario where enforceable rules need to coexist with privacy.

Generation 3: Persistent Reusable Keys (v4.5)​

In earlier versions, each commitment generated a new, single-use Phantom Key. Version 4.5 introduces persistent Phantom Keys — a single key that can be reused across multiple commitments and reveals.

This changes the user experience fundamentally. Instead of managing dozens of one-time credentials, users maintain a single Phantom Key that serves as their private identity on Specter. Think of it as a private wallet — except instead of an address that accumulates a public history, it is a credential that accumulates nothing visible to anyone else.

Persistent keys also enable more sophisticated patterns: recurring private payments, subscription models, ongoing credential verification, and long-lived private channels between parties.

Ghost Protocol is not a feature of Specter. It is Specter. Every other design decision — the Cosmos SDK architecture, the EVM compatibility, the token economics, the bridge infrastructure — exists to make Ghost Protocol as powerful, accessible, and composable as possible.