Phantom Identity vs. Phantom Keys
Phantom Keys and Phantom Identity share the same cryptographic foundation — Poseidon commitments, Merkle tree membership proofs, and Groth16 on BN254 — but they serve fundamentally different purposes. Phantom Keys are one-time bearer instruments designed for send-and-forget data operations. Phantom Identity is a persistent pseudonymous identity designed for long-term, repeated data access.
This page provides a detailed side-by-side comparison to help determine which mechanism is appropriate for a given use case.
Feature Comparison
| Property | Phantom Key | Phantom Identity |
|---|---|---|
| On-chain storage | Commitment deleted on reveal (nullifier spent) | Commitment persists indefinitely (never consumed) |
| Access model | One-time: reveal consumes the key | Unlimited: each connect is independent |
| Nullifier behavior | Spent on access (commitment consumed) | Spent only on revocation (optional, irreversible) |
| Primary use case | Send-and-forget: transfers, one-time sharing, gift cards | Long-term identity: accounts, recurring access, workflows |
| ZK circuit | Redemption Circuit (8 public inputs) | Access Proof Circuit (4 public inputs) |
| Bearer format | Numeric key (24-30 digits) or NFC tag | PNG with embedded keypair + secrets |
| Transaction signing | N/A (key is redeemed, not used for signing) | Direct secp256k1 signing from recovered private key |
| Quantum protection | Optional (quantumSecret in V4+ keys, not enforced) | Built-in rotation (quantum commitment rotated on every access) |
| Anti-replay mechanism | Nullifier (permanent, one-time) | accessTag (session-scoped, per-access) |
| Key recovery | Decode numeric key, derive secrets from seed | Upload PNG, generate Access Proof, recombine split key |
| Passphrase protection | Not supported (key is a number) | Optional AES-256-GCM encryption of PNG metadata |
| On-chain key material | None (Standard) or one-time retrieval (Open Ghost) | Persistent split key in PersistentKeyVault |
| Revocation | Automatic on reveal (nullifier spent) | Explicit revocation required (separate transaction) |
| Anonymity set | All commitments in the Merkle tree | All commitments in the Merkle tree |
Circuit Comparison
The two systems use different ZK circuits optimized for their respective access patterns.
Redemption Circuit (Phantom Keys)
8 public inputs. Designed for one-time reveal with front-running protection and value accounting.
| # | Public Input | Purpose |
|---|---|---|
| 0 | root | Merkle tree root |
| 1 | nullifierHash | Deterministic nullifier (spent on-chain, prevents double-reveal) |
| 2 | recipient | Binds proof to recipient address (prevents front-running) |
| 3 | withdrawAmount | Amount being withdrawn |
| 4 | changeCommitment | Commitment for remaining balance (partial withdrawals) |
| 5 | tokenId | Identifies the token type |
| 6 | policyId | Policy binding (compliance, time-locks, etc.) |
| 7 | policyParamsHash | Hash of policy parameters |
Access Proof Circuit (Phantom Identity)
4 public inputs. Designed for repeatable authentication with no value fields and no nullifier.
| # | Public Input | Purpose |
|---|---|---|
| 0 | root | Merkle tree root |
| 1 | dataHash | Generic data identifier (credential, key, image, etc.) |
| 2 | sessionNonce | Fresh random value per session (prevents proof reuse) |
| 3 | accessTag | Anti-replay binding: |
Vault Comparison
| Property | CommitRevealVault / OpenGhostKeyVault | PersistentKeyVault |
|---|---|---|
| Key storage | One-time (deleted after retrieval) | Persistent (returned without deletion) |
| Access authorization | Nullifier spent in registry | Access Proof verified + accessTag recorded |
| Quantum commitment | Not stored | Stored and rotated on every access |
| Revocation | Automatic (nullifier spent = key gone) | Explicit (revokeKey deletes entry) |
| Anti-replay | Nullifier registry (permanent) | accessTag registry (per-session) |
When to Use Phantom Keys
Phantom Keys are the right choice when:
- The operation is inherently one-time. Sending tokens to someone. Sharing a secret once. Delivering a sealed document. Gift cards, one-time access passes, whistleblower drops.
- Simplicity matters. A numeric key is easy to dictate over the phone, write on paper, or encode in a QR code. No file management, no passphrase to remember.
- No ongoing identity is needed. The sender and recipient do not need a persistent relationship. The key is the entire interaction — share it, reveal it, done.
- Value transfer is involved. The Redemption Circuit supports token amounts, partial withdrawals, and change commitments. Phantom Identity does not handle value directly.
Example: Private Token Transfer
Alice wants to send 100 GHOST to Bob without linking their addresses on-chain:
- Alice vanishes 100 GHOST into a commitment.
- Alice encodes the commitment secrets as a Phantom Key:
9473 0018 7376 9372 0484 1273. - Alice hands Bob the number on a slip of paper.
- Bob reveals the commitment. 100 GHOST is minted to his address.
- The key is consumed. No ongoing relationship.
When to Use Phantom Identity
Phantom Identity is the right choice when:
- The interaction is ongoing. A user needs to authenticate repeatedly. A credential needs to be verified over time. A subscription needs to be checked on every access.
- Signing authority is needed. The user needs to sign transactions from a persistent pseudonymous address. Phantom Identity provides a full secp256k1 keypair; Phantom Keys do not.
- Multi-step workflows span multiple sessions. Commit data in one session, verify it in another, update it in a third — all from the same identity, all unlinkable to the real user.
- Stronger security is required. Split-key storage, optional passphrase protection, and quantum-resistant commitment rotation provide defense-in-depth that a simple numeric key cannot offer.
Example: Persistent Anonymous Account
A user wants to participate in an on-chain governance system without revealing their real identity:
- The user generates a Phantom Identity (downloads a PNG).
- The user seals the identity on-chain (commitment + split key stored).
- Before each governance vote, the user connects: uploads the PNG, enters the passphrase, generates an Access Proof, recovers the signing key.
- The user signs and submits a vote from the pseudonymous address.
- The user disconnects. The signing key is zeroed from memory.
- Over months, the pseudonymous address builds a voting history — but it is never linked to the user's real identity.
Decision Matrix
| Scenario | Phantom Keys | Phantom Identity |
|---|---|---|
| Send tokens privately | Best fit | Overkill |
| One-time secret sharing | Best fit | Overkill |
| Gift card / event ticket | Best fit | Overkill |
| Credential issued once, verified once | Best fit | Overkill |
| Credential verified repeatedly | Not possible (consumed on first use) | Best fit |
| Persistent pseudonymous account | Not possible (no signing key) | Best fit |
| Recurring API authentication | Not possible (consumed on first use) | Best fit |
| Long-term encrypted data access | Not possible (key deleted on retrieval) | Best fit |
| Multi-step privacy workflow | Not possible (identity doesn't persist) | Best fit |
| Subscription/membership key | Not possible (consumed on first use) | Best fit |
| Physical bearer instrument (NFC card) | Best fit | Not ideal (PNG format) |
| Offline, air-gapped sharing | Best fit (numeric format) | Possible (file transfer) |
Using Both Together
Phantom Keys and Phantom Identity are complementary. A common pattern is to use a Phantom Identity as the persistent account and Phantom Keys for individual transactions within that account:
The identity persists. The keys are ephemeral. The identity issues keys; the keys are consumed by recipients. This separation keeps the persistent pseudonym clean while enabling one-time sharing operations.