Reclaim a domain by proof

See Domains for what a domain is and how it’s normally created, administered, and transferred. This page covers reclaiming a domain’s on-chain authority by DNSSEC proof — the sovereign-DNS counterpart to authorizing a new domain by proof — including its timelock mechanics, its threat model, and the sithbit domain reclaim command tree.

sithbit domain reclaim <domain> \
  ( --witness-file <path> | --witness-hex <hex> ) \
  [--payer-keypair <path>] \
  [--skip-preflight]

Reclaiming is the sovereign-DNS counterpart of domain authorize. Where authorize mints a new domain from a DNSSEC proof, reclaim targets a domain that already exists and seizes its on-chain authority for the wallet address a fresh proof establishes — even when that domain is held by someone else on chain. It is the same proof-carrying, permissionless machinery: anyone may submit a current DNSSEC proof and pay for it, because the proof, not the signer, is the authority. The one difference from authorize is the guard rail — a reclaim does not take effect immediately. It runs behind a 7-day timelock, so the current on-chain authority has a window to notice and respond.

DNS is the root of trust, forever

This is the deliberate design intent, stated plainly: the DNS owner of a domain can always reclaim its on-chain authority. On-chain possession of a domain is never permanently sovereign against the DNS root. Whoever controls the domain’s DNSSEC delegation today — and can therefore publish a current _solana.authority.<domain> TXT and sign it down a chain that anchors to the postoffice’s root KSK — can produce a proof that binds the domain to a wallet of their choosing, and reclaim it.

That is not a loophole; it is the point. SithBit domains are DNS domains. Ownership of the on-chain MailDomain account tracks ownership of the real domain name, and the real domain name is governed by DNS, not by the chain. If a domain changes hands at the registrar, or a stale/hostile party holds the on-chain authority, the rightful DNS owner is never locked out: a fresh proof reclaims the authority. The chain defers to the DNS root of trust as the final arbiter of who owns a name.

The two-step timelock

Because a reclaim can seize a live domain’s authority, it cannot be instantaneous — that would let a fresh proof yank a domain out from under its current holder with no warning. So a reclaim is a request → wait → finalize flow, mirroring deactivation’s shape:

1. Request. domain reclaim stages the DNSSEC witness and, on a verified proof, opens the timelock: it creates a small transient PDA seeded on the domain, stamped with the current chain time and the proven incoming authority (the ed25519 key the leaf TXT published). The MailDomain account itself is untouched — its authority does not change yet. The presence of that pending PDA is the “reclaim pending” flag.
2. Wait. A 7-day clock runs (RECLAIM_TIMELOCK_SECS). During it the domain keeps its current authority and mail keeps flowing.
3. Finalize. Once the clock elapses, domain reclaim --finalize installs the recorded authority onto the domain and closes the pending PDA. The chain was walked once, at request time, so finalize trusts the recorded key and is permissionless — any fee-payer may crank it. The rent refund, however, does not follow the cranker: the pending PDA records the wallet that funded the request, and finalize pays the refund back to that wallet. A stranger turning the crank performs a service; they cannot capture the requester’s deposit by doing so.

Before the timelock elapses, the reclaim can be cancelled by either the domain’s current authority (the standing holder rejecting an unwanted reclaim) or the proven key itself; the canceller receives the pending PDA’s rent refund. Cancelling is authority-gated rather than permissionless, which is why it is the one path where the refund follows the signer.

Request the reclaim

sithbit domain reclaim <domain> \
  ( --witness-file <path> | --witness-hex <hex> ) \
  [--payer-keypair <path>] \
  [--skip-preflight]

The witness, its two input sources, the client-side size bound, the automatic buffer staging + ComputeBudget bump + precompile emission for non-RSA chain links, and the automatic buffer close on success are exactly as domain authorize describes — a reclaim reuses that whole pipeline. It also requires the same prerequisite root KSK and charges the same authorization fee (0.01 SOL by default) once the proof verifies. The --payer-keypair funds the pending PDA’s rent plus that fee and is the only required signer.

sithbit domain reclaim example.com --witness-file ./proof.bin

Finalize after the timelock

sithbit domain reclaim --finalize <domain> \
  [--payer-keypair <path>] \
  [--skip-preflight]

Once at least 7 days have passed since the request, this swaps the domain’s authority to the proven key and closes the pending PDA (rent to the fee-payer). Run before the timelock has elapsed, it is rejected on-chain (ReclaimTimelockNotElapsed). It is permissionless — the fee-payer need not be anyone in particular.

sithbit domain reclaim --finalize example.com

Cancel a pending reclaim

sithbit domain reclaim --cancel <domain> \
  [--keypair <path>] \
  [--skip-preflight]

Aborts an in-flight reclaim before it finalizes, closing the pending PDA. The signer must be the current authority or the proven key; the domain stays with its current authority as if the request had never happened.

sithbit domain reclaim --cancel example.com

Seeing a pending reclaim

domain get surfaces any in-flight reclaim beneath the domain’s authority line — the request timestamp, the proven incoming authority, and whether the timelock has elapsed:

sithbit domain get example.com

Domain 'example.com' (…) has authority <current> and is active
Reclaim pending: requested at <ts> for authority <proven key>; timelock not yet elapsed (unlocks at <ts>)

A pending reclaim freezes the marketplace

While a reclaim is pending, the domain cannot be bought or listed. Both domain buy and domain sell are refused on-chain with DomainReclaimPending (error 71). This closes an obvious front-run: without it, a holder who saw an incoming reclaim could dump the domain on the open marketplace — selling it out from under the reclaimer — or a buyer could pay for a domain that is about to change owner. Once the pending is cancelled or finalized (or never existed), listing and buying are allowed again.

Threat model: the timelock is the defense window

The 7-day timelock is the whole security argument for reclaim. A reclaim proves DNS ownership as of proving time — it is a snapshot of the domain’s DNSSEC state when the witness was assembled. The timelock turns that snapshot into a notice-and-veto window: the current on-chain authority (or an operator watching for pending reclaims) sees the request, and can cancel it, migrate custody, or otherwise respond before the authority actually changes hands. Nothing is seized silently or instantly.

That window also bounds a subtler risk. A DNSSEC RRSIG is valid for its whole signature window, so a proof reflects DNS state at the moment it was signed, not the moment it is submitted — a proof captured while a party controlled the domain stays cryptographically valid until its RRSIGs expire, even if control has since moved on. The timelock caps the damage of such a stale-but-still-valid (replayed) proof: because finalizing takes 7 more days after the request lands, the true current owner always has time to notice a reclaim opened against an out-of-date proof and cancel it. The defense is not “proofs never go stale” — it is “a stale proof cannot complete a reclaim faster than the real owner can veto it.” Keep signature windows short and rotate the delegated authority key when custody changes to shrink the replay surface further.

For the broader admin-key and trust discussion, see the threat model.

Related

• Domains — what a domain is and its normal creation/administration lifecycle.
• Authorize a domain by proof — the sibling operation that mints a new domain from a DNSSEC proof, with no timelock.
• Looking up a domain — reading a domain’s current authority and any pending reclaim.
• List a domain for sale — the marketplace listings a pending reclaim freezes.
• Threat model — the broader admin-key and trust discussion this page’s threat-model section draws on.