Security model
Non-custodial, signed, and slow on purpose.
LegacyNetwork never holds private keys, seed phrases or assets, and never signs on your behalf. The only transactions we build are unsigned ones you choose to sign (anchoring your policy fingerprint, paying the optional setup fee).
What is stored
- Wallet addresses of the owner and of accepted guardians and beneficiaries; labels you give them; optional emails.
- Your timers and quorum, and the history of check-ins, reminders, cases and decisions — each with the exact signed message and signature.
- Your instructions as ciphertext: server-sealed (AES-256-GCM, key outside the database) or passphrase-sealed (PBKDF2-SHA256 with 310,000 iterations → AES-256-GCM in your browser; we only store ciphertext, salt and IV).
- Optional claim codes, stored only as scrypt hashes.
Signatures
Sign-in uses Sign-In With Solana. Every proof of life, guardian decision and emergency request is a separate human-readable message naming the action, vault, case, wallet and time. The server rebuilds the exact text, checks the ed25519 signature, rejects anything older than 10 minutes and refuses to reuse a signature.
On-chain anchor
Your policy fingerprint (SHA-256 over timers, quorum, people and the instruction ciphertext) can be written to Solana as an SPL Memo signed by your wallet: legacynetwork:v1|vault=…|policy=…. Anyone can later check which policy was in force.
Threat model
| Threat | Mitigation | Control |
|---|---|---|
| A guardian goes rogue | Cannot act alone: quorum of signed approvals, then your cancel window. Guardians never see instructions. | Quorum ≥ 2 |
| A beneficiary wants early access | Emergency requests need guardians and give you the cancel window; you are notified immediately. A wallet cannot be guardian and beneficiary at once. | Role separation |
| Your session cookie is stolen | Check-ins and decisions need a fresh wallet signature, not just a session. A stolen cookie cannot approve a recovery. | Signed attestations |
| Your wallet is compromised | An attacker could check in or edit the vault. Changes to people and timers are announced to guardians and logged; the anchored policy fingerprint shows what you originally agreed to. | Change alerts |
| Our database leaks | Server-sealed instructions are AES-256-GCM encrypted with a key kept outside the database. Passphrase-sealed instructions are encrypted in your browser and are unreadable to us. | Encryption at rest |
| Our service is down for a week | Nothing can trigger without a final reminder sent ≥ 24 hours earlier; downtime only delays recovery. | Fail-safe timers |
| Phishing invite links | Invites can be locked to a wallet; tokens are random 192-bit values and only their SHA-256 hash is stored. | Hashed invites |
Honest limits
Server-sealed instructions can technically be decrypted by the service operator, which is why we recommend passphrase sealing for anything sensitive. A release is only as good as the instructions you leave. And if you put a seed phrase in your instructions, whoever opens the release can move your funds — we strongly advise leaving locations and contacts instead.
See also: how it works · terms and disclaimers.