CIP-Wallet Inheritance

Placeholder for Wallet Inheritance

(Work in progress)

CIP: ?
Title: Wallet Inheritance
Authors: Roar Holte
Comments-URI: CIP-Wallet Inheritance
Discord: Youblob
Ideascale proposal: Online Makerspace
Status: Draft
Type: Standards
Created: 2023-08-12
License: CC-BY-4.0
Requires: Cardano native wallet
Relation: This effort will be presented for the Cardano Summit Hackathon 2023


Whitepaper: Whitepaper
Beta release: [can test blueprint functionality]
Dora BUIDL: Youblob | Buidls | DoraHacks
Youblob-Cardano Source code: Bitbucket

Similar projects

Dead Man’s Chest - GitHub - ariady-putra/morbid: Davy Jones' Locker

Dead Man’s chest smart contract is an example to solve a very well known problem in cryptocurrencies. Upon death or lost keys, it is no longer possible for next of kin / beneficiaries to retrieve crypto assets.

We can look at the Dead Man’s Chest as a subscription based model, where the User needs to micromanage the Treasury Chest, fill it up with valuables and maintain the lock manually, and the recipient of a Dead Man’s Key needs to have an understanding on how to proceed by unlocking the Chest. Meaning there are several thresholds to overcome in order for it to work seamlessly in both ends.

Summary of the differences;

Dead man’s chest CIP-Wallet inheritance
Create Chest Automated native wallet is given upon registering user account in system
Add Treasure Automated using connected native wallet connected to User
Delay Unlock Automated by default, inactivity period can be edited/set through User settings along with new recipient of inheritance.
Unlock Chest 2FA/Spending password is used for purchases
Resend Chest N/A


  • The main purpose with this proposal is to lower the threshold from the end User and recipients by enabling an automatic inheritance solution through a wallet, creating standard processes for systems running native cardano wallet solution.

  • Through the cardano native wallet implementation, the system is currently set to handle the wallet secret keys. This is to create a baseline for the function, and hopefully see how it can be adapted to f.ex Lace later on.

  • Inheritance; as Blueprint NFT’s will continue to generate income even if the Author(s) passes away or stops using a service, a smart contract to handle account inactivity is added.

  • A User must be able to go in and edit the inheritance function by setting a new wallet address through a UI

  • The recipient of an inheritance should not need to do anything other than see a transaction have been made towards their wallet with all assets transferred.

User Journey Pre-requisites

  • Cardano native wallet is implemented giving End-User a digital wallet upon registrating a User Account in the system.
  • The system handles the secret keys, but Users can set spending password/2FA to confirm transactions on daily use.

User Journey

  • By default the inheritance wallet is set to the system Treasury, a wallet maintained by the System owners, where voting by the community on different DIY projects are introduced and supported.
  • Users are able to edit their own inheritance wallet settings through their profile and set their own private wallet address.
  • Users are able to set period before rule is set in effect. [i.e.; 1 month - default 3 years]
  • Users will get notification through their registered channels before the inheritance rule is set in effect by the system.
  • IF there are less than x value in wallet, inherit rule is ignored.
  • The period is on a loop, and will always trigger the check each time the set period is reached.
  • The inherit function can be used as a paid service (User needs to activate it) or come predefined.

How to test

  • After new User registration.
    • Verify that system created a native wallet for end-user.
    • Verify that system included inherit rule on wallet.
    • Verify that system included free predefined Treasury Wallet for the inherit address.
      • [Optional] Verify that the User is able to activate Wallet Inherit and add their own address of their choosing.
  • Daily operations - Owner
    • Verify that the User is able to update Wallet Inherit recipient address by paying the transaction fee.
    • Verify that the User is able to update Wallet Inherit grace period by paying the transaction fee.
    • Verify that Inherit rule is triggered when x value in wallet is above set threshold.
    • Verify that Inherit rule is not triggered when x value in wallet is below set threshold.
    • Verify that Inherit rule is retriggered indefinitely each time it reaches check period.
    • Verify that Inherit rule grace period is reset every time User logs in to the system.
  • Daily operations - Recipient
    • Verify that funds have been received for each period.
    • Verify that Inherit can be set up as a train, where each Wallet Inherit rule pushes the funds down to the next cart (read: wallet)


  • inactivity [the time reached between each login to a service]
  • inheritance [rule for transferring assets from one wallet to another]
  • system owners [Admins & Devs maintaining the system]


To fully embrace the different aspects around real life events by enabling functionality to prevent value loss in a system and making it easy for the end-users and recipients to use the system.



Metadata JSON schema

Metadata example including the transaction metadata label


The format of the content field is required to be an array of 64 bytes chunks, as this is the maximum size of a JSON field in the Cardano ledger.
Tools, such as wallets, are required to recompose the content of the message.

The current Cardano protocol parameter for maximum transaction size, that will hold the metadata, is around 16KB.

Backwards compatibility

No backwards compatibility breaking changes are introduced.

Reference implementation

We leave the decisions, such as what and how to display communication messages, up to downstream tools and wallets.


This CIP is licensed under CC-BY-4.0

1 Like