Hop-History Relay and Byzantine Custody Chain

Mechanism

A hop-history relay treats every forward of a governed payload as an event that must leave a structural trace inside the payload itself. When a node receives a payload destined for a downstream peer (or for general flooding within a topology), it does not simply re-broadcast the bytes. Before the payload exits the node's network interface, the node executes a deterministic annotation procedure: it constructs a hop record containing its credentialed device identifier, a monotonic local sequence number scoped to that node's relay history for the message family, the wall-clock or vector-clock timestamp of relay, and an optional metadata block describing reception channel, signal characteristics, and (for relays carrying credentialed position attestations) coarse geographic position. The hop record is then signed by the relaying node's device key over the concatenation of the prior hop history, the immutable payload body, and the new record's own fields. The signed record is appended to the hop-history field, and the augmented payload is forwarded.

The signature scope is the load-bearing structural choice. Because each new hop record signs over all prior records plus the payload body, the hop history is a chained construction: tampering with any earlier record, or with the payload body, invalidates every subsequent signature in the chain. A receiving node performing admission evaluation walks the chain from origin signature outward, verifying each appended hop record against the relaying node's credential at the time of that hop and against the running hash of all bytes signed up to that point. A single broken link rejects the entire payload at the protocol layer; a verified chain is admitted with the full path available as structured evidence inside the same atomic unit the consumer is already evaluating for origin authenticity.

The hop-history field is bounded. Memory-native devices operate under hard memory budgets; an unbounded annotation that grows with relay depth would eventually exceed payload-size limits or starve other protocol fields. The bound is configured per message family and per topology: a tactical mesh might bound at sixteen hops; a sensor-aggregation topology at four; a long-haul backbone at sixty-four. When the bound is reached, relaying nodes either refuse further relay (forcing the originator to choose a shorter path) or apply a documented compression policy that retains the first hop, the last hop, and a representative sample of intermediate hops along with a digest of the elided records. The compression policy is itself credentialed: the relaying node signs the compression as a structural transformation, and downstream observers admit the compressed form under the same chain-verification rules.

Operating Parameters

Several parameters govern hop-history behavior in practice. The first is the hop-bound itself, which trades path resolution against payload overhead. A bound of sixteen on a payload averaging two hundred bytes of body adds roughly two kilobytes of hop annotation at full depth — tolerable for a mesh whose link-layer MTU exceeds three kilobytes, prohibitive for an LPWAN topology. The bound is a deployment-level configuration carried in the topology's governance record, not a per-payload choice; consumers know the bound before evaluating any payload because they participate in the same governance domain.

The second parameter is the signature scheme and key-rotation discipline applied to relaying nodes' device keys. Hop-history evaluation requires that the verifier resolve each relaying node's credential as it stood at the time the hop was signed, not as it stands at evaluation time. A node that has since rotated its key, been revoked, or had its credential narrowed must still be evaluable for hops it signed before the change. The architecture relies on credential chains that include validity intervals; the relaying node's hop record carries a credential-version reference so the verifier resolves the correct historical credential without ambiguity.

The third parameter is the timestamp discipline. Hop timestamps drive both ring detection and propagation-anomaly evaluation. Devices participating in a governed mesh maintain a clock-discipline credential — either a wall-clock-with-bounded-skew attestation or a vector-clock participation attestation — so that hop timestamps can be ordered and compared without each verifier independently re-establishing trust in each device's clock. Skew bounds are deployment-level: a tactical mesh with GPS-disciplined clocks operates at sub-millisecond bounds; a commercial sensor mesh may operate at hundred-millisecond bounds. The skew bound determines how tightly downstream observers can detect temporal anomalies (replays, holds, out-of-order injection) in the hop sequence.

The fourth parameter is the cycle-detection rule. A relaying node consulting the in-flight hop history before appending its own record can detect that its own identifier already appears, indicating a routing cycle. The rule is structural: if the node's identifier appears in the existing history within a configured cycle-window, the node refuses relay and emits a credentialed cycle-observation rather than adding a redundant hop. The cycle-window is parametric because some topologies legitimately revisit nodes (store-and-forward through a known concentrator); others (flat tactical mesh) treat any revisit as anomalous.

Alternative Embodiments

The disclosed mechanism admits several embodiments that adapt the core annotation discipline to topology and operational constraints. A first embodiment uses full per-hop signatures as described above, suitable for topologies where relay nodes have adequate compute and where downstream consumers must independently verify each hop. A second embodiment uses aggregate signatures: relaying nodes contribute to a multi-signature construction (BLS aggregates, Schnorr multi-signatures, or threshold signatures) so that a chain of N hops produces a single aggregate signature occupying constant space rather than N individual signatures. The aggregate embodiment is preferred for topologies with severe payload-size constraints; the trade-off is that individual hop attribution requires the original component signatures to be retained somewhere accessible (typically in a parallel out-of-band log) for forensic decomposition.

