HIP: Native Recursive Name Coins

[denuoweb]

This PR proposes Native Recursive Name Coins, a consensus mechanism that allows an active Handshake name to register an immediate child as an independent first-class Handshake name coin.

After registration, the child has independent ownership, resource data, renewal, transfer, revocation, and recursive delegation state. It survives the transfer, expiration, revocation, and re-registration of its ancestors.

This proposal is an alternative to the secondary-tree architecture described by HIP-0016. It accepts greater authenticated global state in exchange for native name ownership and independent child transactions.

The proposal requires a hard fork. This PR does not propose an activation height and does not claim production readiness. It is being submitted as a draft for protocol and consensus-design review.

[shadstoneofficial]

Thanks for putting this proposal forward. We operate .agent, .chatbot, and other managed namespaces through HeadlessDomains, alongside Bob Wallet and several Handshake resolver, browser, hosting, and marketplace applications. Native Recursive Name Coins could therefore have a significant practical impact across our ecosystem.

Directionally, we support the goal. Giving an SLD independent ownership, renewal, transfer, resource data, and recursive delegation could make SLDs substantially more useful for long-term identities and applications.

We also understand that sovereign children would not be maintenance-free. Each child receives its own Handshake renewal state and follows the existing renewal and expiration lifecycle independently of its parent. Renewing .agent would not renew janice.agent, and expiration of .agent would not invalidate an independently renewed janice.agent. We support requiring native SLD owners to carry substantially the same ongoing renewal responsibility as TLD owners.

Existing SLD migration

Our largest concern is migration of existing SLDs.

HeadlessDomains already has active customers holding annually renewable managed registrations such as janice.agent. These registrations exist in a registry database and DNS infrastructure; consensus has no knowledge of the customer’s entitlement.

As written, existing SLDs would not automatically become native child coins. After activation, the parent owner would need to register each child and choose its initial on-chain recipient address.

Could the HIP explicitly address migration and collision policy for existing managed or DNS-issued SLDs?

Our intended commercial policy would likely be:

• Existing managed registrations continue under their present annual lifecycle.
• An active customer receives exclusive first right to convert their matching SLD into a sovereign child.
• Native conversion is an optional premium upgrade, not an automatic migration.
• The child is issued directly to a wallet address verified as controlled by the customer.
• A customer who declines conversion keeps the existing managed registration.
• The parent operator does not issue that matching native child to another party while the managed registration remains active and in good standing.

This would let registries preserve existing customer commitments while introducing native ownership as a stronger and distinct product.

The protocol itself cannot enforce that policy, however. A parent could technically register an existing customer’s SLD to any address. It would be helpful for the HIP to discuss expected best practices, migration windows, existing-registrant protection, and proof of recipient-address control.

Managed registration versus native ownership

For registry operators, native issuance materially changes the product.

Before conversion, a registry may control annual renewal, account recovery, transfers, expiration, DNS, and reassignment. After native issuance, the parent cannot revoke, reclaim, replace, or impose future registry rent on the child while it remains active.

That makes a premium initial issuance or conversion price reasonable. Recurring revenue would then come from optional services such as managed DNS, manifests, hosting, monitoring, assisted renewal, custody, multisig, and marketplace services—not from the ability to confiscate the native name.

Does the proposal expect the registration transaction to support an ordinary payment output to the parent alongside DELEGATE and REGISTER_CHILD? A standardized atomic issuance pattern could allow the transaction to:

1. Recreate the parent coin;
2. Create the sovereign child;
3. Lock the child’s required HNS value;
4. Pay an agreed issuance amount to the parent.

This would be useful for registries and marketplaces, especially if the recipient can safely contribute the child value and issuance payment without giving the parent custody of the resulting name.

Existing DNS collisions

The resolution rule also creates a migration concern.

If janice.agent already exists as an ordinary DNS child and a native janice.agent is later registered, upgraded resolvers must prefer the native child. The native registration can therefore change the meaning of a hostname already in production.

The HIP should explicitly document:

