Skip to main content

Glossary

Alphabetical definitions of terms used throughout the Specter documentation. Terms in bold within definitions link to their own glossary entry where applicable.

Access Proof​

A zero-knowledge proof that demonstrates knowledge of a commitment's preimage without consuming its Nullifier. Used by Phantom Identity for persistent, repeatable authentication. Unlike a redemption proof (used in Summon), an access proof records an Access Tag instead of a nullifier, allowing the commitment to be accessed unlimited times.

Access Tag​

A unique identifier derived from the NullifierSecret and a Session Nonce during an Access Proof. Access tags are recorded on-chain to prevent replay within a session but do not consume the commitment. Each authentication session produces a different access tag, making sessions unlinkable.

aghost​

The smallest denomination of the GHOST token. 1 GHOST = 10^18 aghost. Analogous to wei in Ethereum or uatom in Cosmos. All on-chain token amounts are denominated in aghost.

Bearer Instrument​

A credential where possession equals authorization. Whoever holds the instrument can use it — no identity verification, no account lookup, no password. Phantom Keys and Phantom Identities are bearer instruments: the numbers (or the PNG file) are the access.

Blinding Factor​

A random BN254 field element included in every Commitment to provide semantic security. The blinding factor ensures that identical data committed twice produces different commitment hashes, preventing an observer from detecting duplicate commitments.

BN254​

The elliptic curve (also called alt-bn128 or bn256) used for all Groth16 proof generation and verification in Specter. It operates over a ~254-bit prime field and supports bilinear pairings, which are required for efficient on-chain proof verification via Ethereum's ecPairing precompile. Provides approximately 100-110 bits of classical security.

CometBFT​

The Byzantine Fault Tolerant consensus engine (formerly Tendermint) that provides Specter's consensus layer. Delivers immediate finality, ~2.5-second block times, and BFT safety as long as more than 2/3 of validators are honest.

Commitment​

A Poseidon hash that irreversibly binds a user to specific data without revealing that data. The 4-input variant is Poseidon4(secret, nullifierSecret, dataHash, blinding) for general data. The 7-input variant adds tokenId, amount, policyId, and policyParamsHash for token operations. Once inserted into the Merkle Tree, a commitment can be proven via a ZK proof without revealing its inputs.

CommitRevealVault​

The core Solidity smart contract that implements the Ghost Protocol's commit/reveal logic. It accepts Commitments during Vanish operations, verifies Groth16 proofs during Summon operations, and coordinates with the NullifierRegistry and CommitmentTree.

Data Hash​

A Poseidon hash of the arbitrary data being committed. The data hash is one input to the Commitment function. The protocol does not interpret the data hash — it treats it as an opaque field element. The semantics of what the hash represents (credential, image, API key, token metadata) are determined by the application layer.

Ghost Protocol​

Specter's core primitive: a commit/reveal system for any data. Users hash data into a Poseidon Commitment, insert it into an on-chain Merkle Tree, and later prove knowledge of the committed data using a Groth16 zero-knowledge proof. The commit and reveal operations are cryptographically unlinkable. The GHOST token is one use case; the protocol supports arbitrary data types.

Ghostmint​

A custom precompile in Specter's EVM that bridges between the Cosmos SDK bank module and EVM-side operations. It enables Vanish operations to burn native GHOST tokens and Summon operations to mint them, without requiring a token pool or custodial contract.

Groth16​

The zero-knowledge proof system used in Specter. Produces constant-size proofs (3 group elements, ~128 bytes) with fast verification (a single pairing check). Requires a circuit-specific Trusted Setup. Security relies on the Knowledge of Exponent assumption and the hardness of the discrete log problem on BN254.

Merkle Tree​

A binary hash tree where each leaf is a Commitment and each internal node is the Poseidon hash of its two children. The tree provides efficient membership proofs — proving a commitment exists in the tree requires only a logarithmic-length path (20 hashes for a tree of depth 20, supporting ~1M leaves). The root of the tree is published on-chain by the Root Updater.

Nullifier​

A value derived from the NullifierSecret that is recorded on-chain when a Commitment is revealed (summoned). The NullifierRegistry enforces that each nullifier can only be used once, preventing double-spending. The nullifier is computed so that it cannot be linked to the commitment it consumes — an observer sees the nullifier but cannot determine which commitment was revealed.

