UID Resolution Query Protocol: Distributed Lookup Across Anchor Node Networks

by Nick Clark | Published March 27, 2026 | PDF

A content unique identifier (UID) is meaningful only insofar as it can be resolved against an authoritative record that ties the identifier to a specific canonical object, its provenance, and its lineage. The UID resolution query protocol described here defines how a querying client locates the responsible anchor nodes, submits a structured request, receives a response that includes the cryptographic evidence necessary to verify the binding, and reconciles conflicting answers when the network is partitioned or partially compromised. The protocol is designed to operate identically across centralized infrastructure, federated deployments, fully decentralized substrates, and offline caches, and to remain tamper-evident even when individual responders are byzantine.


Mechanism

Resolution begins when a querying client presents a UID together with a verification policy that specifies the level of evidence the client requires. The UID itself is a structurally derived identifier, computed from the content's canonical form and bound into the anchored chain at the moment of original ingest. Because the UID is derived from structure rather than assigned by fiat, any participant in possession of the canonical bytes can independently recompute the UID and confirm that a returned record corresponds to the content actually being inspected. The protocol therefore distinguishes two operations that are conflated in conventional registries: locating a record (lookup), and confirming that the located record is the correct one for the specific bytes in hand (verification).

The protocol layers a lookup phase, an evidence phase, and a reconciliation phase. In the lookup phase the client uses a deterministic routing function to identify the set of anchor nodes that are responsible for the UID's keyspace partition. Routing is a pure function of the UID, the published topology, and the epoch of the anchored chain, so two clients computing the routing independently obtain the same responder set. Each responder receives a query frame containing the UID, the requested evidence level, and a freshness predicate that bounds the staleness the client will accept. The freshness predicate is expressed in chain-relative terms (a minimum committed height) rather than wall-clock terms, because clock skew and partition delay would otherwise allow stale responders to pass off outdated bindings as current.

In the evidence phase each responder returns a resolution envelope. The envelope carries the canonical object descriptor, the inclusion proof that ties the UID into the most recent committed root, the chain of intermediate commitments connecting that root to the genesis anchor, and any policy attestations that govern downstream use of the object. The inclusion proof is constructed so that the client can verify the binding using only the public chain head and a set of sibling hashes; the responder cannot fabricate a binding without producing a hash collision against the committed root. Where the binding has been superseded - for example because a canonical object has been re-ingested under a corrected lineage - the envelope additionally contains the supersession record and the proof of its commitment.

In the reconciliation phase the client collates envelopes from multiple responders. Conflicts are resolved structurally: an envelope is preferred over another if its committed root is a descendant of the other's root in the anchored chain, or if it carries a more recent supersession record whose commitment is itself anchored. Where envelopes cannot be ordered - the case that arises during a true network partition - the client surfaces the divergence to the caller rather than silently choosing a winner, because silently picking sides during a partition is the failure mode that allows split-brain identity to propagate. The protocol explicitly treats unresolvable divergence as a first-class outcome.

Cross-substrate operation is achieved by anchoring the chain head into one or more witness substrates whose own commitments are independently auditable. A client that has acquired a recent witness commitment - from a public ledger, a notarial timestamp service, or a peer with whom it has already synchronized - can verify any envelope without requiring direct access to the anchor network at the time of verification. This is what allows resolution to function across air-gapped boundaries, in offline forensic settings, and during prolonged loss of connectivity.

Operating Parameters

A deployment of the protocol is characterized by several tunable parameters. The responder fan-out determines how many anchor nodes are queried in parallel for each UID; smaller fan-outs reduce bandwidth but increase the probability that a transient responder failure forces a retry, while larger fan-outs improve resilience at the cost of network load. The evidence level requested by the client ranges from a bare descriptor (suitable for non-load-bearing display) through full inclusion proofs (suitable for legal evidentiary use) to a witnessed envelope that additionally carries cross-substrate commitments (suitable for adversarial settings). Each level corresponds to a different point on the latency-assurance curve, and the protocol allows the level to be selected per query rather than fixed for the deployment.

The freshness predicate is bounded by the committing cadence of the anchored chain. Chains that commit frequently allow tighter freshness predicates and therefore faster detection of stale or withheld bindings, at the cost of higher commitment overhead. Chains that commit infrequently amortize cost across more bindings but widen the window during which a withholding responder could plausibly claim its older view is current. The protocol does not prescribe a cadence; it requires only that the cadence be published as part of the topology so that clients can reason about the meaning of any particular freshness assertion.

