Skip to main content

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.

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.