Every company building Bitcoin tooling owes its users an honest answer to a specific question: what happens to my Bitcoin if you go away?

Most answers fall into one of three categories. “Your funds are safe with our partners” (custodial — you’re trusting another company to outlive us). “You can export everything and migrate” (better, but you need to know to do it before we shut down). “The protocol itself enforces what you have” (best — works regardless of our status).

Bitheritance is firmly in the third category, by architectural design. Let me walk through exactly why.

The artifact is a standard Bitcoin transaction

When you finish building an inheritance plan with us, the output is a fully-signed Bitcoin transaction. Not a database entry, not a JWT, not a contract on some sidechain — a hex-encoded transaction that any Bitcoin wallet in existence can parse and broadcast.

02000000000101a3f4...b9e8c01dac51 [thousands of hex chars] 00000000

That hex string is the inheritance. Every other thing we provide (the heir handoff PDF, the QR code, the share URL, the saved-plans page, the email alerts) is commentary — packaging that makes the transaction easier to handle. Strip all of that away and the hex still works.

Our server never sees a private key

This is the architectural part. Bitheritance’s WASM runs entirely in your browser. When the wizard asks your wallet to build and sign the timelocked transaction, all the cryptographic action happens locally — in Sparrow, on your Coldcard, inside whatever signer you use. Our server learns the result (a signed transaction hex) but never the means (your seed phrase, private key, master fingerprint).

What we do hold on our server, when you opt in:

  • Your email address (for sign-in via magic link)
  • The signed-transaction hex you saved (not encrypted — but again, signed transactions are share-safe until the unlock block)
  • Watch-only descriptors / xpubs you save (public-key material; can derive addresses but can’t sign)
  • Monitoring subscriptions (we poll the chain for plans you opted in to)

What we cannot hold, regardless of what we wanted to do:

  • Your private keys, in any form
  • The ability to broadcast your inheritance before the unlock block (the network rejects it)
  • The ability to redirect your inheritance to a different address (already signed; the recipient is committed)
  • The ability to invalidate your plan (only you can do that, by spending a committed UTXO)

So: what if we shut down tomorrow

Concretely, the scenarios that matter:

Scenario 1: you have the inheritance package

You ran the wizard, you got the package (JSON / QR / share URL / printed PDF). Bitheritance.app stops responding tomorrow.

Nothing has changed for the inheritance itself. The transaction is signed and waiting. Your heir, on the unlock block, opens the package in any tool that handles raw Bitcoin transactions and broadcasts. Concrete examples:

  • Sparrow: Tools → Load Transaction → paste the hex → Broadcast Transaction
  • Electrum: Tools → Load transaction → From text → Broadcast
  • Bitcoin Core CLI: bitcoin-cli sendrawtransaction <hex>
  • mempool.space’s broadcaster: paste hex into the “broadcast transaction” tool, submit
  • blockstream.info’s broadcaster: same

The heir handoff kit PDF we generate has all of this baked in. Open the PDF, the “Signed transaction (raw hex) — fallback” section lists exactly these instructions.

Scenario 2: you only have your account, not the package

You signed in to Bitheritance, saved your plans to your account, never downloaded the JSON or printed the PDF. We disappear before you got around to it.

This is worse but not fatal. Your saved plans contain the signed transaction. Some practical mitigations:

  • The watchtower’s /account/export endpoint produces a full JSON dump of everything we hold for you. While Bitheritance is reachable, click “Export your data” in Settings any time — it gives you the canonical artifact.
  • The repo is open source. If you’re paranoid about deployment longevity, run the watchtower yourself (Docker Compose example in the repo) and save plans to your instance. Same code, your hardware.
  • The frontend SPA is a static bundle. Cloudflare Pages going away doesn’t take it with them; the GitHub Actions deploy produces a dist/ you can host anywhere.

The point: even if our specific deployment goes offline, the code and the artifacts you produced with it are recoverable as long as you exported them.

Scenario 3: we get hacked

Worst plausible breach: an attacker gains full database access and steals everything we hold. That means:

  • They get every user’s email address (a directory of “people who care about Bitcoin self-custody enough to set up inheritance plans”)
  • They get every saved heir package (the signed transactions — which they could broadcast at the unlock block, but those broadcasts go to the heir’s address, not the attacker’s)
  • They get every saved xpub (privacy harm — they can derive every past and future address for these wallets, but they can’t spend without the corresponding private keys)
  • They get every plan-alert subscription’s email + recipient list

None of that lets them steal Bitcoin. The signed transactions go where they were always going to go. Xpubs can derive addresses but not sign. Email addresses are not funds.

That’s not “nothing harmful happened” — privacy matters and the directory of users is itself sensitive — but it’s strictly less bad than the equivalent breach of a custodial Bitcoin product, where keys are at risk and funds can be drained.

The open-source argument

The whole codebase is on GitHub. The frontend is a static SPA buildable from source. The backend (Rust watchtower + SQLite) has a docker-compose.yml in the repo. The deployed binaries are reproducible from a specific commit hash, which we surface in the footer of the landing page (and via /version on the API).

Practically speaking, this means:

  • A skeptical user can audit that we’re not doing something different from what we claim. The audit isn’t trivial — Rust + WASM + cryptographic primitives — but the surface area is bounded.
  • A community can fork. If we shut down or change direction in ways our users disagree with, anyone who wants can run the existing version forever.
  • An attacker can’t ship a backdoor unilaterally. Updates flow through the deploy pipeline, which produces auditable build artifacts.

We’re not promising bulletproof — software supply chains can be attacked at many layers — but the transparency floor is much higher than a closed-source SaaS could offer.

What we ARE asking you to trust us about

Honest list:

  • The current deployed code matches the source. Reproducible builds reduce this trust but don’t eliminate it; you’re trusting the GitHub repo + Cloudflare Pages + Railway pipeline.
  • We don’t log private data we shouldn’t. Our codebase shows we don’t, but you’re trusting the running deploy hasn’t been backdoored since the audit.
  • We poll the chain honestly. When we say a plan “looks valid,” we’re asserting that based on our Esplora reads. You can independently verify against any block explorer.
  • Magic-link emails go where you expect. Our SMTP-of-record (Resend) sees recipient addresses; they’re a legitimate company but they’re in the trust loop.

That’s the actual list. Notice what’s not on it: “we hold your funds securely.” We literally cannot.

If the question “what happens when this company disappears?” is something you’ve asked custodial Bitcoin services and gotten unsatisfying answers to, this is what a real answer looks like. The inheritance lives in your wallet and on Bitcoin. We’re the tool that helped you build it. Tools come and go; signed transactions are forever.