Our servers are blind, and we built them that way
The people you love should never inherit a locked screen. Your vault reaches our servers already encrypted, its keys left behind on your device — so we release only what your rules permit: key-shares, never plaintext.
Zero-Knowledge
By Design
Encryption
XChaCha20-Poly1305
Key Derivation
scrypt (N=2^15)
Threshold Crypto
Shamir, threshold you set
In-Transit
TLS 1.2 / 1.3
At Rest
Client-encrypted
Release gates
Fail closed
Architecture
Four Pillars of Zero-Knowledge
Every layer adds defense in depth. From your device to our servers, there's not one place where you simply have to trust us.
Client-Side Encryption
All encryption happens on your device, and your master password never leaves it. The keys that decrypt your vault are derived there and are not sent to us.
Implementation
scrypt (N=2^15, r=8, p=1) → 256-bit master key
Ciphertext-Only Storage
Vault items and document bytes are stored as ciphertext, and the keys that open them are not stored with them. Your account and your nominees’ contact details ARE stored readable — the service cannot notify or verify someone whose address it cannot read.
Implementation
XChaCha20-Poly1305 (AEAD) for vault items and document bytes alike
No Server-Side Vault Decryption
Your vault key is derived on your device and never transmitted, so no code path on our side decrypts it. We do hold a server-side wrapping key for stored key envelopes — it protects those envelopes and does not open your vault.
Implementation
Vault key derivation and every key operation happen client-side
You Hold the Keys
Your master key derives category keys via HKDF-SHA-256, and asset keys below those. Each document gets a fresh random key wrapped under its category key. You control the root of trust.
Implementation
HKDF-SHA-256 with domain separation; Shamir Secret Sharing for vault key
Cryptography
Standardized Primitives — No Custom Crypto
We use only battle-tested, standardized algorithms. No proprietary constructions.
Vault items & documents
XChaCha20-Poly1305 (AEAD)
Wire format
SVAULT:v2
Key derivation
HKDF-SHA-256
Vault passphrase stretching
scrypt (N=2^15)
Account login password
Argon2id (server-side)
In transit
TLS 1.2 / 1.3
Key Management
Threshold Cryptography & Key Hierarchy
Your vault key is never stored whole. It is split into shares with Shamir's Secret Sharing, and you choose how many shares exist and how many are needed to rebuild it.
Key Derivation Hierarchy
Master Key (MK)
scrypt (N=2^15) → 256-bit
Vault Key
HKDF(MK, 'vault')
Credentials Key
HKDF(MK, 'credentials')
Documents Key
HKDF(MK, 'documents')
Assets Key
HKDF(MK, 'assets')
Bank
DEK → wrapped by CK
Insurance
DEK → wrapped by CK
Will
DEK → wrapped by CK
Crypto
DEK → wrapped by CK
Property
DEK → wrapped by CK
Investment
DEK → wrapped by CK
Medical
DEK → wrapped by CK
Digital
DEK → wrapped by CK
Each asset/document gets a unique random DEK, wrapped by its category key. Category keys derive from master key via HKDF-SHA-256 with domain separation.
Shamir Secret Sharing
Vault Master Key
Split into the shares you choose — any threshold-many reconstruct
Every share is encrypted to its recipient's own public key before it leaves your device. LifeWyn holds no share of its own, and stores only the sealed envelopes and the audit trail. You choose the recipients and the threshold.
Inheritance
Controlled, Verified, Proportional Disclosure
A hospital stay is not a goodbye. Different life events open different doors — each reveals only what it should, and nothing more.
Multi-Signal Verification
Confirmations and screened documents raise confidence; conflicts, tamper flags and duplicate cases raise fraud risk against it. No single signal decides.
Least Privilege Release
The people you name receive only the key-shares for what you left them — scoped by asset, by condition, and by the timing rules you set. Nothing spills over.
Verified & Auditable
Every release is written to the hash-chained audit trail. And no one is left guessing — each nominee receives a claim kit with the forms, contacts, and step-by-step guidance they'll need.
Release safeguards
Eight checks, and any one of them can stop it
Encryption decides how a record is sealed. These decide what has to be true before it opens at all — and each one is sufficient on its own to hold or cancel a handover.
One-tap cancellation
You can stop any release, at any stage before completion, from your phone. No explanation required.
Verified documents
Certificates and supporting papers have to be submitted and screened. A claim on its own is not evidence.
Recipient identity check
The person claiming access proves they are the person you named, with a government ID and a liveness check. A forwarded email is not enough.
Trusted-contact sign-off
The contacts you nominated are asked to confirm, with a 48-hour window to respond. A single confirmation from you resets the entire sequence.
Waiting periods
Nothing is irreversible during the grace period you chose, and a time lock you set has to elapse even after everything else is verified.
Fraud review
Conflicting evidence caps the confidence score, and ambiguous cases go to human review rather than through. Support staff cannot release a share under any circumstances.
Minimum disclosure
Each recipient receives only the key-shares for the records assigned to them. There is no mode in which anyone receives everything.
No asset custody
LifeWyn never holds your money. Even a complete compromise would expose a map, never a balance.
Transparency
What We Can & Cannot Do
Honest capability model — no marketing fluff, just technical reality.
What LifeWyn Can Do
- Store your ciphertext securely
- Release encrypted key-shares to nominees
- Run automated life-signal check-ins
- Notify nominees when rules trigger
What LifeWyn Cannot Do
- Read your vault contents
- Reconstruct your master key
- Grant access without verification
- Reset your master password
Compliance
Standards, and what we have not certified
What the platform implements, and — just as plainly — which certifications nobody has audited us against.
SOC 2 Type II
No audit has been performed or scheduled
ISO 27001
No certification has been sought
GDPR
Access, rectification and export are implemented; erasure is a recorded request
DPDP Act (India)
Consent records and data-rights workflows are implemented
Data residency
One deployment region today; per-region hosting is not offered
Found a vulnerability?
Report it before telling anyone else. We will not take legal action against a good-faith report.
How to reportQuestions
Asked and answered
How secure is LifeWyn?
Your vault is encrypted on your own device with XChaCha20-Poly1305 before anything uploads, so what reaches our servers is ciphertext. The master key is derived from your passphrase using scrypt and split with Shamir Secret Sharing, so no single party — including LifeWyn — ever holds a working copy. Every release is written to a hash-chained audit trail. We use standardised primitives rather than proprietary constructions, and we hold no formal certification yet: SOC 2 and ISO 27001 have not been started, and we say so on this page rather than letting a procurement team discover it.
Can LifeWyn read my vault?
No. Not because of a policy, but because your records reach us already unreadable. Vault items and documents are stored as ciphertext, and the keys that open them are derived on your device and never sent to us. We can produce ciphertext to a court, a regulator or an attacker, and nothing more.
If you release key-shares, does that mean you can open my vault?
No, and this is the question worth understanding properly. Every share is encrypted to its recipient's own public key before it leaves your device. LifeWyn holds no share of its own, and keeps only the sealed envelopes and the audit trail. A recipient combines the shares released to them with their own to open the records assigned to them, and reconstruction happens on their device. This is why “we release key-shares” and “we have no back door” are both true at once.
What happens if your servers are breached?
An attacker gets ciphertext. Your records stay encrypted, because the key to open them was never there. A leaked backup is as useless as the live database, and an employee with full database access sees nothing readable. This is the practical difference between a service that promises not to look and one that cannot.
What if I forget my passphrase?
LifeWyn cannot reset it. There is no server-side copy of your master key, which is exactly why a breach of our servers cannot expose your vault. Recovery runs through the recovery shares and trusted contacts you set up on your first day, which is why setup asks for them before anything else. If you lose both your passphrase and your recovery shares, the vault cannot be opened by anyone. We know how hard that reads, and it is the unavoidable cost of a design in which your vault stays sealed with keys only you and the people you choose ever hold.
What happens to my vault if LifeWyn shuts down?
You can export everything, any day. The export is a documented open format that you decrypt with your own passphrase and recovery shares, so it opens without our servers and without our company existing. Because we never hold a working copy of your key, no wind-down and no new owner can read your data. If we ever have to close, you get clear advance notice and a full export window first.
Deep Dives
Explore Security Topics
Technical deep-dives for engineers, auditors, and security-conscious users.
Your Keys. Your Rules. Your Legacy.
LifeWyn never holds your master key — it stays with you. You decide who receives shares, when they rotate, and when to revoke them. Give the people you love a way in, long before they need it.
Standard, well-reviewed primitives — no proprietary cryptography