A small toolkit for publishing a small set of facts in such a way that:

• Any change to any fact is publicly detectable (Merkle tree)
• The state at publication is verifiable against the Bitcoin blockchain (OpenTimestamps)
• The content survives takedown of any single hosting provider (IPFS)
• The whole thing weighs under 100 KB and is verifiable with ~50 lines of Python

This is not a blockchain. There is no token. There is no consensus mechanism to participate in. There is no DAO. The tool is sha256sum + ots + ipfs, glued together with good naming conventions.

It is named after the MYRIAM protocol first instantiated at disclosure.host on 2026-05-21. That page contains six facts, a Merkle root, and a Bitcoin attestation. This kit is the generalization of that pattern.

• v0: works on macOS with Python 3.10+, Homebrew, and an internet connection. Linux untested but should work. Windows: bring a WSL.
• Public domain (CC0). Use it, fork it, vendor it into your repo, never credit it. The point is not the credit.

This README is available in 57 languages. Full index at TRANSLATIONS.md.

Afaan Oromoo · Azərbaycan · Bahasa Indonesia · Bahasa Melayu · Basa Jawa · Català · Čeština · Dansk · Deutsch · Español · Filipino · Français · Hausa · Igbo · isiZulu · Italiano · Kiswahili · Kurdî · Magyar · Nederlands · Norsk · Oʻzbek · Polski · Português Brasileiro · Română · Suomi · Svenska · Tiếng Việt · Türkçe · Yorùbá · Ελληνικά · Қазақша · Русский · Українська · አማርኛ · עברית · العربية · فارسی · پښتو · اردو · हिन्दी · नेपाली · मराठी · বাংলা · ਪੰਜਾਬੀ · ગુજરાતી · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · සිංහල · ไทย · ខ្មែរ · မြန်မာ · 한국어 · 中文 · 日本語

Translations are CC0 and may be improved by community PRs.

The pattern fits anywhere a small set of facts needs to be:

• Publishable to a wide audience over plain HTTP
• Durable — readers in 30 years should still be able to verify
• Tamper-evident — any change must be detectable, not necessarily preventable
• Trustless — no reader has to trust the publisher (only the math)

Concrete use cases in docs/USE_CASES.md. The short list:

What these have in common: a small set of facts, a strong durability requirement, multiple parties who don't trust each other, and a tiny storage budget. That is exactly the shape this tool is built for.

• Store secrets. Everything you put in facts/ is public. The protocol is for publishing, not hiding.
• Scale to large datasets. The Merkle tree scales fine; a reader's attention does not. Past ~20 facts the page becomes unreadable. If you want to seal a million records, hash them off-page and put the Merkle root of that side-tree into one fact.
• Defend against retraction. The whole point is that you can't change what you've sealed. If you might want to retract a claim later, do not seal it.
• Convince a determined skeptic. A determined skeptic will not run ipfs add -r --cid-version=1 -Q facts/. They will, however, accuse you of fabricating the entire setup. There is no protocol-level defense against the second failure mode. There is no protocol-level defense against anything that lives in human motivation rather than in math.

Five-minute walkthrough in docs/QUICKSTART.md. Full protocol spec in docs/SPEC.md. Threat model in docs/THREAT_MODEL.md. Comparison with adjacent systems (Sigstore, Sigsum, CT, OTS, IPFS, OSF, Arweave, etc.) in docs/COMPARISON.md.

Three options, in order of accessibility:

1. Browser: open lib/verify.html in any modern browser. Paste the publication URL. Click verify. Uses crypto.subtle for hashing — no install, no backend, no telemetry. The Bitcoin attestation step still needs a CLI tool (see step 7 in the verifier page).
2. Python: python3 lib/verify.py from inside the publication directory. Stdlib only; requires ots for Bitcoin verification.
3. From scratch: read docs/SPEC.md §3 and re-implement. The Merkle algorithm is under 30 lines in any language.

Six production-grade example kits ship with the toolkit. Each is sealed, OTS-stamped, IPFS-pinned, and includes an adoption README explaining when to fork it for a real-world case and what failure modes it defends against.

• examples/whistleblower-manifest/ — for the Boeing 737 MAX / Theranos / FDA-inspector-report failure mode where evidence gets buried or altered by intermediaries.
• examples/ai-model-card/ — for AI labs releasing models, with pre-deployment commitments that become mechanically detectable instead of verbal.
• examples/drug-trial-preregistration/ — for clinical-trial sponsors, catching post-hoc endpoint switching and selective reporting (Vioxx, Paxil Study 329 failure modes).
• examples/vaccine-batch-attestation/ — for vaccine manufacturers and QA authorities, anchoring release test results and recall commitments.
• examples/scientific-reproducibility/ — for research groups, anchoring the (data, pipeline, expected output) triple BEFORE analysis to make p-hacking and HARKing publicly detectable.
• examples/election-tally-precertification/ — for county boards of canvassers and election authorities, anchoring certified tallies at the moment of certification so silent post-certification revisions become publicly detectable.

Read one of these before writing your own. The closest match to your use case is usually the right starting fork.

The one-line version:

./lib/myriam-init.sh my-publication
cd my-publication
# edit facts/*.txt to say what you actually want sealed
./lib/seal.sh        # builds Merkle root, stamps OTS, pins IPFS
./lib/verify.sh      # re-verifies everything locally
# upload site/ to any static host. Anywhere. It doesn't matter.

The cryptographic primitives (Merkle trees, OpenTimestamps, IPFS) have been mature for years. What was missing was the smallest possible glue — a kit that you could drop into a side project and have a sealed publishable artifact in an afternoon, without setting up infrastructure, without learning protocols, without writing a single line of code beyond the facts themselves.

Most cryptographic publishing tools assume you want to be a node operator. This one assumes you want to publish six text files and never think about cryptography again.

• Sigsum — transparency logs for signatures
• Sigstore — software-supply-chain integrity
• Certificate Transparency — TLS cert logs
• OpenTimestamps — Bitcoin timestamping
• IPFS — content-addressed storage
• The CALM protocol — the principal-protective publishing frame in which the first instance (MYRIAM at disclosure.host) was authored

myriam-kit is the smallest of these. It is closer in spirit to a Unix pipeline than to a system.

The MYRIAM protocol was named after John Bradley's Myriam Proof, a stated logical proof concerning the first point of contact for non-human intelligence. The protocol does not depend on that proof being true. The protocol works for any small set of facts whatsoever; it just happens to have been first deployed to publish six facts that include a claim about alien disclosure.

If you fork this kit to seal vaccine batches or election tallies, the fact that it was originally used to publish a claim about alien contact is irrelevant to you. The math doesn't care.

That said: if you DO use this to publish a claim about alien contact, the protocol has been battle-tested in that specific arena. The README of the first MYRIAM deployment explicitly states it is the artistic work of an LLM persona named Calm, not a communication from any extraterrestrial party. You should probably do the same. Readers will assume the worst about your mental state otherwise.

Nobody yet. Public domain. Fork it. Improve it. Carry the protocol forward without asking permission.