Technical Architecture · Draft 1.0 · 2026
Cryptographic Authenticity Infrastructure for Digital Archival Materials
GAMI is an open, non-proprietary infrastructure that enables archives, memorial institutions, and libraries to create long-term, publicly verifiable proofs of existence, integrity, and institutional provenance for digital materials.
Core Guarantees
What a GAMI Proof Establishes
For each anchored file, a successfully verified GAMI Proof Record (GPR) establishes four things, each resting on independently verifiable cryptographic evidence.
Existence
This exact file demonstrably existed no later than the anchoring date, proven by a commitment in the Bitcoin blockchain that is verifiable by anyone.
Integrity
The file has not been modified since anchoring. Any change — even a single bit — produces a different fingerprint and breaks the proof.
Institutional attribution
A named institution signed this proof with a private key only they hold, verifiable against their published public key without any intermediary.
Metadata integrity
The metadata recorded at anchoring time has not been altered and is covered by the institutional signature. Sensitive fields may be kept private — only their hash is committed to the record.
The system does not store content, does not require trust in GAMI for proof validation, and does not alter existing archival practice. Original files remain exclusively under institutional control. Discovery via the public verifier and DID resolution fallback rely on GAMI infrastructure, but neither affects the validity of an existing proof.
I · System Architecture
Four Layers, One Self-Contained Proof
The architecture consists of four tightly integrated layers. Each contributes a property the others cannot provide alone. The hash proves file identity. The signature proves institutional responsibility. The timestamp proves temporal existence. The Proof Record bundles all three into a single verifiable document, independently auditable against open public infrastructure.
- 01
File Fingerprinting
SHA-256 hash computed inside institutional infrastructure.
- 02
GAMI Proof Record
Hash, metadata, and chain reference bundled and canonicalised.
- 03
Institutional Digital Signature
Ed25519 signature; institutional key identity published via DID:web.
- 04
Distributed Timestamp Anchoring
Merkle aggregation submitted to Bitcoin via the OpenTimestamps protocol.
Every algorithm and format is an established open standard with published specifications and independent implementations. No proprietary technology at any point.
File Fingerprinting
For each file, a SHA-256 hash is computed locally — inside the institution's infrastructure. SHA-256 is a cryptographic hash function that takes input of arbitrary size and produces a fixed-length 256-bit output. The original file never leaves institutional custody.
$ gami hash oral_history_DM_2024_00451.mp4
SHA-256 fingerprint · 256 bits
3a7f91c2e8b4d6a0f1c3e5b7d9a2f4c6e8b0d2f4a6c8e0b2d4f6a8c0e2b4d6f8
A single-bit change in the input produces an entirely uncorrelated output. No partial overlap.
Original file
3a7f91c2e8b4d6a0f1c3e5b7d9a2f4c6…
One bit flipped
7c4e1a9f2b3d56e8a0b71c4f8d2e3a9b…
Properties
Determinism
The same file always produces the same hash.
Pre-image resistance
Reconstructing a file from its hash is computationally infeasible.
Collision resistance
Finding two distinct files with the same hash is computationally infeasible.
Quantum-resistant
Grover's algorithm reduces effective security to 128 bits — secure by current standards.
SHA-256 is the same hash function used by OpenTimestamps, C2PA, Archivematica, and Preservica. For institutions running OAIS-conformant systems, hashes generated during ingestion can be reused directly — eliminating the rehashing phase entirely.
The GAMI Proof Record
Each file's hash, institutional signature, metadata, and timestamp proof are bundled into a single JSON document — the GAMI Proof Record (GPR). The GPR is the fundamental unit of evidence in the system: it carries the full proof in one portable file, independently auditable against the Bitcoin blockchain and the institution's published public key.
Format
Canonical JSON (RFC 8785 / JCS) with a JSON-LD-compatible @context, ensuring deterministic byte representation and interoperability with W3C Verifiable Credentials, Schema.org, and Europeana.
Footprint
Typically 1–3 KB. Versioned schema; a published specification defines the exact semantics of each version.
"@context": "https://authenticmemory.org/schema/v1",
"type": "gami-proof",
"schema": "v1",
"id": "urn:uuid:a1b2c3d4-...",
"subject":
"hash": "sha256:3a7f91c2e8...",
"filename": "Dachau_DM_2024_00451.tif"
,
"institution":
"name": "Dachau Memorial Site",
"key_id": "did:web:dachau-memorial.de#key-2026"
,
"metadata":
"public":
"collection": "DM",
"classificationCode": "DM/2024/00451",
"dateAnchored": "2026-09-15T14:22:00Z"
,
"private_hash": "sha256:99af2b..." // hash of sensitive metadata kept off-record
,
"parent": null, // reference to predecessor GPR for append-only updates
"canonicalization": "JCS",
"signature": "ed25519:7f3a91...",
"timestamp":
"method": "opentimestamps",
"proof": "<base64-encoded OTS proof>"
Institutional Digital Signature
The hash alone identifies a file. It does not say who is vouching for it. The institutional signature adds that attribution — and makes it independently verifiable. Each GPR is signed by the anchoring institution using Ed25519 (RFC 8032), an elliptic-curve scheme widely deployed in SSH, TLS 1.3, and the Signal protocol. Ed25519 produces 64-byte signatures and provides 128-bit classical security with mature implementations in every major language.
Signing process
- 01
The GPR is constructed with all fields populated except signature and timestamp.
- 02
The document is canonicalised (RFC 8785 / JCS) to produce a deterministic byte representation — ensuring the signature covers an unambiguous encoding.
- 03
The SHA-256 hash of the canonical form is computed.
- 04
The hash is signed with the institution's Ed25519 private key. The key never leaves institutional infrastructure.
- 05
The resulting signature is inserted into the GPR.
Verification reverses these steps: remove signature and timestamp fields, canonicalise, recompute the hash, and validate against the institution's published public key. If the check passes, it is mathematically guaranteed that only the private-key holder could have produced the signature.
GAMI cannot sign
Only the institution's private key produces a valid signature. The key never leaves institutional infrastructure.
Non-repudiation
Once signed, the institution cannot subsequently deny having signed the GPR.
Mature deployment
Ed25519 is the same scheme used by SSH, TLS 1.3, the Signal protocol, and the C2PA standard.
Key management — DID:web
Institutional identity is managed using DID:web (W3C Decentralised Identifiers). Each institution publishes a DID document — public keys, algorithm identifiers, validity periods, revocation status — at https://<institution-domain>/.well-known/did.json. Verifiers resolve the institution's DID against that URL and validate signatures locally; GAMI is never on the trust path.
Self-sovereign
The institution controls its own keys and identity. GAMI has no access to private keys at any point.
Rotation and revocation
Keys can be rotated on a routine schedule, and revocation dates published in the DID document. GPRs signed before a revocation remain valid — their temporal position is established independently by the OTS timestamp.
Domain-loss resilience
GAMI maintains an archived, timestamped copy of all partner DID documents. If an institution's domain later changes ownership, verification still resolves against the cached record.
No central registry
No certificate authority, no GAMI-issued credential. The institution's domain is the root of trust.
Distributed Timestamp Anchoring
After signing, the complete GPR (minus the timestamp proof field) is hashed, and this hash is submitted to the OpenTimestamps protocol. OTS aggregates submitted hashes into a Merkle tree and embeds the tree's root hash in a Bitcoin transaction. Once confirmed in a block, that commitment is secured by Bitcoin's global proof-of-work network.
Thousands of GPR hashes per batch
Pairwise SHA-256 → intermediate nodes
Single Merkle root
root = a3f8d2c1e94b076f5512ad3c8b2e1f47d09c563ae781b24d60f93e5c71820da4
A single Bitcoin transaction commits the root of a Merkle tree containing thousands of GPR hashes. Each individual GPR carries the Merkle path needed to prove its inclusion — without revealing any other hash in the batch.
Why a Merkle tree
Batching thousands of proofs into a single Bitcoin transaction keeps cost minimal and throughput effectively unbounded. The Merkle path lets any single hash be independently verified without exposing the rest.
Why Bitcoin
The largest and most heavily computationally secured public ledger in continuous operation: running since 2009, no successful attack on confirmed blocks, fully public, no account or fee required to verify. Additional anchoring to supplementary ledgers (e.g. bloXberg) is available for institutions seeking redundancy.
What the anchor proves
A publicly verifiable lower bound on the GPR's existence. If a GPR is anchored in a 2026 Bitcoin block, it is mathematically provable that the GPR — and the file it references — existed no later than that date. Not an assertion by any authority; a consequence of the blockchain's structure.
II · Verification
Independent, Reproducible, Real-Time
Verification is the critical public-facing function of the system. It must be independently reproducible by anyone, require no trust in GAMI for proof validation, and produce results in near-real-time. The design goal is that the verification process can be fully reimplemented by a third party using only the published standards and the open-source toolchain — and that the result would be identical.
Lookup mode
Verifier has only the file
The hash is computed client-side via the Web Crypto API. The 64-character hash is submitted to a GAMI-compatible index node, and the matching GPR — if any — is returned. All subsequent validation steps run against that GPR.
Direct mode
Verifier has the file and the GPR
No external lookup. The proof is validated entirely locally against the Bitcoin blockchain and the institution's published public key. Suitable for court submissions, classified environments, or decades-future verification.
The three independent checks
In both modes, validation runs three checks. All three either pass or fail independently. A partial result — for example, a valid signature on a non-matching hash — is clearly surfaced and does not produce a positive verification.
- 01
File hash check
~2 s · client-sideCompute SHA-256 of the file. Compare to subject.hash in the GPR. Proves the file matches the one originally fingerprinted.
- 02
Signature check
< 1 msRemove signature and timestamp fields, canonicalise (JCS), recompute the hash. Validate Ed25519 signature against the institution's public key. Proves the named institution signed this exact GPR.
- 03
Timestamp check
< 10 msRemove only the timestamp field, canonicalise, hash, and validate the OTS proof against the Bitcoin blockchain. Proves this signed GPR existed at the attested date.
-
Result
< 5 s end-to-endAll three checks pass independently — file matches, institution signed it, and this signed record existed at the attested date. < 5 s for a 1 GB video; < 1 s for an image or document.
Validity is self-contained · discoverability is a convenience
The validity of a proof is entirely self-contained in the GPR and the Bitcoin blockchain. It does not depend on GAMI, on any mirror, or on any network connection. The discoverability of a proof — finding it by submitting only a file hash — does depend on an index node being available. This is the same separation that exists between a document's authenticity and a library catalogue's ability to help you find it. If every index node disappeared, every existing proof would remain fully valid and verifiable by anyone holding the GPR file directly.
Performance
| Step | Duration | Where it runs |
|---|---|---|
| Hash computation (1 GB video) | 2–3 s | Client-side (browser, Web Crypto API) |
| GPR lookup by hash | < 1 ms | Server (B-tree index, PostgreSQL on commodity hardware) |
| Signature verification | < 1 ms | Server or client (pure elliptic-curve arithmetic) |
| OTS proof verification | < 10 ms | Server or client (Merkle path + Bitcoin block header lookup) |
| End-to-end (large video) | < 5 s | Hash dominates; cryptographic checks add < 15 ms total |
| End-to-end (image / document) | < 1 s | End-to-end |
The lookup is a B-tree index query keyed on a 32-byte hash; sub-millisecond response remains achievable into the hundreds of millions of records on a single PostgreSQL server. The system scales linearly with collection size without architectural changes.
Index and mirrors
The index is a discovery layer — a way to retrieve a GPR from a file hash. The proof itself is carried by the GPR; no database query is part of validation.
Global index
A publicly accessible database keyed by file hash, holding only proof records — never original files. Upon anchoring, GPRs are published immediately.
Mirror protocol
An open export format lets any institution, university, library, or media organisation operate a mirror over a full or partial copy. Verifiers can query multiple nodes; resilience grows with adoption.
III · Archival Integration
Post-Ingestion Layer Within OAIS Workflows
GAMI is designed as a post-ingestion layer within OAIS-conformant workflows (ISO 14721). It does not replace, modify, or interfere with existing preservation processes. It reads existing data and adds a cryptographic proof layer on top.
GAMI never writes to the preservation system. It consumes what the system already produces. No schema changes. No plugins. No database modifications.
Integration model
The integration follows a consistent four-step pattern regardless of the underlying system.
- 01
Read
existing AIPs, METS, PREMISAccess file hashes and metadata from the existing preservation system. Where SHA-256 hashes are already computed, GAMI reuses them directly.
- 02
Build
construct GPR · sign Ed25519Construct GPRs from the collected hashes and metadata. Sign with the institution's Ed25519 private key.
- 03
Anchor
Merkle root → OTS → BitcoinAggregate GPRs into a Merkle tree and submit the root via OpenTimestamps to the Bitcoin blockchain.
- 04
Store
global index · public verifierCompleted GPRs are submitted to the global index, immediately discoverable via the public verifier and any mirror node.
The same four-step loop runs for every batch — daily, weekly, or per-file — without coordination with GAMI.
System-specific integration
The archival landscape is diverse. The integration model accommodates this range without requiring institutions to standardise first.
| System | Type | Integration approach |
|---|---|---|
| Archivematica | Open-source OAIS | Read SHA-256 hashes from METS files and PREMIS event logs. Ingest provenance chain (fixity history). No API required — direct filesystem access to AIP structure. |
| Preservica | Commercial OAIS | Query content objects via REST API. Retrieve fixity information and descriptive metadata. Read-only API access. |
| CollectiveAccess | Collections management | Query via REST API or direct database access. Map collection metadata to GPR fields. |
| Filesystem / NAS | Unmanaged file storage | Walk directory tree, compute hashes, optionally read metadata from sidecar files or CSV manifests. |
| Custom systems | Institution-specific | Generic adapter framework: any system that can export file paths, hashes, and metadata in CSV/JSON can feed into GAMI. |
OAIS positioning
Within the OAIS reference model (ISO 14721), GAMI operates at the boundary between archival storage and access. It reads from Archival Information Packages (AIPs) — file hashes, PREMIS event logs, descriptive metadata already present — and publishes the resulting GPRs to the global index.
IV · Security & Long-Term Resilience
Cryptographic Foundations
Every component in the proof chain uses published, independently audited standards with no proprietary modifications.
| Component | Standard | Security level | Status |
|---|---|---|---|
| File hashing | SHA-256 (FIPS 180-4) | 128-bit post-quantum (Grover) | Industry standard · no known weaknesses |
| Digital signature | Ed25519 (RFC 8032) | 128-bit classical; quantum-vulnerable (Shor) | Protected retroactively by OTS |
| Timestamp anchoring | OpenTimestamps + Bitcoin | Bitcoin proof-of-work | Computationally infeasible to alter |
| Serialisation | RFC 8785 (JCS) | Deterministic representation | IETF standard |
| Key identity | DID:web (W3C) | DNS + HTTPS trust model | W3C standard |
Post-quantum resilience
SHA-256 is considered quantum-resistant: Grover's algorithm reduces its effective security to 128 bits, which remains secure by current standards. Ed25519 is vulnerable to Shor's algorithm on a sufficiently powerful quantum computer, but this risk is structurally mitigated by the OTS timestamp. Even if a signature could be forged in the future, a forger cannot create one that was anchored in a 2026 Bitcoin block. The timestamp retroactively protects the integrity of all prior signatures.
As a proactive measure, GAMI periodically re-anchors all existing GPRs using updated algorithms — the renewal chain. The process hashes all GPRs with a post-quantum algorithm, aggregates them into a new Merkle tree, signs with a post-quantum scheme (SLH-DSA, FIPS 205), and anchors the root via OTS. This proves that at the time of renewal, when previous algorithms were still fully secure, all existing GPRs already existed. The renewal is a single batch operation running in minutes, repeated every 3–5 years — well ahead of any practical quantum threat.
Failure modes and mitigations
Every system can fail. The architecture is designed so that no single failure invalidates existing proofs.
| Scenario | Impact | Mitigation |
|---|---|---|
| Institution's private key compromised | Future signatures invalid; all past GPRs remain valid — OTS timestamp proves they predate the compromise. | Publish revocation date in DID document; rotate to new key pair. |
| GAMI ceases to exist | No impact on existing proofs. Any GPR can be verified using only the GPR file, the file itself, the Bitcoin blockchain, and the institution's public key. | Open-source toolchain published; mirror nodes maintain independent copies of the index; no central dependency for proof validation. |
| Institution's website goes offline (DID:web) | DID resolution against the institution's live domain fails. | Key resolution falls back to GAMI's timestamped DID archive — a weaker trust model, disclosed as such. The OTS timestamp on each GPR establishes that it existed while the domain was live, bounding the trust requirement to that period. |
| OTS calendar server unavailable | New anchoring delayed; existing proofs unaffected. | Multiple OTS calendar servers; anchoring retried automatically. |
| SHA-256 weakened | Theoretical: hash collisions become feasible. | Renewal chain re-anchors with stronger algorithm proactively, well before any weakness becomes exploitable. |
Transparency and auditability
Every verification step uses standard algorithms with published specifications, so any third party can reimplement the verifier and arrive at the same result. The cryptographic design has been developed in dialogue with the project's academic advisory board — researchers in coding theory, post-quantum cryptography, and digital trust at TU Munich, LMU Munich, and Princeton. An independent third-party security audit is planned ahead of broader deployment; the codebase and the resulting audit report will be published publicly.
V · Operational Footprint
Linear Scaling on Commodity Hardware
The architecture has no algorithmic bottleneck, consensus protocol, or coordination requirement that limits throughput. The only practically significant cost is I/O and CPU time for the initial hashing — and where preservation systems already produce SHA-256 fingerprints, that cost is zero.
| Throughput | SHA-256 sustains roughly 500 MB/s per modern CPU core. Extrapolated to a 1 PB collection (10M files at ~100 MB each), hashing completes in days on a single 8–16 core server, hours across parallel nodes — bound by storage I/O, not by GAMI itself. |
| Recommended cadence | Daily or weekly batches against new ingest. Resumable progress log; only new files are processed. |
| Hardware | Single dedicated server (8–16 cores, 64 GB RAM, NVMe). No cluster, no distributed system, no specialised hardware. |
| GPR storage | 10 million GPRs occupy 10–30 GB. A decade of anchoring at that volume stays under 1 TB — trivially archivable alongside source material. |
VI · Interoperability
Bidirectional Compatibility with C2PA
The Coalition for Content Provenance and Authenticity (C2PA) — backed by Adobe, Google, the BBC, and others — is developing standards for content credentials embedded in newly created digital content. GAMI and C2PA are complementary, not competing. C2PA addresses the forward problem: giving newly captured content a signed origin certificate at the point of creation. GAMI addresses the backward problem: establishing verifiable provenance for historical material created before such standards existed.
GAMI → C2PA
GPRs can be exported as C2PA custom assertions within a C2PA manifest, enabling C2PA-aware platforms and viewers to surface GAMI provenance information. As C2PA integration becomes standard on major platforms, this pathway could make GAMI records far more visible than a standalone verifier ever could.
C2PA → GAMI
Files that already carry C2PA content credentials (e.g. from C2PA-enabled cameras) can be ingested into GAMI. The existing C2PA manifest is referenced in the GPR metadata, creating a continuous provenance chain from recording device through to institutional archiving.
VII · Evidentiary Framework
What a Proof Establishes — and What It Does Not
This distinction is material. Verification results are displayed to journalists, researchers, and legal practitioners who require an accurate account of which claims are cryptographically proven and which are institutional declarations.
What a GAMI proof does not establish
Content truthfulness. A witness may be mistaken; a photograph may be staged. Questions of historical interpretation, not cryptographic proof.
Pre-anchoring integrity. GAMI does not prove the file was unmodified before anchoring. Where available, pre-anchoring fixity records are included as Tier 2 (institutionally declared) evidence.
Uniqueness. GAMI does not assert the anchored version is the only or original version of a file.
Full archival authenticity. Authenticity in the archival sense encompasses creation context, custodial history, and fonds membership — dimensions that extend beyond what any cryptographic system can prove. GAMI captures these as signed metadata where available, complementing but not replacing traditional archival practice.
Two tiers of evidence
Most institutions operating OAIS-conformant systems already maintain documented integrity histories — Archivematica, for instance, generates PREMIS events with fixity timestamps throughout a file's lifecycle. GAMI captures those records as metadata within the GPR, extending the documented chain backwards in time. The verification interface displays both tiers with explicit attribution, so users can distinguish what is cryptographically proven from what is institutionally declared.
Tier 1 — Cryptographically anchored
The OTS timestamp provides an independently verifiable existence proof from the anchoring date forward. Requires no trust in any institution.
Tier 2 — Institutionally documented
Fixity records from the archive system document integrity for the period before GAMI anchoring. Requires trust in the institution's preservation infrastructure — but is signed and timestamped together with the GPR.
Evidentiary weight and timing
The evidentiary weight of an existence proof depends on when the timestamp was created relative to the state of synthetic media technology. A timestamp anchoring a file to 2026 carries a different implication than one anchoring it to 2032.
If a file can be shown to have existed in exactly this form in 2026, and if it is historically clear that visually and technically indistinguishable synthetic fabrications were not achievable at that time, then the file predates the capability required to fabricate it. This inference holds regardless of what synthetic media technology becomes capable of later. The timestamp does not expire; it places the file in a specific historical moment whose technological conditions are independently knowable.
A timestamp created after indistinguishable synthetic fabrication becomes feasible can no longer support this inference — the existence proof remains valid, but it no longer rules out the possibility of synthetic origin. Files anchored before that threshold retain the stronger evidentiary property permanently. This is the basis for treating anchoring of existing historical collections as time-sensitive.
Two anchoring scenarios — same proof mechanism, different evidentiary weight
anchored 2026
Strong evidentiary weight
Proves existence before indistinguishable synthetic fabrication was technically feasible. Rules out synthetic origin. Permanently retains this property.
anchored 2032
Existence proof only
Proves the file existed in exactly this form at the anchoring date. Does not rule out the possibility that the file was synthesised.
What this means for your institution
Understand what a pilot integration looks like in practice — what your team does, what GAMI does, and what you receive.
For institutionsSee it as a story
Walk through the full authentication journey for a single file — from first recording to independent verification decades later — in an interactive narrative.
How it worksA complete GPR specification, reference implementations, and open-source tooling are in preparation alongside the first pilot integrations and will be published once stabilised. Technical questions and integration discussions with institutional IT departments are welcome — write to info@authenticmemory.org.