What does the customer's appliance sign?

The appliance, running inside the customer's own environment, signs the SHA-256 hash of a sealed evidence bundle - the bundle itself, and any content it contains, never leaves the customer's environment.

How does the operator verify the customer's signature without seeing the content?

The customer signs a payload containing the bundle hash and associated metadata using a registered Ed25519 key; the operator verifies that signature against the registered public key, which only requires the hash and metadata already in the request - never the bundle's own content.

Why does the resulting anchored record carry two independent signatures?

The customer's signature vouches for the content; the operator's validator quorum signature vouches for the fact and timing of anchoring. Because they cover different things - content versus anchoring event - a party relying on the record gets independent attestation from both sides of the trust boundary.

Cross-Trust-Boundary Co-Anchoring

Q: What does the operator's validator quorum sign?

A canonical anchor statement describing the anchoring event itself - a subject-type identifier, a deterministically-derived subject identifier, the bundle hash, an engine-commit identifier, and a timestamp - not the underlying content, which the operator never receives.

Executive Summary

Compliance and audit evidence produced inside a customer's own environment - a sealed CREB bundle generated by an in-tenant appliance, for example - needs independent, operator-side attestation to be maximally useful as evidence, but sending the underlying bundle to the operator for that attestation would defeat the entire point of keeping the data in the customer's own environment. JIL Sovereign's cross-trust-boundary co-anchoring resolves this: the customer's appliance signs only the SHA-256 hash of its sealed bundle and submits that hash, together with a small set of metadata, to an operator-side receiving service. The operator verifies the customer's signature, then has its own Byzantine-fault-tolerant validator quorum sign a canonical statement about the anchoring event - not the bundle's content, which the operator never sees.

The resulting anchored record therefore carries two independent cryptographic attestations from two different trust domains: the customer's signature vouching for the content, and the operator's validator quorum signature vouching for the fact and timing of the anchoring, without the operator's validators ever having access to what was anchored.

Core Innovation: A validator quorum operated by one party synthesizes a co-signature over the anchoring event of a bundle signed and held entirely by another party, so the resulting record carries independent attestation from both trust domains without the anchoring party ever receiving the underlying content.

Problem Statement

Standard notarization and timestamping services provide a single party's signature over a hash - useful, but it leaves the record with only one side's attestation. Blockchain-anchored hash-only commitments solve the "don't reveal the content" problem but typically stop at recording a hash with no independent quorum co-signature layered on top. VPC-peered or vendor-hosted data-sharing arrangements can add a second party's attestation, but only by having the content itself cross the trust boundary - the opposite tradeoff from what a customer operating under a strict data-residency posture needs.

Independent signatures composing every anchored record

Underlying content bytes received by the anchoring operator

Canonical fields comprising the signed anchor statement

Why Existing Approaches Fall Short

Single-party notarization/timestamping: one signature over a hash, no second independent attestation.
Hash-only blockchain anchoring: records a hash on-chain but without a dedicated quorum co-signature specific to the anchoring event.
VPC-peered / vendor-hosted data sharing: a second party can attest, but only after the content itself crosses into the second party's environment.

Technical Architecture

Who Signs What

Party	What Is Signed	What They Receive
Customer appliance	The SHA-256 bundle hash and submission metadata (customer ID, vertical, tier, timestamp)	The full sealed bundle - stays entirely in the customer's own environment
Operator validator quorum	A canonical anchor statement: subject type, deterministically-derived subject ID, the bundle hash, an engine-commit identifier, and the anchor timestamp	Only the bundle hash and metadata - never the bundle's content

Verification and Quorum Synthesis Sequence

The operator's receiving service verifies the customer's Ed25519 signature over the submitted hash and metadata against a registered per-customer public key.
On success, a deterministic subject identifier is derived from the customer ID and bundle hash (a UUID-v5-style construction, so the same customer/hash pair always yields the same subject ID).
A canonical anchor statement is assembled from the subject type, subject ID, bundle hash, engine-commit identifier, and timestamp, then hashed and signed by a Byzantine-fault-tolerant quorum of the operator's own validators - the design target being a threshold quorum out of a broader validator set spanning multiple jurisdictions.
The BFT-shaped record - the anchor statement plus the quorum's signatures, validator identifiers, and jurisdictions - is forwarded to the canonical anchor-storage layer for an idempotent insert keyed on content hash.
A receipt (anchor ID, timestamp, and an operator-side signature) is returned to the customer's appliance for storage alongside the original bundle as proof of anchoring.

Content-Blind by Construction

Because the request schema the operator's receiving service accepts contains only the bundle hash, submission metadata, and the customer's signature - never a payload field for bundle content - the operator's validators are structurally incapable of signing over content they were never given, regardless of the volume or sensitivity of what the bundle actually contains.

Prior Art Differentiation

Approach	Independent Second-Party Attestation?	Content Crosses Trust Boundary?	Quorum-Based?
Single-party notarization/timestamping	No	Depends	No
Hash-only blockchain anchoring	Not specific to the anchoring act	No	Depends on chain
VPC-peered / vendor-hosted sharing	Yes	Yes - content crosses	Depends
JIL Sovereign cross-trust-boundary co-anchoring	Yes - independent validator quorum	No - only the hash crosses	Yes

Patent Claim

Independent Claim 52: A computer-implemented method for cross-trust-boundary co-anchoring of cryptographically-sealed evidence, comprising: receiving, at an anchor-receiving service operated by a first party, a bundle hash and an associated digital signature produced by a second party's appliance over content that remains resident exclusively within the second party's own computing environment; verifying the second party's digital signature against a registered public key associated with the second party, without the first party receiving or storing the underlying content corresponding to the bundle hash; responsive to successful verification, synthesizing a canonical anchor statement comprising a subject-type identifier, a deterministically-derived subject identifier, the bundle hash, an engine-commit identifier, and a timestamp; obtaining a Byzantine-fault-tolerant quorum of digital signatures from a plurality of validators operated by the first party over the canonical anchor statement, the quorum of validators attesting to the anchoring event rather than to the underlying content; and committing the canonical anchor statement and its quorum signatures to an immutable ledger, such that the resulting anchored record carries independent cryptographic attestation from both the second party, as to the content, and the first party's validator quorum, as to the anchoring event, without the first party ever gaining access to the underlying content.