# Specter Protocol Whitepaper # Privacy-Native Layer 1 Blockchain with Ghost Protocol # Version 1.0 | March 2026 # https://whitepaper.specterchain.com --- ## Cover # Specter Protocol ## Privacy-Native Layer 1 Blockchain with Ghost Protocol **Whitepaper v1.0** | March 2026 --- Specter is the first Layer 1 blockchain designed from the ground up for privacy. At its core is **Ghost Protocol** — a general-purpose commit/reveal primitive that makes any on-chain data private by default. Not just tokens. Not just transactions. *Any data.* Built on Cosmos SDK with full EVM compatibility, Specter gives developers the tools they already know (Solidity, MetaMask, Hardhat) while adding something no other chain offers: privacy as a native building block. **[Download full whitepaper as plaintext (.txt)](/llms-full.txt)** — single file, optimized for AI and LLMs. --- ### Resources | | | |---|---| | **Website** | [specter.foundation](https://specter.foundation) | | **Documentation** | [docs.specter.foundation](https://docs.specter.foundation) | | **Block Explorer** | [specterscan.io](https://specterscan.io) | | **Twitter** | [@ghostcoinhq](https://twitter.com/ghostcoinhq) | | **Telegram** | [@ghostcoinhq](https://t.me/ghostcoinhq) | | **GitHub** | [specter-foundation](https://github.com/specter-foundation) | --- ### Legal Disclaimer This whitepaper is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation for any security, token, or other financial instrument. Nothing in this document should be treated as legal, financial, investment, or tax advice. **Forward-Looking Statements.** This whitepaper contains forward-looking statements regarding the Specter Protocol, Ghost Protocol, the GHOST token, and related technology. These statements involve known and unknown risks, uncertainties, and other factors that may cause actual results, performance, or achievements to differ materially from any future results expressed or implied by the forward-looking statements. Such factors include, but are not limited to: changes in technology, regulatory environments, market conditions, the competitive landscape, and the ability of the Specter team to execute on its development roadmap. **No Guarantees.** The information presented here is believed to be accurate as of the date of publication, but no representation or warranty — express or implied — is made regarding its accuracy, completeness, or suitability for any purpose. The Specter Foundation reserves the right to update, amend, or revise this whitepaper at any time without notice. **Not Financial Advice.** GHOST tokens are not securities. Participation in the Specter network involves significant risk. You should consult your own legal, financial, and tax advisors before making any decisions related to the Specter Protocol or GHOST token. Past performance of any technology, protocol, or token is not indicative of future results. **Regulatory Uncertainty.** Blockchain technology and digital assets are subject to evolving regulatory requirements across jurisdictions. It is your responsibility to ensure compliance with applicable laws in your jurisdiction. **Subject to Change.** The technical specifications, token economics, and other details described in this whitepaper represent current plans and intentions. They are subject to change based on ongoing research, development, audits, community feedback, and regulatory considerations. ## Abstract # Abstract Privacy is not a luxury — it is a basic expectation of how people interact with the world. When you pay for coffee, no one sees your bank balance. When you sign a contract, the rest of the world does not get a copy. Yet on today's blockchains, every transaction, every balance, and every interaction is permanently visible to anyone with an internet connection. Specter is a privacy-native Layer 1 blockchain built to fix this. At its heart is **Ghost Protocol**, a general-purpose commit/reveal primitive that brings real privacy to *any* on-chain data — not just tokens, but secrets, credentials, documents, votes, sealed bids, and anything else a developer can imagine. Here is how it works: when you commit data through Ghost Protocol, you seal it into a cryptographic envelope. The chain stores only the commitment hash — a fixed-size fingerprint that reveals nothing about what is inside. When you later need to prove something about that data, you generate a zero-knowledge proof that demonstrates you know the contents without ever exposing them. A **Phantom Key** — a bearer credential generated at commit time — is the only thing you need to access your private data later. The cryptography behind this is battle-tested and efficient. Ghost Protocol uses **Poseidon hashing** (a ZK-friendly hash function with 7 inputs, including policy binding) to create commitments, and **Groth16 zero-knowledge proofs** to verify them. Every proof is a constant 256 bytes with 8 public inputs — compact enough to verify on-chain at roughly 220,000 gas. **Nullifiers** ensure each commitment can only be revealed once, preventing double-spending without sacrificing privacy. A quantum-safe keccak256 layer provides an additional defense against future cryptographic threats. Specter is built on the **Cosmos SDK** with **full EVM compatibility**, so developers can write privacy-aware smart contracts in Solidity and users can connect with MetaMask — no new tools required. The chain uses **CometBFT** consensus for approximately 5-second finality, giving transactions the speed users expect. Ghost Protocol has evolved through three generations of innovation: basic commit/reveal laid the foundation, **programmable policies** (v4.4) added rules that execute automatically at reveal time, and **persistent reusable Phantom Keys** (v4.5) let users maintain a single privacy identity across multiple interactions. Together, these make Ghost Protocol not just a privacy tool, but programmable privacy *infrastructure*. The native token, **GHOST**, has a fixed supply of **1 billion tokens** and powers everything on the network — gas fees, staking, governance, and Ghost Protocol operations. Cross-chain bridges via **Hyperlane** connect Specter to Ethereum, Base, and Arbitrum, so privacy does not mean isolation. Specter is not another privacy coin. It is a complete execution environment where privacy is the default, composability is the design, and the entire Ethereum developer ecosystem works out of the box. ## Introduction # The Case for Privacy-Native L1 ## The Transparency Paradox Imagine sending a friend $50 for dinner. The moment you do, they can see your entire wallet balance, every transaction you have ever made, and every protocol you have ever interacted with. Now imagine that same visibility applied to every vendor you pay, every employer who sends your salary, and every stranger who happens to notice your address on a block explorer. This is the reality of transparent blockchains today. What was designed as a feature for trustless verification has become a liability for real-world use. Every payment is a public record. Every DeFi position is visible. Every NFT purchase, every DAO vote, every on-chain interaction — all of it is permanently, irrevocably public. And it is not just financial data. On a transparent chain, *everything* is exposed: your voting patterns, your credential history, your business relationships, and your participation in communities. The blockchain remembers all of it, forever, for anyone to see. For individuals, this means a stranger can reconstruct your financial life from a single address. For businesses, it means competitors can monitor your treasury, your vendor payments, and your strategic moves in real time. For organizations, it means sensitive membership lists, voting records, and internal processes are public by default. This is not a privacy problem that can be solved at the application layer. It is a fundamental design flaw in how transparent blockchains work. ## Why Bolt-On Privacy Fails The blockchain industry has tried to solve this problem in several ways. Each approach made meaningful progress, but each falls short of what real privacy requires. ### Privacy Coins: Zcash, Monero Privacy coins pioneered on-chain confidentiality, and they deserve credit for proving it was possible. But their privacy is **single-purpose** — it only covers token transfers. You cannot build a private voting system on Monero. You cannot create a sealed-bid auction on Zcash. The privacy does not extend to arbitrary data, smart contracts, or programmable logic. They solved privacy for *money*, not for *everything else*. ### ZK Layer 2s: Aztec ZK rollups like Aztec bring zero-knowledge proofs to smart contracts, which is a genuine step forward. But they inherit a fundamental constraint: they are **anchored to a transparent Layer 1**. Settlement, data availability, and bridging all happen on Ethereum — where everything is visible. Composability is also limited; private state on an L2 cannot easily interact with other protocols or chains. The privacy boundary ends at the rollup. ### Mixers: Tornado Cash Mixers demonstrated that commit/reveal cryptography works beautifully for breaking transaction links. Tornado Cash proved that Groth16 proofs and Merkle trees could provide real anonymity on Ethereum. But mixers are **single-purpose tools** — they shuffle tokens, nothing more. There is no extensibility, no programmable logic, no way to build new private applications on top of them. They are a privacy appliance, not privacy infrastructure. ## Why Layer 1, Not Layer 2 If zero-knowledge proofs work on Ethereum (as Tornado Cash proved), why build a whole new chain? Because Ghost Protocol requires something that no existing Layer 1 can provide: **native token burn and mint at the protocol level**. When you commit tokens through Ghost Protocol, those tokens are *burned* — removed from circulation entirely. When you reveal, new tokens are *minted*. This is not a transfer. It is not a wrapper. It is actual destruction and creation of native tokens, and it requires a protocol-level precompile (`ghostmint`) that only a purpose-built chain can offer. On Ethereum, you cannot burn ETH and mint new ETH from a smart contract. You can lock tokens in a contract (as Tornado Cash does), but that leaves a visible pool that can be analyzed, sanctioned, or drained. True burn/mint breaks the link completely — there is no pool, no contract balance, no on-chain trace connecting the committed tokens to the revealed ones. Beyond `ghostmint`, a dedicated Layer 1 gives Specter something equally important: **sovereignty**. Specter runs its own validators, its own consensus, and its own governance. No external Layer 1 can censor Specter transactions, freeze Specter contracts, or change Specter's rules. Privacy requires sovereignty, because privacy that depends on someone else's permission is not privacy at all. This is why Specter exists: not because the world needs another blockchain, but because privacy needs to live at the foundation — in the consensus layer, in the execution engine, in the token model itself. Everything above that foundation benefits automatically. ## Design Philosophy # Design Philosophy Every technical decision in Specter traces back to five core principles. These are not marketing slogans — they are the actual constraints we use when evaluating tradeoffs, choosing cryptographic schemes, and designing protocol upgrades. ## 1. Privacy as Primitive Privacy in Specter is not a feature you enable. It is the foundation everything else is built on. Most blockchains start with a transparent execution model and then try to add privacy on top — through mixers, encrypted mempools, or optional shielded transactions. This approach always leaks. The transparent base layer creates metadata, the privacy tools become identifiable patterns, and users who opt in to privacy stand out from those who do not. Specter inverts this. **Ghost Protocol's commit/reveal pattern is the base layer.** It is the primitive that other features compose on, the way ERC-20 is the primitive that DeFi composes on in Ethereum. When privacy is the starting point rather than an afterthought, every application built on top inherits it by default. Developers do not need to think about privacy engineering — they get it from the infrastructure. ## 2. Composable Privacy A privacy primitive is only useful if developers can build with it. Ghost Protocol is designed to be **composed, extended, and combined** — not used as a standalone black box. This means commit/reveal is not locked into a single use case. A developer can use it to build private token transfers *and* sealed-bid auctions *and* anonymous credentials *and* private voting — all using the same underlying primitive, the same proof system, and the same Phantom Key abstraction. Programmable policies (introduced in v4.4) take this further. A commitment can carry rules — time locks, recipient restrictions, minimum amounts, compliance hooks — that execute automatically at reveal time. Privacy and programmability are not in tension. They reinforce each other. The goal is an ecosystem where privacy-aware applications compose as naturally as DeFi protocols compose on Ethereum today. ## 3. Sovereign Execution Specter runs on its own chain, with its own validators, its own consensus, and its own governance. This is a deliberate choice, not a limitation. Sovereignty means no external authority can censor Specter transactions. No Layer 1 governance vote can freeze Specter contracts. No rollup sequencer can reorder or exclude private operations. The chain's rules are determined by GHOST token holders and the validator set — no one else. This matters more for a privacy chain than for any other type of blockchain. Privacy that depends on another chain's good behavior is fragile. If your privacy Layer 2 settles on a chain that decides to blacklist your contract, your privacy disappears. Specter's sovereignty ensures that cannot happen. Sovereignty also enables protocol-level features that no L2 can offer, like the `ghostmint` precompile that burns and mints native tokens — the cryptographic foundation of Ghost Protocol's unlinkability. ## 4. EVM Compatibility Specter supports the full Ethereum Virtual Machine. If you can write it in Solidity, you can deploy it on Specter. If your users have MetaMask, they can use Specter. If your toolchain includes Hardhat, Foundry, or Remix, it works on Specter. This is not a philosophical compromise — it is a practical one. The Ethereum ecosystem has millions of developers, battle-tested tooling, and years of smart contract patterns. Rebuilding all of that for a custom VM would delay privacy adoption by years and fragment the developer community. Instead, Specter meets developers where they are. Write your contracts in Solidity. Test them with the tools you know. Deploy them to a chain where privacy is native. The learning curve is not "how do I use this new VM?" — it is "how do I use Ghost Protocol in my existing contracts?" EVM compatibility also means Specter can support existing standards (ERC-20, ERC-721, ERC-1155) alongside new privacy-native patterns. DeFi protocols, NFT marketplaces, and DAO frameworks can be ported to Specter with minimal changes and immediately benefit from the privacy infrastructure underneath. ## 5. Progressive Decentralization Specter launches with a focused validator set and grows from there. This is the honest approach to decentralization. Many projects launch with claims of full decentralization and then spend years dealing with the consequences: low-quality validators, governance attacks, upgrade paralysis, and fragmented communities. Specter takes a different path: start with a set of vetted, high-performance validators, prove the technology works, and then systematically expand the validator set as the network matures. Progressive decentralization means: - **Testnet first.** Every protocol upgrade ships to testnet before mainnet. Ghost Protocol, programmable policies, and Phantom Keys are all validated in adversarial conditions before they touch real assets. - **Growing the validator set.** The network begins with a curated set and opens to permissionless validation as the staking economics and slashing conditions are battle-tested. - **Community governance.** GHOST token holders gain increasing control over protocol parameters, upgrades, and treasury allocation as the governance framework matures. The destination is full decentralization. The path is honest, incremental, and engineered for reliability at every step. ## The Privacy Problem # The Privacy Problem ## It Starts With a Simple Payment You pay a freelancer for a project. On a transparent blockchain, that single transaction tells the freelancer — and anyone else watching — exactly how much money you have. Not just in that wallet, but across every token, every position, every protocol interaction tied to that address. Your entire financial life, exposed by a $500 payment. Now scale that up. Every merchant you pay can see your balance. Every employer who sends your salary can trace where you spend it. Every DeFi protocol you interact with broadcasts your strategy to competitors. Every donation you make is a public record. This is not a hypothetical. This is how transparent blockchains work *right now*, and it is the single biggest barrier to mainstream adoption. ## Your Transaction Graph Is Public Every on-chain transaction creates a link between two addresses. Over time, these links form a **transaction graph** — a complete map of who paid whom, when, and how much. Transaction graphs are extraordinarily revealing. Academic research has shown that even a few transactions can identify patterns: regular salary deposits, recurring subscription payments, tax payments at consistent intervals. These patterns are unique enough to fingerprint users, even when they use multiple wallets. For individuals, this means your financial behavior is an open book. For businesses, it means competitors can reverse-engineer your operations: your supplier relationships, your payroll structure, your treasury management strategy, and your customer base. ## Address Clustering: You Cannot Hide Behind Multiple Wallets A common response to the privacy problem is to use multiple wallets. It does not work. **Address clustering** is a set of well-documented techniques that blockchain analysis firms use to group wallets controlled by the same entity. The methods are straightforward and effective: - **Common input ownership.** If two addresses are used as inputs in the same transaction, they are almost certainly controlled by the same person. Every time you consolidate funds, you link your wallets together. - **Change address detection.** When a transaction sends more than the intended amount, the remainder goes to a change address. These are algorithmically identifiable and immediately tie the change address to the sender. - **Behavioral fingerprinting.** Gas price patterns, transaction timing, token preferences, and protocol interactions create a behavioral signature that persists across addresses. Even without a direct on-chain link, statistical analysis can group wallets by behavior. - **Deposit address reuse.** Every time you deposit to a centralized exchange, the exchange links your address to your verified identity. Withdrawal addresses receive the same treatment. Chain analysis companies like Chainalysis and Elliptic have built billion-dollar businesses on these techniques. Their tools are used by governments, exchanges, and private investigators. The transparent ledger is not just visible — it is *analyzed*, *indexed*, and *sold*. ## The Enterprise Problem For individuals, the privacy problem is about personal financial exposure. For enterprises, it is existential. Consider a company that manages its treasury on-chain. Every competitor can see: - **How much runway they have** — the total value of their holdings, updated in real time. - **Who they are paying** — vendor relationships, contractor payments, partnership deals. - **Their strategic moves** — token acquisitions, DeFi positions, governance votes. - **Their financial health** — burn rate, revenue patterns, funding inflows. No CFO would accept this level of transparency in traditional finance. Yet on-chain, it is the default. This is why most enterprise blockchain adoption has stalled at private, permissioned networks — not because the technology is wrong, but because the privacy model is. ## The Metadata Problem Even when privacy tools exist, the metadata surrounding their use creates new vulnerabilities. If you interact with a privacy-focused contract on Ethereum, the interaction itself is visible. The timing, the gas spent, the contract address — all of it is public. An observer may not know *what* you did, but they know you *used a privacy tool*, which itself is a signal. This is the fundamental limitation of privacy as an opt-in feature on a transparent chain. The act of seeking privacy becomes a distinguishing mark. On a chain where everything is transparent by default, the people who choose privacy stand out. ## The Design Flaw The privacy problem is not a bug in any specific blockchain. It is a **design flaw in the transparent ledger model** itself. Transparent blockchains were designed for a world where trustless verification was the primary goal. Every node needs to validate every transaction, so every transaction must be visible. This was a reasonable tradeoff when blockchain was a niche technology used by a small community of enthusiasts. But blockchains are no longer niche. They process billions in daily volume. They hold corporate treasuries, process payroll, manage supply chains, and govern decentralized organizations. The assumption that all participants are comfortable with total financial transparency was never realistic, and it becomes less realistic with every new user. The solution is not to bolt privacy onto a transparent foundation. The solution is to build a chain where privacy is the foundation itself — where zero-knowledge proofs replace open ledgers, where commitments replace balances, and where users reveal only what they choose to. That is what Specter was built to do. ## Core Innovation # Ghost Protocol Ghost Protocol is the core innovation at the heart of Specter. It is a **general-purpose commit/reveal privacy primitive** — a cryptographic building block that makes any on-chain data private by default. This is an important distinction. Ghost Protocol is not a mixer. It is not a shielded transaction scheme. It is not limited to tokens. It is privacy *infrastructure* — a foundation that developers use to build any private application they can imagine. ## The Envelope Analogy The simplest way to understand Ghost Protocol is to think about envelopes. **Commit (Vanish).** You take a piece of data — tokens, a secret, a vote, a credential, a sealed bid — and place it inside a cryptographic envelope. The envelope is sealed with a unique hash that acts as a fingerprint: it proves the envelope exists and has specific contents, but reveals nothing about what is inside. The chain stores only this fingerprint. Your original data is gone from the public ledger. **Reveal (Summon).** Later, when you need to prove something about your data, you do not open the envelope. Instead, you generate a zero-knowledge proof — a mathematical demonstration that you know exactly what is inside, without ever showing it. The chain verifies your proof, confirms you have not used this envelope before, and grants you access to what you committed. The data is never exposed. Your **Phantom Key** is the credential that ties you to your envelope. It is a bearer credential — whoever holds it can generate the proof needed to reveal. No accounts, no addresses, no on-chain identity required. ## Not Just Tokens Most privacy solutions focus on one thing: hiding who sent money to whom. Ghost Protocol does that, but it does much more. Because the commit/reveal pattern works with *any data*, Ghost Protocol enables: - **Private token transfers** — commit tokens, reveal them to a new address with no link to the sender. - **Sealed-bid auctions** — commit bids that no one can see until the reveal phase. - **Anonymous credentials** — commit a proof of identity or qualification, reveal it on demand without exposing the underlying data. - **Private voting** — commit votes that cannot be observed or influenced before the counting phase. - **Confidential documents** — commit document hashes for timestamping and verification without revealing contents. - **Secret sharing** — commit secrets that can be selectively revealed to authorized parties. The same primitive, the same proof system, the same Phantom Key abstraction — applied to an unlimited range of use cases. This is what makes Ghost Protocol infrastructure rather than a tool. ## How It Works Ghost Protocol's cryptography is built on two proven components: **Poseidon hashing** for commitments and **Groth16 zero-knowledge proofs** for verification. ### Commitments: Poseidon7 When you commit data through Ghost Protocol, the system generates a commitment hash using **Poseidon7** — a Poseidon hash function configured with 7 inputs: 1. **The Phantom Key secret** (your private credential) 2. **A nullifier secret** (used later to derive the nullifier and prevent double-reveal) 3. **A token identifier** (identifies which token is being committed) 4. **The amount** being committed 5. **A random blinding factor** (ensures uniqueness) 6. **A policy address** (optional, for programmable rules) 7. **A policy parameters hash** (optional, encodes the policy's specific conditions) The 7-input design is deliberate. By including the policy binding directly in the hash, Ghost Protocol ensures that the rules governing a commitment are cryptographically locked at commit time. No one — not even the committer — can change the policy after the fact. Poseidon was chosen specifically because it is **ZK-friendly**: it requires far fewer constraints inside a zero-knowledge proof circuit than traditional hash functions like SHA-256 or keccak256. This translates directly to smaller proofs and lower verification costs. ### Proofs: Groth16 When you reveal a commitment, the system generates a **Groth16 zero-knowledge proof** — a succinct, non-interactive proof that demonstrates: 1. You know the original data that was committed 2. The commitment exists in the on-chain Merkle tree 3. The nullifier you are presenting is correctly derived from your commitment 4. The policy conditions (if any) are satisfied Every Groth16 proof in Ghost Protocol is exactly **256 bytes** with **8 public inputs**, regardless of the complexity of the underlying data. This constant size is a critical property: it means verification cost is predictable (approximately 220,000 gas) and the proof reveals nothing about what was committed — whether it was 1 GHOST or 1 million, a simple transfer or a complex policy-bound credential. ### Nullifiers: Preventing Double-Reveal Each commitment has a unique **nullifier** — a value derived from the commitment's secrets that is published at reveal time. The chain maintains a set of all used nullifiers. If a nullifier has been seen before, the reveal is rejected. This mechanism prevents double-spending (for tokens) and double-use (for credentials) without revealing *which* commitment is being spent. The nullifier is mathematically linked to the commitment but cannot be traced back to it — only the holder of the Phantom Key can compute the correct nullifier. ### Quantum Safety: keccak256 Layer Ghost Protocol includes a **quantum-safe keccak256 layer** as an additional defense. At commit time, a quantum secret is generated and its keccak256 hash is stored on-chain. At reveal time, the preimage must be provided and verified. This ensures that even if future quantum computers could break the elliptic curve cryptography underlying Groth16, the keccak256 hash provides an independent barrier that quantum algorithms cannot efficiently attack. ## The Transaction Lifecycle Here is the complete flow of a Ghost Protocol transaction, from commit to reveal: [Diagram: sequenceDiagram] **Commit Phase (Vanish):** 1. The user selects the data or tokens to commit, along with any optional policy rules. 2. The client application generates the necessary secrets and computes the Poseidon7 commitment hash. 3. A quantum secret is generated and hashed with keccak256. 4. The commitment hash (and quantum hash) are submitted to the chain. If tokens are involved, they are burned via the `ghostmint` precompile. 5. The commitment is inserted into the on-chain Merkle tree. 6. The user receives a **Phantom Key** — a bearer credential containing all the secrets needed to later reveal. **Reveal Phase (Summon):** 1. The user loads their Phantom Key into the client application. 2. The client builds a Merkle inclusion proof showing the commitment exists in the tree. 3. A Groth16 zero-knowledge proof is generated with 8 public inputs, proving knowledge of the commitment without revealing it. 4. The proof, nullifier, and quantum preimage are submitted to the chain. 5. The chain verifies the ZK proof (constant 256 bytes, approximately 220,000 gas). 6. The chain verifies the quantum preimage against the stored keccak256 hash. 7. If a policy is bound, the chain enforces it. 8. The nullifier is recorded to prevent future reuse. 9. Tokens are minted to the recipient (or access is granted, depending on the use case). ## Three Generations of Innovation Ghost Protocol has evolved through three major iterations, each expanding what is possible: ### Generation 1: Basic Commit/Reveal The foundation. Users can commit data or tokens and reveal them later with a zero-knowledge proof. This alone provides unlinkability — the reveal cannot be traced back to the commit. It is the core primitive that everything else builds on. ### Generation 2: Programmable Policies (v4.4) Commitments gain the ability to carry **rules that execute at reveal time**. A policy might enforce: - **Time locks** — the commitment cannot be revealed before a certain block or timestamp. - **Recipient restrictions** — only a specific address (or set of addresses) can reveal. - **Minimum hold periods** — tokens must remain committed for a minimum duration. - **Compliance hooks** — external verification (like KYC attestation) can be required at reveal. - **Conditional logic** — arbitrary conditions evaluated at reveal time. Because the policy binding is included in the Poseidon7 hash, policies are **tamper-proof**. They cannot be modified after commitment. This makes Ghost Protocol suitable for regulated environments, escrow arrangements, and any scenario where enforceable rules need to coexist with privacy. ### Generation 3: Persistent Reusable Keys (v4.5) In earlier versions, each commitment generated a new, single-use Phantom Key. Version 4.5 introduces **persistent Phantom Keys** — a single key that can be reused across multiple commitments and reveals. This changes the user experience fundamentally. Instead of managing dozens of one-time credentials, users maintain a single Phantom Key that serves as their private identity on Specter. Think of it as a private wallet — except instead of an address that accumulates a public history, it is a credential that accumulates *nothing visible to anyone else*. Persistent keys also enable more sophisticated patterns: recurring private payments, subscription models, ongoing credential verification, and long-lived private channels between parties. --- Ghost Protocol is not a feature of Specter. It *is* Specter. Every other design decision — the Cosmos SDK architecture, the EVM compatibility, the token economics, the bridge infrastructure — exists to make Ghost Protocol as powerful, accessible, and composable as possible. ## Protocol Architecture: Overview # Architecture Overview If you have ever stacked building blocks as a kid, you already understand how Specter is put together. The protocol is a layered stack where each layer does one thing well and hands off to the next. From the bottom up, it looks like this: **CometBFT consensus** keeps everyone honest. **Cosmos SDK** manages the chain's core functions — accounts, tokens, staking. **The EVM** runs smart contracts in Solidity, exactly like Ethereum. **Ghost Protocol** adds the privacy layer on top. And **applications** — the things people actually use — sit at the very top. Let's walk through it visually: [Diagram: flowchart TB] ## Why Layers Matter Each layer in the stack has a clear boundary and a clear job: - **Consensus (CometBFT):** The foundation. All validators agree on the order and validity of transactions. This is the bedrock that everything else trusts. - **Cosmos SDK:** The chain's operating system. It handles native tokens via `x/bank`, validator management via `x/staking`, and a custom `x/ghostmint` module that lets the EVM mint and burn native GHOST tokens — something no standard Ethereum chain can do. - **EVM Execution:** A full Ethereum Virtual Machine powered by go-ethereum. Any Solidity contract that works on Ethereum works here, unchanged. The `ghostmint` precompile is a special bridge that lets smart contracts reach down into the native token layer. - **Ghost Protocol:** The privacy contracts — `CommitRevealVault` for private token transfers, `OpenGhostVault` for private data storage, `PersistentKeyVault` for reusable credentials, and the policy system that lets developers attach rules to private data. - **Applications:** The products people actually interact with. Vanish and Summon for private token transfers. Revels for private data sharing. Stealth addresses, dead man's switches, cross-chain bridges — all built on top of Ghost Protocol without modifying a single line of infrastructure code. ## The Key Insight Most privacy solutions are bolted onto existing blockchains as an afterthought. Specter is different. Privacy lives at the protocol level, baked into the architecture from the very first layer. Every layer above it inherits that privacy by default. This means a developer building on Specter does not need to "add privacy" to their application. They simply build on Ghost Protocol, and privacy comes for free. The same way a web developer does not need to "add HTTPS" to every page — it is just how the internet works now. ## Composability Because Ghost Protocol is a set of smart contracts on a standard EVM, every privacy primitive is composable. A Revel can reference a Vanish commitment. A Dead Man's Switch can be funded through the bridge. Stealth addresses can receive tokens from any application. Everything talks to everything else, and developers can combine these building blocks in ways we have not even imagined yet. ## Protocol Architecture: Execution Environment # Execution Environment Here is the best part about building on Specter: if you have ever written a Solidity contract, deployed to Ethereum, or connected MetaMask to a dApp — you already know how to use Specter. There is nothing new to learn. ## Full EVM, No Compromises Specter runs a complete Ethereum Virtual Machine powered by go-ethereum (geth), the same execution engine that powers Ethereum itself. This is not an "EVM-compatible" approximation or a transpiled subset. It is the real thing, running natively inside the Cosmos SDK. What this means in practice: - **Any Ethereum smart contract** deploys and runs on Specter without modification. ERC-20 tokens, NFTs, DEXes, lending protocols — they all work. - **All Ethereum tooling works.** MetaMask, WalletConnect, Hardhat, Foundry, Remix, Ethers.js, Viem — connect them to Specter and they just work. - **Standard JSON-RPC endpoints** mean block explorers, indexers, and analytics tools plug in seamlessly. [Specterscan.io](https://specterscan.io) provides a familiar block exploration experience. Developers do not have to choose between privacy and the Ethereum ecosystem. Specter gives you both. ## The ghostmint Precompile Here is where things get interesting. Standard EVMs have a fundamental limitation: smart contracts can transfer tokens between accounts, but they cannot *create* or *destroy* native tokens. The token supply is fixed at the protocol level, and the EVM has no way to reach down and change it. Ghost Protocol needs exactly this capability. When you **Vanish** tokens (commit them privately), those tokens need to be burned from the sender's balance so they cannot be double-spent. When you later **Summon** them (reveal with a zero-knowledge proof), fresh tokens need to be minted to the recipient. This is a protocol-level operation that normal Solidity contracts simply cannot perform. The **ghostmint precompile** solves this. It is a special contract address baked into the EVM that bridges the gap between Solidity smart contracts and the Cosmos SDK's native `x/bank` module. When Ghost Protocol contracts call the precompile, it reaches into the chain's native token system to mint or burn GHOST tokens directly. Think of it like a special door in the EVM that opens into the chain's treasury. Only authorized contracts — specifically, the Ghost Protocol vaults — have the key. ## Why Not Just Use Wrapped Tokens? You might wonder: could we just use a wrapped token (like WETH on Ethereum) and avoid all this complexity? We could, but it would break the privacy model. Wrapped tokens leave traces — you can see when tokens enter and leave the wrapper contract, which creates a linkability problem. By operating on *native* tokens through the precompile, Ghost Protocol ensures there is no wrapper contract to observe. Tokens simply vanish from one address and, later, appear at another — with zero on-chain link between the two events. ## Gas and Performance Because the EVM is running natively (not in a compatibility layer), gas costs on Specter are comparable to Ethereum. Zero-knowledge proof verification — the most expensive operation Ghost Protocol performs — costs approximately 220,000 gas. That is roughly the same as a Uniswap trade on Ethereum, and with Specter's lower gas prices, it is significantly cheaper in practice. ## Protocol Architecture: Network Topology # Network Topology A blockchain is not just software — it is a network of machines working together. Understanding who does what in the Specter network helps you understand how the system stays healthy, fast, and private. ## The Players [Diagram: graph TB] ### Validators Validators are the backbone of the network. They run CometBFT consensus, propose blocks, vote on block validity, and collectively maintain the canonical state of the chain. Each validator stakes GHOST tokens as collateral — their skin in the game that incentivizes honest behavior. Validators communicate with each other in a peer-to-peer mesh, gossiping transactions and participating in consensus rounds. The validator set is permissionless: anyone with sufficient stake can join. ### Relayer Services Privacy creates a unique infrastructure challenge. When commitments are stored as hashes in a Merkle tree, *someone* needs to maintain the full tree so that users can generate proofs against it. That is where relayer services come in. Relayer services are off-chain infrastructure that supports the privacy layer: - **Merkle Tree Indexer:** Watches the chain for new commitments and maintains the complete Poseidon Merkle tree off-chain. Without this, users would need to reconstruct the entire tree themselves to generate a proof. - **Commitment Hasher:** Pre-computes hashes for efficient tree updates, keeping the indexer fast even as the tree grows. - **Proof Generator:** Helps thin clients (like mobile wallets) generate zero-knowledge proofs without needing the full proving key locally. This is a convenience service — users with sufficient hardware can always generate proofs themselves. - **Bridge Relay:** Monitors external chains (Ethereum, Base, Arbitrum) for deposit events and relays them to Specter, and vice versa. This is the heartbeat of the Hyperlane bridge system. Relayer services are designed to be run by multiple independent operators. While a single relayer going offline would degrade user experience, it would not compromise security — the chain continues to operate, and users with local tree data can still generate and submit proofs directly. ### Clients Clients are the user-facing layer. This includes web-based dApps at [specter.foundation](https://specter.foundation), mobile wallets, and standard Ethereum wallets like MetaMask. Clients connect to validators via JSON-RPC (just like on Ethereum) and to relayer services for Merkle tree data and proof generation assistance. Because Specter is fully EVM-compatible, any Ethereum client library — Ethers.js, Viem, Web3.js — works out of the box. ### External Chains Specter does not exist in isolation. Through the Hyperlane bridge, it connects to Ethereum, Base, and Arbitrum. Bridge relay nodes monitor lock/mint events on both sides, ensuring that tokens can flow freely between Specter and the broader crypto ecosystem. Privacy does not have to mean being an island. ## Resilience The network is designed so that no single point of failure can take down the system. Validators are distributed and incentivized by staking. Relayer services can be run by anyone. Clients can connect to any available validator. And the bridge relay is operated by multiple independent parties. Even if pieces of the infrastructure go offline temporarily, the core chain — and its privacy guarantees — remain intact. ## Protocol Architecture: State Model # State Model Every blockchain has state — the running tally of who owns what. On Ethereum, that state is transparent: anyone can look up any address and see its balance, its transaction history, and every contract it has ever interacted with. On Specter, the state model is designed from the ground up to store *proofs of knowledge* rather than the knowledge itself. Here is what lives on-chain and how it all fits together. ## Commitment Storage: The Poseidon Merkle Tree At the heart of Ghost Protocol is a **Poseidon Merkle tree** — a binary hash tree that stores every commitment ever made on the network. - **Depth:** 20 levels, giving a capacity of roughly 1 million commitments per tree. - **Hash function:** Poseidon, a hash function specifically designed to be efficient inside zero-knowledge proof circuits. Where keccak256 (Ethereum's hash function) would make ZK proofs prohibitively expensive, Poseidon keeps them fast and affordable. - **Root stored on-chain:** Only the Merkle root — a single 32-byte value that summarizes the entire tree — is stored in the smart contract. This is all the chain needs to verify proofs. - **Full tree maintained off-chain:** Relayer services (Merkle tree indexers) maintain the complete tree so that users can look up their leaf position and compute the Merkle path needed to generate a proof. ### Root History When you generate a zero-knowledge proof, you prove that your commitment exists in the tree *as of a particular root.* But the root changes every time a new commitment is added. If only the latest root were valid, you would have a tiny window to submit your proof before it became stale. To solve this, Ghost Protocol keeps the **last 100 Merkle roots** valid. This means you can generate a proof against a recent root and still have it accepted even if new commitments have been added in the meantime. It is a simple mechanism that makes the user experience dramatically smoother. ## Nullifier Registry Nullifiers are what prevent double-spending in a privacy system. When you reveal a commitment (for example, when you Summon tokens), the contract records a **nullifier** — a unique value derived from your secret and the commitment itself. If anyone tries to reveal the same commitment again, the contract checks the nullifier registry and rejects the transaction. The registry is straightforward: ``` mapping(bytes32 => bool) ``` Once a nullifier is recorded, it stays forever. There is no undo, no expiry, no admin override. This permanence is a feature, not a limitation — it is what makes double-spending mathematically impossible. The nullifier itself reveals nothing about the original commitment. It is derived using Poseidon hashing in a way that makes it impossible to link a nullifier back to the commitment it came from, unless you already know the secret. ## Quantum Commitments Zero-knowledge proofs today rely on mathematical assumptions (specifically, the difficulty of the discrete logarithm problem on elliptic curves) that a sufficiently powerful quantum computer could theoretically break. Specter includes a defense-in-depth layer for this scenario. When you create a commitment, the contract also stores a **quantum commitment**: ``` keccak256(quantumSecret) ``` This is a plain hash of a separate secret. If the ZK proof system is ever compromised, users can still prove ownership by revealing the preimage of their quantum commitment. Keccak256 is a traditional hash function whose security does not depend on the same mathematical assumptions as ZK proofs — it remains secure even against known quantum algorithms. Think of it as a backup lock on your front door. You hope you never need it, but you sleep better knowing it is there. ## Policy Bindings Ghost Protocol's programmable policies (introduced in v4.4) need to be tamper-proof. When a commitment is created with a policy — say, a timelock that prevents early redemption — that policy must be cryptographically bound to the commitment so that no one can swap in a different policy later. This is handled through two on-chain mappings: - **`commitmentPolicies`:** Maps each commitment hash to its associated policy contract address. - **`commitmentPolicyParamsHashes`:** Maps each commitment hash to a hash of the policy's parameters (e.g., the expiry timestamp for a timelock, or the allowed destination for a restriction). Because the policy address and parameter hash are included as inputs to the Poseidon7 commitment hash itself, any attempt to tamper with the policy would change the commitment hash — and the proof would fail. The policy is as immutable as the commitment it is attached to. ## Putting It All Together When you interact with Ghost Protocol, here is what actually happens to the chain's state: 1. **Commit:** A new leaf is added to the Merkle tree. The root is updated. Policy bindings are stored. A quantum commitment is recorded. Your tokens are burned (if applicable). None of this reveals what you committed. 2. **Reveal:** You submit a ZK proof and a nullifier. The contract verifies the proof against a recent root, checks that the nullifier has not been used, records the nullifier permanently, and executes the reveal action (minting tokens, releasing data, etc.). The beauty of this model is that commits and reveals are completely unlinkable on-chain. The Merkle tree, the nullifier registry, and the quantum commitments are all that the chain stores — and none of them reveal the connection between a commit and its corresponding reveal. ## Protocol Architecture: Cross-Chain # Cross-Chain Bridges Privacy is only useful if you can actually get your assets into the private environment. Nobody wants to be stuck on an island, no matter how beautiful it is. That is why Specter connects to the broader crypto ecosystem through a bridge system built on **Hyperlane**. ## How It Works The bridge follows a straightforward **lock-and-mint** model: 1. **Deposit:** You lock your tokens in a bridge contract on the source chain (Ethereum, Base, or Arbitrum). 2. **Relay:** Bridge relay nodes detect the lock event and relay it to Specter. 3. **Mint:** A synthetic **g-token** is minted on Specter, representing your locked asset 1:1. Going the other direction works in reverse: 1. **Burn:** You burn your g-tokens on Specter. 2. **Relay:** The burn event is relayed back to the source chain. 3. **Unlock:** Your original tokens are released from the bridge contract. This is a two-way bridge. Assets flow freely in both directions. ## Supported Assets | g-Token | Underlying Asset | Source Chains | |---------|-----------------|---------------| | **gUSDC** | USDC | Ethereum, Base, Arbitrum | | **gWETH** | WETH | Ethereum, Base, Arbitrum | | **gVIRTUAL** | VIRTUAL | Base | These g-tokens are GhostERC20 tokens on Specter — privacy-enabled tokens with built-in commit/reveal support and ZK proof compatibility. They can be transferred, traded, and — most importantly — used with Ghost Protocol just like native GHOST tokens. You can **Vanish** gUSDC to make it private, **Summon** it later to a different address, and the entire process is indistinguishable from any other Ghost Protocol operation. ## Why Hyperlane? Hyperlane is a modular interoperability protocol that lets us customize the security model for each bridge route. Rather than relying on a single multisig or a centralized relayer, Hyperlane's architecture allows for multiple independent validators to attest to cross-chain messages. This means: - **No single point of trust.** Multiple independent parties must agree that a lock or burn event actually happened before the other side acts on it. - **Customizable security.** Different bridge routes can have different security configurations based on the value at risk and the chains involved. - **Extensibility.** Adding new chains or new assets does not require a protocol upgrade — it is a configuration change. ## Privacy Across Chains Here is where it gets exciting. Once your assets are bridged to Specter as g-tokens, they inherit all of Ghost Protocol's privacy capabilities. You can: - **Vanish gUSDC** on Specter, breaking the link between your Ethereum address and your Specter activity. - **Summon gWETH** to a completely new address that has no on-chain connection to the one that deposited. - **Create Revels** with bridged assets, sharing private data that references cross-chain tokens. - **Set up Dead Man's Switches** with bridged tokens, creating cross-chain contingency plans. The bridge is the on-ramp. Ghost Protocol is the destination. Together, they mean that your USDC on Ethereum can become fully private on Specter — and when you are done, it can flow back to any address on any supported chain. ## Bridge Security Bridge exploits have been some of the most costly incidents in crypto history, so this is a topic we take seriously. The Hyperlane bridge on Specter is secured by: - **Multiple independent relay operators** who must reach consensus on cross-chain events. - **On-chain verification** of relay messages before any minting or unlocking occurs. - **Rate limiting and monitoring** to detect and contain anomalous bridge activity. We will publish detailed bridge security audits before mainnet launch. Until then, bridge parameters (including operator sets and rate limits) may be adjusted as the system is hardened. ## Consensus # Consensus If you have ever tried to get a group of friends to agree on where to eat dinner, you have an intuitive sense of the consensus problem. Now imagine those friends might be lying to you. That is Byzantine fault tolerance — and it is the foundation of how Specter keeps everyone honest. ## CometBFT: The Short Version Specter uses **CometBFT** (formerly known as Tendermint), one of the most battle-tested consensus engines in the blockchain world. It powers dozens of production chains in the Cosmos ecosystem and has processed billions of dollars in transactions. The headline number: **approximately 5-second finality.** When your transaction is confirmed on Specter, it is *final* — no waiting for 12 confirmations, no worrying about chain reorganizations. Your transaction is settled before you can blink twice. ## How a Block Gets Made Every consensus round follows a three-phase process. Let's walk through it: [Diagram: sequenceDiagram] ### Phase 1: Propose A designated proposer (selected in a round-robin fashion, weighted by stake) assembles a block of pending transactions and broadcasts it to all validators. Think of this as someone at the dinner table saying, "How about pizza?" ### Phase 2: Prevote Each validator examines the proposed block. If the block is valid — transactions are well-formed, the state transitions are correct, the proposer followed the rules — the validator broadcasts a **prevote** in favor. If more than two-thirds of validators prevote for the same block, the round advances. This is like everyone at the table saying, "Yeah, pizza sounds good." ### Phase 3: Precommit Once a validator sees that more than two-thirds have prevoted, it broadcasts a **precommit** — a stronger commitment that it will accept this block. When more than two-thirds of validators precommit, the block is finalized and appended to the chain. Dinner is booked. No take-backs. ## Byzantine Fault Tolerance The "Byzantine" in BFT refers to the [Byzantine Generals Problem](https://en.wikipedia.org/wiki/Byzantine_fault) — a classic computer science puzzle about reaching agreement when some participants might be actively trying to sabotage the process. CometBFT provides **BFT safety** as long as fewer than one-third of validators are malicious: > **Safety guarantee:** The network tolerates **f < n/3** Byzantine (arbitrarily malicious) validators, where **n** is the total number of validators weighted by stake. In plain language: as long as more than two-thirds of the staked GHOST is controlled by honest validators, no attacker can cause the network to finalize an invalid block, reverse a finalized transaction, or create a fork. Even if the remaining validators are not just offline but actively trying to break things. This is a strong guarantee. It means: - **No double-spending.** A finalized transaction stays finalized. - **No censorship (in the long run).** A malicious proposer can delay your transaction for one round, but the next honest proposer will include it. - **No secret forks.** Unlike proof-of-work chains, there is no scenario where two competing chains exist simultaneously without validators being provably at fault (and losing their stake). ## Why CometBFT for Privacy? You might wonder why the consensus mechanism matters for a privacy-focused chain. The answer is finality. Privacy systems that use commit/reveal patterns need transactions to be final. If a chain could reorganize after you reveal a commitment, an attacker could observe the reveal, then force a reorg that replays the commitment on a different fork — potentially learning the link between your commit and reveal. CometBFT's instant finality eliminates this entire class of attacks. Once your commit is in a block, it is permanent. Once your reveal is in a block, it is permanent. No reorgs, no uncertainty, no race conditions. The privacy guarantees of Ghost Protocol rest on this foundation. ## Staking and Validator Economics Validators secure the network by staking GHOST tokens. The economics are straightforward: - **Stake to participate.** Validators (and their delegators) lock GHOST tokens as collateral. - **Earn rewards.** Honest validators earn a share of transaction fees and block rewards. - **Risk slashing.** Validators who misbehave — double-signing blocks or going offline for extended periods — have a portion of their stake burned. This is the penalty that makes attacks economically irrational. Delegators can stake their GHOST with a validator they trust, sharing in the rewards (and the risks) without running infrastructure themselves. This makes the network more decentralized by lowering the barrier to participation. ## Privacy Architecture: Overview # Privacy Goals Here is a question that most blockchain privacy projects never ask: *what exactly are we making private?* For most privacy coins, the answer is narrow — hide the sender, hide the amount, and call it a day. Specter thinks bigger. Ghost Protocol is not a privacy tool for tokens. It is a privacy primitive for *any data.* ## The Four Confidentiality Goals Every interaction through Ghost Protocol is designed to protect four distinct dimensions of privacy: ### 1. Sender Privacy When you commit data or tokens through Ghost Protocol, your address is recorded as having made *a* commitment — but what you committed is invisible. And because the Merkle tree holds thousands of commitments from thousands of users, your commitment blends into the crowd. ### 2. Receiver Privacy When someone reveals a commitment (for example, Summoning tokens to a new address), there is no on-chain link between the original committer and the revealer. The zero-knowledge proof demonstrates that the revealer knows a valid secret — without revealing *which* commitment that secret belongs to. The recipient is completely anonymous. ### 3. Amount Privacy For token operations, the amount committed is sealed inside the cryptographic envelope. The commitment hash does not encode the amount in any observable way. At reveal time, the ZK proof verifies that the amount is correct without exposing it until the tokens are actually minted. ### 4. Data Privacy This is where Specter truly stands apart. Ghost Protocol's commit/reveal primitive works on arbitrary data, not just token amounts. Through the **OpenGhostVault**, any piece of data — a document hash, a vote, a sealed bid, an API credential, a message — can be committed, stored privately, and revealed selectively. The same cryptographic guarantees that protect token transfers protect *everything.* ## The General-Purpose Primitive The key insight behind Ghost Protocol is deceptively simple: **any data that can be hashed can be committed.** And any commitment can be revealed with a zero-knowledge proof. This means Ghost Protocol is not an application — it is infrastructure. The commit/reveal primitive is like TCP/IP for privacy: a foundational layer that applications build on top of. Token privacy (Vanish/Summon) is just the first application. Data privacy (Revels) is the second. Persistent credentials (Phantom Keys) are the third. But the primitive itself is general enough to support applications we have not invented yet. A developer who wants to build a private voting system does not need to design new cryptography. They commit votes through Ghost Protocol, and the privacy comes for free. A developer building a sealed-bid auction does the same. A developer creating a private credential system — same primitive, same guarantees. ## Privacy as a Default, Not an Option On most blockchains, privacy is an opt-in feature that marks you as suspicious. "Why are you using the privacy tool? What are you hiding?" Specter flips this model. Because Ghost Protocol is woven into the base layer, privacy is not a special mode — it is just how the chain works. When privacy is the default, using it carries no signal. You are not "the person who used the privacy feature." You are just a user, indistinguishable from everyone else. This is a subtle but critical distinction. Privacy tools that only a few people use actually provide *less* privacy, because the anonymity set is small. When everyone uses the same privacy infrastructure, the anonymity set is the entire network. ## Privacy Architecture: Cryptographic Primitives # Cryptographic Primitives Let's start with the everyday version. Imagine you want to prove you are over 21 to get into a bar, but you do not want to show your ID — because your ID also has your home address, your full name, and a terrible photo from 2019. A zero-knowledge proof is like a magic stamp on your hand that says "verified: over 21" without revealing anything else. That is what Ghost Protocol does, at scale, for any data on the blockchain. Here is the cryptography that makes it possible. ## Poseidon: The ZK-Friendly Hash Hash functions are the building blocks of all blockchain cryptography. They take any input and produce a fixed-size fingerprint that is (for all practical purposes) impossible to reverse. Ghost Protocol uses **Poseidon**, a hash function specifically designed to be efficient inside zero-knowledge proof circuits. Why not just use keccak256, the hash function Ethereum uses? Because keccak256 is *expensive* to prove in ZK. It was designed for speed on regular CPUs, not for the algebraic constraint systems that ZK proofs use. Poseidon, by contrast, was designed from the ground up for this exact purpose — it requires dramatically fewer constraints, which means faster proof generation and lower verification costs. Ghost Protocol uses three variants of Poseidon, each tailored to a specific job: ### Poseidon2 (2 inputs) Used for **Merkle tree nodes** and **nullifier derivation**. Every pair of leaves in the Merkle tree is hashed together with Poseidon2 to build the tree structure. Nullifiers — the values that prevent double-spending — are also derived using Poseidon2. ### Poseidon4 (4 inputs) Used for **data and Revel commitments** in the Open Ghost Vault. When you commit arbitrary data (not tokens), the four-input variant captures the necessary fields in a single hash. ### Poseidon7 (7 inputs) Used for **token commitments with policy binding** in the Commit Reveal Vault. The seven inputs include the token address, the amount, the secrets, and — critically — the policy address and policy parameter hash. This is what makes policies tamper-proof: change any input, and the entire commitment hash changes. ## Groth16: Constant-Size Proofs Zero-knowledge proofs come in many flavors. Ghost Protocol uses **Groth16**, a proving system known for producing the smallest possible proofs with the fastest possible verification. The numbers: - **Proof size:** Constant **256 bytes**, regardless of what you are proving. Whether you are proving ownership of a single token commitment or demonstrating compliance with a complex policy, the proof is always the same size. - **Verification cost:** Approximately **220,000 gas** — roughly the cost of a Uniswap swap on Ethereum. On Specter, with lower gas prices, this is very affordable. - **Curve:** **BN254** (also known as alt_bn128), the same elliptic curve used by Ethereum's precompiled contracts for pairing operations. Groth16 does require a one-time **trusted setup** ceremony for each circuit. This ceremony generates proving and verification keys, and the security of the system depends on at least one participant in the ceremony being honest and destroying their toxic waste (the secret randomness used during setup). Ghost Protocol's circuits have undergone this ceremony, and the parameters are published for anyone to verify. ## The Two Circuits Ghost Protocol uses two distinct ZK circuits, each serving a different purpose: ### Redemption Proof (8 public inputs) This is the circuit used for one-time reveals — when you Summon tokens, reveal a Revel, or claim any single-use commitment. The proof demonstrates: - You know the secret (the Phantom Key) corresponding to a valid commitment in the Merkle tree. - The commitment matches the claimed token, amount, and policy. - The nullifier is correctly derived (preventing reuse). - You have not tampered with any of the commitment's bound data. The eight public inputs are values that the verifier contract checks against on-chain state, such as the Merkle root, the nullifier hash, the recipient address, and the token details. ### Access Proof (4 public inputs) This is the circuit used for **persistent Phantom Keys** — reusable credentials that can be verified multiple times without being consumed. The proof demonstrates that you hold a valid persistent key without revealing which one, using only four public inputs. Critically, this proof does *not* produce a nullifier, which is what allows it to be used repeatedly. ## Nullifier Formula The nullifier is what prevents double-spending, and its derivation is carefully designed to be both secure and unlinkable: ``` nullifier = Poseidon2(Poseidon2(nullifierSecret, commitment), leafIndex) ``` This two-layer structure ensures that: - Knowing the nullifier reveals nothing about the commitment (you would need the secret to make the connection). - The leaf index is included so that even if the same secret were used in two different commitments (which is discouraged but theoretically possible), the nullifiers would be different. ## Quantum-Safe Layer Here is something we think about even though we hope it never matters: quantum computers. The security of Groth16 proofs on BN254 relies on the hardness of the discrete logarithm problem on elliptic curves — something a sufficiently powerful quantum computer could theoretically crack using Shor's algorithm. Ghost Protocol includes a defense-in-depth mechanism: ``` quantumCommitment = keccak256(quantumSecret) ``` At commit time, a separate quantum secret is hashed with keccak256 (a traditional hash function, not an elliptic-curve-based one) and stored on-chain. If the ZK proof system is ever compromised, users can prove ownership by revealing the preimage of their quantum commitment. Keccak256's security against quantum computers is much stronger — the best known quantum speedup against hash functions (Grover's algorithm) only provides a quadratic speedup, meaning a 256-bit hash still offers 128 bits of quantum security. That is more than enough. Think of it as wearing both a seatbelt and having an airbag. You hope the seatbelt (ZK proofs) always works. But if it ever does not, the airbag (quantum commitment) is there to protect you. ## Privacy Architecture: Phantom Keys # Phantom Keys A **Phantom Key** is how you access your private data on Specter. When you commit something through Ghost Protocol — whether it is tokens, a document, or a credential — a Phantom Key is generated. It is the only thing you need to later prove that the commitment is yours. Think of it like a coat check ticket. You hand over your coat (commit your data), and you get a ticket (the Phantom Key). When you come back, you show the ticket, and you get your coat. Nobody needs to know your name. Nobody checks your ID. The ticket is the proof. Over three generations, Phantom Keys have evolved from simple one-time credentials into a powerful, programmable identity system. ## Generation 1: Basic One-Time Keys The original Phantom Key. A bearer credential — whoever holds it can claim the commitment. Commit once, reveal once, and the key is spent. Simple, elegant, and sufficient for basic private transfers. This is the foundation that Vanish and Summon are built on. You Vanish tokens, receive a Phantom Key, and later use that key to Summon the tokens to any address. The key contains the cryptographic secrets needed to generate the zero-knowledge proof that unlocks your commitment. One-time keys are maximally private: they are used once, produce a nullifier that permanently marks them as spent, and leave no reusable trace. ## Generation 2: Programmable Keys (v4.4) Generation 2 introduced **embedded policies** — rules that are cryptographically bound to the Phantom Key and enforced automatically at reveal time. The key does not just prove you own a commitment; it also carries the conditions under which that commitment can be claimed. Three policy types ship at launch: ### TimelockExpiry The commitment cannot be revealed until a specific time has passed (or must be revealed before a deadline). Use cases include vesting schedules, embargoed information, and time-delayed transfers. ### DestinationRestriction The commitment can only be revealed to a specific address or set of addresses. This enables KYC-gated transfers, where tokens can only flow to verified wallets — privacy and compliance coexisting in the same transaction. ### ThresholdWitness The reveal requires approval from one or more additional parties (witnesses). This enables multi-party authorization: board approvals, institutional controls, or joint custody arrangements — all while keeping the underlying commitment private. What makes these policies special is that they are **tamper-proof**. The policy address and parameter hash are included as inputs to the Poseidon7 commitment hash. Attempting to change the policy would change the commitment hash, which would invalidate the ZK proof. There is no way to remove or modify a policy after commitment — it is as permanent as the cryptography that binds it. ## Generation 3: Persistent Keys (v4.5) Persistent Phantom Keys are the breakthrough that turns Ghost Protocol from a privacy tool into a privacy *identity system.* Unlike one-time keys, a persistent key is **reusable**. It can be verified an unlimited number of times using the Access Proof circuit, and it is never consumed. It stays valid until it is explicitly revoked by its creator. This changes everything. A persistent Phantom Key is not just a receipt for a single commitment — it is a *credential* that proves ongoing access to something. ### Use Cases - **API Keys:** Issue a persistent Phantom Key as an API credential. The holder can authenticate as many times as they want, and the key can be revoked instantly if compromised. No passwords, no tokens stored in databases — just a cryptographic proof of access. - **Software Licenses:** A persistent key proves that someone has purchased a license. It can be verified on every launch without being "used up." Revoke it to end the subscription. - **Team Credentials:** Issue persistent keys to team members for access to shared resources. When someone leaves the team, revoke their key. No need to rotate shared secrets. - **AI Chat Sessions:** A persistent key can represent an ongoing conversation or session. Each interaction verifies the key without consuming it, maintaining continuity and privacy. - **Subscription Access:** Media paywalls, gated communities, premium features — all can be unlocked with a persistent Phantom Key that stays valid as long as the subscription is active. ### How Revocation Works Persistent keys are stored in the **PersistentKeyVault** and support two revocation policies: - **BEARER** (default): Anyone who holds the Phantom Key can revoke it — true bearer instrument behavior. - **ISSUER_ONLY**: Only the wallet that originally sealed the key can call revoke — giving issuers full control over the credentials they create. In both cases, revocation is permanent and immediately invalidates the key for all future Access Proof verifications. ## Export Formats Phantom Keys are just data — cryptographic secrets encoded in a portable format. Specter supports multiple ways to share and store them: | Format | Description | Best For | |--------|-------------|----------| | **Numeric Code** | A human-readable number that can be typed or dictated | Phone calls, manual entry | | **QR Code** | A scannable image | In-person transfers, mobile wallets | | **PNG Image** | A downloadable image file | Messaging apps, email | | **PDF Document** | A printable document with the key and instructions | Paper backup, formal transfers | | **NFC Card** | An NTAG 424 DNA card with the key written to its secure memory | Physical access cards, gift cards, collectibles | The NFC format is worth highlighting. An NTAG 424 DNA card is a tamper-resistant hardware chip that can store a Phantom Key and present it via near-field communication — tap your card to a reader, and the key is transmitted. This brings blockchain privacy into the physical world: imagine a keycard that grants access to a building, where the access credential is a zero-knowledge proof on Specter. No central database. No admin who can see who entered when. Just cryptographic proof of authorization. ## Privacy Architecture: Protocol vs Application # Protocol vs Application Layer One of the most important architectural decisions in Ghost Protocol is the clean separation between the **protocol layer** (infrastructure that anyone can build on) and the **application layer** (products that people actually use). This is not just good engineering — it is what makes Specter an ecosystem rather than a single product. ## The Protocol Layer: Infrastructure The protocol layer consists of three core vaults and a policy system. These are the building blocks — general-purpose, composable, and designed to be used by any application. ### CommitRevealVault The foundation. Accepts token deposits, stores commitments in the Poseidon Merkle tree, and processes zero-knowledge proof-verified withdrawals. This is the engine behind private token transfers. It handles minting, burning, nullifier tracking, and root history — all the low-level plumbing that makes private tokens work. Any developer can build on top of CommitRevealVault. It does not care what your application looks like or what your user experience is. It just provides a guarantee: tokens go in privately, and tokens come out privately, with a ZK proof linking the two that reveals nothing about who, what, or when. ### OpenGhostVault The same commit/reveal primitive, but for arbitrary data instead of tokens. Any data that can be represented as a hash can be committed, stored privately, and revealed selectively. The vault uses Poseidon4 commitments (four inputs) to capture the data fields. OpenGhostVault is what makes Ghost Protocol general-purpose. Without it, Specter would be just another privacy coin. With it, Specter is a privacy *platform*. ### PersistentKeyVault Manages persistent Phantom Keys — reusable credentials that can be verified repeatedly without being consumed. Handles key creation, access verification (via the Access Proof circuit), and explicit revocation. This vault turns Ghost Protocol from a transactional privacy system into a credential system. It is the infrastructure layer for subscriptions, licenses, memberships, and any other use case where ongoing access matters. ### Policy System A modular framework for attaching enforceable rules to commitments. Policies are smart contracts that implement a standard interface, and they are cryptographically bound to commitments via Poseidon7 hashing. The system is extensible — anyone can write and deploy new policy contracts. ## The Application Layer: Products Applications are what users interact with. They are built on top of the protocol layer, and they define the user experience, the business logic, and the specific use case. Here are the applications that ship with Specter: ### Vanish and Summon The flagship privacy application. **Vanish** commits tokens into the CommitRevealVault, burning them from your address and giving you a Phantom Key. **Summon** uses a ZK proof to mint those tokens to any recipient address. The result: a private transfer with no on-chain link between sender and receiver. ### Revels Private data sharing built on OpenGhostVault. A Revel is a piece of data — a message, a document hash, a secret, anything — committed privately and revealed selectively. Use cases range from encrypted messaging to sealed-bid auctions to private attestations. ### Stealth Addresses A system for receiving tokens at one-time addresses that cannot be linked back to your main identity. The sender generates a unique address for each transfer, and only the recipient can detect and claim the funds. This solves the "public address" problem — you can share a single stealth meta-address, and every payment you receive arrives at a different, unlinkable address. ### Dead Man's Switch A time-based contingency system. You commit tokens or data with a condition: if you do not check in before a deadline, the commitment automatically becomes claimable by a designated beneficiary. Use cases include inheritance planning, emergency access to shared accounts, and fail-safe mechanisms for critical data. ### NFC Cards Physical cards (NTAG 424 DNA) that store Phantom Keys in tamper-resistant hardware. Tap a card to a reader to transmit a credential. This bridges the gap between digital privacy and the physical world — access cards, gift cards, loyalty programs, and collectible items that carry real cryptographic credentials. ### Bridge The Hyperlane-powered bridge that connects Specter to Ethereum, Base, and Arbitrum. Tokens locked on source chains become g-tokens on Specter, and those g-tokens work with every Ghost Protocol application. ## Why This Separation Matters The protocol/application split means that Ghost Protocol is not a closed system. Specter ships with a set of applications, but anyone can build new ones. A developer who wants to create a private voting system, a confidential NFT marketplace, a sealed-bid auction house, or something we have not thought of yet — they can build it on top of the same CommitRevealVault, OpenGhostVault, and PersistentKeyVault infrastructure. The protocol layer provides the privacy guarantees. The application layer decides what to do with them. This is how ecosystems grow: by making the infrastructure open and letting creativity happen on top. ## Privacy Architecture: Trust Assumptions # Trust Model Every system requires trust in *something*. Anyone who tells you their system is "trustless" is either confused or selling you something. The honest approach is to be explicit about what you must trust, what you do not need to trust, and where the boundaries are. Here is Specter's trust model, laid out plainly. ## What You Must Trust ### CometBFT Consensus (f < n/3) You must trust that more than two-thirds of the validator set (weighted by stake) is honest. This is the standard Byzantine fault tolerance assumption. If more than one-third of validators collude, they could potentially halt the network or censor transactions. They could *not*, however, steal your private data or forge ZK proofs — those guarantees come from cryptography, not consensus. ### BN254 Pairing Assumptions (Groth16) You must trust that the mathematical problems underlying the BN254 elliptic curve are hard to solve. Specifically, Groth16 relies on the hardness of the discrete logarithm problem and bilinear pairing assumptions on this curve. These are well-studied assumptions that have held up for decades, and BN254 is the same curve used by Ethereum's precompiled pairing contracts. If these assumptions were broken, it would affect far more than just Specter. ### Keccak256 Preimage Resistance (Quantum Layer) You must trust that keccak256 is a secure hash function — specifically, that no one can find the input that produces a given output. This is one of the most conservative assumptions in all of cryptography. Keccak256 (SHA-3) has been extensively analyzed and is considered secure against both classical and quantum attacks. ### Groth16 Trusted Setup You must trust that at least one participant in Ghost Protocol's trusted setup ceremony was honest and destroyed their secret randomness. If *all* participants colluded (or were compromised), it would theoretically be possible to forge proofs. In practice, setup ceremonies are designed with enough independent participants that this risk is negligible. ## What You Do NOT Need to Trust This is the more interesting list — the things that Specter's design explicitly removes from the trust model: ### No Trusted Third Party for Privacy There is no privacy server, no mixing coordinator, no relayer that can see your data. Your privacy comes from cryptography (ZK proofs and Poseidon hashing), not from trusting someone to keep your secrets. No operator, no foundation member, no validator can see what is inside your commitments. ### No Admin Can Reveal Your Data There is no admin key, no governance vote, no emergency mechanism that can expose the contents of a commitment. The data is sealed by mathematics, not by access controls. Even if every Specter team member wanted to reveal a commitment, they could not — they simply do not have the information needed. ### No One Can Link Commits to Reveals On-chain, a commitment and its corresponding reveal are two separate, unlinkable events. The Merkle tree structure, the nullifier design, and the ZK proof system are all designed to make this link impossible to establish from public data. An observer can see that *someone* committed and that *someone* revealed, but they cannot determine that these two events are related. ### No One Can Forge a Proof Under the BN254 assumptions, it is computationally infeasible to create a valid ZK proof without knowing the underlying secret. You cannot claim someone else's commitment, spend a nullifier you did not derive, or bypass a policy binding. ### No One Can Double-Spend The nullifier registry is permanent and immutable. Once a nullifier is recorded, the same commitment can never be revealed again. There is no mechanism — administrative or otherwise — to reset or bypass the nullifier check. ## Honest Limitations We believe in being straightforward about the things that are not perfect: ### Relayer Infrastructure The Merkle tree indexer and proof generation service are convenience infrastructure. If all relayer services go offline, users who do not have a local copy of the Merkle tree cannot generate proofs until the services are restored. The chain itself continues to operate, and no data is lost — but the user experience degrades. We mitigate this by designing relayer services to be run by multiple independent operators. ### NTAG 424 DNA Hardware Physical NFC cards that store Phantom Keys depend on the security of the NTAG 424 DNA chip. While this chip includes AES-128 encryption, rolling CMAC authentication, and tamper-resistant hardware design, it is ultimately a piece of physical hardware manufactured by a third party (NXP Semiconductors). The security guarantees are only as strong as the hardware implementation. ### Anonymity Set Size Privacy improves as more people use the system. A Merkle tree with 100 commitments offers less privacy than one with 100,000, because the set of possible identities an observer must consider is smaller. In the early days of the network, the anonymity set will be smaller than at maturity. This is an inherent bootstrapping challenge for any privacy system. ### Metadata Leakage Ghost Protocol protects the *contents* of your transactions, but certain metadata is inherently visible on a public blockchain: the fact that a transaction occurred, the gas paid, the timing, and the contract called. Sophisticated traffic analysis could potentially narrow down possibilities, especially in the early days when usage is lower. We encourage users who need the strongest privacy guarantees to consider their operational security practices as well. ## The Bottom Line Specter's trust model is designed to minimize the number of things you have to believe. The core privacy guarantees — your data is sealed, your commits and reveals are unlinkable, no one can forge proofs or double-spend — rest on well-studied mathematical foundations, not on trusting any person or organization. Where we do depend on trust assumptions (consensus, curve security, setup ceremonies), we use the most battle-tested and widely-scrutinized options available. ## Privacy Architecture: Regulatory # Compliance and Regulation There is a persistent myth in the blockchain world that privacy and compliance are opposites — that if you build privacy, you must be against regulation, and if you support regulation, you must be against privacy. This is a false choice, and Ghost Protocol's programmable policy system proves it. Privacy is not about hiding from the law. It is about controlling who sees your information and under what conditions. That is exactly what Ghost Protocol's policies enable — **programmable, enforceable rules that operate at the cryptographic level**, built into the privacy system rather than bolted on top. ## Policies as Compliance Tools Ghost Protocol ships with three policy types, each of which maps directly to real-world compliance requirements: ### DestinationRestriction = KYC-Gated Transfers The DestinationRestriction policy limits where a commitment can be revealed. Only pre-approved addresses can receive the funds or data. In compliance terms, this is **KYC-gated transfer control.** An institution can issue tokens through Ghost Protocol that can only be redeemed by verified wallets. The tokens remain private (amounts hidden, transfers unlinkable), but the compliance constraint — "these funds can only go to verified recipients" — is cryptographically enforced. No one has to trust that a compliance officer is checking a spreadsheet. The rule is embedded in the mathematics. ### TimelockExpiry = Vesting Enforcement The TimelockExpiry policy prevents a commitment from being revealed until a specific time has passed, or requires it to be revealed before a deadline. In compliance terms, this is **automated vesting and lockup enforcement.** Token grants that must vest over two years? The timelock enforces it — there is no early withdrawal, no exception, no way to "accidentally" unlock tokens ahead of schedule. Regulatory hold periods? Same mechanism. The enforcement is not a checkbox in a dashboard that someone might forget to check. It is a condition baked into the cryptographic commitment itself. ### ThresholdWitness = Institutional Controls The ThresholdWitness policy requires one or more additional parties to approve a reveal before it can be executed. In compliance terms, this is **multi-party authorization for institutional transactions.** A treasury disbursement that requires board approval? A fund transfer that needs sign-off from a compliance officer? The threshold witness policy makes these requirements cryptographically binding — the transaction literally cannot execute without the required approvals, regardless of who wants it to. ## How This Works in Practice Consider a compliant institutional use case: 1. A regulated fund wants to transfer USDC to a counterparty privately (because broadcasting your trade sizes to the entire market is a terrible idea). 2. The fund bridges USDC to Specter as gUSDC and commits it through Ghost Protocol with two policies: - **DestinationRestriction:** Only the counterparty's verified wallet can receive the funds. - **ThresholdWitness:** The fund's compliance officer must co-sign the reveal. 3. The commitment is private — no one on-chain can see the amount or the parties involved. 4. When it is time to settle, the counterparty initiates the reveal. The compliance officer provides their witness signature. The policies are verified as part of the ZK proof. The funds are released. At no point did privacy conflict with compliance. The fund got transaction confidentiality (their trade size is invisible). The regulator got enforcement guarantees (funds can only go to verified recipients, with institutional oversight). And none of this required a trusted intermediary — it is all enforced by cryptography. ## Extensibility The policy system is not limited to the three policies that ship at launch. The framework is modular: anyone can write and deploy new policy contracts that implement the standard interface. As regulatory requirements evolve, new policies can be created to meet them — without modifying Ghost Protocol itself. Imagine future policies for: - **Geographic restrictions** that limit where commitments can be revealed based on jurisdiction. - **Amount limits** that cap the value of individual transactions for compliance thresholds. - **Audit trails** that allow a designated regulator (and only that regulator) to decrypt transaction details under specific legal conditions. - **Expiry policies** that automatically return funds after a regulatory hold period. The point is not that we have solved every compliance challenge today. The point is that the architecture is designed to *accommodate* compliance, rather than fight it. Privacy and regulation are not enemies. They are two sides of the same coin: giving people control over their information while ensuring that rules can still be enforced. ## A Note on Philosophy Specter is built for a world where privacy is a right and compliance is a reality. We do not believe that building privacy tools makes you anti-regulation, and we do not believe that supporting regulation means surrendering privacy. The programmable policy system is our answer to the false dichotomy: privacy by default, compliance by design. ## Security Model # Security Model Security is not a feature you add at the end. It is a property of every design decision, every line of code, and every assumption you make. Here is how Specter keeps you safe — organized by threat category, with honest discussion of both strengths and limitations. ## BFT Consensus Safety **Threat:** A group of validators colludes to finalize invalid blocks, double-spend tokens, or censor transactions. **Protection:** CometBFT provides Byzantine fault tolerance with the guarantee that the network remains safe as long as fewer than one-third of validators (weighted by stake) are malicious: > **f < n/3** — the network tolerates up to f Byzantine validators out of n total. This means an attacker would need to control more than one-third of all staked GHOST to compromise consensus. Even then, the attack would be detectable (validators who double-sign are identifiable), and the attacker's stake would be slashed — making the attack economically destructive to the attacker. **Limitation:** If more than one-third of validators go offline simultaneously (without being malicious), the network halts until enough validators return. This is a liveness issue, not a safety issue — no invalid state transitions can occur, but the chain stops producing blocks. ## Zero-Knowledge Proof Soundness **Threat:** An attacker forges a ZK proof to claim tokens they do not own, bypass a policy, or double-spend a commitment. **Protection:** Ghost Protocol uses Groth16 on the BN254 curve. The soundness of Groth16 means that producing a valid proof without knowing the witness (the secret inputs) is computationally infeasible under the BN254 pairing assumptions. These are well-studied cryptographic assumptions that have held for decades and are used by Ethereum itself for precompiled pairing operations. The two circuits — Redemption Proof (8 public inputs) and Access Proof (4 public inputs) — are each designed to verify specific claims about commitments, nullifiers, and policies. The proof either verifies or it does not. There is no gray area. **Limitation:** Groth16 requires a trusted setup ceremony. If all participants in the ceremony colluded, forged proofs would theoretically be possible. In practice, ceremonies are designed with enough independent participants to make this risk negligible. ## Quantum-Safe Layer **Threat:** A future quantum computer breaks the elliptic curve assumptions underlying Groth16 and BN254, allowing an attacker to forge ZK proofs. **Protection:** Every commitment in Ghost Protocol includes a quantum commitment: ``` quantumCommitment = keccak256(quantumSecret) ``` This is a separate defense layer that does not depend on elliptic curve cryptography. If ZK proofs are ever broken, users can prove ownership by revealing the preimage of their quantum commitment. Keccak256 is resistant to quantum attacks — Grover's algorithm provides only a quadratic speedup against hash functions, meaning a 256-bit hash retains 128 bits of security even against a quantum adversary. **Limitation:** The quantum-safe layer is a fallback mechanism, not a full replacement for ZK proofs. If activated, it would require a protocol upgrade to define the new verification process, and it would not provide the same privacy guarantees as ZK proofs (revealing the preimage inherently discloses information). It is a safety net, not a seamless transition. ## NFC Card Security **Threat:** An attacker clones, extracts, or tampers with a Phantom Key stored on an NFC card. **Protection:** Specter's physical NFC cards use **NTAG 424 DNA** chips from NXP Semiconductors, which include multiple hardware security features: - **AES-128 encryption** for secure communication between the card and reader. - **Rolling CMAC (Cipher-based Message Authentication Code)** that generates a unique authentication code for every tap, preventing replay attacks. - **Tamper-resistant hardware** designed to resist physical probing, side-channel attacks, and fault injection. - **Unique chip identifiers** that are burned in at manufacturing and cannot be changed. **Limitation:** Hardware security is ultimately bounded by the physical implementation. While NTAG 424 DNA is considered industry-leading for NFC security, no hardware is provably unbreakable. State-level adversaries with access to advanced chip analysis equipment may be able to extract secrets, though the cost and effort would be extraordinary. For the highest-security use cases, we recommend treating NFC cards as a convenience layer with a digital backup. ## Smart Contract Security **Threat:** A vulnerability in Ghost Protocol's smart contracts allows an attacker to drain funds, bypass privacy, or corrupt state. **Protection:** Multiple layers of defense: - **OpenZeppelin libraries** for standard security patterns (access control, pausability, reentrancy guards). These are the most audited smart contract libraries in the Ethereum ecosystem. - **ReentrancyGuard** on all external-facing functions that modify state or transfer value. - **Checks-effects-interactions pattern** throughout the codebase — state is updated before any external calls, preventing reentrancy exploits. - **Minimal attack surface** — the core vaults (CommitRevealVault, OpenGhostVault, PersistentKeyVault) are designed to do one thing well, with as little complexity as possible. - **Immutable commitment bindings** — policies, parameters, and commitment data are bound by Poseidon hashing. Even if a contract had a bug, an attacker could not modify an existing commitment's terms without invalidating the proof. **Limitation:** Smart contract security is never absolute. We will conduct professional security audits before mainnet launch and maintain an active bug bounty program. Despite best efforts, the possibility of undiscovered vulnerabilities can never be fully eliminated — only minimized through rigorous engineering, auditing, and responsible disclosure. ## Bridge Security **Threat:** An attacker exploits the cross-chain bridge to mint unbacked tokens on Specter or unlock tokens on a source chain without a corresponding burn. **Protection:** The Hyperlane bridge uses multiple independent relay operators who must reach consensus on cross-chain events. On-chain verification of relay messages occurs before any minting or unlocking. Rate limiting provides an additional layer of protection against large-scale exploits. **Limitation:** Bridge security is one of the hardest problems in crypto. Cross-chain bridges are inherently more complex than single-chain applications because they involve coordinating state across two independent consensus systems. We take this seriously, and bridge parameters will be conservative at launch. ## What We Do NOT Protect Against Being honest about limitations is as important as describing protections: - **Endpoint compromise.** If your device is compromised (malware, keylogger), an attacker may be able to steal your Phantom Keys. Ghost Protocol protects data on-chain, not on your device. - **Voluntary disclosure.** If you share your Phantom Key with someone, they can reveal your commitment. The system cannot protect you from yourself. - **Metadata analysis.** While Ghost Protocol hides the contents of transactions, on-chain metadata (timing, gas usage, contract interactions) is visible. Sophisticated analysis could potentially narrow down possibilities. Operational security matters. - **Social engineering.** No cryptographic system can protect against being tricked into revealing your secrets. Be cautious about who you share Phantom Keys with and verify the authenticity of any application you interact with. ## The Philosophy Security is not about making guarantees you cannot keep. It is about being clear-eyed about what the system protects, how it protects it, and where the edges are. Specter is designed with defense in depth — multiple independent security mechanisms, each of which would need to be broken separately. The goal is not perfection (which does not exist in security), but a system where the cost of attack always exceeds the value of success. ## Token Economics: Overview # GHOST Token Every engine needs fuel. For the Specter network, that fuel is **GHOST** — the native token that powers every privacy operation, secures the chain through staking, and gives holders a voice in governance. ## What Is GHOST? GHOST is the native gas and privacy token of the Specter network. If you've used ETH on Ethereum or ATOM on Cosmos, you already understand the role: GHOST is what you spend to interact with the chain, what validators stake to secure it, and what the network rewards them with for honest work. But GHOST does something those tokens don't — it's purpose-built for privacy. Every time someone commits a secret, reveals a credential, verifies a zero-knowledge proof, or bridges assets cross-chain, GHOST is the token making it happen. ## Token Basics | Property | Value | |----------|-------| | **Name** | GHOST | | **Decimals** | 18 | | **Smallest Unit** | aghost | | **Conversion** | 1 GHOST = 10^18 aghost | | **Genesis Supply** | 1,000,000,000 (1 billion) | | **Hard Cap** | 1,500,000,000 (1.5 billion) | The smallest indivisible unit of GHOST is called an **aghost** (think of it like wei to ETH, or satoshi to BTC). When you see gas costs quoted in aghost, that's the protocol speaking in its most precise denomination — 1 GHOST equals one quintillion aghost. ## Supply Model GHOST follows a **capped emission model**. The genesis supply is 1 billion tokens, with an additional 500 million tokens available through declining block rewards over approximately 10 years. This means the absolute maximum supply of GHOST is **1.5 billion tokens** — a hard cap enforced at the protocol level. The emission rate starts at 12% in Year 1 and declines annually, reaching a 0.5% tail emission floor. After 10 years, approximately 1,387 million GHOST will have been minted. The emission schedule is designed to reward early validators and stakers while ensuring long-term supply predictability. ## Why "GHOST"? The name isn't just branding. In the Specter ecosystem, privacy is the product. Ghost Protocol is the primitive that makes secrets programmable. GHOST the token is the economic layer that sustains it — aligning incentives so that validators run the network, users get privacy, and the whole system stays healthy. Think of GHOST as the economic heartbeat of a privacy-first chain. Every transaction pulse, every proof verification, every governance vote — they all run on GHOST. ## Token Economics: Utility # Token Utility GHOST isn't a token you buy and forget about. It has a job — four jobs, actually. Every GHOST token serves the network through four distinct pillars of utility. ## 1. Gas: Powering Privacy Operations Every action on the Specter network costs gas, denominated in GHOST. This is the same model you know from Ethereum, but the operations are different — and that's what makes it interesting. Here's what costs gas on Specter: - **Standard transactions** — Sending GHOST or interacting with contracts, just like any EVM chain. - **ZK proof verification** — When someone reveals a secret or claims a credential, the chain verifies a Groth16 zero-knowledge proof on-chain. This costs roughly **~220,000 gas** — meaningful work that the network is compensated for. - **Commitment operations** — Every `commit` and `reveal` in Ghost Protocol involves writing to and reading from on-chain data structures (Merkle trees, nullifier sets). Each operation consumes gas proportional to its complexity. The key insight: privacy isn't free. It takes real computational work to verify proofs and maintain commitment trees. GHOST ensures that work is fairly compensated. ## 2. Staking: Securing the Network Specter runs on CometBFT consensus, which means validators stake GHOST to participate in block production. The more GHOST staked, the more secure the network. - **Delegate to validators** — You don't need to run a node. Delegate your GHOST to a trusted validator and earn a share of their rewards. - **Earn staking rewards** — Validators and their delegators receive GHOST rewards for producing blocks and participating in consensus. - **Secure the network** — Staked GHOST is the economic security backing every transaction. An attacker would need to control a significant portion of staked tokens to compromise the chain — and they'd lose their stake in the process. ## 3. Governance: Shaping the Protocol GHOST holders are not passive participants. They're stakeholders with real power over the protocol's future. - **Vote on proposals** — Protocol upgrades, parameter changes, and treasury allocations all go through on-chain governance. If you hold GHOST, you have a vote. - **Submit proposals** — See something that should change? GHOST holders can create governance proposals and rally the community to support them. - **Parameter changes** — Gas pricing, staking parameters, bridge configurations — the community decides. ## 4. IBC Fee Settlement Specter is a Cosmos SDK chain connected to the broader interchain ecosystem via IBC (Inter-Blockchain Communication). Every cross-chain packet relayed through IBC requires GHOST for relayer fee settlement. - **Relayer compensation** — Relayers who shuttle packets between Specter and other IBC-connected chains are compensated in GHOST. - **Cross-chain demand** — As IBC traffic grows, so does demand for GHOST to settle relay fees. - **Network effect** — More IBC connections mean more relayers, more packets, and more GHOST consumed in fee settlement. ## Four Pillars, One Token Most tokens do one thing. GHOST does four, and they reinforce each other: - Gas usage creates organic demand. - Staking reduces circulating supply and secures the chain. - Governance ensures the protocol evolves in the interest of its users. - IBC fee settlement ties GHOST demand to cross-chain activity. This isn't a token looking for utility — it's a token where every function is load-bearing. ## Token Economics: Supply & Distribution # Supply & Distribution ## Genesis Supply The Specter network launches with a genesis supply of **1,000,000,000 GHOST** (one billion tokens). Combined with a declining emission schedule capped at 500 million additional tokens, the protocol enforces a **hard cap of 1.5 billion GHOST** — no exceptions, no governance override. ## Genesis Allocation | Category | Tokens | % | Purpose | |---|---|---|---| | **Validator & Network Rewards** | 300,000,000 | 30% | Block rewards, staking incentives, validator bootstrapping | | **Ecosystem & Grants Fund** | 180,000,000 | 18% | Developer grants, ecosystem growth, partnerships | | **Core Team & Contributors** | 150,000,000 | 15% | Founding team, early contributors, ongoing development | | **Community & Airdrops** | 100,000,000 | 10% | Community distribution, airdrops, engagement rewards | | **Foundation Treasury** | 90,000,000 | 9% | DAO-controlled reserve for long-term protocol needs | | **Seed Investors** | 90,000,000 | 9% | Early backers who funded initial development | | **Strategic Round** | 50,000,000 | 5% | Strategic partners aligned with protocol goals | | **Relayer Incentives** | 40,000,000 | 4% | IBC relayer rewards and cross-chain infrastructure | ## Why This Distribution? **Validator & Network Rewards (30%)** — The largest allocation goes directly to securing the network. These tokens fund block rewards and staking incentives that attract and retain validators over the long term. A well-funded reward pool means the network doesn't need to rely on high inflation to incentivize participation. **Ecosystem & Grants Fund (18%)** — Building a privacy chain requires a thriving ecosystem of developers, tools, and applications. This fund supports developer grants, hackathon prizes, integration bounties, and partnership incentives that bring real utility to the network. **Core Team & Contributors (15%)** — The people building Specter need to be aligned with the protocol's long-term success. This allocation ensures the team is incentivized to keep building, improving, and maintaining the network for years to come. **Community & Airdrops (10%)** — Getting tokens into the hands of real users is critical. Community allocations cover airdrops, engagement rewards, and programs designed to bootstrap an active user base from day one. **Foundation Treasury (9%)** — A DAO-controlled reserve that acts as the protocol's long-term safety net. Spending from the Foundation Treasury requires governance approval, ensuring the community decides how these funds are deployed. **Seed Investors (9%)** — Early backers who believed in Specter's vision and funded the initial research, development, and infrastructure before the network existed. **Strategic Round (5%)** — Partners who bring more than capital — validator operators, infrastructure providers, and ecosystem players aligned with Specter's privacy-first mission. **Relayer Incentives (4%)** — A dedicated pool to fund IBC relayer operations and ensure reliable cross-chain connectivity from launch. Relayers are the backbone of interchain communication, and this allocation ensures they're properly compensated. ## Supply Model & Hard Cap GHOST follows a **capped emission model** with declining annual issuance: - **Genesis supply:** 1,000,000,000 GHOST - **Maximum emission:** 500,000,000 GHOST over ~10 years - **Hard cap:** 1,500,000,000 GHOST (protocol-enforced) - **Tail emission floor:** 0.5% annual rate The emission schedule is designed to front-load rewards when validator bootstrapping is most critical, then taper to a sustainable tail emission that maintains security incentives indefinitely. ## Emission Schedule | Year | Emission Rate | Tokens Emitted (M) | Cumulative Supply (M) | |------|--------------|--------------------|-----------------------| | 1 | 12.0% | 120.0 | 1,120.0 | | 2 | 8.0% | 89.6 | 1,209.6 | | 3 | 6.0% | 72.6 | 1,282.2 | | 4 | 4.5% | 57.7 | 1,339.9 | | 5 | 3.5% | 46.9 | 1,386.8 | | 6 | 2.5% | 34.7 | 1,421.5 | | 7 | 2.0% | 28.4 | 1,449.9 | | 8 | 1.5% | 21.7 | 1,471.7 | | 9 | 1.0% | 14.7 | 1,486.4 | | 10 | 1.0% | 14.9 | 1,501.2 | After Year 10, the emission rate settles at the **0.5% tail emission floor**, providing ongoing validator incentives without meaningful supply inflation. The hard cap ensures cumulative supply never exceeds 1.5 billion GHOST regardless of governance decisions. ## Vesting Overview All insider allocations (Core Team, Seed Investors, Strategic Round) follow a strict vesting discipline: - **Zero TGE unlock** — No insider tokens are liquid at genesis - **Daily linear vesting** — Tokens unlock continuously on a daily basis, preventing large cliff-driven sell events - **No cliff periods** — Vesting begins immediately at TGE with smooth daily unlocks This approach eliminates the concentrated selling pressure that plagues many token launches. Instead of large unlock events that crash markets, GHOST vesting produces a smooth, predictable daily trickle that the market can absorb organically. ## Design Philosophy The distribution reflects a balanced approach: enough allocated to network security (30% validator rewards + 4% relayer incentives) to ensure robust infrastructure from day one, enough to community and ecosystem (28% combined) to drive organic adoption, and enough to insiders (29% combined team + investors) to attract the talent and capital needed to build — with vesting that keeps everyone aligned long-term. ## Token Economics: Value Accrual # Value Accrual A token is only as valuable as the demand for what it does. Here's how GHOST captures value as the Specter network grows. ## The Fee Model Every transaction on Specter burns gas denominated in GHOST. This is the foundational demand driver — if you want to use the network, you need GHOST. But unlike a generic smart contract platform, Specter's privacy operations create uniquely consistent gas demand. ### Privacy Operations as a Value Driver Consider what happens when someone uses Ghost Protocol: 1. **Commit** — A user deposits a secret into a vault. This writes a commitment to the on-chain Merkle tree, consuming gas. 2. **Reveal** — A recipient claims the secret by submitting a ZK proof. The chain verifies that proof (~220,000 gas), checks the nullifier, and releases the value. 3. **Persistent credentials** — Every use of a Persistent Phantom Key requires proof verification. An API key used 100 times means 100 proof verifications, each consuming gas. Every single privacy operation requires GHOST. Not as an optional fee — as a fundamental requirement of the protocol. The more people use privacy features, the more GHOST the network consumes. ### Cross-Chain Bridge Fees Specter's Hyperlane bridges connect to Ethereum, Base, and Arbitrum, letting users bring in assets like USDC, WETH, and VIRTUAL. Every bridge operation — locking on the source chain, minting on Specter, burning and unlocking on exit — involves transactions that consume GHOST as gas. As bridge volume grows, so does gas demand. Cross-chain activity becomes a flywheel: more bridged assets mean more on-chain activity, which means more gas consumption, which means more demand for GHOST. ### IBC Fee Settlement Beyond EVM bridges, Specter's IBC connections to the Cosmos ecosystem create an additional demand channel. Every cross-chain packet relayed through IBC requires GHOST for fee settlement. Relayers are compensated in GHOST, and as inter-chain traffic grows — governance votes, token transfers, cross-chain queries — so does the base demand for the token. With a dedicated 40 million GHOST relayer incentive pool and a 50% fee recapture mechanism, IBC activity creates a self-reinforcing demand cycle that grows with the network's interchain connectivity. ## The Flywheel Here's the virtuous cycle: 1. **More users** bring more transactions. 2. **More transactions** consume more GHOST as gas. 3. **More gas demand** increases the utility value of GHOST. 4. **Higher GHOST value** attracts more validators and stakers. 5. **More validators** improve network security and performance. 6. **Better network** attracts more users. This isn't theoretical — it's the same flywheel that drives every successful L1, with one important difference: Specter's privacy operations are gas-intensive by nature. A single `reveal` operation costs roughly 10x a standard token transfer. Privacy is computationally expensive, and that expense flows directly to GHOST demand. ## Staking as a Supply Sink Staked GHOST is locked GHOST. As the validator set grows toward the Year 1 target of 150 validators (each requiring a minimum 100,000 GHOST self-delegation), and more holders delegate their tokens, circulating supply decreases. Combined with consistent gas demand from privacy operations, this creates natural supply-side pressure. ## Emission Offset The declining emission schedule (12% → 1% over 10 years) means that new supply issuance decreases each year while network activity — and therefore gas consumption — is designed to increase. Over time, the demand growth from usage should outpace the decreasing rate of new supply entering circulation. ## Value Capture Summary | Activity | GHOST Demand | |----------|-------------| | Standard transactions | Gas fees | | Commit operations | Gas for Merkle tree updates | | Reveal operations | Gas for ZK proof verification (~220k gas) | | Persistent credential usage | Gas per proof verification | | Cross-chain bridging | Gas for mint/burn operations | | IBC fee settlement | Relayer compensation in GHOST | | Staking | Tokens locked, reducing supply | | Governance participation | Tokens held for voting power | The takeaway: GHOST isn't a speculative asset bolted onto a protocol. It's the economic primitive that makes the privacy engine run. Every proof verified, every secret committed, every bridge crossed, every IBC packet relayed — they all flow back to GHOST. ## Token Economics: Staking & Incentives # Staking & Validator Economics Specter is a proof-of-stake network built on CometBFT consensus. That means the chain's security comes from validators who stake GHOST and risk losing it if they misbehave. Here's how the economics work. ## How CometBFT Consensus Works CometBFT (formerly Tendermint) is a Byzantine Fault Tolerant consensus engine. In plain terms: a set of validators take turns proposing blocks, and the rest vote on whether to accept them. As long as more than two-thirds of staked power is honest, the chain is secure. This gives Specter **instant finality** — once a block is committed, it's final. No waiting for confirmations, no risk of reorganizations. For a privacy chain, this matters: you don't want a reveal operation to be rolled back after the secret is already exposed. ## Validator Parameters | Parameter | Value | |---|---| | Minimum validators | 50 | | Target validators (Year 1) | 150 | | Minimum self-delegation | 100,000 GHOST | | Maximum commission rate | 20% | | Commission change delay | 72 hours | | Unbonding period | 21 days | | Downtime slashing | 0.01% of stake | | Double-sign slashing | 5% of stake | ## Validators Validators are the backbone of the network. They run full nodes, propose blocks, vote on consensus, and in return earn rewards. **What it takes to be a validator:** - Run a full Specter node with reliable uptime - Self-delegate a minimum of **100,000 GHOST** - Maintain infrastructure (compute, bandwidth, monitoring) - Stay online and participate honestly in consensus **What validators earn:** - **Block rewards** — New GHOST distributed to validators who propose and sign blocks - **Transaction fees** — A portion of gas fees from every transaction in the blocks they produce - **Commission** — A percentage (up to 20%) of rewards from tokens delegated to them by other holders ## Delegation You don't need to run a validator to earn staking rewards. Any GHOST holder can **delegate** their tokens to a validator of their choice. When you delegate: - Your GHOST is staked on your behalf by the validator - You earn a share of the validator's rewards, minus their commission rate - You retain ownership of your tokens — they're staked, not transferred - You can undelegate at any time (subject to a 21-day unbonding period) Delegation is how the network scales its security beyond just the validator operators. The more GHOST delegated across the validator set, the more expensive it becomes to attack the chain. ## Fee Distribution When a block is produced, the transaction fees collected in that block are distributed among validators and their delegators: 1. **Proposer bonus** — The validator who proposed the block receives a small bonus 2. **Validator commission** — Each validator takes their stated commission percentage 3. **Delegator share** — The remaining rewards are distributed proportionally to all delegators based on their stake This creates a clean incentive: validators compete on uptime, reliability, and commission rates to attract delegators. Delegators pick validators who perform well and charge fair rates. ## Slashing Honest behavior isn't just incentivized — dishonest behavior is penalized. CometBFT includes slashing conditions: - **Double signing** — If a validator signs two different blocks at the same height, **5% of their stake** (and their delegators' stake) is slashed. This is the most severe penalty, and the validator is permanently tombstoned. - **Downtime** — If a validator is offline for an extended period and misses too many blocks, they are temporarily jailed and face a **0.01% slash**. They can unjail after correcting the issue. Slashing is the stick that complements the carrot of rewards. It ensures validators have skin in the game — literally, their own tokens are at risk. ## Relayer Incentive Design IBC relayers are critical infrastructure — they shuttle packets between Specter and other Cosmos chains. Without reliable relayers, cross-chain communication breaks down. The protocol dedicates a **40 million GHOST** incentive pool to ensure relayer operations are economically sustainable. | Parameter | Value | |---|---| | Relayer incentive pool | 40,000,000 GHOST | | Distribution model | Per-packet rewards | | Minimum relayer bond | 10,000 GHOST | | Fee recapture rate | 50% | | Minimum success rate | 95% | **How it works:** - Relayers register by bonding a minimum of **10,000 GHOST** - Rewards are distributed on a **per-packet basis** — the more packets a relayer successfully delivers, the more they earn - Relayers must maintain a **95% minimum success rate** to remain eligible for incentive rewards - **50% of IBC relay fees** are recaptured and recycled into the incentive pool, extending the program's lifespan - The bonding requirement ensures relayers have skin in the game and can be penalized for persistent failures ## Why This Matters for Privacy A privacy chain has higher security requirements than a general-purpose chain. If consensus is compromised, an attacker could potentially censor reveal operations, reorder commitments, or disrupt the Merkle tree. CometBFT's instant finality and strong slashing conditions make these attacks economically irrational. Validators are paid well to be honest, and they pay dearly if they aren't. That's the security model that lets Ghost Protocol operate with confidence. ## Network Incentives # Network Incentives A network is only as strong as the people who show up. Specter is designed so that every type of participant — whether you're running a validator, staking tokens, using privacy features, or building applications — has a clear, rational reason to be here. ## For Validators: Earn While You Secure Validators are the infrastructure layer. You run a node, propose blocks, participate in consensus, and the network pays you for it. **What you get:** - Block rewards in GHOST - Transaction fee revenue from every block you produce - Commission from delegators who trust you with their stake **Why it's rational:** As long as the cost of running your validator is less than your rewards (and it should be, by a healthy margin), validating is profitable. The more the network grows, the more transactions flow through your blocks, the more you earn. ## For Stakers: Grow Your Holdings Not everyone wants to run infrastructure. If you hold GHOST, you can delegate to a validator and earn passive rewards. **What you get:** - A proportional share of your validator's rewards - Exposure to GHOST without active management - A voice in governance through your staked tokens **Why it's rational:** Holding GHOST without staking means your share of the network is diluted by inflation. Staking keeps you whole and then some. It's the difference between holding cash and holding cash that earns interest. ## For Users: Privacy That Works Users come to Specter for one thing above all else: privacy that actually works, on a chain that's fast and affordable. **What you get:** - True privacy through zero-knowledge proofs — not obscurity, not mixing, but mathematical certainty - Fast finality (CometBFT means your transaction is final the moment it's in a block) - Low gas fees compared to privacy operations on Ethereum L1 - Cross-chain access to assets you already own (USDC, WETH, and more via Hyperlane bridges) **Why it's rational:** If you value financial privacy, Specter is purpose-built for it. You're not jury-rigging privacy onto a transparent chain — you're using a chain where privacy is the point. ## For Builders: The Privacy Toolbox Developers get something rare: a full EVM environment with first-class privacy primitives. **What you get:** - Full Solidity/EVM compatibility — deploy your existing contracts and tools - Privacy primitives as building blocks — CommitRevealVault, PersistentKeyVault, stealth addresses, and more - A permissionless policy system — implement `IRevealPolicy` and deploy custom reveal conditions - A growing user base that specifically wants privacy features **Why it's rational:** Building privacy features on a transparent chain is hard. Building them on Specter means the hard parts (ZK circuits, commitment schemes, nullifier management) are already done. You write policies and application logic. The protocol handles the cryptography. ## Game Theory: Honest Behavior Wins The incentive design isn't accidental. It follows a simple game-theoretic principle: **honest participation should always be more profitable than cheating.** - **Validators** earn more by staying online and signing correctly than by attempting double-signs (which get slashed). - **Stakers** earn more by delegating to reliable validators than by chasing short-term gains from unreliable ones. - **Users** benefit from the network effects of a growing ecosystem — more users means more liquidity, more applications, and stronger privacy guarantees (larger anonymity sets). - **Builders** benefit from composability — each new privacy primitive or policy makes every other application on the chain more capable. The result is a network where doing the right thing is also the profitable thing. That's not idealism — it's mechanism design. ## Use Cases # Applications & Use Cases Ghost Protocol is a general-purpose privacy primitive. That's an abstract statement, so let's make it concrete. Here's what people actually do with it — and what you could build next. ## 1. Private Value Transfer (Vanish/Summon) **The story:** You want to pay for coffee without broadcasting your salary to the world. On a transparent blockchain, every transaction is a public announcement — your balance, your spending habits, your counterparties. Ghost Protocol's Vanish/Summon flow changes that. **How it works:** A sender *vanishes* tokens into the **CommitRevealVault**, creating a cryptographic commitment. The recipient receives a secret (off-chain), then *summons* the tokens by proving knowledge of that secret via a zero-knowledge proof. The chain verifies the proof, confirms the nullifier hasn't been used, and releases the funds. **What's private:** The link between sender and recipient is broken. An observer sees a deposit and a withdrawal, but can't connect the two. The sender's identity, the recipient's identity, and the relationship between them are shielded by the ZK proof. ## 2. Secret Sharing (Revels / Open Ghost) **The story:** You're running a sealed-bid auction. Bidders need to commit their bids without seeing each other's numbers, and the auctioneer needs to reveal them all at once after the deadline. Traditional smart contracts can't do this — everything is public the moment it hits the chain. **How it works:** Each bidder commits their bid to the **OpenGhostVault**, which stores the commitment on-chain but keeps the underlying data secret. When the auction closes, the organizer triggers the reveal phase. Bidders (or the organizer, depending on the configuration) publish the reveal keys, and the ZK proof verification confirms each bid matches its original commitment. **Other applications:** - One-time passwords - Confidential document sharing - Sealed governance votes - Verifiable random number generation ## 3. Persistent Credentials (Persistent Phantom Keys v4.5) **The story:** You're running a SaaS product and you want to issue API keys that users can verify on-chain without revealing the key itself. Or you're managing a team and need to distribute access credentials that can be used repeatedly but revoked instantly. **How it works:** The **PersistentKeyVault** stores a commitment to a secret, and the holder can prove knowledge of that secret unlimited times without the nullifier being consumed. Each verification is fresh — the proof is valid, the commitment is checked, but the credential isn't spent. When access should end, the issuer revokes the commitment. **Applications:** - API keys and software licenses - Subscription access tokens - Team credentials with role-based access - AI chat session authentication - Membership verification ## 4. Programmable Bearer Instruments (Programmable Phantom Keys v4.4) **The story:** You want to give someone a birthday gift of 100 GHOST, but they can't open it until their birthday. Or you're a corporate treasury that needs to ensure funds can only be sent to approved destinations. Or you need three out of five board members to approve a withdrawal. **How it works:** Programmable Phantom Keys attach **policies** to credentials — smart contracts that must approve the reveal before it succeeds. The vault checks the policy at reveal time, and if the policy says no, the reveal fails. **Built-in policies:** | Policy | What It Does | |--------|-------------| | **TimelockExpiry** | Credential can only be claimed after a specific timestamp | | **DestinationRestriction** | Funds can only go to pre-approved addresses | | **ThresholdWitness** | Requires M-of-N approved signatures before reveal | These are composable. A single credential can have multiple policies: "claimable after January 1st, only to this address, with 2-of-3 board approval." The policy system is permissionless — anyone can implement the `IRevealPolicy` interface and deploy custom conditions. ## 5. Physical Bearer Instruments **The story:** You hand someone a physical card. They tap it on their phone. Tokens appear in their wallet. No QR codes, no links, no apps to download — just tap and claim. **How it works:** Specter supports NFC cards built on **NTAG 424 DNA** chips. Each card contains a cryptographic secret tied to an on-chain commitment. When tapped, the card generates a one-time authentication code that the mobile app uses to construct a ZK proof and claim the funds. **Applications:** - Gift cards loaded with GHOST or bridged tokens - Event tickets with embedded value - Loyalty rewards on physical cards - Promotional giveaways at conferences The physical layer makes privacy tangible. You can literally hand someone privacy. ## 6. Stealth Addresses **The story:** You want to receive payments without giving the sender (or anyone watching) your actual wallet address. Every payment goes to a unique, one-time address that only you can control. **How it works:** The **GhostStealthAnnouncer** contract implements ERC-5564 stealth addresses. A sender generates a one-time address using your stealth meta-address (a public key you share openly). They send funds to that one-time address. You — and only you — can derive the private key to that address and claim the funds. **Why it matters:** Even with private transfers, receiving at the same address creates a pattern. Stealth addresses eliminate that pattern entirely. Each payment creates a fresh address with no visible link to the recipient. ## 7. Dead Man's Switch **The story:** You hold credentials or assets that need to pass to a backup wallet if something happens to you. You check in periodically — if you stop checking in, the backup can claim everything. **How it works:** The **DMSRegistry** (Dead Man's Switch Registry) lets you register a heartbeat schedule and a backup address. As long as you ping the contract on schedule, nothing happens. If you miss your window, the backup address gains the ability to claim your registered credentials and assets. **Applications:** - Estate planning for digital assets - Business continuity for key personnel - Backup access for teams - Disaster recovery for credentials ## 8. Enterprise Applications **The story:** A corporate treasury needs to move funds privately, but with guardrails — approved destinations only, multi-sig approval, compliance-friendly audit trails. **How it works:** By combining Ghost Protocol's privacy with programmable policies, enterprises get the best of both worlds: - **DestinationRestriction** policies ensure funds only flow to whitelisted addresses - **ThresholdWitness** policies require multi-sig approval from authorized signers - **TimelockExpiry** policies enforce holding periods or vesting schedules - The commitment/reveal pattern provides privacy while maintaining internal auditability (the organization holds the secrets and can audit its own activity) **Applications:** - Corporate treasury management with destination controls - Compliant private transfers between known counterparties - Institutional multi-sig with privacy - Payroll distribution without public salary disclosure ## The Common Thread Every use case above is built on the same primitive: **commit a secret, attach a policy, prove knowledge to reveal**. Ghost Protocol doesn't prescribe what you build — it gives you the cryptographic building blocks and gets out of the way. The contracts that power these use cases — `CommitRevealVault`, `OpenGhostVault`, `PersistentKeyVault`, `GhostStealthAnnouncer`, `DMSRegistry` — are deployed and available. The policies — `TimelockExpiry`, `DestinationRestriction`, `ThresholdWitness` — are composable and extensible. And the policy interface (`IRevealPolicy`) is open for anyone to implement. What will you build? ## Ecosystem # Ecosystem Specter isn't just a protocol spec — it's a living network with real tools you can use today. Here's what's available and how the pieces fit together. ## Wallets & Tools **MetaMask** — Specter is a full EVM chain, which means MetaMask works out of the box. Add the Specter network, and you can send transactions, interact with contracts, and manage your GHOST tokens through the wallet you already know. **WalletConnect** — Any WalletConnect-compatible wallet can connect to Specter dApps. This opens the door to mobile wallets, hardware wallets, and the broader wallet ecosystem. **Specter Block Explorer (specterscan.io)** — A full-featured block explorer for the Specter network. View transactions, inspect contracts, track token transfers, and explore the chain's activity in real time. ## Cross-Chain Bridges Privacy is more useful when you can bring your existing assets along. Specter's cross-chain bridges, powered by **Hyperlane**, connect to major networks and let you move assets seamlessly. ### Supported Source Chains | Chain | Status | |-------|--------| | Ethereum | Live | | Base | Live | | Arbitrum | Live | ### Bridged Tokens When you bridge an asset to Specter, it's represented as a wrapped "ghost" variant: | Source Token | Specter Token | Description | |-------------|---------------|-------------| | USDC | **gUSDC** | Bridged USD Coin | | WETH | **gWETH** | Bridged Wrapped Ether | | VIRTUAL | **gVIRTUAL** | Bridged VIRTUAL token | The bridging process is straightforward: lock your tokens on the source chain, receive the ghost-wrapped equivalent on Specter, use them with full privacy features, and bridge back when you're ready. The wrapped tokens are fully backed 1:1 by the locked originals. ## For Developers If you're building on Specter, you're building on familiar ground with powerful new tools. ### Full EVM Compatibility Specter runs a complete EVM execution environment. Your Solidity contracts, your Hardhat scripts, your Foundry tests — they all work. If it deploys on Ethereum, it deploys on Specter. No new language to learn, no new toolchain to master. ### Privacy Primitives as Building Blocks The Ghost Protocol contracts are deployed and available for any developer to compose with: - **CommitRevealVault** — Single-use private transfers - **OpenGhostVault** — Secret sharing and sealed data - **PersistentKeyVault** — Reusable credentials - **GhostStealthAnnouncer** — ERC-5564 stealth addresses - **DMSRegistry** — Dead man's switch functionality These aren't locked behind SDKs or permissioned APIs. They're smart contracts on-chain, callable by any other contract or EOA. ### Permissionless Policy System This is where it gets interesting. The policy system lets anyone extend Ghost Protocol's behavior by implementing the `IRevealPolicy` interface. Want to create a reveal condition that checks an oracle price feed? Deploy a contract that implements `IRevealPolicy`, point a commitment to it, and the vault will call your policy at reveal time. If your policy returns true, the reveal succeeds. If not, it doesn't. Built-in policies like `TimelockExpiry`, `DestinationRestriction`, and `ThresholdWitness` cover common cases. But the interface is open — you can deploy custom policies for any condition your application needs. ### Getting Started 1. Add the Specter network to your development environment 2. Deploy contracts using your existing EVM tooling 3. Interact with Ghost Protocol contracts for privacy features 4. Implement `IRevealPolicy` for custom reveal conditions 5. Test on the live testnet with faucet GHOST The barrier to entry is intentionally low. If you've built on Ethereum, you can build on Specter — and now your applications can be private. ## Governance # Governance Your voice matters. Specter is governed by its token holders — not a boardroom, not a foundation, not a multisig with five keys. If you hold GHOST, you have a direct say in how the protocol evolves. ## How It Works Specter uses the Cosmos SDK governance module, a battle-tested system that's governed billions of dollars across the Cosmos ecosystem. The process is straightforward: ### The Governance Lifecycle [Diagram: flowchart LR] ### Governance Parameters | Parameter | Value | |---|---| | Proposal deposit | 10,000 GHOST | | Voting period | 7 days | | Quorum | 33.4% of staked GHOST | | Pass threshold | 50% + 1 of votes | | Veto threshold | 33.4% of votes | | Execution timelock | 48 hours | **1. Proposal Created** — Any GHOST holder can submit a governance proposal by depositing **10,000 GHOST**. This could be a protocol upgrade, a parameter change, a treasury spend, or a text proposal signaling community intent. **2. Deposit Period** — After submission, the proposal enters a deposit period. Other GHOST holders can add deposits to show support. Think of it as a spam filter — proposals need enough backing to prove they're serious. **3. Minimum Deposit** — If the deposit threshold is met, the proposal advances to voting. If not, the proposal is rejected and deposits may be returned or burned depending on the outcome. **4. Voting Period** — All staked GHOST holders (validators and delegators) can vote during a **7-day voting window**. Four options: | Vote | Meaning | |------|---------| | **Yes** | Support the proposal | | **No** | Oppose the proposal | | **No with Veto** | Strongly oppose — if **33.4%** of votes are veto, deposits are burned | | **Abstain** | Counted toward quorum but not toward the yes/no outcome | **5. Quorum + Majority** — For a proposal to pass, **33.4% of staked GHOST** must vote (quorum), and more than **50%** of those votes must be "Yes." **6. Timelock** — Passed proposals enter a **48-hour timelock** before execution. This gives validators, delegators, and the community time to prepare for changes and provides a window to detect issues before they take effect. **7. Execution** — After the timelock, proposals are executed automatically by the chain. For parameter changes, the new values take effect immediately. For upgrades, the chain schedules the upgrade at a specified block height. ## What Can Be Governed? Almost everything that matters: - **Protocol upgrades** — New features, bug fixes, consensus changes - **Parameter changes** — Gas pricing, staking parameters, governance thresholds - **Treasury allocation** — Funding grants, ecosystem initiatives, partnerships - **Bridge configuration** — Adding new bridge routes, adjusting bridge parameters - **Policy registry** — Approving or flagging reveal policies ## Foundation & Emergency Multisig While governance is the primary decision-making mechanism, the protocol includes a **5-of-9 Foundation multisig** for security-critical situations only. **Scope:** The multisig can act only on security-critical matters — pausing bridge contracts during an exploit, emergency parameter changes to prevent fund loss, or coordinating responses to consensus failures. It cannot spend treasury funds, change tokenomics, or override governance decisions. **Dissolution:** The Foundation multisig is designed to be **dissolved at Month 24** after mainnet launch. By that point, the validator set and governance participation should be mature enough to handle emergency responses through expedited governance proposals. The dissolution itself is subject to a governance vote. **Transparency:** All multisig actions are logged on-chain, and every action must be accompanied by a public post-mortem within 7 days explaining what happened, why the multisig acted, and what preventive measures are being implemented. ## Foundation Treasury The Foundation Treasury holds **90 million GHOST** (9% of genesis supply) as a DAO-controlled reserve for long-term protocol needs. - **Governance-controlled** — Every spend from the Foundation Treasury requires a governance proposal that passes the standard voting process - **Quarterly reporting** — The Foundation publishes quarterly reports detailing treasury balance, spending, and allocation decisions - **Long-term reserve** — Designed for strategic needs that emerge over time: security audits, legal defense, emergency funding, and opportunities that don't fit neatly into the Ecosystem & Grants Fund The Foundation Treasury is distinct from the Ecosystem & Grants Fund (18% of genesis). The Grants Fund is for active ecosystem building — developer grants, hackathons, partnerships. The Treasury is the protocol's rainy-day fund, deployed sparingly and only with community approval. ## Delegation and Voting If you've delegated your GHOST to a validator, your validator votes on your behalf by default. But you can always override — casting your own vote takes precedence over your validator's vote for your portion of the stake. This means you don't have to actively monitor every proposal if you trust your validator's judgment. But when something matters to you, your vote counts. ## Why On-Chain Governance? Off-chain governance (forum posts, multisig votes, social consensus) works for some projects. But it concentrates power in whoever controls the communication channels and the keys. On-chain governance is transparent, verifiable, and permissionless: - Anyone can propose - Anyone who stakes can vote - Votes are recorded on-chain - Execution is automatic (after timelock) No gatekeepers. No backroom deals. Just token holders making decisions about their protocol. ## Roadmap # Roadmap Building a privacy-first blockchain is a marathon, not a sprint. Here's where we are, where we're going, and what each phase means for the network. ## Phase 1: Testnet (Current) **Status: Live** The foundation is in place and running. This phase is about proving the core technology works, gathering feedback, and hardening the protocol before real value is at stake. **What's live today:** - Core Specter chain running on CometBFT consensus - Ghost Protocol v4.5 — full commit/reveal system with persistent credentials - Programmable Phantom Keys with policy enforcement (TimelockExpiry, DestinationRestriction, ThresholdWitness) - Cross-chain Hyperlane bridges to Ethereum, Base, and Arbitrum - NFC card system for physical bearer instruments - Block explorer at specterscan.io - Testnet faucet for developer and user onboarding - MetaMask and WalletConnect support This is a real, functional network — not a demo. Developers are deploying contracts, users are testing privacy flows, and the protocol is being stress-tested in the wild. ## Phase 2: Mainnet **Status: In Development** The transition from testnet to mainnet is the most critical milestone. It's when GHOST tokens carry real value and the security model has to be bulletproof. **What this phase includes:** - **Production launch** — Mainnet genesis with real economic stakes - **Expanded validator set** — Onboarding additional validators for decentralization and resilience - **Security audits** — Comprehensive third-party audits of the ZK circuits, smart contracts, and consensus layer - **Mainnet bridges** — Production-grade Hyperlane bridges with battle-tested security - **Economic activation** — Staking rewards, fee distribution, and governance go live with real value ## Phase 3: Ecosystem Growth **Status: Planned** A chain is only as valuable as what's built on it. This phase is about turning Specter from a protocol into a platform. **What this phase includes:** - **Developer grants** — Funded programs to incentivize third-party development on Specter - **Third-party applications** — Privacy-first dApps built by independent teams using Ghost Protocol primitives - **Additional bridge destinations** — Expanding cross-chain connectivity beyond Ethereum, Base, and Arbitrum - **Mobile app public launch** — Polished mobile experience for NFC card interactions and privacy transactions ## Phase 4: Advanced Features **Status: Research & Planning** The long-term vision for Specter goes beyond what's possible today. This phase pushes the boundaries of what a privacy chain can do. **What this phase includes:** - **SP1 zkVM integration** — Succinct's SP1 prover for more expressive and efficient zero-knowledge computations, enabling privacy features that go beyond Groth16 circuits - **Additional policy types** — New built-in policies for common use cases (rate limiting, geographic restrictions, time-windowed access, and more) - **IBC interoperability** — Native Inter-Blockchain Communication protocol support, connecting Specter to the broader Cosmos ecosystem - **Full decentralization** — Permissionless validator onboarding, community-driven governance, and progressive removal of any centralized operational dependencies ## The Principle Each phase builds on the last. We don't move forward until the current phase is solid. Privacy technology doesn't get a second chance at trust — if the foundation isn't right, nothing built on top matters. The goal isn't just to launch a mainnet. It's to build a network that people trust with their most sensitive data, and that earns that trust through engineering rigor, transparent governance, and a community that holds the protocol accountable. ## Related Work # Related Work Specter doesn't exist in a vacuum. Privacy in blockchain has a rich history of research, experimentation, and hard-won lessons. Here's how the prior art compares — and where Specter fits in. ## Privacy Coins: Zcash and Monero **What they do well:** Zcash pioneered zero-knowledge proofs in blockchain with zk-SNARKs. Monero built robust transaction privacy with ring signatures and stealth addresses. Both deliver strong financial privacy for their native currencies. **Where they stop:** Privacy coins are exactly that — coins. They provide private transfers of their own native token, but that's the ceiling. No smart contracts. No custom logic. No programmable policies. If you want to build a privacy-preserving application, you're on your own. **How Specter differs:** Specter takes the same cryptographic foundations (zero-knowledge proofs, commitments, nullifiers) and makes them general-purpose. Ghost Protocol isn't limited to token transfers — it handles arbitrary secrets, credentials, bearer instruments, and any data you can commit to. Full EVM compatibility means you can build applications on top of the privacy layer, not just move coins through it. ## ZK Rollups: Aztec and zkSync **What they do well:** Aztec Network brings privacy to Ethereum through a ZK rollup architecture, with encrypted state and private function execution. zkSync provides ZK-powered scaling with optional privacy features. Both leverage Ethereum's security while adding privacy capabilities. **Where they stop:** ZK rollups are fundamentally anchored to a transparent L1. Their privacy is bounded by the rollup's design, and composability with the broader Ethereum ecosystem often requires stepping outside the privacy boundary. They also inherit Ethereum's congestion, fee volatility, and governance decisions. **How Specter differs:** Specter is a sovereign L1 with protocol-level privacy. Privacy isn't a feature bolted onto someone else's chain — it's the chain's reason for existing. This means the consensus layer, the fee model, the governance, and the execution environment are all optimized for privacy workloads. No dependency on Ethereum's roadmap, no L1 bottleneck, no transparent base layer that can leak metadata. ## Mixers: Tornado Cash and Successors **What they do well:** Tornado Cash proved that on-chain privacy was possible on Ethereum using a deposit/withdraw mixer pattern with zero-knowledge proofs. It demonstrated real demand for transaction privacy. **Where they stop:** Mixers are single-purpose tools. You deposit tokens, wait, withdraw to a different address — that's it. No extensibility, no policies, no programmable conditions. Tornado Cash was also sanctioned by OFAC and its developers faced legal action, effectively killing the project and its ecosystem. **How Specter differs:** Ghost Protocol shares the cryptographic DNA (commitments, nullifiers, ZK proofs) but goes far beyond mixing. The commit/reveal pattern is a general-purpose primitive, not a fixed-function mixer. Programmable policies mean you can attach conditions like timelocks, destination restrictions, and multi-sig approval. Persistent credentials mean secrets can be reused. And because Specter is a sovereign chain with its own governance, the protocol's future is determined by its community, not by the regulatory posture of another chain's ecosystem. ## Cosmos Privacy Chains: Penumbra and Namada **What they do well:** Penumbra and Namada are privacy-focused chains built within the Cosmos ecosystem. They share Specter's architectural intuition — that privacy deserves its own chain with purpose-built consensus and native privacy primitives. Penumbra focuses on private DEX trading and staking. Namada provides multi-asset shielded transfers with a unified shielded set. **Where they stop:** Neither offers full EVM compatibility, which limits the developer ecosystem and the range of applications that can be built. Their privacy models are designed primarily for financial transactions rather than general-purpose secret management. **How Specter differs:** Specter combines the sovereign-chain approach with full EVM compatibility, giving developers the familiar Solidity toolchain alongside native privacy primitives. The programmable policy system and physical bearer instrument layer (NFC cards) expand the application scope well beyond financial transactions. And Ghost Protocol's persistent credentials and secret-sharing capabilities address use cases that pure financial privacy chains don't touch. ## Academic Foundations Specter builds on well-established cryptographic and systems research: - **Groth16** (Groth, 2016) — The zero-knowledge proof system used for reveal verification. Groth16 provides succinct proofs with constant-size proof data and efficient on-chain verification, making it practical for blockchain applications. - **Poseidon Hash** (Grassi et al., 2021) — The hash function used for Merkle tree commitments. Poseidon is designed specifically for ZK-circuit efficiency, dramatically reducing the number of constraints compared to traditional hash functions like SHA-256 or Keccak. - **CometBFT** (Buchman, 2016) — The Byzantine Fault Tolerant consensus engine (originally Tendermint) that provides instant finality. Critical for a privacy chain where transaction rollbacks could expose secrets. - **ERC-5564 Stealth Addresses** — The standard for stealth address generation and announcement, implemented in Specter via the GhostStealthAnnouncer contract for unlinkable payment reception. ## Where Specter Sits The privacy blockchain landscape has explored many approaches: private coins, private rollups, mixers, and privacy-first Cosmos chains. Each solved a piece of the puzzle. Specter's contribution is combining these lessons into a single coherent system: a sovereign L1 with EVM compatibility, general-purpose ZK privacy primitives, programmable policies, physical bearer instruments, and cross-chain bridges. Not a private coin, not a mixer, not a rollup — a privacy-first platform where the primitive is programmable and the applications are unbounded. ## Appendix: Cryptographic Proofs # Appendix A: Cryptographic Proofs This appendix provides the full cryptographic specifications underlying the Specter Protocol's Ghost Protocol primitive. It covers hash constructions, field arithmetic, proof systems, circuit definitions, nullifier derivation, and the quantum-safe commitment layer. ## Poseidon Hash Family Specter uses the Poseidon algebraic hash function family, chosen for its efficiency inside arithmetic circuits over prime fields. Three width variants are employed, each matched to a specific data shape. ### Poseidon2 (2 inputs) Used wherever exactly two field elements must be compressed: - **Merkle tree nodes** — hashing left and right children at each level. - **Nullifier derivation** — combining secrets with commitment data (see [Nullifier Derivation](#nullifier-derivation)). - **Access tags** — binding a nullifier secret to a session nonce. - **Token ID computation** — domain-separated hashing of token identifiers. ### Poseidon4 (4 inputs) Used for data commitments and Open Ghost commitments: ``` commitment = Poseidon4(secret, nullifierSecret, dataHash, blinding) ``` This construction binds the owner's secret, an independent nullifier secret, the hash of the protected data, and a random blinding factor into a single hiding, binding commitment. ### Poseidon7 (7 inputs) Used for token commitments in the Ghost Protocol: ``` commitment = Poseidon7(secret, nullifierSecret, tokenId, amount, blinding, policyId, policyParamsHash) ``` This extended preimage binds the full token metadata — denomination, quantity, and policy parameters — into the commitment, enabling the redemption circuit to enforce amount conservation and policy compliance without revealing any field. ### On-Chain Deployment Only **PoseidonT3** (the 2-input variant with a width-3 internal state) is deployed on-chain, costing approximately **30,000 gas** per invocation. The larger variants (Poseidon4, Poseidon7) are computed exclusively off-chain during witness generation; the circuit proves correctness of those evaluations without replaying them in the EVM. ## Field Arithmetic ### BN254 Scalar Field All circuit arithmetic operates over the BN254 scalar field: ``` p = 21888242871839275222246405745257275088548364400416034343698204186575808495617 ``` This is an approximately 254-bit prime. Every value entering or leaving a Groth16 circuit — public inputs, private witnesses, hash outputs — must be an element of F_p. ### keccak256 Reduction When keccak256 digests (256 bits) are used as circuit inputs (for example, the quantum commitment layer), the raw output is reduced modulo p: ``` circuitValue = keccak256(preimage) mod p ``` Because p is close to 2^254, the resulting distribution over F_p has negligible bias (< 2^{-128}). ## Groth16 Proof System Specter uses the **Groth16** zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) instantiated over the BN254 curve. | Property | Value | |---|---| | Proof size | 256 bytes (constant) | | On-chain verification gas | ~220,000 | | Pairing curve | BN254 (alt_bn128) | | Pairing precompile | EIP-197 | | Trusted setup | Per-circuit ceremony | Verification uses the EIP-197 precompiled contract for optimal ate pairing checks, available on Ethereum and EVM-compatible chains including Specter's own execution layer. ## Circuit Specifications ### GhostRedemption Circuit The redemption circuit proves that a party can legitimately withdraw tokens from the Ghost Protocol without revealing the source commitment, the full amount, or any identifying information. **Public inputs (8 field elements):** | Index | Name | Description | |---|---|---| | 0 | `root` | Merkle tree root at the time of proof generation | | 1 | `nullifier` | Unique nullifier preventing double-spend | | 2 | `withdrawAmount` | Amount being withdrawn | | 3 | `recipient` | Address receiving the withdrawal | | 4 | `changeCommitment` | New commitment for any remaining balance | | 5 | `tokenId` | Identifier of the token being redeemed | | 6 | `policyId` | Reveal policy contract address (as field element) | | 7 | `policyParamsHash` | Hash of the policy parameters bound at commit time | **Constraints enforced (via quadratic R1CS):** 1. **Knowledge of preimage** — The prover knows `(secret, nullifierSecret, tokenId, amount, blinding, policyId, policyParamsHash)` such that `Poseidon7(...)` equals the committed leaf. 2. **Merkle membership** — The commitment is a leaf of the Merkle tree with the declared `root`, verified through a 20-level authentication path. 3. **Nullifier correctness** — The declared `nullifier` equals the deterministic derivation from the commitment's nullifier secret and leaf index (see [Nullifier Derivation](#nullifier-derivation)). 4. **Amount conservation** — `withdrawAmount + changeAmount == amount`, where `changeAmount` is the balance locked into `changeCommitment`. 5. **Change commitment validity** — `changeCommitment` is a well-formed Poseidon7 commitment over the change amount and fresh blinding, bound to the same token ID and policy. 6. **Policy binding** — The `policyId` and `policyParamsHash` in the proof match those embedded in the original commitment, ensuring the reveal policy cannot be altered after deposit. ### Access Proof Circuit The access proof circuit enables a commitment holder to prove they control a specific data commitment and to derive a session-bound access tag, without revealing any secret material. **Public inputs (4 field elements):** | Index | Name | Description | |---|---|---| | 0 | `root` | Merkle tree root | | 1 | `dataHash` | Hash of the data being accessed | | 2 | `sessionNonce` | Unique nonce for this access session | | 3 | `accessTag` | Derived tag proving control | **Constraints enforced:** 1. **Knowledge of Poseidon4 preimage** — The prover knows `(secret, nullifierSecret, dataHash, blinding)` such that `Poseidon4(...)` equals a committed leaf. 2. **Merkle membership** — The commitment exists in the tree under the declared `root`, verified through 20 levels. 3. **Access tag correctness** — `accessTag = Poseidon2(nullifierSecret, sessionNonce)`. This binds the proof to a specific session while revealing nothing about the underlying secret or nullifier secret. ## Nullifier Derivation Nullifiers prevent double-spending. Specter derives them deterministically from the commitment's nullifier secret and its position in the Merkle tree: ``` nullifier = Poseidon2(Poseidon2(nullifierSecret, commitment), leafIndex) ``` **Properties:** - **Deterministic** — The same commitment at the same leaf index always produces the same nullifier, so the on-chain NullifierRegistry can detect replays. - **Unlinkable** — Without knowledge of `nullifierSecret`, an observer cannot link a nullifier to its source commitment. - **Leaf-index binding** — Including `leafIndex` prevents nullifier collisions if the same commitment value appears at multiple tree positions. ## Quantum-Safe Commitment Layer Specter includes a commit-reveal scheme that provides defense-in-depth against future quantum adversaries. ### Commit Phase At deposit time, the user generates a random `quantumSecret` and publishes: ``` quantumCommitment = keccak256(quantumSecret) ``` This value is stored alongside the Poseidon commitment in the on-chain vault. ### Reveal Phase At redemption time, the user reveals `quantumSecret` in the clear. The contract verifies: ``` keccak256(quantumSecret) == storedQuantumCommitment ``` ### Security Argument The keccak256 hash function has 256-bit output. Under Grover's algorithm, a quantum adversary requires approximately **2^128** oracle calls to find a preimage — a workload that remains computationally infeasible even with fault-tolerant quantum hardware. This layer ensures that even if the BN254 discrete-log problem is broken by a future quantum computer, an attacker still cannot forge a valid reveal without the original quantum secret. ## Appendix: Consensus Specification # Appendix B: Consensus Specification Specter's consensus layer is built on **CometBFT** (formerly Tendermint Core), integrated through the **Cosmos SDK v0.53+** application framework. This appendix details the consensus parameters, fault-tolerance guarantees, and finality properties of the network. ## Consensus Engine | Parameter | Value | |---|---| | Engine | CometBFT | | SDK version | Cosmos SDK v0.53+ | | Chain ID | `5446` | | Target block time | ~5 seconds | | Finality model | Instant (deterministic) | ## Byzantine Fault Tolerance CometBFT provides **BFT safety** under the standard assumption: > The network tolerates **f < n/3** Byzantine validators, where n is the total number of validators weighted by stake. As long as fewer than one-third of the total voting power is controlled by faulty or malicious validators, the protocol guarantees that: - No two conflicting blocks are committed at the same height. - Every committed block is final and will never be reverted. If the Byzantine threshold is exceeded, the protocol halts (liveness failure) rather than committing conflicting state (safety is preserved). ## Three-Phase Commit Each block progresses through three sequential phases: ### Phase 1: Propose A designated proposer (selected via weighted round-robin) assembles a candidate block from the mempool and broadcasts it to all validators. ### Phase 2: Prevote Each validator evaluates the proposed block against application-level validity rules (including ZK proof verification, nullifier uniqueness, and Merkle root consistency). If the block is valid, the validator broadcasts a **prevote** for the block. Otherwise, it prevotes `nil`. **Threshold:** A block advances to precommit only after receiving prevotes from validators representing **2/3+ of total voting power**. ### Phase 3: Precommit After observing sufficient prevotes, each validator locks on the block and broadcasts a **precommit**. If a validator has not seen 2/3+ prevotes, it precommits `nil`. **Threshold:** The block is committed only after receiving precommits from validators representing **2/3+ of total voting power**. Once 2/3+ precommits are collected, the block is appended to the chain and the application state is finalized. ## Instant Finality Unlike proof-of-work or longest-chain proof-of-stake protocols, CometBFT provides **instant deterministic finality**. A transaction included in a committed block is final from the moment the block is committed — there is no probabilistic confirmation period, no reorganization risk, and no need to wait for additional block confirmations. This property is critical for the Ghost Protocol, where: - **Merkle roots** must be authoritative the instant they are published; clients generate ZK proofs against a specific root and cannot tolerate that root being reverted. - **Nullifiers** must be permanently recorded on first appearance; a chain reorganization could re-enable a spent nullifier, breaking double-spend protection. - **Commitment cooldowns** (5 seconds per address) align naturally with the block time, ensuring at most one commitment per address per block. ## Validator Set The validator set is managed through the Cosmos SDK staking module. Validators bond GHOST tokens and participate in consensus proportional to their bonded stake. Validator additions, removals, and stake changes take effect at epoch boundaries following the standard CometBFT validator update protocol. ## Appendix: Economic Parameters # Appendix C: Economic Parameters This appendix consolidates the fixed economic and network parameters of the Specter Protocol. ## Token Specification | Parameter | Value | |---|---| | Token name | GHOST | | Genesis supply | 1,000,000,000 GHOST | | Hard cap | 1,500,000,000 GHOST | | Emission cap | 500,000,000 GHOST | | Tail emission floor | 0.5% annual | | Decimals | 18 | | Smallest unit | aghost (1 GHOST = 10^18 aghost) | ## Genesis Allocation | Category | Amount (GHOST) | Percentage | |---|---|---| | Validator & Network Rewards | 300,000,000 | 30.0% | | Ecosystem & Grants Fund | 180,000,000 | 18.0% | | Core Team & Contributors | 150,000,000 | 15.0% | | Community & Airdrops | 100,000,000 | 10.0% | | Foundation Treasury | 90,000,000 | 9.0% | | Seed Investors | 90,000,000 | 9.0% | | Strategic Round | 50,000,000 | 5.0% | | Relayer Incentives | 40,000,000 | 4.0% | | **Total** | **1,000,000,000** | **100.0%** | - **Validator & Network Rewards** — Block rewards, staking incentives, and validator bootstrapping over the network's lifetime. - **Ecosystem & Grants Fund** — Developer grants, ecosystem growth, hackathons, integration bounties, and partnership incentives. - **Core Team & Contributors** — Founding team and early contributors, subject to daily linear vesting with zero TGE unlock. - **Community & Airdrops** — Direct community distribution, airdrops, and engagement reward programs. - **Foundation Treasury** — DAO-controlled reserve for long-term protocol needs, governance-approved spending only. - **Seed Investors** — Early backers who funded initial development, subject to daily linear vesting with zero TGE unlock. - **Strategic Round** — Strategic partners and infrastructure providers, subject to daily linear vesting with zero TGE unlock. - **Relayer Incentives** — Dedicated pool for IBC relayer compensation, distributed on a per-packet basis. ## Emission Schedule | Year | Rate | Emitted (M) | Cumulative (M) | |---|---|---|---| | 1 | 12.0% | 120.0 | 1,120.0 | | 2 | 8.0% | 89.6 | 1,209.6 | | 3 | 6.0% | 72.6 | 1,282.2 | | 4 | 4.5% | 57.7 | 1,339.9 | | 5 | 3.5% | 46.9 | 1,386.8 | | 6 | 2.5% | 34.7 | 1,421.5 | | 7 | 2.0% | 28.4 | 1,449.9 | | 8 | 1.5% | 21.7 | 1,471.7 | | 9 | 1.0% | 14.7 | 1,486.4 | | 10 | 1.0% | 14.9 | 1,501.2 | After Year 10, emission settles at the 0.5% tail emission floor. ## Network Parameters | Parameter | Value | |---|---| | Chain ID | 5446 | | Block time | ~5 seconds | | Consensus | CometBFT (Cosmos SDK v0.53+) | ## Validator Parameters | Parameter | Value | |---|---| | Minimum validators | 50 | | Target validators (Year 1) | 150 | | Minimum self-delegation | 100,000 GHOST | | Maximum commission rate | 20% | | Commission change delay | 72 hours | | Unbonding period | 21 days | | Downtime slashing | 0.01% of stake | | Double-sign slashing | 5% of stake | ## Relayer Parameters | Parameter | Value | |---|---| | Relayer incentive pool | 40,000,000 GHOST | | Distribution model | Per-packet rewards | | Minimum relayer bond | 10,000 GHOST | | Fee recapture rate | 50% | | Minimum success rate | 95% | ## Governance Parameters | Parameter | Value | |---|---| | Proposal deposit | 10,000 GHOST | | Voting period | 7 days | | Quorum | 33.4% | | Pass threshold | 50% + 1 | | Veto threshold | 33.4% | | Execution timelock | 48 hours | | Foundation multisig | 5-of-9 (security-critical only) | | Multisig dissolution | Month 24 | ## Ghost Protocol Parameters | Parameter | Value | |---|---| | ZK verification gas | ~220,000 | | Merkle tree depth | 20 | | Merkle tree capacity | ~1,048,576 commitments (2^20) | | Root history size | Last 100 roots | | Commitment cooldown | 5 seconds per address | | Policy gas cap | 100,000 gas (staticcall) | ### Parameter Notes - **ZK verification gas (~220k)** — The cost of verifying a single Groth16 proof on-chain via the EIP-197 pairing precompile. This is the dominant gas cost of a redemption transaction. - **Merkle tree depth (20)** — A depth of 20 supports approximately one million commitments per vault instance. Additional vault instances can be deployed if capacity is exhausted. - **Root history (100 roots)** — The contract stores the last 100 Merkle roots. A proof generated against any of these roots remains valid, giving users a window of approximately 500 seconds (100 blocks at ~5 seconds each) to submit their proof after generating it. - **Commitment cooldown (5 seconds)** — Limits each address to one commitment per block, preventing spam and reducing the effectiveness of timing-based deanonymization attacks. - **Policy gas cap (100,000)** — Reveal policy contracts are invoked via `staticcall` with a hard gas limit of 100,000. This prevents policies from performing unbounded computation or causing out-of-gas reverts in the main redemption transaction. ## Appendix: Glossary # Appendix D: Glossary | Term | Definition | |---|---| | **Access Proof** | A zero-knowledge proof demonstrating that the prover controls a data commitment in the Merkle tree, without revealing the underlying secret or nullifier secret. Used for gated data access in the OpenGhostVault. | | **Access Tag** | A session-bound identifier derived as `Poseidon2(nullifierSecret, sessionNonce)`. Proves control of a commitment for a specific session without exposing the nullifier secret. | | **aghost** | The smallest denomination of the GHOST token. 1 GHOST = 10^18 aghost. Analogous to wei in Ethereum. | | **BN254** | The elliptic curve (also called alt_bn128) used for Groth16 pairings. Its scalar field of ~254-bit prime order defines the arithmetic domain for all Specter circuits. Supported natively via EIP-197. | | **CometBFT** | The Byzantine fault-tolerant consensus engine (formerly Tendermint Core) used by Specter. Provides instant deterministic finality with ~5-second block times. | | **Commit** | The act of depositing a value or data into a Specter vault by publishing a cryptographic commitment to the Merkle tree. Also called "Vanish" in user-facing terminology. | | **Commitment** | A Poseidon hash binding a secret, nullifier secret, and payload (data or token fields) into a single field element stored as a Merkle leaf. Hiding (reveals nothing about the preimage) and binding (cannot be opened to a different preimage). | | **CommitRevealVault** | The main vault contract for private token transfers in Ghost Protocol. Accepts token deposits (burning them), stores commitments in the Poseidon Merkle tree, and processes zero-knowledge proof-verified withdrawals (minting tokens to recipients). Supports policy-bound commits and an optional quantum-safe keccak256 layer. | | **Dead Man's Switch** | A reveal policy that automatically authorizes redemption if the original depositor fails to prove liveness within a configurable time window. Useful for inheritance and recovery scenarios. | | **DestinationRestriction** | A reveal policy that restricts redemption to a predefined set of recipient addresses. The policy parameters hash encodes the allowed destinations, enforced at redemption time via staticcall. | | **Ghost Protocol** | The core privacy primitive of Specter. A system of Poseidon commitments, Merkle trees, Groth16 proofs, and nullifiers that enables private token transfers and data access with programmable reveal conditions. | | **GHOST** | The native token of the Specter network. Used for transaction fees, staking, and governance. Total supply: 1,000,000,000. | | **Groth16** | The zero-knowledge proof system used by Specter. Produces constant-size 256-byte proofs verifiable in ~220k gas via BN254 pairings. Requires a per-circuit trusted setup. | | **g-token** | A GhostERC20 representation of an external token on Specter. Created when a user bridges tokens from an external chain; the bridged tokens can be vanished (committed) into the Ghost Protocol for privacy and later summoned (revealed) to withdraw. | | **Hyperlane** | The cross-chain messaging protocol used by Specter for interoperability. Enables Warp Routes that bridge tokens and messages between Specter and external chains. | | **IRevealPolicy** | The Solidity interface that all reveal policy contracts must implement. Defines a single `validate` function called via staticcall during redemption to enforce custom conditions. | | **Merkle Tree** | A binary hash tree of depth 20 (~1M leaf capacity) using Poseidon2 for internal nodes. Stores all commitments for a vault. The root is published on-chain; proofs of membership are generated off-chain and verified inside ZK circuits. | | **Nullifier** | A deterministic, unique value derived from a commitment's nullifier secret and leaf index: `Poseidon2(Poseidon2(nullifierSecret, commitment), leafIndex)`. Published on-chain at redemption to prevent double-spending. | | **NullifierRegistry** | The on-chain registry that records all spent nullifiers. A redemption transaction is rejected if its nullifier has already been registered. | | **OpenGhostVault** | A vault contract for private data access control. Users commit data hashes and later prove access rights via Access Proofs, enabling privacy-preserving gated content, credentials, and permissions. | | **Persistent Phantom Key** | A Phantom Key type that remains valid across multiple sessions and does not expire unless explicitly revoked. Suitable for long-lived credentials and access grants. | | **PersistentKeyVault** | The vault contract that manages Persistent Phantom Keys. Supports issuance, access verification, and revocation of long-lived credentials via the Ghost Protocol. | | **Phantom Key** | A privacy-preserving credential issued through the Ghost Protocol. Proves authorization or identity attributes without revealing the holder's on-chain address or transaction history. | | **Policy Binding** | The mechanism by which a reveal policy is irrevocably bound to a commitment at deposit time. The `policyId` and `policyParamsHash` are embedded in the Poseidon7 preimage, making them tamper-proof and verifiable inside the ZK circuit. | | **PolicyRegistry** | An informational on-chain registry of reveal policy contracts. Provides discoverability for available policies but is not enforced at the protocol level — any contract implementing `IRevealPolicy` can be referenced in commitments. | | **Poseidon** | An algebraic hash function family optimized for arithmetic circuits over prime fields. Specter uses three variants: Poseidon2, Poseidon4, and Poseidon7. | | **Poseidon2** | The 2-input Poseidon variant (width-3 state). Used for Merkle nodes, nullifier derivation, access tags, and token IDs. The only variant deployed on-chain (as PoseidonT3, ~30k gas). | | **Poseidon4** | The 4-input Poseidon variant. Used for data commitments and Open Ghost commitments: `Poseidon4(secret, nullifierSecret, dataHash, blinding)`. Computed off-chain only. | | **Poseidon7** | The 7-input Poseidon variant. Used for token commitments: `Poseidon7(secret, nullifierSecret, tokenId, amount, blinding, policyId, policyParamsHash)`. Computed off-chain only. | | **Programmable Phantom Key** | A Phantom Key type governed by a reveal policy. The policy contract can enforce expiry, destination restrictions, threshold witnesses, or arbitrary custom logic before the key can be used. | | **Quantum Commitment** | The keccak256 hash of a quantum secret, stored on-chain at deposit time in the CommitRevealVault. Provides defense-in-depth against quantum adversaries who may break BN254 in the future. | | **Quantum Secret** | A random value generated by the depositor and kept private until redemption. Its keccak256 hash forms the quantum commitment. Preimage resistance under Grover's algorithm requires ~2^128 operations. | | **Redemption Proof** | A Groth16 proof generated by the GhostRedemption circuit. Proves Merkle membership, nullifier correctness, amount conservation, change commitment validity, and policy binding without revealing any private inputs. | | **Reveal** | The act of satisfying the conditions required to redeem a commitment — submitting a valid ZK proof, passing the reveal policy check, and (in CommitRevealVault) revealing the quantum secret. Also called "Summon" in user-facing terminology. | | **Reveal Policy** | A smart contract implementing `IRevealPolicy` that defines the conditions under which a commitment can be redeemed. Bound to the commitment at deposit time and enforced via staticcall at redemption. | | **Revels** | The user-facing term for private data sharing built on the OpenGhostVault. A Revel is a piece of data — a message, a document hash, a secret, or credential — committed privately and revealed selectively using zero-knowledge proofs. | | **Session Nonce** | A unique random value used in Access Proofs to bind the proof to a specific session. Prevents replay of access proofs across different sessions. | | **Specter** | The privacy-first blockchain protocol combining CometBFT consensus, EVM execution, and the Ghost Protocol to enable private, programmable, and quantum-aware transactions and credentials. | | **Stealth Address** | A one-time address derived using the ERC-5564 scheme, enabling a sender to create a payment destination that only the intended recipient can detect and spend from. | | **Summon** | The user-facing term for revealing (withdrawing) tokens or data from the Ghost Protocol. Technically, the act of submitting a redemption proof and receiving minted tokens. | | **ThresholdWitness** | A reveal policy requiring M-of-N designated witnesses to co-sign a redemption. Enables multisig-like governance over committed assets without revealing the commitment's owner. | | **TimelockExpiry** | A reveal policy that prevents redemption until a specified block timestamp has passed. Useful for vesting schedules, time-locked escrows, and delayed execution. | | **Vanish** | The user-facing term for depositing (committing) tokens into the Ghost Protocol. Technically, the act of burning tokens and inserting a commitment into the Merkle tree. | | **Warp Route** | A Hyperlane-based bridge route that enables tokens to move between Specter and external chains. Warp Routes lock tokens on the source chain and mint corresponding g-tokens on the destination. | | **Zero-Knowledge Proof** | A cryptographic proof that demonstrates knowledge of information (such as a commitment preimage) without revealing the information itself. Specter uses the Groth16 zk-SNARK system. | ## Appendix: References # Appendix E: References 1. Groth, J. (2016). "On the Size of Pairing-based Non-interactive Arguments." *EUROCRYPT 2016*, Lecture Notes in Computer Science, vol. 9666, pp. 305--326. Springer. 2. Grassi, L., Kales, D., Khovratovich, D., Roy, A., Rechberger, C., and Schofnegger, M. (2021). "Poseidon: A New Hash Function for Zero-Knowledge Proof Systems." *USENIX Security Symposium 2021*. 3. Buchman, E. (2016). "Tendermint: Byzantine Fault Tolerance in the Age of Blockchains." Master's thesis, University of Guelph. 4. Ben-Sasson, E., Chiesa, A., Tromer, E., and Virza, M. (2014). "Succinct Non-Interactive Zero Knowledge for a von Neumann Architecture." *USENIX Security Symposium 2014*. 5. EIP-197: Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-197 6. ERC-5564: Stealth Addresses. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-5564 7. Buterin, V. (2014). "Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform." Ethereum White Paper. 8. Kwon, J. and Buchman, E. (2019). "Cosmos Whitepaper: A Network of Distributed Ledgers." Cosmos Network. https://cosmos.network/whitepaper 9. Sasson, E.B., Chiesa, A., Garman, C., Green, M., Miers, I., Tromer, E., and Virza, M. (2014). "Zerocash: Decentralized Anonymous Payments from Bitcoin." *IEEE Symposium on Security and Privacy (S&P) 2014*, pp. 459--474. 10. Noether, S., Mackenzie, A., and the Monero Research Lab. (2016). "Ring Confidential Transactions." *Monero Research Lab Report MRL-0005*.