[Draft ERC] Succession-Controlled NFTs

ERCs
,
1

Hey Ethereum Magicians,

I’ve been thinking about self-custody and what happens when you can’t access your keys anymore. Not lost keys (social recovery handles that), but permanent unavailability. Death, incapacitation, that kind of thing. Right now the options are custodial services or hoping someone finds your seed phrase. Neither is ideal.

I’ve been working on a minimal standard for ERC-721 tokens that delegate transfer authority to succession registries. Want to get feedback before formal submission.

Repo: github.com/perdura/succession-controlled-nfts

Testnet: Try it on Sepolia

Abstract

TL;DR: An ERC-721 extension where only an authorized registry can transfer your NFT. Combine with ERC-6551 for automatic estate succession.

This ERC defines a minimal interface for ERC-721 tokens that delegate transfer authority to succession registries. When a registry indicates succession conditions are met, only that registry may transfer the user’s token. Combined with ERC-6551 token-bound accounts, a single NFT can control multiple token-bound accounts, and when it transfers through succession, control of all linked accounts automatically transfers to the new holder.

Two interfaces: IERC721SuccessionControlled (an ERC-721 extension) and ISuccessionRegistry (policy verification). Policy logic is up to the implementation: time-based, guardian-approved, oracle-triggered, or custom.

Motivation

How it works: Mint an NFT, deploy a registry, link token-bound accounts, configure your policy. If you stop checking in, your beneficiary can claim control.

image
image1844×202 27.7 KB

Digital assets lack succession mechanisms. When someone dies or loses access permanently:

  • Smart contract ownership doesn’t transfer automatically
  • Assets in DeFi positions, DAOs, and vaults remain locked
  • Successors must locate and claim each asset individually
  • No on-chain mechanism exists for planned, conditional transfers

Existing solutions address adjacent problems:

Social Recovery (ERC-4337, Safe) - designed for emergency key recovery. Requires active guardian coordination, assumes you’ll eventually recover access yourself.

Token Bound Accounts (ERC-6551) - NFTs can own accounts, but no conditional transfer policies. Immediate transfers only.

Dead Man’s Switch (Sarcophagus) - requires off-chain storage dependencies.

Custodial Services - ongoing fees, centralized trust, defeats self-custody.

This standard adds the missing piece: conditional, policy-based NFT transfers. One registry call can transfer an entire estate.

Specification

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

IERC721SuccessionControlled

An ERC-721 extension that delegates transfer authority to a succession registry.

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/IERC721.sol";

interface IERC721SuccessionControlled is IERC721 {
    /// @notice Emitted when a succession registry is authorized for a user.
    event SuccessionRegistryAuthorized(address indexed user, address indexed registry);

    /// @notice Returns the succession registry authorized to transfer a user's tokens.
    /// @param user The token owner
    /// @return The authorized registry address, or address(0) if unrestricted
    function successionRegistryOf(address user) external view returns (address);
}

Requirements:

  1. When successionRegistryOf(user) returns a non-zero address, transfers of that user’s tokens MUST revert unless msg.sender equals the returned registry address.

  2. Implementations SHOULD disable approve() and setApprovalForAll() for succession-controlled tokens to prevent circumventing registry restrictions.

  3. The SuccessionRegistryAuthorized event MUST be emitted when a registry is authorized for a user.

  4. Registry authorization is implementation-specific. Implementations MAY allow direct user authorization, factory-only authorization, or governance approval.

ISuccessionRegistry

Minimal interface for succession policy verification and execution.

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.20;

interface ISuccessionRegistry {
    /// @notice Emitted when succession is executed
    event SuccessionExecuted(address indexed from, address indexed to);

    /// @notice Check if succession conditions are met for a subject.
    /// @param subject Address whose succession status to query
    /// @return True if succession can be executed
    function isSuccessionOpen(address subject) external view returns (bool);

    /// @notice Execute succession for a subject.
    /// @dev MUST revert if isSuccessionOpen(subject) returns false.
    ///      MUST emit SuccessionExecuted on success.
    function executeSuccession(address subject) external;
}

Requirements:

  1. isSuccessionOpen(subject) MUST return true only when all succession conditions for subject are satisfied.

  2. executeSuccession(subject) MUST revert if isSuccessionOpen(subject) returns false.

  3. executeSuccession(subject) MUST emit SuccessionExecuted on successful transfer.

  4. Policy logic is implementation-specific. Time-based inactivity, guardian approval, oracle triggers, any combination.

Security Consideration: Deploy separate registry instances per subject. Multi-subject registries create centralization risk and honeypot attack vectors.

Rationale

Minimal Interface Design

Two functions per interface. A registry only needs isSuccessionOpen() and executeSuccession(). How it determines “open” is up to the implementation.

Subject Parameter

The subject parameter supports both single-subject registries (recommended) and multi-subject registries. Single-subject deployments via EIP-1167 minimal proxies provide better security isolation at minimal gas cost.

Registry-Controlled Transfers

Standard ERC-721 transfer functions (transferFrom, safeTransferFrom) remain callable but MUST revert when a registry is authorized. This preserves interface compatibility while enforcing succession rules.

ERC-6551 Integration

This standard complements ERC-6551 token-bound accounts. A succession-controlled NFT can own multiple TBAs. When the NFT transfers through succession, the new holder automatically controls all linked TBAs and their contents. No per-account claims required.

Why Not Modify ERC-6551 Directly?

ERC-6551 defines account ownership, not transfer policies. Succession logic belongs at the NFT layer, not the account layer. This separation lets any NFT provide a succession mechanism without touching account implementations.

Reference Implementation

84 tests passing. Gas: ~384k for atomic estate creation (NFT + Registry + TBA), ~27k for policy setup, ~100k for succession execution.

github.com/perdura/succession-controlled-nfts

Questions

  1. Is the interface minimal enough, or should it be even simpler?
  2. Existing efforts I should know about or collaborate with?
  3. Attack vectors I’m missing? Security analysis
  4. Should this require ERC-6551, or stay agnostic to account type?
  5. Should estate creation and policy setup be atomic? Keeping them separate leaves the factory policy-agnostic but creates an intermediate unconfigured state.

Tear it apart.

Thanks to Jeffrey Scholz for encouraging this work as a standard and for early feedback.