An inheritance product asks for an unusual amount of trust: you are betting that it still works correctly years from now, when you are not around to check. That bet deserves an honest inventory rather than a marketing page.
Everything below is current as of the date on this article.
Status
Beta, on Solana devnet. The inheritance program and the Legacy Vault run against a test network. Devnet tokens have no monetary value and the network is reset periodically. Set it up, rehearse a full claim, learn how it behaves — but do not treat it as a settlement for real assets yet.
Not externally audited. The on-chain program has an internal test suite and an end-to-end release test, and it has not yet been reviewed by an independent security firm. Until it has, treat the guarantees on these pages as our best engineering effort rather than an audited fact.
Program upgrade authority. While a program remains upgradeable, whoever holds that authority could in principle change its rules. Locking it — or placing it under governance — is part of the path to mainnet, and is not done yet.
The vault's release path
This is the most important limitation on this page.
The asset side is enforced entirely on-chain. Nobody, including us, can release deposited assets early or block a legitimate claim.
The vault side cannot work that way, because a public blockchain cannot hold a secret. Item keys are split into shares across separate parties, and today one of those parties is our backend, which also performs the on-chain check that decides whether an heir may receive its share.
What that means concretely
Our share alone reveals nothing, so a compromise of our storage does not expose your vault. But because our backend both holds a share and makes the release decision, an operator or attacker with sufficient control of it — acting together with an heir — is the one remaining path to an early release. The chain is checked correctly today; that check is not yet enforced by something other than us.
The intended fix is to widen the share set to include independent guardians, so that no single operator holds enough to matter and the release decision is not concentrated in one place. That work is specified and not yet shipped.
Until it is, size what you put in the vault accordingly, and prefer the passphrase-split pattern for anything catastrophic if released early — see storing a recovery phrase.
Design trade-offs
- Metadata is not encrypted
Item titles and categories are stored in the clear so lists can be rendered. Name items accordingly.
- A released recovery phrase cannot be recalled
The gate prevents releases that have not happened; it cannot un-read words. Hence the required passphrase split.
- SOL is the only inheritable asset today
The on-chain program can escrow SPL tokens and NFTs, but the app does not yet expose a way to deposit them. Only deposited SOL passes to an heir.
- SPL deposits would be hard to reclaim
When token deposits arrive: reclaiming a finalized estate returns SOL, but deposited tokens are not enumerable in one instruction and would not be returned automatically.
- Compressed NFTs cannot be escrowed at all
A cNFT lives in a Merkle tree rather than a token account, so the vault cannot hold one even once token deposits ship.
- One heir
A single primary heir. The data model allows more later; the product does not do it today.
- Solana only
No EVM chains, no Bitcoin. External wallets are covered by vault items, not by on-chain escrow.
- No hardware wallet support
A ledger-style device cannot currently be used with the Switch.
- Finalization is terminal
Deliberate, so a returning owner cannot strip an heir. It also means a false trigger takes a slower reclaim path.
Operational caveats
Notification delivery. Device-scheduled warnings work offline and are the primary safety net — but only once you have granted the OS notification permission. Until you do, nothing is scheduled at all and no warning will ever arrive. The inheritance screen's contact card shows the current state and links straight to the system setting; if it reads Device notifications: Off, that is your safety net switched off. Remote push additionally depends on platform configuration that is not complete on every platform, so do not build your plan on push arriving.
Vault items sealed before your heir registers. An heir has to register a vault key of their own before anything can be encrypted to them. If you add items first, they are stored with no heir share — readable by you, not yet releasable to them. The app repairs this by re-sealing those items the next time you open the Legacy Vault screen. So if your heir registers late, open your vault once afterwards and let it settle, or those items will not be readable by them on release.
Warnings can be stale. Each device schedules from the state it last saw, so a check-in on another device may not immediately silence a warning elsewhere. All warning copy therefore says "open the app" rather than asserting your status.
RPC dependence. Balances, history and status come from Solana RPC endpoints. A rate-limited or degraded endpoint shows stale data. The chain is always the authority — check a block explorer if something looks wrong.
What this is not
Not a legal instrument. Not a substitute for a will. Not regulated financial advice. Not insured. Not a backup service for your own access.
Why publish this
Because the alternative is asking you to trust a description that is more flattering than the code. If any of the above changes materially, this page changes with it — the date at the top is the version you are reading.
Questions about any of it are welcome, and the honest answer is more useful to us than the comfortable one.