Dev Update 006: The Inheritance Protocol Explained
Hey Unchained Community,
When a crypto holder dies or becomes permanently incapacitated, their assets are typically lost. There is no standardized, trustless mechanism for transferring ownership to heirs without involving a centralized custodian. The Inheritance Protocol is built to change that.
How It Works
Setup is a single instruction: setInheritancePlan(beneficiary_addresses, shares, waiting_period). The contract records the configuration and a timestamp of the last activity. From that point, the user's normal on-chain behavior, any transaction signed by their wallet, automatically updates the lastActive timestamp. No special action required. Ordinary usage is the heartbeat.
If no transaction occurs within the waiting period, any address can call claimInheritance. The contract verifies inactivity, then transfers the user's token balance to the designated beneficiaries according to the predefined shares.
The Delayed Distribution Window
After claimInheritance is called, assets don't transfer immediately. A secondary waiting period, configurable, separate from the inactivity threshold, gives the original user time to reappear and contest. If the user signs any transaction during this window, the claim is cancelled and the plan resets. This exists specifically to handle edge cases: extended hospitalization, loss of internet access, or any situation where a user is temporarily unreachable but not actually gone.
Privacy
The contract stores a hash of the inheritance plan on-chain. The actual plan, beneficiary addresses, share percentages, waiting period, is stored off-chain and revealed only at the point of claim. From an on-chain perspective, all that's visible during normal operation is that a plan exists. The contents are not public until they need to be.
The Dead Man's Switch Architecture
At the smart contract level, this is implemented as a dead man's switch pattern. The inactivity threshold is tracked in slots, consistent with how the rest of the protocol suite handles time. The heartbeat can be any valid on-chain transaction, the user doesn't need to send dedicated heartbeat transactions if they're actively using their wallet. The zero-value heartbeat option exists for users who hold but rarely transact.
Current internal work involves validating the interaction between the delayed distribution window and heartbeat resets near the inactivity boundary. These edge cases are well-understood in design. The work is ensuring the implementation matches the spec precisely.
The Solana Unchained Dev Team