[Draft ERC] Succession-Controlled NFTs

[tian0]

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.

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.

[wjmelements]

I like the idea of NFTS being used for ownership policies (ERC-6551). They are a good match because your estate might divide among several parties and so you can have different policies (or even estate executors) for different assets.

As for the keepalive message, that’s a good fit if you trust your executor. One problem is that it expects you to constantly ping it. Another possibility would be to allow the executor to challenge you and then you would have some configurable duration to reply. If you get annoyed because they challenge you while you are still alive, you could replace them.

Did you also consider an EIP-7702 based approach? My previous idea to solve this was largely to hand over your entire account to the executor (which could itself be a smart contract or a policy).

[Ankita.eth]

This is a strong primitive. Anchoring succession at the ownership layer instead of the account layer creates much cleaner isolation and enables independent policies per asset domain.

One improvement that could make this significantly safer is introducing an explicit succession state machine rather than a binary eligibility check. For example:

• Active → Challenged → Grace Period → Executable → Finalized

This makes succession progression transparent, gives the owner a deterministic recovery window, and prevents abrupt ownership transitions based purely on inactivity assumptions.

Another useful direction could be allowing owners to pre-commit succession intent using signed authorizations that registries can verify later. This shifts the trust model toward cryptographic intent rather than continuous liveness monitoring, which is inherently unreliable over long time horizons.

Compared to account-level delegation approaches like ERC-7702, ownership-rooted succession provides more granular control and avoids full account takeover risk. It also composes naturally with ERC-6551, where each succession NFT can represent an isolated control boundary.

This approach has the potential to establish succession as a native ownership primitive rather than something layered on top of account abstraction.

[tian0]

Thank you both for digging into this.

@wjmelements good point on the check-in being a burden. A challenge-response model would be a lot more practical. And being able to replace an executor who challenges prematurely is a useful safeguard.

7702 came up early in the design process. @zergity’s InheritableEOA takes that route. As Ankita noted, NFT-rooted succession avoids full account takeover. The two approaches solve different parts of the same problem and I think they could compose.

@Ankita.eth the state machine progression is an elegant approach. The reference is basically binary right now, but Challenged and Grace Period states would give owners a clear recovery window. It also ties into the challenge-response pattern @wjmelements brought up.

For signed authorizations, pre-committing intent cryptographically could work. Revocation improves on the reference since it’s reactive instead of periodic.

One question this raised for me: Should registry safety patterns like state progression live in this spec, or evolve separately?

My thinking is to keep this spec minimal and let registry design evolve independently, but I could see the argument for baseline requirements. I’m curious about your take on that.

[Ankita.eth]

I think keeping the ERC minimal is the correct approach. The ERC should only define the ownership transfer authority and registry interface, not enforce specific safety patterns.

State progression, challenge-response, and revocation logic belong at the registry implementation layer, since different use cases will need different policies and risk models.

What could help is documenting recommended registry safety patterns separately, so implementations can follow secure designs without making the ERC itself too restrictive.

This keeps the standard flexible while still enabling safer registry implementations.

[tian0]

Great point. Documenting safety patterns separately so they’re not buried in the spec or too restrictive sounds like the best path forward.