Directory

Name resolution connects a handle to a creator record and the services that record authorises. The directory must provide evidence for its answer, including an answer that a name is absent.

Data model

The directory holds a sparse Merkle tree whose leaves commit to the current state of each name. The position of a name in the tree is derived from the hash of its text.

The tree commits to current state only, not to per-name history. History is available by replaying the update stream.

Absence versus emptiness

Two distinct situations, which clients must not conflate:

• The name is absent. Nobody has claimed it.
• The name is present with an empty value. Somebody holds it and has published nothing.

Only the first means the handle is available.

Roots

The directory publishes a signed root carrying a strictly increasing sequence number and the tree root hash. It is signed by the directory operator and co-signed by witnesses over identical bytes.

Because the co-signatures cover the same bytes, a witness set holding two different roots at the same sequence number holds a conviction — see Misbehaviour.

Reads

A read returns the record together with a proof against a root the client already trusts:

• Inclusion proof — the name is present, and the record hashes into the tree root.
• Non-inclusion proof — the name is absent, proven positively.

A client:

1. Verifies the root’s operator signature and its witness co-signatures.
2. Checks the root against its own quorum and freshness policy.
3. Verifies the proof against the tree root.
4. Only then decodes and uses the record.

A response failing any step fails the read. There is no fallback where an unverified response is used, and no state in which “the directory returned nothing” is treated as absence.

Registration and updates

A registration or update is signed by the creator root and gated by proof-of-work over the request. The work is paid to nobody. It exists so that sweeping the namespace for every plausible handle is expensive rather than free.

Validation at the directory layer:

• the signature verifies under the claimed creator root
• for a first write, the signer is the record’s own root key
• for an update, the signer matches the current record’s root key
• the sequence number strictly exceeds the current record’s
• the proof-of-work meets current difficulty

Updates are held pending between root commits, so several can be accepted without each waiting for its own commit interval.

Freshness

Root freshness is a quorum and advancement property, never a timestamp:

• enough distinct witnesses from the client’s configured set must have co-signed the root
• the root’s sequence number must be within the client’s configured lag of the newest root the client can establish

A root failing either test is stale, and stale is a failure rather than a weaker pass.

Anchoring

A client’s trust root is an anchored state: the operator key, a witness set with a threshold, a maximum lag, and one specific anchored root.

This is the load-bearing requirement, and the easiest to get subtly wrong:

A client that learns its root by asking the same party it is about to check has verified nothing. That party can supply whatever root makes its own answers check out.

For anchoring to mean anything the anchored state must be published somewhere the party being checked does not control, and the client must pin the anchor reference rather than a root fetched at runtime.

An independently published reference and the client behaviour that checks it are both deployment requirements. The current boundary is stated in Limits.

Name control and disputes

A verified lookup establishes control of a name within the namespace. It does not establish a person’s real-world identity, resolve impersonation or decide a trademark dispute. Registration policy and dispute handling remain responsibilities of the namespace operator.