• How ordinary DNS children and native children interact;
• Recommended migration procedures;
• Whether resolvers should expose that a native boundary replaced an ordinary parent-controlled child;
• How registries should prevent accidental or malicious shadowing during transition.

Descendant discovery and TLD encumbrances

We agree that wallets and marketplaces must disclose that a TLD may be encumbered by independently owned descendants.

Our concern is that the rolling child-log commitment does not make those descendants enumerable or self-retrieving. It verifies a supplied history, but a seller, archival node, or indexing service must still retain and provide the underlying sequence.

A buyer of .agent needs a dependable way to discover every active sovereign child and evaluate the namespace restrictions being inherited. If the history is unavailable, the buyer may know that child registrations occurred without being able to determine which children remain active.

Could the proposal provide a stronger data-availability or indexing expectation for:

• Complete child-history retrieval;
• Active descendant enumeration;
• Verification by wallets and marketplaces;
• SPV-compatible encumbrance proofs;
• Recovery when the seller does not provide the history?

Renewal versus permanent state

We recognize that active child ownership expires without renewal. Our state-growth concern is different: every first registration creates a permanent authenticated tombstone even after the child expires.

The proposal has:

• No child auction;
• No burned registration fee;
• No per-parent lifetime quota;
• No separate state fee;
• A minimum 1 HNS locked output;
• A new unusable historical output when an expired child is later re-registered with another generation.

Has the 1 HNS threshold been evaluated against the permanent authenticated-state, proof-bandwidth, indexing, UTXO-history, and renewal costs created by each child?

Before activation, we would like to see measurements covering:

• State growth per initial child;
• State growth per later generation;
• Proof sizes at realistic and maximum depths;
• Resolver costs for checking every suffix;
• Archival/indexing requirements;
• Spam economics at different HNS prices.

A burned registration component, dynamic minimum, state bond, or another mechanism may be worth evaluating if 1 HNS does not adequately price the permanent network burden.

Bob Wallet and ecosystem implementation

Bob Wallet embeds hsd and directly uses its covenant, NameState, wallet, transaction, DNS resource, full-node, and SPV components. Supporting this fork would require considerably more than recognizing two new covenant numbers.

Bob would need:

• A compatible hsd implementation;
• Recursive name hashing and full-name display;
• DELEGATE and REGISTER_CHILD transaction support;
• Generation-based child lifecycles;
• Independent child renewals, updates, transfers, finalization, and revocation;
• Parent-encumbrance disclosure;
• Child-history retrieval;
• Full-node and SPV proof support;
• Ledger and other hardware-wallet signing support;
• Safe activation and database migration behavior.

Our browsers and gateways would need deepest-active-child resolution before ordinary DNS or HeadlessDomains API fallback. Our marketplaces would need to distinguish root TLDs, native sovereign children, and managed conventional SLDs.

We would not support activation until there is:

• A reference hsd implementation;
• Defined node and wallet RPCs;
• Indexing and history-retrieval interfaces;
• Regtest vectors and integration tooling;
• Full-node and SPV proof implementations;
• Resolver compatibility testing;
• Hardware-wallet support;
• A substantial public testnet period;
• A clear chain-split and rollback plan.

Overall position

We are supportive of exploring Native Recursive Name Coins. The ownership model could enable a meaningful new class of independently controlled Handshake identities and could give existing namespace operators a path from managed registrations to optional sovereign ownership.

We would be interested in testing HeadlessDomains issuance and Bob Wallet claims on regtest or a dedicated testnet.

Before supporting a mainnet hard fork, however, we would want the proposal to resolve or more fully specify:

1. Protection and migration of existing SLD registrants;
2. Collisions with existing ordinary DNS children;
3. Atomic paid issuance and recipient participation;
4. Descendant-history availability and TLD encumbrance discovery;
5. Permanent-state economics;
6. Concrete wallet, RPC, SPV, resolver, and hardware-signing requirements;
7. Activation readiness and ecosystem coordination.

We think HeadlessDomains and Bob Wallet could provide a useful real-world implementation case once the consensus design reaches that stage.