Skip to main content
Use the Owner SDK to renew or reclaim eligible names, transfer your namespace or change its Resolver. These operations require the current namespace owner’s authorization, except transfer acceptance, which the proposed new owner signs. The governed testnet rejects new permanence locks.

Reclaim, renew and treasury

These are separate operations; choose the one you need. Owner renewal accepts an explicit extension. The holder renewal flow instead extends by the immutable policy term and has an early-renewal window. A finite name expires only when ledger time is strictly greater than its expiry. The Registrar also exposes owner-authorized set_renewal_grace(secs), with a zero default and a maximum of 90 days. Grace blocks ordinary reissue for eligible expiries; it does not preserve resolution after expiry or disable owner reclaim. Enabling grace establishes an expiry cutoff. Positive duration changes retain it, while disabling and re-enabling creates a new cutoff. Owner 0.12.0 has no dedicated grace helper, so use the contract interface with the current owner’s authorization.

Transfer the namespace

  1. The current owner proposes the new owner:
  1. The recipient reviews the proposal and accepts with its own SoranOwner client:
Ownership moves on acceptance. To withdraw a pending offer, the current owner calls owner.cancelNamespaceTransfer("acme") instead. Acceptance advances the ownership epoch and disables the previous owner’s native claim settings. The new owner must configure registration; returning to the former owner does not restore old approval authority. Existing holder renewal and record rights remain independent of public-claim enablement. This transfers the namespace in Registry. To transfer one issued name, use the Holder SDK.

Change routing

On an unlocked namespace, the owner can select an eligible Resolver. Its storage is separate: address, memo, text and reverse records do not migrate automatically. Prepare and verify those records before changing routing. Clearing or selecting an incompatible Resolver does not establish a safe default payment destination. Complete payment reads must fail when they cannot verify the instruction. A permanent Registry Resolver pointer cannot change. Holder records within that fixed Resolver remain mutable.

Code upgrades and permanence

The governed testnet keeps contracts upgradeable and rejects makePermanent. You can use a non-reclaimable, no-expiry policy, but it does not remove governance or owner upgrade authority. See ownership guarantees. An approved code upgrade retains the Registrar or Resolver address and storage. Selecting a different Resolver is a routing change and does not automatically copy its records. See governance and upgrades.

Storage availability

Archived contract state still belongs to its recorded owner. Write flows can require extra signed restoration transactions and their network fees. Reads must report unavailable/archived state honestly; a read-only simulation does not guarantee a restore happened. Check included transaction hashes before retrying an uncertain operation.