The Chain of Evidence
Raeez Lorgat, 2026
Border crossings produce records of what happened, when, and under which conditions. Goods and money receive different paperwork. A corporation foreign-qualifying in a new jurisdiction, a fund distributing to investors abroad, and a fiduciary transferring assets between regulatory regimes each produce their own records.
Courts, regulators, and counterparties rely on these records to reconstruct events. The records form an evidence chain, but they remain scattered across incompatible systems and formats, without a structural guarantee of completeness or integrity. Most institutional systems therefore cannot answer the question “did this sequence of crossings occur in this order, and has anyone tampered with the record?”
A hash chain makes the sequence tamper-evident. Haber and Stornetta (1991) first applied it to this problem, and the same structure underlies git and blockchains. Each record includes its predecessor’s hash, so modifying a record changes its hash and breaks the subsequent links through to the present. A party controlling storage can rewrite the whole chain, but anyone holding the current head can recompute backward and detect the tampering.
This paper applies that idea to cross-jurisdictional corridor crossings. A zone is a jurisdiction that runs one kernel, the software that is the sole writer of its compliance-sensitive state; a corridor is a bilateral channel between two zones through which an entity’s compliance state passes under recognition terms the two zones have agreed in a corridor instrument; a crossing is one passage through it. The paper states what the records must contain, what rules govern the chain’s growth, and what each layer of the construction proves.
The corridor receipt
Every corridor crossing produces one receipt with one cryptographic commitment. This receipt is the atomic unit of the evidence chain.
A receipt identifies the corridor, direction, time, sequence number, and the entity’s state before and after the crossing. It also records the governing regulatory packs and the compliance evaluations performed. Regulatory packs are the versioned, machine-readable rule sets each jurisdiction publishes. Three further fields describe the chain.
The predecessor root ties the receipt to everything that came before: it must equal the previous receipt’s next root. The next root is the digest of this receipt’s own canonical content, computed by the commitment function below; because that content includes the entity’s post-crossing state, one digest serves as both the chain link and the commitment to the state the crossing produced. The accumulator root commits to the chain’s entire history before this receipt; its role is explained with the Merkle Mountain Range below.
The commitment function – the function that computes the next root from the receipt’s content – must be deterministic and canonical. Two systems processing the same receipt must produce the same digest. Determinism fails by default when the receipt contains sets (which have no canonical ordering), timestamps (which have multiple valid representations), and optional fields (whose absence can be encoded in more than one way). Canonical serialization removes every such ambiguity. The JSON Canonicalization Scheme (RFC 8785) fixes the encoding – object keys sorted, one form for each number and string – and deliberately preserves array order and leaves timestamps and optional fields to the application. The receipt schema fixes those three: sets are deduplicated and lexicographically sorted before they are encoded as arrays, timestamps are normalized to a fixed format, and optional fields follow a documented convention. The receipt is serialized into canonical bytes and hashed with SHA-256 (FIPS 180-4).
Two fields are excluded from the digest. The proof field carries the appender’s signature and auxiliary verification artifacts, such as inclusion paths and folding material. The signature is computed over the next root, so it cannot be part of the content that root hashes. The next root itself is excluded because finding bytes that contain their own SHA-256 digest is computationally infeasible. All remaining fields enter the digest.
Each endpoint of a corridor keeps its own chain of the crossings its kernel records. At each append, the kernel records the crossing, appends the receipt in the atomic step described below, and signs the next root. The signature travels in the proof field. The zone that keeps this chain is its operator, and the corridor and operator together identify the chain. The sections below treat one such chain. Its invariants make a bad append detectable, while the signature attributes that append to the operator’s key.
The append rule
A receipt chain is an ordered, gap-free, hash-linked sequence with three invariants enforced on every append.
First, sequence numbers are gap-free. Receipt n must carry sequence number n, so appends cannot skip a receipt or insert one out of order. If the chain has twelve receipts, an append with sequence number 14 is rejected.
Second, linkage to the current state is exact. The new receipt’s predecessor root must equal the chain’s current head, and its accumulator root must equal the accumulator’s current root. If either fails, the receipt is claiming to extend a chain state that does not match reality: it was computed against stale state, or someone is trying to fork the chain.
Third, commitment integrity holds. The new receipt’s next root must equal the commitment function applied to its content. If it does not, the receipt was corrupted in transit or modified after commitment.
Only after all three checks pass does the chain advance: the head moves to the new receipt’s next root, the receipt joins the sequence, and its next root is pushed into the accumulator. The checks and the advance are one atomic step. Appends are serialized per chain and the head moves by compare-and-swap, so a receipt computed against a head that has since moved fails the linkage check and is re-derived against the new head; two appends never interleave.
The append rule fails closed: a receipt that fails any check is rejected entirely. Partial acceptance, “append but flag for review,” and deferred validation are all excluded. Refusing the append preserves the chain’s invariants and evidentiary value.
Why a hash chain is not enough
A hash chain answers one question well: has any entry been modified since it was committed? Walk the chain from the head backward, recomputing digests at each step. If every computed digest matches, the chain is intact; any mismatch is tampering.
Checking whether a specific receipt was included, or whether it preceded another receipt, also requires a linear scan. A corridor with thousands of crossings needs a more efficient way to answer these point queries.
A Merkle Mountain Range answers them in logarithmic time. The MMR is an append-only accumulator (Todd, 2012; Bünz et al., 2020). Every append pushes the receipt’s next root as the next leaf, so a receipt’s leaf index equals its sequence number. The MMR maintains a set of perfect binary trees – the peaks – that together commit to all leaves. To prove that a receipt is included, produce the Merkle path from its leaf to its peak plus the set of peaks; the verifier recomputes the path, bags the peaks, and checks the result against the MMR root. And because leaf order is append order, two inclusion proofs also settle precedence: the receipt at the lower index was committed first.
The MMR’s hashing is domain-separated: leaf digests are computed over bytes prefixed with one constant, internal nodes with another – the discipline of Certificate Transparency (RFC 6962), which keeps append-only Merkle logs of the web’s certificate issuance. Without it, an attacker could construct a payload that is simultaneously a valid leaf and a valid internal node, and lead the verifier to accept a proof for content that was never appended.
A verifier who skips the chain walk must obtain the MMR root from an authenticated source. Otherwise, an operator can substitute a root and prove inclusion of arbitrary content. Each receipt’s hashed content therefore includes the MMR root over all preceding receipts. An authenticated head authenticates the accumulator over that entire prior history. The committed root excludes only the head itself, which the verifier holds directly.
The operator’s signature makes the head attributable to the operator. The watcher quorum described next makes it a head a party may act on. The accumulator root inherits the head’s authentication, allowing inclusion proofs to verify without a chain walk.
The chain head commits to the full ordered history. Against that commitment, the MMR proves a receipt’s inclusion and position efficiently. The two mechanisms supply tamper-evident sequence and efficient point queries, respectively.
Fork detection
Hash chains have a well-known vulnerability: equivocation. A malicious chain operator can maintain two chains that diverge from a common ancestor, presenting one version to one party and a different version to another. Both chains are internally valid – correct hash links, correct sequence numbers, correct commitments. They simply disagree about what happened after the fork point.
Two signed receipts can prove equivocation directly. In a gap-free chain, the operator signs exactly one receipt at each sequence number. Suppose two receipts belong to the same corridor and are signed under the same operator’s key. If they have the same sequence number and distinct digests, any party holding both has self-contained, attributable proof of two signed histories. No quorum strengthens this proof, and no honest operator can produce such a pair.
Detecting that pair requires the two views to meet. An operator serving one history to each party can evade every local check and cause damage before anyone obtains both. Watchers bring views together systematically and within bounded time. The companion Sovereign Jurisdiction Network paper specifies the watcher layer in full. This section states what the receipt chain requires of it.
A corridor admits a finite set W of watchers, fixed by its registration policy. Each watcher holds a registered Ed25519 key (Bernstein et al., 2012). The operator posts the bond the corridor instrument requires of its endpoints, and each watcher posts a bond at registration. A bond custodian holds both kinds of bond as an escrow agent outside either endpoint’s unilateral control. Proven equivocation makes either bond slashable. Slashing requires an accepted proof and action through the custodian, never the detector’s output alone.
A watcher reads each receipt as it is appended, verifies the operator’s signature, and attests only heads that verify. It signs each attestation over five values: the chain identifier, which names the corridor and its operator; the observed head’s digest and sequence number; the watcher’s local timestamp; and the corridor epoch, the monotone period counter the protocol advances. Although the digest commits to the sequence number, the attestation also carries that number in the clear. The fork predicate below is then decidable from attestations alone.
Attestations are collected per corridor epoch, which bounds only collection latency. An attestation is discarded if its timestamp falls outside the named epoch by more than the corridor’s configured clock-skew tolerance. The tolerance is a deployment parameter, set to five minutes in the reference profile.
A watcher attests at most one head per sequence number of a chain. Honest observation yields one receipt at each height. A watcher served two heads at one height, both under the operator’s signature, already holds the operator’s equivocation proof and files it instead. A key signing two distinct digests at one sequence number of one chain is itself equivocating. Both its attestations are discarded from every count, and its bond is slashed.
A fork is declared when a chain’s attestation record, read whole and not by epoch, contains two distinct head digests at the same sequence number, each backed by at least \theta attestations from distinct watchers, where \theta is a corridor parameter bounded below by \lceil |W|/3 \rceil + 1. Equal height distinguishes a fork from honest growth. Each append changes the head, so distinct digests at distinct heights do not establish a fork. Two at one height establish two histories.
Checking the whole record prevents a rewind attack across epochs. A branch served late gathers its \theta attestations at height h after the genuine head at h gathered its own. An epoch-local check would find no conflict and admit both heads under the reliance rule below. Since the predicate depends only on the attestation set, every party holding that set reaches the same verdict regardless of arrival order.
The bound follows from quorum arithmetic. Assume at most f = \lceil |W|/3 \rceil watchers are faulty. Any f + 1 attestations from distinct watchers include at least one honest watcher. A digest reaching \theta was therefore served under the operator’s signature to an honest observer. Two such digests at one height prove that the operator signed conflicting heads. Each quorum’s honest watcher holds the signed receipt it verified, so together the quorums hold the direct signature pair described above. That pair proves equivocation without the fault bound.
Detection establishes equivocation and leaves the underlying transactions for adjudication. The protocol does not select a branch, because any selection rule gives influence to whoever controls its inputs. Under the fault bound, a verifier can check the two quorum-backed attestation sets as a signed proof of equivocation from the attestations alone. The sets concern one chain and one sequence number, with two digests and at least \theta distinct watcher signatures behind each. They provide grounds to slash the operator’s bond, suspend or demote the corridor, and support action by counterparties, regulators, and courts. The receipts and their parties must then establish which branch, if either, reflects the crossings that occurred. The fork proof establishes the operator’s false statement, after which adjudication proceeds over authenticated records.
The scheme has three boundaries, all set by \theta. Suppression: detection fails when more than |W| - \theta watchers collude with the operator. Fewer than \theta honest watchers remain, so the head served to them cannot gather a quorum. Framing: \theta colluding watchers can attest a digest the operator never signed at a height the genuine head also reaches. They can thereby fabricate a fork proof against an honest operator. At |W| = 10 with \theta at its floor of five, framing takes five watchers and suppression takes six.
Detection and its soundness both rest on the fault bound f. Suppression takes |W| - \theta + 1 colluders and framing takes \theta. With \theta in the window f + 1 \le \theta \le |W| - f, both need more than f colluders. One attack hides a fork, while the other manufactures one.
Partition: an operator can serve a substitute head to a counterparty and fewer than \theta watchers, raising no quorum and therefore no fork. The reliance rule defeats this substitute: a party acts only on a head backed by \theta attestations. An unbacked head remains the operator’s bare assertion.
Bonds price only proven equivocation. The operator forfeits its bond on a fork proof, and a watcher forfeits its bond on two attestations at one height of one chain. Silent collusion violates no slashing condition stated here. Watchers may withhold attestations of the head served to honest observers or attest only the substitute head, without forfeiting their bonds. The only mitigation stated here is diversity among watchers with misaligned incentives, such as the corridor partner, the operator’s regulator, and independent auditors. This is the known boundary of accountability by observation (Haeberlen, Kouznetsov, and Druschel, 2007). The companion paper examines what watcher independence can and cannot mean.
Content-addressed asset identity
The receipt must identify the asset crossing the corridor. A smart asset is a digitally represented economic instrument whose lifecycle is governed by the compliance rules of the jurisdictions it touches. Its identity must remain usable across systems and independent of a naming authority’s continued operation and good behavior. Database keys are local to one system, URLs change, and authority-assigned identifiers retain that dependence.
Content addressing meets all three constraints: the asset’s identity is the digest of its genesis record. The genesis record fixes the asset’s origin – the creator, identified by a public key rather than an entry in anyone’s registry; the jurisdiction of creation; the instrument’s metadata; the creation time; and a creator-chosen nonce. None of this changes after creation. By collision resistance, distinct genesis records yield distinct identifiers, and the nonce makes intended-distinct assets distinct records: a creator issuing a batch of otherwise-identical instruments in the same instant separates them by nonce. The identifier carries an algorithm tag alongside the digest, so the hash function can be replaced without invalidating existing identifiers – the scheme of the companion Content-Addressed Identity paper, which also treats the one thing the identifier deliberately does not establish: that the genesis record corresponds to a creation act some sovereign recognizes. That is supplied by attestation, and attestations bind to the digest.
IPFS and git use the same principle of deriving an object’s identity from its content. Two systems independently computing the same asset’s genesis digest arrive at the same identifier without coordination or a registry lookup. The identifier is a deterministic function of the thing it identifies.
The genesis digest identifies the asset’s origin. It does not establish compliance, transfer permission, or the rules governing the asset. The compliance evaluation at each corridor crossing answers those questions, and the receipt chain records that evaluation.
The layered proof stack
The full system makes five distinct proof claims, each answered by a different mechanism.
Transition commitment: “this receipt’s digest is a deterministic function of its content.” Answered by the canonical commitment function.
Ordered append: “this receipt extends the chain’s current head, in sequence, without gaps.” Answered by the three-invariant append rule.
Inclusion and order: “this receipt is in the committed history, at this position.” Answered by an MMR inclusion proof against an authenticated head.
Equivocation evidence: “the operator signed two histories.” Answered by two operator-signed receipts of one chain at one sequence number with distinct digests, or by two quorum-backed watcher attestation sets at one sequence number drawn from one chain’s whole attestation record.
Verification without the data: “this chain is well-formed, checkable by a verifier who holds an attested head and nothing else.” Its mechanism remains a design target, with the obligations stated below.
Separate checks identify failures of commitment, sequencing, inclusion, attestation, or folding. A single “the chain is valid” check would leave those causes ambiguous and make the system harder to audit.
Walking a chain of n receipts costs O(n) hashes. SHA-256 streams at gigabytes per second on commodity hardware. A million receipts of ten kilobytes each are ten gigabytes, which a verifier holding the data walks in seconds. The constraint is access to the complete receipt data. A corridor counterparty, regulator, or court may need verification without holding every receipt or being entitled to do so. Receipts carry state that does not all cross jurisdictional boundaries. The target is therefore a proof of a well-formed chain that can travel without the chain itself.
The intended mechanism is incrementally verifiable computation built on a folding scheme (Kothapalli, Setty, and Tzialla, 2022). Fix the step relation F, which holds at step i exactly when the receipt’s sequence number is i, its predecessor root equals the previous receipt’s next root, its next root equals the commitment function applied to its canonical content, and its accumulator root correctly extends the previous receipt’s. A folding scheme reduces checking two claimed executions of F to checking one, so a prover maintains a running instance that accumulates the whole chain, folding each receipt in as it is appended. The running instance does not grow as the chain does, and the final proof – after a compression step, which is also where zero knowledge enters if it is wanted – has size and verification cost governed by the circuit for F, not by n.
The relation fixes what is proved, and two versions differ by orders of magnitude in proving cost. With F as stated, the proof establishes that the chain is well-formed: correctly sequenced, correctly linked, correctly committed. It does not establish that the compliance evaluations recorded in the receipts were correctly computed; for that, the evaluation itself – the per-domain verdict computation the companion How Compliance Composes paper specifies – must move inside F. What the construction delivers now is the O(n) walk for a verifier who holds the data and the O(\log n) inclusion proof for one who holds an authenticated head. The folded chain proof is contingent on fixing F’s circuit and on the soundness of the folding backend, and the construction claims nothing stronger until both are discharged.
Why this structure matters
The construction uses established hash chains (Haber and Stornetta, 1991), Merkle trees (Merkle, 1987), content addressing, and Ed25519 signatures. Its contribution is their application to cross-jurisdictional evidence.
Each layer answers a specific question, and the layers compose into an auditable proof stack for corridor crossings. Signed receipts record what happened, the chain fixes their order, and the MMR supports efficient point queries. Watchers bring conflicting views together within bounded time, so operator signatures can establish attribution and bonds can be slashed. Folding would permit verification without the data once its proof obligations are discharged. The genesis digest identifies the assets being transferred.
Each layer has its own verification rule, threat model, and possible failures. At the scale of millions of corridor crossings, diagnosing those failures requires distinguishing malformed receipts, chain-order violations, accumulator omissions, conflicting signed heads, and failed folds.
Courts, regulators, and counterparties need a diagnosis specific enough to act on. A bare “verification failed” does not supply one. “The predecessor linkage broke between receipts 4,271 and 4,272, and here is the signature over the bad append” identifies both the failure and its attribution.
Every corridor crossing must produce a receipt linked to its predecessor. The MMR, watchers, folding scheme, and content addressing extend that requirement into efficient queries, attributable faults, and verification at scale, subject to the obligations above.
References
Bernstein, D. J., Duif, N., Lange, T., Schwabe, P., and Yang, B.-Y. High-Speed High-Security Signatures. Journal of Cryptographic Engineering, 2(2):77-89, 2012.
Bünz, B., Kiffer, L., Luu, L., and Zamani, M. FlyClient: Super-Light Clients for Cryptocurrencies. In Proceedings of the IEEE Symposium on Security and Privacy (S&P), 2020.
Haber, S. and Stornetta, W. S. How to Time-Stamp a Digital Document. Journal of Cryptology, 3(2):99-111, 1991.
Haeberlen, A., Kouznetsov, P., and Druschel, P. PeerReview: Practical Accountability for Distributed Systems. In Proceedings of the ACM SIGOPS Symposium on Operating Systems Principles (SOSP), 2007.
Kothapalli, A., Setty, S., and Tzialla, I. Nova: Recursive Zero-Knowledge Arguments from Folding Schemes. In Advances in Cryptology (CRYPTO), LNCS 13510, Springer, 2022.
Laurie, B., Langley, A., and Kasper, E. Certificate Transparency. RFC 6962, Internet Engineering Task Force, 2013.
Merkle, R. C. A Digital Signature Based on a Conventional Encryption Function. In Advances in Cryptology (CRYPTO), LNCS 293, Springer, 1987.
National Institute of Standards and Technology. Secure Hash Standard (SHS). FIPS PUB 180-4, 2015.
Rundgren, A., Jordan, B., and Erdtman, S. JSON Canonicalization Scheme (JCS). RFC 8785, Internet Engineering Task Force, 2020.
Todd, P. Merkle Mountain Ranges. OpenTimestamps documentation, 2012.