Nomen

Summary

Nomen is a decentralized naming protocol by Ursus Camp. It tries to keep the minimum parts needed for DNS-like names:

1. Global uniqueness — solved by publishing a name claim on Bitcoin. Bitcoin's block ordering answers "who claimed this name first?"
2. Owner-authenticated updates — solved by Nostr events signed by the same key that owns the Bitcoin claim.
3. Resolution infrastructure — solved by indexers / name servers that read Bitcoin claims, follow Nostr relays, and answer DNS-like queries.

This makes Nomen a hybrid between Handshake and Nostr NIP-05. Like Handshake, it uses a blockchain to order scarce human-readable names. Like NIP-05, it uses Nostr events as a signed record transport. Unlike ENS, there is no smart contract registry; unlike PKARR, the human-readable namespace is scarce and globally ordered.

Nomen is experimental and appears lightly maintained: the ursuscamp/nomen repository had 17 GitHub stars, 4 forks, 5 releases, and its most recent push was 2023-11-26 when checked on 2026-05-04. The specifications repository ursuscamp/noms is even smaller. That does not invalidate the design, but it means Nomen should be treated as a research prototype rather than a dependable name layer.

Historical context

Decentralized naming repeatedly runs into Zooko's triangle: names that are human-meaningful, decentralized, and secure/global are difficult to combine. Earlier systems chose different points:

Nomen's key historical move is refusing to bootstrap another consensus layer. It asks: if Bitcoin already provides censorship-resistant ordering, and Nostr already provides a relay-based signed-event network, can names be built by composing them?

The answer is technically yes, but with adoption caveats. Every resolver must index Bitcoin transactions and monitor Nostr relays; no major browser, OS resolver, or wallet ships this out of the box.

Architecture

Name claim:
  Bitcoin transaction commits to name + owner public key
  └─ first valid claim in Bitcoin ordering wins

Record updates:
  owner signs Nostr kind 38300 event
  └─ event contains DNS-like records / name metadata

Resolution:
  Nomen indexer scans Bitcoin for claims
  Nomen indexer subscribes to Nostr relays for updates
  indexer answers queries as a name server / explorer

The protocol separates ownership from records:

• Ownership is slow, final, and globally ordered through Bitcoin.
• Records are faster, mutable, and distributed through Nostr.
• Indexers assemble the view by applying protocol rules.

This is close to an event-sourced registry: Bitcoin establishes the root event, Nostr streams subsequent state transitions, and resolvers materialize the current state.

Protocol pieces

Bitcoin claim layer

Nomen claims are published to the Bitcoin blockchain. The repository describes the ownership rule as simple: the first valid claim to a name owns it. Bitcoin provides:

• A globally replicated append-only log.
• Work-backed ordering of conflicting claims.
• Censorship resistance proportional to Bitcoin transaction inclusion.
• No need for a bespoke token or chain.

Trade-off: claiming a name costs Bitcoin fees, is visible on-chain, and is subject to Bitcoin confirmation latency. There is also no smart-contract-enforced renewal or clawback logic unless specified in higher-level protocol rules.

Nostr record layer

After a name is claimed, the owner publishes signed Nostr events to update records. The NOM specifications define Nostr event kinds:

This makes updates cheap and widely relayable. Because Nostr events are signed, an indexer can verify that a record update came from the owner key anchored by the Bitcoin claim.

Trade-off: Nostr relays are not guaranteed to retain every event. Robust resolution needs multiple relays, replay protection, and indexer persistence.

Indexer / name server

The ursuscamp/nomen repository includes the Nomen Explorer, described as the first indexer or name server for the protocol. Indexers are not trusted to create ownership, but users do rely on them for availability and correct materialization unless they run their own.

The clean deployment model is:

• Run your own Nomen indexer.
• Configure clients to use it as a resolver.
• Cross-check results against Bitcoin and Nostr signatures when high assurance matters.

Evidence at a glance

Maturity and active development

Interpretation: Nomen is worth tracking as a design primitive, but not as a mature censorship-resistance substrate. It lacks the implementation depth of GNS, the economic/security weight of ENS, and the active tooling momentum of PKARR.

Use cases

1. Nostr-native human names

Nostr has public keys but still leans on DNS/HTTPS for human-readable aliases through NIP-05. Nomen gives a Nostr-native alternative:

alice.<nomen namespace>
  Bitcoin claim -> Alice's public key
  Nostr record -> relays, service endpoints, profile records

This removes dependence on a web domain for the alias, while preserving human readability.

2. Bitcoin-anchored service names

Services that already trust Bitcoin finality can use Nomen names for endpoints, donation addresses, mirrors, or metadata. A resolver could return:

• A records / AAAA records for IP endpoints.
• TXT records for contact metadata.
• Nostr relay hints.
• Content hashes for IPFS and Filecoin or Arweave mirrors.

3. Experiments in minimal dDNS composition

Nomen is useful for protocol designers because it demonstrates a modular pattern:

• Use a battle-tested global ordering layer for scarce names.
• Use a signed event network for mutable records.
• Let resolvers be independently operated.

This pattern may reappear in future Bitcoin, Nostr, or off-grid naming systems.

Trade-offs

Strengths

• No new blockchain. Bitcoin handles global ordering and anti-double-claim semantics.
• No new transport layer. Nostr handles signed event distribution.
• Simple ownership rule. First valid claim wins.
• Nostr-native. Fits the relay/event culture better than DNSSEC or EVM-only systems.
• Self-hostable indexer. Users can run their own name server rather than trusting a company.

Limitations

• Light adoption. Tiny GitHub footprint and no mainstream client support.
• On-chain privacy leak. Name claims are public Bitcoin transactions.
• Name squatting. First-claim-wins systems invite squatting unless there are auction, renewal, or social-layer mitigations.
• Relay availability. Nostr updates may disappear unless relays and indexers persist them.
• Indexer complexity. Resolvers must watch both Bitcoin and Nostr, then apply protocol rules correctly.
• No native lookup privacy. Queries to a Nomen resolver can reveal names being resolved unless combined with Overview - Mix Networks or private resolver operation.

Attack surface

Comparison

Operational notes

If experimenting with Nomen:

1. Treat it as a lab protocol, not critical production DNS.
2. Run your own indexer if correctness matters.
3. Archive relevant Nostr events; do not assume arbitrary relays preserve history.
4. Publish record updates to several relays.
5. Keep the Bitcoin claim key in cold storage or a hardware signer.
6. Mirror important endpoints in PKARR, .onion, or conventional DNS until client support matures.

Primary sources

• GNUnet software status

• Nomen implementation — github.com/ursuscamp/nomen.

• Nomen specifications — github.com/ursuscamp/noms.
• NOM-02 — protocol v1 and Nostr kind 38300 name records.
• NOM-04 — relay-published index data and Nostr kind 38301.
• Nostr protocol specifications — github.com/nostr-protocol/nips.
• Bitcoin protocol reference — developer.bitcoin.org.