Contract Architecture

The Specter protocol is composed of interconnected smart contracts deployed on the Specter chain (Chain ID 5446). The architecture follows a modular design: a central vault manages commit-reveal flows, while peripheral contracts handle Merkle state, nullifier tracking, token management, policy enforcement, and native asset bridging.

Architecture Diagram

Contract Relationships

Contract	Role	Depends On
CommitRevealVault	Central privacy vault; accepts deposits (commits) and processes withdrawals (reveals) via ZK proofs	CommitmentTree, NullifierRegistry, GhostRedemptionVerifier, NativeAssetHandler, AssetGuard, Policy contracts
GhostRedemptionVerifier	Verifies Groth16 ZK-SNARK proofs on-chain (BN254 curve)	None (pure verifier)
CommitmentTree	Maintains an incremental Merkle tree of deposit commitments with a root history ring buffer	PoseidonT3
NullifierRegistry	Tracks spent nullifiers to prevent double-withdrawals	None
NativeAssetHandler	Bridges native GHOST token between EVM and Cosmos layers via burn/mint mechanics	0x0808 ghostmint precompile
AssetGuard	Token whitelist; validates which ERC-20 tokens can enter the vault	None
GhostERC20Factory	Deterministic CREATE2 deployment of GhostERC20 tokens	AssetGuard
GhostERC20	Privacy-compatible ERC-20 with Poseidon-based token ID hashing	PoseidonT3, AssetGuard
PolicyRegistry	Informational registry of available reveal policies	None
TimelockExpiry	Policy: enforces time-window constraints on reveals	None
DestinationRestriction	Policy: restricts reveal recipient to a single address or Merkle allowlist	None
ThresholdWitness	Policy: requires M-of-N witness signatures to authorize a reveal	None
DMSRegistry	Dead Man's Switch registry for key recovery and inheritance	GhostRedemptionVerifier, CommitmentTree
PoseidonT3	Poseidon hash function (t=3, 2 inputs) used for commitment and token ID computation	None

Deployed Addresses (v4.5)

Deployed on March 4, 2026 to the Specter chain (Chain ID 5446).

Contract	Address
CommitRevealVault	0x908aA11Dc9F2e2C3F69892acaDE112e831c0a14a
GhostRedemptionVerifier	0xc0A9BcF60A6E4Aabf5Dd3e195b99DE2b9fac3Dee
CommitmentTree	0xE29DD14998f6FE8e7862571c883090d14FE29475
NullifierRegistry	0xaadb9c3394835B450023daA91Ad5a46beA6e43a1
NativeAssetHandler	0xA0bA5389b07BAdDAaE89B8560849774Bf015acc3
AssetGuard	0x12d5a4d9Db0607312Fc8F8eE51FDf18D40794aD1
GhostERC20Factory	0xE842ffe639a770a162e0b7EB9f274E49aCA8Fb95
PoseidonT3	0xacaef99b13d5846e3309017586de9f777da41548
PolicyRegistry	0x2DC1641d5A32D6788264690D42710edC843Cb1db
TimelockExpiry	0xd84D534E94f1eacE9BC5e9Bd90338d574d02B95c
DestinationRestriction	0x584F2c7F6da6f25a7bF6A1F3D7F422683Ac52Ef1
ThresholdWitness	0x5814e4755C0D98218ddb752D26dD03feba428c80
DMSRegistry	0x14d5629136edAc7ef2b2E5956838b9Bb0211eB9d

Commit-Reveal Flow

1. Commit phase -- A depositor calls commit() or commitNative() on the CommitRevealVault, providing a Pedersen commitment (and quantum-safe commitment). The vault checks token authorization via AssetGuard, transfers tokens, and calls CommitmentTree.recordCommitment() to insert the commitment leaf.
2. Merkle root update -- An off-chain operator computes the new Merkle root from the updated tree and calls CommitmentTree.updateRoot().
3. Reveal phase -- A withdrawer generates a ZK-SNARK proof demonstrating knowledge of a valid commitment in the tree without revealing which one. The vault verifies the proof via GhostRedemptionVerifier, checks the nullifier via NullifierRegistry, enforces any attached policies, and releases funds.

Policy Enforcement

Policies are optional constraints attached at commit time. During reveal, the vault calls the policy contract via staticcall with a 100,000 gas cap. The policy must implement the IRevealPolicy interface and return true for the reveal to succeed. See the Policy Overview for details.