Summary
Naming systems make different promises about persistence. Some registrations expire unless renewed on a chain. Some records disappear unless republished. An onion-service address instead depends on its identity key. Treat renewal, publication and key backup as separate jobs.
How it works
| System | Lifecycle in the cited documentation | Operational consequence |
|---|---|---|
ENS .eth registration |
Registration has an expiry; the registrar documents a 90-day grace period before a temporary premium auction. Anyone can pay to renew a name. | Monitor the registration's expiry and renew before it. This rule does not describe every ENS name or subname. |
| Handshake | hsd mainnet sets renewalWindow to (2 * 365) * blocksPerDay: roughly two years expressed in blocks. |
Monitor the chain's name state and renew well before the window closes. Wall-clock estimates are not the consensus rule. |
| Namecoin | The FAQ specifies semi-expiry after 31,968 blocks without an update or renewal, then final expiry after another 4,032 blocks. | Semi-expiry stops resolution while retaining ownership; after final expiry anyone may register the name. |
| Pkarr | DHT records are ephemeral and require periodic republishing. | Keep a publisher running and retain the key needed to sign fresh records. |
| Onion services | Tor stores the service's identity keys in HiddenServiceDir; its setup guide requires protecting that directory. |
Back up the service keys securely if the same address must survive a host loss. |
Trust model / threat model
The renewal wallet and publication key are high-value credentials. Tor explicitly warns that someone obtaining an onion service's keys can impersonate it. A backup must therefore be both recoverable and protected from disclosure.
A renewal and a record update are not interchangeable across these systems. ENS permits another account to pay a renewal without making that account the owner. Namecoin's FAQ distinguishes update/renewal from re-registration after expiry. Use the actual state transition for the system you operate.
A maintenance plan
Keep an inventory of names, controlling keys, renewal or republishing obligations and a recovery contact. Set reminders with enough time to fix a funding or signing problem. Rehearse restoring a noncritical name or test service before relying on a backup for a public address. For Pkarr, test resolution after restarting the publisher; for an onion service, confirm that restoring the key directory restores the expected address.
Readiness
Usable. These mechanisms are documented, but each has its own maintenance model. There is no universal recovery desk behind a key-controlled name.
Limits
This covers the named registration and publication mechanisms, not every wallet's recovery feature or every subname policy. A name can resolve correctly while its destination is unavailable. Plan naming and hosting recovery together.
Primary sources
- ENS ETH registrar, renewal and grace period
- Handshake hsd mainnet renewal parameters
- Namecoin FAQ: semi-expiry, expiry and wallet backup
- Pkarr record lifetime and republishing
- Tor onion-service setup and key protection
Page history
- Updated
- 2026-10-25
- Origin
- Written for ungovernable.tech.
- Improve this page
- Suggest an edit — issues and pull requests are welcome.