OlympusLedger

Open-source infrastructure that lets anyone verify that a document matches a previously committed cryptographic record—without uploading the document or trusting a single institution.

Comment

Inspiration

When a document is leaked, published, or used as evidence, people are usually asked to trust the institution that produced it—or trust a website that could later be changed.

That is a serious problem for journalists, lawyers, public-records users, auditors, and human-rights investigators. A PDF can be altered, replaced, or quietly removed, while ordinary timestamps and download pages provide little independent evidence of what existed before.

Olympus was inspired by a simple question:

Can we prove that a document existed, prove that it has not changed, and let someone verify that claim years later—even offline—without uploading the document itself?

What Olympus does

Olympus is open-source, privacy-preserving infrastructure for document integrity.

A file is hashed locally and committed to an append-only cryptographic ledger. The system produces a portable proof bundle that can be independently verified later. Verification can be performed using only the document’s hash, so private documents do not need to be uploaded merely to check whether they were committed.

The working prototype demonstrates:

  • Local BLAKE3 hashing before upload
  • Hash-only verification
  • Authenticated file commitments
  • Append-only ledger storage
  • Rejection of duplicate, conflicting, and invalid record operations
  • Downloadable proof bundles
  • Independent offline verification using Rust and JavaScript verifiers
  • Rejection of invalid API keys and duplicate commitments

Olympus also includes advanced layers implemented in the repository, including zero-knowledge proof circuits, privacy-preserving redaction commitments, optional Tor-based federation, and external anchoring through RFC 3161 timestamping, Sigstore Rekor, and OpenTimestamps.

How we built it

Olympus is a self-contained Rust and Tauri desktop application. The backend uses Axum, SQLx, and an embedded PostgreSQL database, so the default application does not require a separate cloud service or database installation.

The cryptographic core uses domain-separated BLAKE3 hashing, sparse Merkle trees, Ed25519 signatures, Poseidon, Baby Jubjub, and Groth16 proofs. The frontend is built with React, TypeScript, Vite, Tailwind, and TanStack Query.

The core workflow is:

Ingest → Canonicalize → Hash → Commit → Prove → Verify

What I built during Build Week

Olympus existed before Build Week, so I focused the event on a specific new extension: a durable, transactional SQLite storage backend for the sparse Merkle tree and verification workflow.

During Build Week, I added:

  • Durable SQLite-backed storage
  • Atomic transaction commit and rollback
  • Snapshot refresh for long-lived readers
  • Canonicalization-receipt verification
  • Rejection of duplicate, conflicting, and invalid records
  • Durable reopen and recovery checks
  • Membership and non-membership proof validation
  • A standalone, judge-ready executable and demo workflow

I used Codex as an engineering partner to inspect the existing architecture, implement the new storage abstraction, diagnose failures, generate adversarial tests, and harden the release.

I used GPT-5.6 to review design tradeoffs, analyze security and threat-model assumptions, identify edge cases, and refine the demonstration and documentation.

The repository also contains standalone offline verifiers, so users do not have to trust the Olympus application itself. The goal is for a proof bundle to remain useful outside the original interface and long after the original operator is gone.

What we learned

We learned that the hardest part of a cryptographic integrity system is not generating a hash. It is making every surrounding decision precise and independently checkable.

That meant designing:

  • Append-only, write-once behavior
  • Persistent signing keys
  • Canonical document processing
  • Domain-separated hash inputs
  • Portable proof bundles
  • Offline verification
  • Explicit threat-model limitations
  • A clear separation between demonstrated functionality and audit-gated functionality

We also learned that privacy and public accountability do not have to be opposites. A system can publish enough cryptographic evidence to verify an integrity claim without publishing the underlying sensitive document.

Challenges

The biggest challenges were building a usable desktop experience around security-critical Rust code, keeping database and cryptographic state consistent, and making proofs verifiable across independent implementations.

The zero-knowledge layer also introduced trusted-setup and ceremony requirements. Olympus currently includes the circuits and runtime proving and verification paths, but production deployment requires a multi-contributor ceremony and additional external review. We state that limitation explicitly rather than presenting development artifacts as final trust infrastructure.

Another challenge was supporting real documents and real workflows. Redaction, PDF structure, canonicalization, proof packaging, authentication, recovery, and offline verification all create edge cases that a simple hash-only prototype would not address.

Why it matters

Olympus is designed as a proof layer that can sit beside existing document portals, newsroom workflows, legal processes, public-records systems, and investigative tools.

It does not ask users to trust a single company, server, or dashboard. It gives them a portable cryptographic receipt that can be checked independently.

You do not have to trust us.

You can verify us.

Built With

Share this project:

Updates