Skip to main content

Risks and Tradeoffs

This system is not safe by default. It is safe by design.

Ghost Protocol makes specific choices that increase security at the cost of convenience and recoverability. These are intentional tradeoffs, not oversights.

Permanent Loss Is Possible​

If you lose your secret, your commitment is lost forever.

There is no recovery mechanism. No administrator can help you. No backup exists in the system. The commitment will remain on-chain, permanently unrevealed and permanently inaccessible.

This is by design. If there were a recovery mechanism, that mechanism would be a backdoor. Anyone who could recover your commitment could also access it without your consent.

Mitigation: Back up your secrets securely. Store them offline. Use multiple independent backups. Treat your secrets like physical cash—if you lose them, they are gone.

No Recovery, No Reversals​

Once a reveal happens, it cannot be undone.

If you reveal to the wrong address, the value is gone. If you reveal at the wrong time, you cannot take it back. If you reveal accidentally, there is no undo button.

This is by design. If reveals could be reversed, the finality guarantee would be broken. Someone could always claim a reveal was accidental and demand reversal.

Mitigation: Double-check everything before revealing. Use interfaces that require confirmation. Start with small amounts until you are comfortable with the system.

Administrative Roles Exist​

Ghost Protocol contracts do have administrative roles:

  • The GhostVault owner can pause the entire system, preventing all deposits and withdrawals
  • The GhostVault owner can change the verifier contract, which determines what ZK proofs are accepted
  • The root operator controls which Merkle roots are recognized, gating which commitments can be revealed

These roles exist for operational reasons (upgrading circuits, emergency response). They represent a trust assumption: you must trust that the operators will not abuse these capabilities.

No administrator can access your secrets or reveal your commitments on your behalf. But they can prevent you from using the system.

Mitigation: Understand the trust assumptions. The protocol is not fully trustless — operational control exists. Decentralization of these roles is planned but not yet implemented.

Relayer Trust Model​

The current implementation includes a server-side proof generation service (the "proof relayer"). If you use this service:

  • You send your voucher secrets (secret, nullifier secret, blinding factor) to the relayer server
  • The relayer generates the ZK proof on your behalf
  • The relayer could, in theory, use your secrets to reveal your commitment to a different address

This exists because ZK proof generation requires WebAssembly support and significant computation, which some clients (especially mobile) cannot perform locally.

Mitigation: The relayer is operated by the core team on a dedicated server. Client-side proof generation is available for users who prefer not to trust the relayer. Use client-side proof generation for high-value commitments.

User Responsibility Is Required​

Ghost Protocol assumes you know what you are doing.

The system will let you:

  • Lose your secrets
  • Reveal to wrong addresses
  • Commit value you cannot track
  • Make mistakes with no recourse

The system will not:

  • Warn you about every risk
  • Prevent obviously bad actions
  • Hold your hand through complex operations
  • Save you from yourself

This is by design. A system that protects users from themselves must understand what users want. Understanding what users want requires surveillance. Ghost Protocol does not surveil.

Mitigation: Learn how the system works before using it with significant value. Read the documentation. Ask questions. Practice with small amounts.

Cryptographic Assumptions​

Ghost Protocol's security depends on cryptographic assumptions:

  • Hash function security: The Poseidon hash function must be preimage-resistant and collision-resistant.
  • Proof soundness: The zk-SNARK system must be sound—fake proofs should be impossible to generate.
  • Trusted setup: The initial parameters must be generated correctly and the toxic waste must be destroyed.

If any of these assumptions fail, the system's security guarantees may be compromised.

Mitigation: These are standard assumptions used by many cryptographic systems. They have been studied extensively and are considered secure by the cryptographic community. However, cryptography can be broken. Nothing is guaranteed forever.

Smart Contract Risk​

The smart contracts implementing Ghost Protocol may contain bugs.

The contracts are open source but have not yet been independently audited (see What Exists Today). A subtle bug could allow an attacker to:

  • Forge proofs
  • Double-spend
  • Lock funds
  • Violate privacy

Mitigation: The system is currently on testnet only. Independent audits are planned before mainnet launch. Start with small amounts. Wait for audits and battle-testing before committing significant value.

This Is Not for Everyone​

Ghost Protocol is appropriate for people who:

  • Understand the technology
  • Accept responsibility for their own security
  • Value privacy enough to accept the tradeoffs
  • Can manage their own secrets reliably

Ghost Protocol is not appropriate for people who:

  • Need recovery mechanisms
  • Expect customer support
  • Want someone else to fix their mistakes
  • Cannot securely manage cryptographic secrets

This is not a value judgment. Different people have different needs. Ghost Protocol serves a specific need and is honest about what it does not provide.

The risks described here are features, not bugs. They are the cost of the guarantees Ghost Protocol provides. If you are not comfortable with these tradeoffs, this system may not be right for you.