Security posture

Loud failures

The failure mode this project treats as unacceptable is the silent one: a system that keeps working, keeps showing a green state, and is wrong. Each decision below turns one of those into a noisy failure instead.

Encrypt the seed, never derive it

The Zcash seed is random and encrypted under a key derived from a Solana signature. The signature unlocks the seed and never becomes the seed. If a wallet changed its message format, a derived seed would quietly produce a new and empty account while the old funds sat unreachable with no error anywhere. Encryption turns that same event into a loud decryption failure with the original seed still intact.

Exporting the recovery phrase is a gate

Nothing continues until the phrase has been saved. The alternative is a wallet whose only copy lives in one browser's storage.

The Merkle check is unconditional

Orchard's dummy-note disjunction would let a zero-value note skip the tree check entirely. It was not inherited, and a test asserts it stays that way.

The tag is domain-separated from the nullifier

Otherwise an attestation written today links a Zcash spend to a Solana account months from now. That is privacy which fails later rather than now, which is the hardest kind to notice.

A balance stays blank until a scan completes

A zero shown because nothing has been looked at yet is indistinguishable from a zero that is true. One of those is how a wallet tells somebody their money is gone.

An import proves before it stores

A vault file has to decrypt, and the seed inside it has to derive the address the file claims, before anything is written. The same rule covers a typed recovery phrase. Storing first and verifying later fails on the day somebody needs the funds.

A shield writes its record before it broadcasts

The transaction id is a hash of the transaction, so it exists before the transaction is sent. Writing it first means an interruption anywhere after that leaves something with an id to ask the chain about, instead of a window where money moved and nothing on the machine knew.

The private side

None of this ever leaves your browser: the seed, the spending key, every viewing key, the Merkle witness, note values, note commitments, and your Zcash address.

Building the proof stays here permanently, because a server that built it would have to see the note, the amount and the witness, and that is the premise of the product rather than a preference.

What leaves is the finished proof and its public inputs. The quorum that checks it, and anybody who repeats the check, learns nothing from it that was not already public.

Trust assumptions

Stated up front, because a reader who discovers them alone discounts everything else. Zolar does not use the word trustless and will not until these are gone.

The attester quorum

soundness

Solana cannot follow Zcash consensus, so a quorum has to assert what the Ironwood tree looked like and verify the proof against it. It sees public tree state and no note, key or balance, and it can never take your ZEC. What it can do is assert a root it invented and sign attestations for notes that never existed, and no proof system catches that, because the proof would be a valid proof about their tree.

The relay

metadata

A browser cannot speak to a Zcash light node directly, so queries pass through a thin relay. It never sees a key, a seed or a witness. It does see your IP address and what you asked for.

Solana checks signatures

fraud proof

It checks that the quorum signed, not that the mathematics holds. What keeps the quorum honest is that the proof is published beside the attestation and verifies in 6.4 ms anywhere, so a signature the proof does not support is detectable by the first person who looks, attributable to whoever signed it, and therefore punishable.

Zcash finality

probabilistic

Proof of work settles in probability rather than in a moment. An anchor can be reorganised out from under a proof, which is why the shielding path takes its anchor 10 blocks below the tip and the scanner rolls back 100 blocks on every resume.

Rejected approaches

Each was taken seriously enough to be written down, and each was dropped for a reason that still holds.

An encrypted seed on a public chain, IPFS, or Arweave

Three reasons, the third decisive. It cannot be withdrawn once written, because closing an account removes it from active state and never from history. It builds a public catalogue of people holding shielded ZEC, inside a product whose entire proposition is that such a list should not exist. And Ironwood ships quantum-recoverable notes while the signature scheme guarding that blob does not, so harvest now and decrypt later would have every ingredient it needs from day one. What matters is whether the public can see the blob, not where it sits.

A third-party key network holding the vault

Access control does solve the public problem, and it adds a party that holds the fate of user keys. For storing the keys to money that is a bad trade, because networks migrate, and a vault that depends on one migrates with it or dies with it.

A hosted login as the Zcash wallet

This is a different object rather than an unsupported one. A signer signs. Zcash needs whole key material in the client to derive the key tree, to trial-decrypt every note during a sync, and to generate a proof. None of those three is signing a transaction, and forcing it would make an email account the key to shielded ZEC.

Sign-in-with-Solana for vault binding

Its payload carries a nonce and a timestamp, so the signature is guaranteed to differ every time. Binding needs a fixed byte string, which means a plain signed message.

Proving from a transparent address

Funds at a transparent address are public, traceable, and outside this circuit. The wallet reads that balance and offers one signed step to shield it, because a balance somebody holds is a fact they are entitled to see. What it will not do is treat a transparent address as a place to prove from, or as the main way in. The cost is real and accepted: many exchanges can only withdraw to a transparent address, so the route in from one runs through a shield rather than straight into the pool.