Reconciliation timeouts govern how long a client waits for additional envelopes before declaring a divergence. Timeouts that are too short cause spurious divergence reports under normal jitter, while timeouts that are too long delay legitimate resolution. The protocol specifies that timeouts be expressed as functions of measured round-trip time to the responder set, not as fixed constants, so that the same client behaves correctly on a low-latency LAN and a high-latency satellite link without reconfiguration.

Alternative Embodiments

The protocol admits several embodiments that share its structural guarantees while differing in deployment details. In a fully decentralized embodiment, anchor nodes are operated by mutually distrusting parties and the routing function is derived from a published distributed hash table; clients verify envelopes using only public chain heads and never need to trust any individual operator. In a federated embodiment, anchor nodes are operated by a consortium under a shared governance agreement; the routing function may be biased to keep traffic within administrative domains, but the cryptographic verification path is unchanged.

In a centralized cloud embodiment, the anchor network collapses to a single logical service backed by replicated storage; the protocol still applies because the inclusion proofs and chain commitments remain meaningful and verifiable by external auditors, even when the operator is a single entity. In an edge embodiment, anchor nodes are deployed at network boundaries with intermittent connectivity to the broader chain; queries that cannot be resolved against fresh state are returned with an explicit staleness annotation so that downstream consumers can decide whether to act on the cached answer.

Hybrid embodiments are explicitly contemplated. A deployment may run a centralized hot path for low-latency queries while periodically committing into a decentralized cold path for tamper-evidence; the protocol exposes both paths to clients and lets the client choose based on its evidence requirement.

Composition with Other Mechanisms

UID resolution composes with the other mechanisms of the content anchoring system. Resolution outcomes are consumed by downstream policy engines, which use the canonical descriptor and its lineage to decide whether the content may be admitted, displayed, redistributed, or used as training data. The protocol's evidence levels are designed to align with the evidentiary thresholds those policy engines impose, so that policy decisions can be expressed in terms of the assurance the resolution carried rather than as ad-hoc trust assertions about the responder.

Resolution also composes with structural quarantine mechanisms in adjacent systems. Where a UID has been quarantined - for example because its canonical object has been flagged as adversarial - the resolution envelope carries the quarantine marker and its lineage, so that consumers cannot inadvertently route around the quarantine by resolving through a different responder. The composition is structural: the quarantine is a property of the binding itself, not a side-channel advisory.

Finally, resolution composes with the audit machinery of the anchored chain. Every envelope returned to a client is itself a record that can be replayed against the chain to confirm that the responder behaved correctly at the time of the query. This allows after-the-fact auditing of responder behavior without requiring that the audit trail be maintained by the responder itself.

Prior-Art Distinctions

Conventional content identification systems address resolution through metadata tags, perceptual hashes, watermarks, or centralized registries. Metadata tags are easily stripped during reformatting and convey no cryptographic binding to the underlying bytes. Perceptual hashes provide approximate matching but are not deterministic across transformations and cannot be cryptographically committed in a way that survives adversarial preprocessing. Watermarks tie the identifier to the rendered surface rather than the canonical object and are degraded or removed by routine media processing. Centralized registries provide authoritative lookup but introduce a single point of failure and require trust in the registry operator's continued availability and honesty.

The UID resolution query protocol is distinguished from each of these by the combination of structurally derived identifiers, anchored chain commitments, multi-responder reconciliation, and cross-substrate witnessing. No element of this combination is, on its own, novel as a cryptographic primitive; the novelty lies in their composition into a protocol that simultaneously survives metadata stripping, registry compromise, network partition, and substrate migration. The protocol does not depend on any single trust assumption that could be violated by a single compromised participant.

Disclosure Scope

This disclosure covers the structured query and response framing, the routing function, the envelope schema and its evidence levels, the freshness predicate semantics, the reconciliation algorithm including its handling of unresolvable divergence, and the cross-substrate witnessing path. It covers the protocol behavior under all deployment topologies described above, and the composition of the protocol with downstream policy engines, quarantine machinery, and audit mechanisms.

The disclosure is not limited to any particular hash function, signature scheme, chain commitment structure, or transport. It contemplates substitution of equivalent cryptographic primitives, including post-quantum primitives where the underlying assumptions are weakened in the future. It contemplates substitution of the routing function with any deterministic function of the UID and the published topology. It contemplates substitution of the witness substrate with any independently auditable commitment service. The structural guarantees of the protocol depend on the composition, not on the specific instantiations.

Nick Clark Invented by Nick Clark Founding Investors:
Anonymous, Devin Wilkie
72 28 14 36 01