ERC-7878: Bequeathable Contracts

Inheritance of tokens after the owner's death

Metadata
Status: ReviewStandards Track: ERCCreated: 2025-02-01
Authors
Wamith Mockbill (@wamith)
Requires
EIP-20, EIP-165, EIP-721, EIP-1155
Links
GitHub pageDiscussion on Ethereum Magicians

Abstract

This EIP proposes a standard interface for contracts to allow tokens to be inherited after the owner's death. The interface allows token owners to set up a Will and designate executors to enable the transfer of tokens to inheritors after a specified waiting period.

Motivation

Crypto Tokens in general and NFTs in particular are starting to be used to tokenise real-world assets. In order for them to be adopted by the main stream finance world, there needs to be a way to inherit these tokens after the owner has passed away. Currently, there is no standardised way for token holders to pass on their digital assets in the event of their death.
This EIP aims to solve this problem by providing a standard interface for "bequeathable" tokens, allowing for a secure and transparent process of token inheritance. In designing this interface we have tried to follow the real world process of Will creation and execution.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Every compliant contract MUST implement the Bequeathable interface:



Functions


    

  1. setWill: Allows a token owner to set up or update their Will.
    2. 

  2. getWill: Returns the current Will details for a given owner.
    3. 

  3. announceObit: Initiates the inheritance process by an executor.
    4. 

  4. cancelObit: Cancels an active obituary process.
    5. 

  5. getObit: Retrieves the current obituary status.
    6. 

  6. bequeath: Transfers tokens to the inheritor after the waiting period.
    7. 



Events


    

  1. ObituaryStarted: Emitted when an obituary is announced.
    2. 

  2. ObituaryCancelled: Emitted when an obituary is cancelled.
    3. 



Rationale


The standard follows what currently happens in real life when preparing and executing a Will.


    

  1. An owner writes a Will and in doing so names the executor(s) of their Will
    2. 

  2. Upon passing away, the executor will announce the Obituary
    3. 

  3. The Will is read and the inheritors are identified
    4. 

  4. The transfer of ownership is executed according to the wishes of the Will
    5. 



However, real life is not always as straight forward as this. Conflicts happen all the time. To handle this situation and to keep the interface simple, we added the ability to cancel the Obituary by ANY of the executors. In this way, if there is any conflict, it can be challenged out in the courts and once the matter is settled, the Obituary process can start again.


Again to keep the interface clean, all the tokens get transferred to one address. It is then that person's responsibility to execute any further transfers.


Backwards Compatibility


This EIP is compatible with existing token standards like ERC-20, ERC-721 and ERC-1155. It can be implemented alongside these standards without affecting their core functionality.


Test Cases


Tests are included in Bequeath.test.js.


Reference Implementation


See Bequeathable.sol


Security Considerations


Implementers should carefully consider access control mechanisms to ensure that only authorized parties can execute Will-related functions.


The moratoriumTTL should be set to a reasonable duration to allow for potential disputes or corrections. We recommend at least 30 days, especially for tokens that are of high value.  It limits the potential damage in scenarios such as the obituray process being triggered by a bad actor who has taken over one of the executor wallets.


Copyright


Copyright and related rights waived via CC0.