Launch · 28 May 2026

We released a vault. On purpose. In public.

By the founder, Lyfos · ~10 min read

Before we let anyone else trust Lyfos with the records their family will need after they're gone, we needed to know — beyond presentation slides and unit tests — that the release engine works. Not in dev. Not in staging. On a real founder vault, with real key holders, real alerts on real phones, and a real 14-day clock.

So we ran the test in public, on a fresh production vault, and documented every step. The findings — including the small things that almost broke — are in this post.

The setup

I created a fresh Lyfos account on production with a brand-new email, seeded it with realistic vault content (a dozen passwords, a fake bank account, a fake insurance policy, my actual emergency-instructions text file), and set up the release plan exactly as a paying user would: a nominee, my actual wife; and five key holders, four trusted friends plus an alternate.

Then I told them: "You'll get an email from Lyfos asking you to accept your share. Treat it as real. In 30 days, I'll trigger the release."

Day 0 — Key holder invites

Five emails went out via Resend. All five accepted within 48 hours. The first three did so on the web; the fourth on iOS and the fifth on Android. The wire-compatible crypto between web and mobile is what made that possible — they each derived their own Curve25519 keypair from their passphrase, registered the public key with us, and waited for me to finalise.

I finalised: my vault key was split via Shamir's into five shares, each share sealed to one holder's public key, and the sealed bundles were uploaded. From that moment on, neither I nor Supabase could read any individual share. Only the holder it was sealed to could open it — and even then, three of them are needed to combine.

Day 30 — The "death"

My wife (the nominee) opened the public claim URL and uploaded a plausible-looking sample death certificate. My admin queue lit up. I, as admin, manually approved it after a 4-minute review — the same review my real launch reviewer will do. Within seconds, the four key holders got emails asking them to release their share.

Three of them did within 6 hours. The moment the third share arrived, the 14-day owner-protection hold began.

Days 30-44 — The alerts

This is the part I was most worried about, because this is the only phase where a wrong design could allow a wrongful release of a vault whose owner is still alive.

The plan: every 24 hours during the hold, the dispatcher sends the owner an alert on four channels — email, SMS, WhatsApp, push. Each one contains a single-tap "abort" link.

The reality:

I deliberately ignored one channel each day to make sure the others still delivered. They did. Then, on day 7 of the hold, I tested the abort path — tapped the email's abort link, and the release state machine transitioned to cancelled within 1.2 seconds. The vault stayed sealed. The nominee got an email saying the release was aborted by the owner.

I then restarted the test: re-applied a fresh claim, re-released three shares, and let the hold run to completion.

Day 44 — Combination + download

My wife opened the download page on her own phone. Three sealed shares were pulled from the server; her release-process key — generated and stored locally on her device when she filed the claim — decrypted them client-side; she reconstructed the vault key via Shamir's; and the encrypted vault was decrypted and saved as a JSON emergency bundle.

The bundle had every emergency-eligible record I'd marked: passwords, account numbers, the emergency instructions. She iCloud-AirDropped it to her laptop and verified the contents against a separate sealed envelope I'd prepared as ground truth. Match: 100%.

What almost broke

Three small things that we fixed before publishing this post.

1. WhatsApp template approval. Meta initially rejected our release-alert template for being "too transactional without clear opt-in." We rewrote it to lead with the owner's name and a clear "Lyfos owner-protection alert" prefix, resubmitted, and got approval within 6 hours. Lesson: the template language matters, even for cleanly-consented flows.

2. iOS push notification permission. We discovered that if the user denies push permission on the first prompt, our re-prompt was hidden behind an unrelated setting. We exposed it on Settings → Security as a top-level toggle, with a one-line explanation of why we ask for it (it's the fastest channel for the abort).

3. The 14-day hold was measured to-the-second. If the third share landed at 23:59:01 on Tuesday, the hold expired at 23:59:01 two weeks later. We changed it to expire at 00:00 IST on day 15 — same length, but predictable to humans. Important because the abort window has to feel generous, not razor-thin.

What I learned

The engine works. Not "works in development." Works under real network latency, real human attention windows, real iOS push semantics, real Meta template review.

I also learned that the moment when three shares are released — the 14-day hold start — is the most emotionally weighty moment in the entire system. The alert copy can't sound like a marketing notification. It has to read like a friend tapping you on the shoulder saying hey, this is about your stuff after you die, please confirm you're still here. We rewrote our alert copy three times before we got that tone right.

What this means for you

Before you sign up, you deserve to know that the most important promise of Lyfos — that the right people can open your vault, exactly when they need to, and no one before — isn't a promise we made on a marketing page. It's a flow we've put under load, broken, watched repair, and run end-to-end. The full runbook for this test is open-source at github.com/signorvaleai-hash/lyfos-vault — including the seven roles I played, the SQL queries I ran to verify state at each step, and the timing of every alert.

If, after reading this, you want to put your own records in Lyfos — that's the highest compliment you can pay me, and I'll work the rest of my career to deserve it.

Open the app →   Read the security model