NullifierSecret​

A BN254 field element that is part of every Commitment preimage. It is used to derive both the Nullifier (for one-time reveals) and the Access Tag (for persistent access). Derived deterministically from the user's seed via HKDF-SHA256.

Open Ghost​

A mode of the Ghost Protocol where a third party can commit data on behalf of another user. The committer does not need to know the Secret or NullifierSecret — they submit a pre-computed Commitment hash. This enables use cases like bulk credential issuance, gift cards, and airdrops where the issuer vanishes data that recipients later summon.

Phantom Identity​

A persistent, reusable anonymous identity encoded as a PNG bearer object. Contains a split-encrypted secp256k1 keypair, commitment secrets, and a quantum secret. Unlike a Phantom Key (which is consumed on first use), a Phantom Identity survives indefinitely. Each authentication session uses an Access Proof to recover the private key without consuming the commitment.

Phantom Key​

A Bearer Instrument for data. A set of secret numbers encoded as groups of four digits (e.g., 9473 0018 7376 9372 0484 1273) that represent the preimage of a Commitment in the Merkle Tree. Whoever knows the numbers can generate a zero-knowledge proof and reveal the committed data. Phantom Keys are consumed on use — the Nullifier is spent, preventing reuse.

Policy​

A programmable constraint enforced during Vanish or Summon operations. Policies are implemented as Solidity contracts that the CommitRevealVault calls during commit/reveal processing. Examples include time locks (minimum delay between commit and reveal), amount limits (maximum value per operation), and compliance hooks (external verification requirements).

Poseidon​

An algebraic hash function designed for efficient computation inside zero-knowledge circuits. Operates natively on finite field elements using field multiplications and additions (S-box: x^5), requiring approximately 8x fewer R1CS constraints than SHA-256. All Commitments, Nullifiers, Access Tags, Merkle Tree nodes, and token identifiers in Specter are computed using Poseidon.

PersistentKeyVault​

An on-chain contract that stores the encrypted second half of a Phantom Identity's split private key. When a user authenticates with an Access Proof, the vault releases the encrypted key share, which is combined with the local share (stored in the PNG) to reconstruct the full secp256k1 private key. The vault enforces that only valid access proofs can retrieve the key share.

Reveal​

See Summon.

Secret​

A BN254 field element that is part of every Commitment preimage. Together with the NullifierSecret, Data Hash, and Blinding Factor, it forms the private input to the commitment hash. Derived deterministically from the user's seed via HKDF-SHA256. Knowledge of the secret is required to generate a valid ZK proof for the commitment.

Session Nonce​

A unique value used in Access Proof generation to derive a fresh Access Tag for each authentication session. The session nonce ensures that repeated authentications with the same Phantom Identity produce different access tags, preventing session linkability.

Split-Key Encryption​

The encryption scheme used by Phantom Identity to protect the secp256k1 private key. The private key is XOR-split into two shares: one stored locally in the PNG file (encrypted with AES-256-GCM under the user's passphrase) and one stored on-chain in the PersistentKeyVault (encrypted with AES-256-GCM under a key derived from the commitment secrets). Both shares are needed to reconstruct the private key.

Trusted Setup​

A multi-party computation ceremony that generates the proving key and verification key for a Groth16 circuit. The ceremony produces "toxic waste" (secret randomness) that must be destroyed. If any single participant honestly destroys their contribution, the toxic waste is unrecoverable and the parameters are safe. Specter requires a production trusted setup ceremony before mainnet launch.

Vanish​

The commit phase of the Ghost Protocol. Data or tokens "vanish" from public view by being hashed into a Poseidon Commitment and inserted into the Merkle Tree. For tokens, the vanished amount is burned (destroyed, not deposited). The original data is never stored on-chain — only the commitment hash.

Zero-Knowledge Proof​

A cryptographic proof that demonstrates knowledge of information without revealing that information. In Specter, ZK proofs demonstrate: (1) the prover knows the preimage of a Commitment, (2) that commitment exists in the Merkle Tree, and (3) the Nullifier is correctly derived. The verifier learns only that these statements are true — nothing about the committed data, the prover's identity, or which specific commitment was proven.