What we can’t see

Vague privacy claims are worthless. Here is exactly what each part of the system can learn about you, and what it can’t.

Who learns what

Party	Can learn	Cannot learn
Coordination chain (anyone reading it)Testnet-ready	That a vault with a given commitment exists, and its policy: inactivity period, unlock time, guardian threshold, and the beneficiary and guardian Merkle roots. When the owner checks in (block time and day epoch), and when the policy is changed. For each claim: the nullifier, the share in basis points, and a hash of the payout destination. Recovery activity: vote counts per proposed new commitment, cancellations and rotations. The address that submitted each transaction. That is yours if you submit it yourself.	Who the owner is. There is no owner address; ownership is knowledge of a secret. Who the beneficiaries or guardians are, or which of them claimed or voted. Where a payout went (only its hash), or anything inside an encrypted data vault. A link between your wallet and your vault, when a relayer submits for you.
RelayerIn development	The transaction it submits, which becomes public anyway. Your IP address and timing, unless you connect through Tor or a VPN. Refuse to relay. You can always submit yourself or use a different relayer.	Change the action, the new owner commitment or the payout destination. All of them are bound into the proof. Create proofs, or learn any secret.
KeepersIn development	Everything on the coordination chain, plus the payout destinations they execute. Their own key share and the encrypted shares they store. Refuse or delay signing. The threshold tolerates a minority of offline or uncooperative keepers.	Move funds or release a data key without a valid claim accepted on-chain, unless a threshold of keepers colludes. Act at all, where your policy requires an owner or guardian share in the signing set. Decrypt your data or see your secrets.
IPFS and storageIn development	Ciphertext, its size and its content identifier (CID). When it was stored and fetched, and from which IP or gateway.	Plaintext. Encryption happens on your device before upload.
Us, the operators	What anyone can read on-chain. That a TCP connection reached this web server. We keep no access logs and set no cookies. Ship the code you run. A malicious app update is a real risk; see the threat model.	Your owner secret, beneficiary secrets or guardian secrets. They are generated and kept on your devices. Recover, freeze, pause or upgrade a vault. The registry has no admin. Tell you who owns a given vault. We do not know.

What we defend against, and what we don’t

Designed to resist

Chain observers mapping owners to heirs. Nothing identifying is stored, and Merkle membership hides which leaf is acting.
Replay and front-running. Owner proofs are bound to one action, chain and registry. Payout destinations are bound into claim proofs, and nullifiers are single-use.
Double claims. There is one nullifier per beneficiary per vault.
Guardian takeover of a live vault. Any owner check-in cancels the recovery round in progress.
A minority of keepers going rogue or offline. Signing needs a threshold and a valid on-chain claim. The keeper network is in development.
Us. We hold no secrets, and the registry has no admin key.

Known limits

Bugs. A flaw in the circuits or contracts could break any of the above. Both are open for review.
Threshold collusion. If enough keepers collude they can move funds or decrypt data. Requiring your own or your guardians’ share in the signing set narrows this.
k colluding guardians can rotate your vault while you are not checking in. Pick guardians and k accordingly.
Your device. If it is compromised, your owner secret is too.
Metadata. Policy parameters, check-in timing and claim counts are public. Network-level observers can correlate timing unless you use Tor.
Malicious frontend. Whoever serves the app code could, in principle, ship code that leaks secrets. Reproducible, verifiable builds are planned.
Forgetting to check in. The vault will open. That is the point, so choose a period you can keep.

This website follows the same rules

Static HTML and CSS. No JavaScript is shipped at all.
No cookies, analytics, tracking pixels, embeds or third-party requests.
Fonts are self-hosted. Nothing is fetched from a CDN.
A strict Content-Security-Policy, Referrer-Policy: no-referrer, and a deny-all Permissions-Policy.
Access logging is turned off on the web server.
An onion service is planned and will be advertised with an Onion-Location header.