GHOST Token

GHOST is one application of the Specter protocol -- the native token of the Specter blockchain. While the Specter protocol is a general-purpose data privacy system that handles credentials, images, API keys, and any other data type, GHOST demonstrates how private value transfer works as a specific use case built on the same cryptographic primitives.

Role in the Network

GHOST serves four functions within the Specter ecosystem:

Function	Description
Gas fees	Every transaction on the Specter chain requires GHOST for gas, following the EIP-1559 dynamic fee market model
Validator staking	Validators stake GHOST through the Cosmos SDK x/staking module to participate in CometBFT consensus
On-chain governance	GHOST holders participate in governance proposals via the x/gov module
Private value transfer	GHOST can be committed and revealed through the privacy protocol (vanish/summon)

Denomination

GHOST follows the standard 18-decimal EVM convention:

1 GHOST = 10^18 aghost

The base unit aghost (atto-ghost) is the smallest indivisible unit. All on-chain accounting, Merkle tree commitments, and ZK circuit arithmetic use aghost values. The GHOST denomination is a display-layer convenience.

Unit	Value in aghost
1 aghost	1
1 GHOST	1,000,000,000,000,000,000

Dual Representation

GHOST exists simultaneously as a Cosmos SDK native token and as an EVM-accessible asset. This dual representation is managed by the NativeAssetHandler contract and the x/ghostmint precompile.

On the Cosmos side, GHOST is a standard x/bank denomination (aghost). It can be sent between accounts, staked, used for governance, and transferred via IBC. On the EVM side, GHOST is the native gas token (equivalent to ETH on Ethereum). The NativeAssetHandler bridges these two representations through the ghostmint precompile at address 0x0808.

Token Privacy as a Special Case

Private GHOST transfers use the 7-input commitment variant and the 8-input redemption circuit, which are specialized versions of the general-purpose data protocol:

Protocol Variant	Commitment	Circuit	Used For
Generic data	Poseidon4(secret, nullifierSecret, dataHash, blinding)	4-input access proof	Credentials, images, API keys, any data
Token (GHOST)	Poseidon7(secret, nullifierSecret, tokenId, amount, blinding, policyId, policyParamsHash)	8-input redemption proof	Private token transfers

The token variant extends the generic data commitment with three additional fields:

• tokenId -- identifies which token (native GHOST or a GhostERC20)
• amount -- the quantity of tokens being committed
• policyId / policyParamsHash -- optional programmable constraints on the reveal

The redemption circuit adds two additional public inputs beyond the generic circuit's outputs:

• policyId -- the policy contract address embedded in the proof
• policyParamsHash -- the hash of policy parameters embedded in the proof

These additional fields enable the burn/mint model that makes private token transfers possible: the protocol needs to know the token type and amount to destroy the correct tokens on commit and create the correct tokens on reveal.

Commit/Reveal for GHOST

The private transfer flow for GHOST follows the same commit/reveal pattern as all data in the Specter protocol:

1. Vanish (Commit): User sends GHOST to the CommitRevealVault. The vault calls NativeAssetHandler.burnNativeFrom(), which calls the ghostmint precompile, which calls x/bank.BurnCoins(). The GHOST tokens are destroyed. A Poseidon commitment hash is recorded in the Merkle tree.

2. Summon (Reveal): User generates a Groth16 ZK proof demonstrating knowledge of the commitment preimage and Merkle tree membership. The vault verifies the proof, records the nullifier, then calls NativeAssetHandler.mintNativeTo(), which calls the ghostmint precompile, which calls x/bank.MintCoins(). Fresh GHOST tokens are created and sent to the specified recipient.

The commit and reveal transactions are cryptographically unlinkable. The ZK proof demonstrates that a valid commitment exists in the tree without identifying which one. The anonymity set is the entire set of commitments in the tree.

Not a Wrapper, Not a Pool

GHOST's privacy model is fundamentally different from pool-based approaches:

• No custodial pool. Tokens are destroyed on commit and created on reveal. There is no contract holding a balance of tokens that could be frozen, sanctioned, or drained.
• No wrapper token. GHOST does not have a "private" and "public" version. The same token moves between public state and private commitments via burn and mint.
• No frozen funds risk. Because tokens in the commitment tree are "virtual" (they exist only as Poseidon hashes, not as token balances), there is no contract balance that constitutes "frozen" or "locked" funds.

The Mint & Burn Flow page details the complete lifecycle, and Supply Mechanics explains how the protocol guarantees supply conservation.