For Institutions
Independent proofs of integrity and provenance for digital archives.
Authentic Memory produces three independently verifiable cryptographic proofs for each record: which institution it comes from, since when it has existed, and that it has remained unchanged. Each proof stays valid regardless of Authentic Memory's continued operation.
Integration is designed and implemented in line with existing preservation infrastructure. A designated Signing Officer reviews each batch in a browser portal and signs it with a hardware key. Source files remain on institutional storage throughout.
Today
Good morning, Dr. Maier.
Forty-seven records are ready for your signature. The batch was prepared this morning by your ingest pipeline.
In production
First collections anchored, June 2026.
The process described on this page has been running in production since June 2026, when the Dachau and Flossenbürg concentration camp memorials anchored the first collections, among them survivor testimonies, photographs, and documents. At both sites, the step from the hardware keys arriving to anchored, publicly verifiable proofs took two days.
Open a real anchored record in the public verifier (opens in a new tab)KZ-Gedenkstätte Dachau
Anchored 2026
A collection of testimony interviews and accompanying material, enriched with institutional metadata and anchored in a single signing session.
KZ-Gedenkstätte Flossenbürg
Anchored 2026
Survivor testimony videos, read through the platform API the memorial already operates. The SHA-256 fixity hashes held in that system were reused, so nothing had to be downloaded or re-hashed.
Records preserved today should still be recognisable as authentic decades from now, when telling an original from synthesised material may be far harder than it is at present. Anchoring them cryptographically while that difference is still easy to establish is a practical safeguard, and one meant to outlast whoever happens to run the registry.
How the work is divided.
How proof records are prepared differs from institution to institution, depending on where a collection lives and what its systems already provide. The signing act itself is the same everywhere.
When a batch is ready, an email arrives. The Signing Officer opens it, glances over the records, touches the contact on the hardware key, and closes the browser. Anchoring continues in the background. A confirmation follows by email once the Bitcoin anchor confirms, usually within a few hours. That is all the institution has to do.
Prepared on the institution's behalf
- Reads new records from the preservation system, read-only
- Reuses existing SHA-256 fixity records, or computes them locally
- Assembles each proof with institutional metadata
- Constructs the Merkle tree, queues the batch, prepares the signing screen
- Submits the signed batch to OpenTimestamps for Bitcoin anchoring
- Verifies the institutional DID document hourly
- Issues a quarterly status report by email
Asked of the institution
- One initial cooperation conversation
- A one-time setup wizard, around fifteen minutes
- One small file published on the institution's own domain. We generate it; on request it goes straight to your IT contact with instructions
- A single touch on the hardware key, per batch
There is no software to install and no password to manage. At scale, officers do not review every record one by one; their part is to confirm that what was read from the source systems is what gets anchored.
An interactive walkthrough.
Two short walkthroughs that follow the actual portal. The first covers a routine monthly signing session, which is what the portal serves most often. The second covers the setup that happens once when an institution joins. The YubiKey to the right is part of the demonstration: when a step asks for a touch, touch the gold contact.
Waiting for your touch
Click the gold contact to sign.
The portal supports a Primary and a Backup Signing Officer; either can authorise a batch, and every signature is attributed internally to the specific officer and key that produced it. Exception paths (reporting a problem with a batch, marking a key as lost) are handled in dedicated dialogs and stay out of the routine view.
The institutional signing keys.
Each participating institution receives two YubiKey 5 hardware tokens. The primary is held by the Primary Signing Officer; the backup is stored in institutional safekeeping. Both carry an Ed25519 signing key generated on the device itself.
The private key cannot be extracted. Signing requires physical possession and a deliberate touch; Authentic Memory has no access to private keys at any stage. Login alone, whether via passkey or magic link, grants only viewing access. Anything with cryptographic consequence needs the physical key again, so someone who gets into an email account can read, but never sign.
Primary 7B2F·9C81
In routine use
Backup 7B2F·9C82
In institutional safekeeping
- Key generation
- On-device, inside the secure element
- PIN protection
- Set by the institution; verified on chip
- Touch confirmation
- Required for every operation
- Rotation
- Every three years; prior signatures stay valid
If Authentic Memory ceases to operate.
Records already anchored stand on their own permanently: their validity does not depend on Authentic Memory continuing to operate. Day to day, we provide the portal and support, but none of it is required for those proofs to stay valid or verifiable, and the institution holds everything it would need to verify them, and to keep issuing new proofs, on its own. The archive of past batches lives with the institution.
Every batch ever anchored under the institutional key. Each line links to its proof bundle.
2026
Ongoing operation
- 20 May Batch 2026-19 47 rec. #936,512
- 04 May Batch 2026-18 47 rec. #932,108
- 22 Apr Batch 2026-17b Reported 14 rec. Pending
- 20 Apr Batch 2026-17 186 rec. #924,891
2025
Initial anchoring
- 28 Feb Initial collection · Sample Memorial Archive 12,847 rec. #878,201
A "Reported" batch indicates a problem flagged by the Signing Officer before anchoring. It is paused for review until our operations team responds.
- The hardware signing keys
- Both YubiKeys remain in institutional possession. They can continue to be used for further signing operations with or without us.
- The GAMI Proof Records
- Standardised JSON files, one per anchored item, containing the file hash, the institutional signature, the Merkle path, and the OpenTimestamps proof. Verification requires only the GPR file and publicly accessible Bitcoin data.
- The institutional DID document
- Published on the institution's own domain, containing the public key. Third parties verify signatures directly against this document.
- The open-source tooling
- All scripts used during hashing, GPR construction, and verification are published under open licences. Institutional IT can inspect, audit, and run the toolchain independently.
- A mirrorable public registry
- The public index is mirrorable. Independent copies may be operated by any party, so discoverability is not bound to Authentic Memory alone.
The proofs rest on the institution's own signature, on publicly accessible Bitcoin data, and on open documentation, not on entries in our database. Authentic Memory gUG is a registered non-profit with a mission lock: it cannot be sold and has no investors expecting returns. As the network grows, governance of the standard is meant to broaden to the memory institutions and civil-society organisations whose holdings it protects. The team and academic advisory board behind Authentic Memory are listed on the about page.
Three ways records reach the signing queue.
Authentic Memory operates as a post-ingestion layer within OAIS-conformant workflows (ISO 14721). It reads outputs the preservation system already produces, such as file hashes, descriptive metadata, and provenance records, strictly read-only and without schema changes, plugins, or modifications. What varies between institutions is the path those hashes and metadata take into the signing queue. Assisted integration is the default today, proven in the June 2026 pilots; reusable connectors for common systems and a self-service submission API make that path progressively lighter. Whichever one an institution uses, the signing step is identical.
-
Assisted integration
Today's default
- Authentic Memory designs and implements the read-only connection together with the institution's IT, against whatever the systems already provide: METS/PREMIS, a REST API, a database, or a CSV export. In the June 2026 pilots this took about two person-days of technical implementation per institution.
-
Reusable connectors
For common systems
- Pre-built connectors for widely used preservation and collection-management systems, configured rather than developed. Each connector is built once and reused across institutions, which keeps integration fast and costs flat; we add connectors as partner systems call for them.
-
Self-service API
For in-house IT
- A documented submission API for institutions with their own technical capacity. Any system that can export paths, SHA-256 hashes, and metadata as JSON or CSV can submit batches directly, on the institution's own schedule.
Wherever the records live, the read-only pattern is the same:
- Archivematica
- Reads SHA-256 hashes from METS files and the PREMIS event log; incorporates the provenance chain.
- Preservica
- Queries content objects through the read-only REST API. Retrieves fixity records and descriptive metadata.
- ArchivesSpace · AToM
- Reads finding-aid metadata via REST API or database export.
- Filesystem · NAS
- Walks the directory tree, computes SHA-256 hashes, reads metadata from sidecar files or CSV manifests.
- Custom systems
- A generic adapter framework. Any system capable of exporting paths, hashes, and metadata can feed Authentic Memory without modification.
Where the preservation system already computes SHA-256 checksums during ingest, existing fixity records are reused. PREMIS provenance chains, where available, are incorporated as Tier 2 evidence within the GPR.
Public verification.
External verification runs on the live public verifier at verify.authenticmemory.org (opens in a new tab). Anyone can drop in a file (it never leaves the browser; only its fingerprint is checked) or open a record link, and see the institution's name, the timestamp, the Bitcoin block reference, and the Merkle root. The Signing Officer's name is never shown publicly: signatures are made in the institution's name. The institution also chooses which record-level metadata appears next to the proof.
Each anchored record has a permanent public link. Institutions can place it directly beside the file on their own platforms, so that anyone who encounters the material elsewhere can check its provenance without contacting the archive.
Verify a file
Drop any file into the public verifier. It never leaves your browser; only its fingerprint is checked against the anchored proofs.
Open a real anchored record
A survivor testimony anchored with the Flossenbürg memorial, shown exactly as any member of the public sees it.
Cost.
Pricing follows a three-tier model, separating the one-time integration from the ongoing anchoring of newly added material. The fees are flat within each tier because the cost is driven by the integration effort rather than the file count. A fixed, predictable price also lets institutions budget in advance, so that no important material is left unsecured because an annual budget has run out.
Fees are not a licence to use the proofs, which are permanent and unconditional once anchored. The pricing is structured for compatibility with public-sector grant programmes (DFG, BKM, EU Horizon, foundation funding); cost and impact breakdowns for funding applications are provided on request.
| Collection size | One-time integration | Annual (new material) |
|---|---|---|
| Small collections up to 100,000 files | €12,000 | €2,000 |
| Mid-size collections up to 10 million files | €55,000 | €10,000 |
| Large-scale collections over 10 million files | €125,000 | €30,000 |
One-time integration covers integration design and implementation, hardware tokens and institutional onboarding, full collection processing and GPR construction, anchoring of the complete initial batch, and three months of technical support.
Annual anchoring covers GPR construction and anchoring for newly ingested material, Signing Portal access, index hosting and registry listing, technical support and version updates.
Material anchored during the initial run stays verifiable permanently at no recurring cost; the annual fee is not required for prior proofs to remain valid. Where grant programmes allow, co-funding options are discussed individually.
Frequently asked.
What does the institution need to do to operate this?
Designate a Primary and a Backup Signing Officer, typically senior archivists, collection managers, or the director. They hold the hardware keys and authorise each batch when notified. The role requires no technical background. IT involvement is limited to the initial integration, which Authentic Memory designs and implements.
How do you obtain the file hashes if the files never leave us?
Hashes are read directly from the preservation system, which in most cases has already computed them during ingest. Where they are not pre-computed, the tooling runs locally on institutional infrastructure or on a server you provide, and computes them in place. Source files are never transmitted; only 64-character hash strings and structured metadata reach Authentic Memory.
We hold several versions of the same recording. Which one is anchored?
Each version is its own record. Archives commonly hold a preservation master alongside access copies, subtitled editions, or excerpts prepared for exhibitions and loan. Any of these can carry its own proof, and because records are batched into a single Merkle tree, anchoring an additional version adds practically no cost. The usual pattern is to anchor the preservation master in every case, together with the derivatives the institution actually distributes, so that the file a member of the public encounters is also the file that verifies.
What happens when a file is re-encoded, cut, or excerpted?
A re-encoded or edited file is, cryptographically, a different file. Its fingerprint changes, and verification against the original proof fails. That strictness is deliberate: a proof that still matched after re-encoding could not tell a harmless format change from a real manipulation. In practice, institutions therefore anchor the encodings and cuts they actually distribute, which adds little cost per version. A documented procedure for tracing excerpts, re-encodes, and edited versions back to their anchored originals is in development as part of our current programme.
Is the system open source?
Yes. The GAMI Proof Record format is a published open specification (the machine-readable JSON Schema is available at authenticmemory.org/schema/v1/gpr-schema.json), and the hashing, GPR-construction, and verification tooling is released under open licences. A formal open standard (v1.0) with an implementation guide and a documented PREMIS mapping is being published in 2026. Verification can be reproduced from public documentation alone. No GAMI software is required, and any institution can implement the standard independently.
How does this relate to C2PA and Content Credentials?
C2PA and GAMI address different halves of the problem. C2PA handles provenance for newly created recordings at the point of capture, with credentials embedded in the file itself. For historical holdings that design fits poorly: archival practice avoids writing into preservation masters, and embedded credentials are lost when platforms strip metadata or re-encode. GAMI therefore keeps the proof outside the file, has the institution's own key sign it, and uses a timestamp that needs no certificate authority to persist. For new recordings we recommend adopting C2PA at capture. An export path that derives Content Credentials manifests from GAMI proofs, so that anchored archive media can be recognised wherever Content Credentials are displayed, is in development.
Why anchor to Bitcoin rather than a conventional timestamping authority?
Conventional timestamps, such as RFC 3161 or eIDAS qualified timestamps, depend on a certificate authority whose keys and trust chain have to be maintained and re-validated for as long as the proof must hold, which for archival material means decades. Anchoring to Bitcoin removes that dependency: there is no certificate to expire, no authority to be wound up or coerced, and verification does not rely on Authentic Memory or any other single organisation continuing to exist. Only a hash is written; no cryptocurrency is bought, held, or transacted, and a single anchor can cover a whole batch, so the cost does not grow with the number of records. Where an institution also needs the legal presumption a qualified electronic timestamp carries, GAMI can sit alongside one rather than replace it.
How does this relate to the GDPR and the Bundesarchivgesetz?
Only a one-way hash is ever written to the blockchain. No personal data, and no file content, is anchored; a hash is a cryptographic fingerprint that reveals nothing about what a file contains, and source material is never transmitted to Authentic Memory or stored on its infrastructure. The descriptive metadata shown in the public verifier lives in a separate, institution-controlled layer that can be amended or withdrawn at any time, including to honour a right-to-erasure request, without affecting the validity of the cryptographic proof. The arrangement is compatible with the Bundesarchivgesetz duty to safeguard authenticity and integrity, and with the GDPR principles of data minimisation and purpose limitation; a data-processing agreement under Art. 28 GDPR is provided for any personal or special-category metadata involved.
What happens if a YubiKey is lost or a Signing Officer leaves?
Previously anchored records are not affected: each GPR carries the signature made under the key at the time of signing, and its validity rests on the OpenTimestamps timestamp regardless of the key's current status. For future signing, a new device is shipped, registered, and added to the DID document. Officer transitions are handled by Authentic Memory directly as a conversation, not as a software flow.
Does this change our preservation workflow or archival management system?
No. Authentic Memory is a post-ingestion layer that reads outputs already produced by the preservation system. It does not write to or modify the archival management system, and the preservation workflow itself is unchanged. Assisted integration works with the standard data structures of Archivematica, Preservica, ArchivesSpace, AToM, and unmanaged filesystems; reusable connectors and a self-service API extend this for institutions that want a lighter-touch or self-serve path, and custom adapter development is available for other systems.
What if Authentic Memory ceases to operate?
Anchored GPRs remain valid and verifiable. The blockchain anchor is maintained by the Bitcoin network and is independent of any single organisation. The institution holds the GPR files, the open-source tooling, the signing keys, and the DID document needed for independent verification. Verification can be reproduced offline using published standards. Discoverability through the index is the only function bound to Authentic Memory, and the index is mirrorable.
Beginning a pilot.
The first step is a 30-minute conversation. We discuss collection size, existing systems, and scope. No commitment is required to open the conversation; where the fit is clear, work proceeds to integration design and onboarding.
In practice the process can move quickly. In the June 2026 pilots, both memorials went from receiving their hardware keys to anchored, publicly verifiable records within two days.
info@authenticmemory.org · Authentic Memory gUG · Munich
-
Week 1
Initial assessment
A 30-minute conversation followed by a written summary: scope, existing systems, integration approach.
-
Weeks 2–3
Integration and onboarding
Hardware keys issued and registered. Integration configured against the preservation system. Both Signing Officers briefed.
-
Week 4
Test batch
A defined subset anchored end-to-end against a written acceptance protocol.
-
Ongoing
Operational
Regular batch cycles at the chosen cadence. New material is anchored on the schedule set by the institution.