Summary
Design, but do not yet implement, explicit and safe ways to preserve registered names when an owner wants a successor or becomes permanently inactive.
This preserves the useful part of Q-Support record 45abad68f163701f57fa11cf, “Add Inheritance Lists to Names.” Its proposal included an ordered heir list, a long inactivity trigger, a response window for each successor, and eventual reclamation of names with no configured successor.
Current Qortium behavior
Qortium supports an owner-initiated zero-price direct name transfer that a named recipient must accept through the existing sell/buy-name flow. It does not currently have:
- successor or heir lists;
- inactivity-triggered succession;
- delayed claims or successor response windows;
- delegated permissions over a name;
- automatic name release, auction, or lottery; or
- consensus state for cancelling and resolving succession conflicts.
Required design split
Treat these as separate policy and consensus questions:
- Voluntary succession: an owner deliberately configures one or more prospective successors, with clear activation, delay, notification, acceptance, cancellation, replacement, and conflict rules.
- Inactivity reclamation: a separate decision about whether and when a name with no active owner action can ever become available again.
The design must define what counts as owner activity, how false death or lost-access assumptions are reversed, what happens during reorgs and concurrent transfers, and how existing names/state migrate.
Explicitly out of scope
- Account balances, private keys, minting rights, and every asset other than the registered name.
- Automatic confiscation or redistribution of account funds.
- A lottery or auction mechanism unless separately proposed and approved.
- Implementation before a threat model and consensus-compatibility review are accepted.
Control of a name is not control of the account that owns it.
First deliverable
Produce a design document covering:
- goals and non-goals;
- voluntary succession and inactivity reclamation as independent state machines;
- transaction and repository state changes;
- activation, delay, acceptance, cancellation, and conflict semantics;
- abuse cases, recovery paths, reorg/orphan behavior, and migration;
- API/client implications; and
- protocol compatibility and activation strategy.
This item is intentionally deferred for later design discussion. Code should not begin until the policy and consensus design receive maintainer approval.
Summary
Design, but do not yet implement, explicit and safe ways to preserve registered names when an owner wants a successor or becomes permanently inactive.
This preserves the useful part of Q-Support record
45abad68f163701f57fa11cf, “Add Inheritance Lists to Names.” Its proposal included an ordered heir list, a long inactivity trigger, a response window for each successor, and eventual reclamation of names with no configured successor.Current Qortium behavior
Qortium supports an owner-initiated zero-price direct name transfer that a named recipient must accept through the existing sell/buy-name flow. It does not currently have:
Required design split
Treat these as separate policy and consensus questions:
The design must define what counts as owner activity, how false death or lost-access assumptions are reversed, what happens during reorgs and concurrent transfers, and how existing names/state migrate.
Explicitly out of scope
Control of a name is not control of the account that owns it.
First deliverable
Produce a design document covering:
This item is intentionally deferred for later design discussion. Code should not begin until the policy and consensus design receive maintainer approval.