How we built a vault we can't read.

This is the long version. If you're security-curious, read straight through. If you just want the punchline: your data is encrypted on your device with a key derived from a passphrase only you know plus a Secret Key only you have. We hold neither, so we can't decrypt anything — by you, by us, or by anyone.

The 1Password model, applied to estate planning

1Password popularized a security architecture where the user's secret material is split between something they remember (a passphrase) and something they have (a printed Secret Key). The two are combined locally to derive a master encryption key. That key never leaves the device, and the vendor never sees either input.

We apply the same architecture to estate-planning data — wills, beneficiary allocations, asset inventories, family records — that other vault products store in plaintext-readable form on their own servers.

How your master key is derived

master_key = PBKDF2(
  passphrase + Secret Key,
  per-vault salt,
  100,000 iterations,
  SHA-256
)

The salt is per-vault and stored alongside the vault — it's not secret. The 128-bit Secret Key plus the 100,000 PBKDF2 iterations together make brute-forcing the passphrase impractical even if an attacker has the encrypted file.

All vault data is then encrypted with AES-256-GCM using the master key. Each field carries its own random IV, and GCM's authentication tag prevents tampering.

What we store on our servers

Nothing — unless you opt into our paid Storage tier (which uses Cloudflare R2, and even then your documents are encrypted client-side before upload).

  • Your passphrase — nowhere. Used transiently during key derivation, then discarded.
  • Your Secret Key — only in your printed Emergency Kit PDF.
  • Your master key — derived in memory at unlock time, garbage-collected on lock.
  • Your vault file — AES-GCM ciphertext, optionally synced to your Google Drive.

What this protects against

  • A breach of our servers can't expose your data, because your data isn't on our servers. Only the encrypted file is, and only if you opt in.
  • An employee of ours can't read your vault — even if they were paid, threatened, or compromised.
  • A court order or subpoena can't compel us to hand over your data, because we genuinely don't have it.
  • Social engineering can't trick us into unlocking your vault for someone pretending to be you — there's no unlocking ceremony for us to perform.

What it can't protect against

Losing both your passphrase and your Emergency Kit. If both are gone, the vault cannot be unlocked — by you, by us, or by anyone. There is no reset link, no support ticket, no recovery code we hold. This is the price of zero-custody and we're upfront about it.

Mitigations: register a passkey on your trusted devices (a third unlock path that wraps the master key locally), print two copies of the Emergency Kit and store them separately, and store your passphrase in a password manager that's not in the same place as the kit.

How to verify our claims

Don't take our word for it. Open the network panel in any browser inspector and watch what the vault sends — encrypted blobs, never plaintext. Inspect the Emergency Kit PDF and you'll see your own Secret Key printed there, and nowhere else. Lock the vault and search the database files on your device for any of your asset names — they won't be there.

Reporting a vulnerability

Found something? We want to hear about it. Reports go through the same feedback inbox everything else uses — submit it, pick the "Security" tile, and the report lands in our urgent queue, kept private between you and the founder. No public listing, no community voting on security tickets.

Report a vulnerability

No mailbox to send to on purpose. Email forms are spam magnets and noisy for both sides. Routing through the in-app form gates the intake with Cloudflare Turnstile (one click, no captcha to solve), keeps the report attached to a conversation thread, and skips the email game entirely.

What to expect

  • 1. First reply within 72 hours, usually faster. A real human (Seth, the founder) is reading these.
  • 2. Coordinated disclosure. We aim to ship a fix within 30 days of confirmation for medium/high severity. We'll keep you in the loop on timing; please don't publish details until the fix is out.
  • 3. Public credit once it ships, if you want it. We'll list your name (or handle) below as a thank-you. Opt in via the conversation thread.
  • 4. Safe harbor for good-faith research that doesn't access other users' data, doesn't degrade the service, and doesn't try to monetize the bug. You won't hear from a lawyer for poking at our public surfaces in good faith.

About bug bounties

We don't run a paid bounty program yet — and we'd rather say that plainly than dress up a $20 token payout as a "program." Researchers we'd actually want submitting to us aren't going to fill out tax forms for $20, and we'd rather not pretend.

Here's the honest plan: a real bounty launches once two things are true.

  1. There are enough real users that a public exploit would hurt enough to justify paying researchers to find it first.
  2. There's more than one person on call. A bounty implicitly promises a response SLA; we won't take payments for a service a single founder on vacation can break.

Tiered $100 / $250 / $500 / $1,000+ by severity, run through a managed platform (HackerOne or Bugcrowd) so the KYC, tax forms, and international payouts aren't ours to fight with. Until then, public credit + a sincere thank-you is what we can offer, and we offer it honestly.

Hall of fame

Nobody's reported a vulnerability yet — when someone does and a fix ships, this is where their name will land (with their permission). Come be first.

Convinced? Or skeptical and want to poke at it yourself?

Either way, the vault is free.

Open your vault