Security & trust model

This page states Hestia's security model plainly: what an observer can and cannot see, what each off-chain party is trusted for, and the known limits you must respect before putting real value at risk.

What is private vs. public

A private send reveals nothing but two new commitments and two ciphertexts. Deposits and withdrawals expose amounts at the boundary with the public world — but neither can be linked to the rest of your shielded activity.

Trust assumptions

• The chain is authoritative. All security-critical state — the tree, nullifiers, approved association roots — lives on-chain. Off-chain components only cache and relay it.
• The indexer is untrusted for integrity. It can serve stale data or withhold service, but it cannot fabricate state you'll accept: your SDK can rebuild everything from chain events and verifies proofs against on-chain roots.
• The relayer is untrusted for integrity. recipient, withdrawAmount, and feeAmount are bound into the proof's public signals, so a relayer can submit your transaction faithfully or not at all — never redirect or skim it. It can refuse service or pay gas; that's the extent of its power.
• No party can spend for you. Spending requires sk, which never leaves your device and is never part of any disclosure.

The strongest adversary among the off-chain components can therefore cause denial of service, not theft or deanonymization beyond what is already public.

Client-side proving

Proofs are generated where the keys are — in your process or browser. The witness (amounts, notes, sk) is never transmitted. There is no server holding your plaintext to be compromised or subpoenaed, because no server ever receives it. This is the foundation of the privacy guarantee, not a convenience.

Compliance properties

• Provenance is proven, not disclosed. Every spend proves its label is in an approved association set in zero knowledge.
• Lineage cannot be laundered. The single-input join-split stamps the input's label onto its outputs, so clean and tainted funds can't be merged into an ambiguous origin.
• Disclosure is consensual and scoped. A viewing key reveals only your own history, read-only, and only when you hand it over.

Key handling

Because the identity is derived from a signature over hestia.io/keys/v1, anyone who can make your wallet sign that exact message can derive your identity. Protect the wallet accordingly, and be deliberate about which message you sign.

Known limits of v0.1

• Trusted setup is single-contributor. The keys behind the live Base-mainnet verifiers come from a fresh setup whose entropy was generated with crypto.randomBytes and discarded, so no one holds its toxic waste — distinct from the repo's reproducible fixed-entropy dev ceremony, which is insecure by design. What is still missing is a public multi-party ceremony with a verifiable transcript; that, not the current setup, is the standard for very large value. See circuits.
• No external audit yet. The contracts and circuits have not been independently audited.
• Anonymity set. Privacy quality scales with how many notes share the pool and your association set. A small or empty set provides weak unlinkability regardless of the cryptography.
• Relayer availability. Fully decoupling a withdrawal address from gas history depends on a relayer being willing to submit. Self-host one if you need that guarantee.

Hestia is open source precisely so these properties can be verified rather than trusted. If a claim on this page can't be checked against the code, treat the code as the source of truth and tell us.