Open Ghost Protocol

The Open Ghost Protocol is Specter's system for sealed data sharing — committing arbitrary data to the Merkle tree and enabling one-time retrieval by a Phantom Key holder. While Standard Phantom Keys were originally designed for the GHOST token use case, Open Ghost extends the same commit/reveal paradigm to any data: credentials, images, API keys, encryption keys, documents, or anything else that can be hashed.

Open Ghost uses a dedicated set of contracts (OpenGhostVault, OpenGhostKeyVault, OpenGhostReveal) with a separate Merkle tree and separate nullifier registry from the token system. This separation ensures that data operations cannot interfere with token operations and vice versa.

Architecture

Commitment Structure

Open Ghost uses a 4-input Poseidon commitment, distinct from the 7-input commitment used by the token system:

$$\text{commitment} = \text{Poseidon}_4(\text{secret},\; \text{nullifierSecret},\; \text{dataHash},\; \text{blinding})$$

Field	Description
secret	User's secret (derived from seed via HKDF)
nullifierSecret	Nullifier derivation secret (derived from seed via HKDF)
dataHash	Hash of the sealed data (credential, image, API key, etc.)
blinding	Random blinding factor (derived from seed via HKDF)

The dataHash is generic — it is simply the hash of whatever data the user wants to seal. The protocol does not interpret or constrain the data type. This is what makes Open Ghost a general-purpose data protocol:

Data Type	dataHash Computation
Credentials	Hash of credential JSON/payload
Images	Hash of image bytes
API keys	Hash of API key string
Encryption keys	Hash of key material
Documents	Hash of document content
Arbitrary bytes	Hash of raw byte array

Fee-Based Commits

Unlike the token system (where the user deposits tokens that are burned into the commitment), Open Ghost uses a fee-based model:

• The user pays a commitment fee (in native GHOST) to insert their commitment into the tree.
• No tokens are locked or burned — the commitment represents data, not value.
• The minimum fee is configurable by the vault owner and serves as spam prevention.
• Collected fees are withdrawable by the designated fee recipient.

function commit(bytes32 commitment)
    external payable returns (uint256 leafIndex)

The commit function validates the commitment (non-zero, valid field element), checks the fee, inserts the commitment into the OpenCommitmentTree, and returns the leaf index.

Separate Infrastructure

Open Ghost maintains its own Merkle tree and nullifier registry, independent from the token system:

Component	Token System	Open Ghost
Vault	CommitRevealVault	OpenGhostVault
Merkle tree	CommitmentTree	OpenCommitmentTree
Nullifier registry	NullifierRegistry	OpenNullifierRegistry
Proof verifier	RedemptionVerifier	OpenGhostRevealVerifier
Key storage	N/A	OpenGhostKeyVault

This separation provides several guarantees:

• No cross-contamination: a data nullifier cannot interfere with a token nullifier.
• Independent scaling: the data tree can grow independently of the token tree.
• Different security properties: token commits require deposit verification; data commits require only fee payment.
• Upgradability: each system can be upgraded independently.

One-Time Key Retrieval: OpenGhostKeyVault

The OpenGhostKeyVault is the on-chain component that enables sealed data sharing with one-time retrieval semantics. It stores encrypted key material during the seal phase and returns it exactly once during the reveal phase, then permanently deletes it.

Key Lifecycle

Storage Structure

Each key entry in the vault contains:

Field	Type	Description
commitment	bytes32	The associated commitment hash
encKeyPartB	bytes	The encrypted key part B
exists	bool	Whether the entry has been retrieved yet

Security Properties

• Nullifier-gated retrieval: the retrieveAndDeleteKeyPartB function checks that the provided nullifier has been spent in the OpenNullifierRegistry. This means the ZK proof must be verified and the reveal transaction must be confirmed before the key part can be retrieved.
• Atomic deletion: the key entry is deleted in the same transaction that returns it. There is no window where the key exists after retrieval.
• No second retrieval: once exists is set to false (via delete), subsequent calls revert with KeyNotFound. The data is gone permanently.
• Split-key security: neither keyPartA (in the Phantom Key) nor keyPartB (on-chain) is sufficient alone to decrypt the data. An attacker who compromises only the vault or only the Phantom Key learns nothing.

Use Cases

Encrypted Message Delivery

Alice wants to send Bob a private message. She seals the message into an Open Ghost commitment, shares the Phantom Key with Bob (via any channel), and Bob reveals it to retrieve the message. The message content never appears on-chain — only its hash is committed. After retrieval, the decryption key is deleted and the message cannot be accessed again through the protocol.

Sealed Document Sharing

A company issues a legal document to a counterparty. The document is sealed into Open Ghost, and the Phantom Key is delivered via certified mail or secure courier. The counterparty reveals the document exactly once. The one-time retrieval ensures the document was accessed by the intended recipient and cannot be re-accessed by a compromised system.

One-Time Secret Sharing

A DevOps engineer needs to share an API key with a colleague. Instead of sending it over Slack (where it persists in logs), they seal it into Open Ghost and share the Phantom Key. The colleague reveals it, the key material is decrypted, and the on-chain key part is permanently deleted. No persistent record of the secret exists on any server.

Credential Issuance

An identity provider issues a credential (e.g., KYC attestation, diploma, certification) as a sealed Open Ghost commitment. The credential holder receives a Phantom Key and can reveal the credential to any verifier. The one-time retrieval model works for credentials that should be claimed once and then held locally by the recipient.

Privacy-Preserving Data Drops

A whistleblower seals documents into Open Ghost and distributes Phantom Keys to journalists. Each key reveals a different set of documents. The whistleblower's identity is never linked to the commitments (the commit transaction can be submitted via a relayer). The documents can only be retrieved once per key, limiting uncontrolled distribution.

Comparison with Standard Phantom Keys

Property	Standard Phantom Key (Token)	Open Ghost Key (Data)
Commitment inputs	7 (includes tokenId, amount, policy)	4 (includes dataHash)
Deposit	Token burn	Fee payment
Reveal output	Token mint to recipient	Decryption key retrieval
On-chain key storage	None	OpenGhostKeyVault (one-time)
Partial withdrawal	Yes (change commitment)	No (data is atomic)
Merkle tree	Shared with token system	Separate (OpenCommitmentTree)
Nullifier registry	Shared with token system	Separate (OpenNullifierRegistry)
Primary use	Private value transfer	Sealed data sharing