A third embodiment uses Merkle-tree hop accumulation rather than linear chaining. Each relaying node appends its hop record as a leaf in a hop-history Merkle tree carried with the payload; the root is signed and the tree itself can be pruned by downstream relays for size while retaining inclusion proofs for hops the sender wishes to highlight. This embodiment is preferred when payloads are subject to selective-disclosure requirements: a downstream observer can verify that a particular intermediary participated without seeing the full hop list.

A fourth embodiment uses zero-knowledge attestations of hop-history properties rather than the hop records themselves. A relaying node produces a zero-knowledge proof that 'the payload reached me through a path satisfying policy P' — for instance, that all intermediaries hold credentials in a permitted set, or that the path length is within a bound — without disclosing the identities of intermediaries to the downstream observer. This embodiment is preferred for privacy-sensitive deployments (medical or commercial settings) where path verification is required for admission but path disclosure is contraindicated.

A fifth embodiment integrates ring-detection observations into the routing fabric. Relaying nodes that detect cycles emit credentialed cycle-observations that propagate as their own first-class messages; the routing layer subscribes to these observations and adapts forwarding tables accordingly. This embodiment treats hop-history relay not just as a payload property but as a feedback signal into routing itself.

Composition

Hop-history relay composes with the broader memory-native protocol stack in three architecturally significant ways. First, it composes with the credentialed-observation primitive: each hop record is itself a credentialed observation about the relay event, and the same admissibility evaluation that consumers apply to payload content applies to hop records. A consumer's policy can require that all relays in the path hold credentials in a specified authority domain; can elevate scrutiny on payloads whose paths include relays with marginal credential standing; or can refuse admission outright when the path includes any relay flagged as compromised in a recent revocation observation.

Second, hop-history relay composes with the lineage-continuity primitive. The hop history is a forward-looking lineage record (where a payload went after origin) complementing the backward-looking content lineage (what the payload represents and how it was derived). A downstream consumer that needs to assess not just whether to admit the payload but whether to act on it can inspect both lineages: the content lineage tells the consumer whether the underlying data was derived through an admissible chain; the hop lineage tells the consumer whether the path of arrival was operationally sound. Operational decisions in adversarial environments require both.

Third, hop-history relay composes with cross-authority handoff governance. When a payload crosses an authority boundary, the receiving authority's evaluation policy treats the originating-authority hop history as one structured input and the receiving-authority hop history (after handoff) as another, with a translator observation bridging the two. The composite hop history thus spans authorities while preserving each authority's sovereignty over its own segment — an alignment that is structurally identical to the cross-authority lineage continuity already established for content.

Prior-Art Distinction

Existing path-recording disciplines do not produce the load-bearing properties claimed here. IP-layer record-route options (RFC 791) record router addresses but are advisory, unauthenticated, frequently stripped by intermediate equipment, and not bound to payload integrity. BGP path attributes record autonomous-system traversal but operate at a coarse granularity suitable for routing-policy decisions, not custody verification, and are subject to well-documented spoofing and origin-hijack attacks because the attribute is not signed by each AS. Onion-routing constructions (Tor) deliberately obscure path information from intermediaries and from endpoints, which is the opposite design goal: hop history makes the path verifiable to consumers, not opaque.

Distributed-ledger approaches that record relay events on a shared ledger introduce different problems. Ledger writes are slow relative to mesh-protocol tempo, expensive at scale, and create a global serialization point that contradicts the bounded-locality assumption memory-native protocols require. The hop-history approach disclosed here keeps the path evidence inside the payload itself — co-located with the content it attests to — and avoids any architectural dependency on a shared write target. The combination of in-payload chain-of-signatures, bounded annotation discipline, credential-versioned verification, and cycle-detection structural rules has not been disclosed in combination prior to the priority date of U.S. Provisional Application 64/050,895.

Disclosure Scope

The disclosure encompasses the hop-history annotation discipline as a structural property of governed-mesh payloads, the chained-signature construction over prior history plus payload body, the bounded-annotation policies (with per-family configuration and credentialed compression), the credential-version-resolved verification procedure, the timestamp-discipline credentials supporting temporal anomaly detection, and the cycle-detection rules emitting credentialed cycle-observations. The disclosure further encompasses the alternative embodiments enumerated above (aggregate-signature, Merkle-accumulation, zero-knowledge attestation, and routing-feedback embodiments) and the compositions with credentialed-observation admissibility, lineage continuity, and cross-authority handoff governance. The scope of the disclosure is the architectural treatment of relay path as in-band structural evidence — not any single signature scheme or topology — and is intended to cover equivalents that achieve the same load-bearing properties through analogous constructions.