PQ Transparency is live

In April we shipped PostQ Ledger — a per-org, hash-chained, hybrid-signed Merkle audit log. It answered the question regulated buyers kept asking: can you prove nothing was changed retroactively? But it raised a sharper one: why should anyone trust PostQ’s copy of the log?

Today we’re answering it. PQ Transparencyis a standalone, public, post-quantum-signed transparency log — the same trust model as Certificate Transparency and Sigstore Rekor, but quantum-safe and independently verifiable. It’s live at postq.dev/transparency, the server is open source, and it ships with a CLI, an HTTP API, and a deployable witness service.

Why a separate log at all

Ledger is private and per-org — it’s your internal audit trail. Transparency is public and open: anyone can submit an artifact or event, and anyone can verify a receipt without a PostQ account. The two share the same DNA (Merkle trees, signed checkpoints) but solve different problems. Crucially, Transparency lets a third party verify claims about your Ledger without ever seeing your org’s data— more on that below.

And to be clear about what it’s not: there are no tokens, no consensus, no gas, no chain. It’s a single-writer, append-only Merkle log with signed checkpoints. The integrity comes from the cryptographic structure, not from a distributed ledger.

Submit once, verify forever

You submit a file or a JSON event. The server hashes it with SHA-512, appends the hash as an RFC 6962 Merkle leaf, signs a fresh checkpoint, and hands you a receipt: the artifact hash, the leaf index, a Merkle inclusion proof, the signed checkpoint, and the signature algorithm. The receipt is a standalone proof — no server trust required to check it later.

# Install the CLI
go install github.com/postqdev/postq-transparency/cmd/postq@latest

# Submit a file → writes artifact.txt.receipt.json
postq trans submit artifact.txt

# Inspect the latest signed checkpoint
postq trans checkpoint

# Verify the receipt offline — hash + Merkle + ML-DSA signature
postq trans verify artifact.txt artifact.txt.receipt.json --online

Tamper with the artifact by a single byte and verification fails: the hash no longer matches, and the Merkle proof no longer reconstructs the signed root. That’s the whole point — the storage is assumed hostile, and the math catches any change.

Post-quantum checkpoints (ML-DSA-65)

Every checkpoint is a signed commitment to the tree: { log_id, tree_size, root_hash, timestamp }, signed with ML-DSA-65 (FIPS 204)— the standardized post-quantum signature formerly known as Dilithium. A future quantum adversary can’t forge a checkpoint or back-date an entry. The signed bytes are a stable, newline-delimited note so any verifier, in any language, can reproduce them byte-for-byte:

postq-transparency/v1
log_id=log:f706f709d11f7c0c17e69e16a4ae493f
tree_size=42
root=sha512:fc79e0e3d4b162783960983482aad5d9...
timestamp=2026-06-08T03:00:07Z

A classical Ed25519 signer is available for local dev, but it’s clearly labelled non-post-quantum and the public instance runs ML-DSA-65.

Consistency proofs: prove the log is append-only

A signed checkpoint proves what the tree looked like at one moment. A consistency proof(RFC 6962 §2.1.2) proves that a later checkpoint is a valid extensionof an earlier one — that the log only ever appended, and never removed, altered, or reordered an entry. Anyone holding an old checkpoint can verify the new one is honest:

postq trans consistency 1 42   # prove size-1 tree → size-42 tree

This is the cryptographic backbone that makes a transparency log more than “a database we promise not to edit.”

Independent witnesses: don’t even trust us

There’s one attack a single-operator log can’t defend against on its own: equivocation, or showing different histories to different people (a “split view”). The defense is a witness— an independent party that cosigns each checkpoint, but only after verifying the consistency proof. With one honest witness in a different cloud account or region, the log operator alone can no longer forge or roll back history.

PQ Transparency ships a deployable witness as a first-class service. It holds its own ML-DSA-65 key and refuses to cosign anything that isn’t a valid append-only extension:

# Run an independent witness (ideally a different region/org)
pqt-witness --addr :8081 --id witness-1

# Point the log at it — checkpoints now carry witness cosignatures
pqtrans-server --witnesses https://witness-1.example.com

Present the witness a tampered or inconsistent extension and it returns HTTP 409 and signs nothing. Cosignatures flow into every checkpoint and receipt under cosignatures[], each independently verifiable with the witness’s public key. This is the same operator-trust property a hardware TEE gives you — achieved with a second party, on commodity infrastructure.

Real hardware attestation (AWS Nitro)

And for teams that do want the hardware story, our signing enclave moved beyond mock attestation. It now produces genuine AWS Nitro Enclavesattestation documents — COSE_Sign1 CBOR blobs from the Nitro Security Module, signed by the AWS Nitro Attestation PKI, carrying PCR0/1/2 measurements of the running image. The private key never leaves the enclave; every signature comes with cryptographic proof of exactly which code produced it.

People ask how this compares to Azure Confidential Ledger. ACL runs in Intel SGX and gets hardware operator-trust — but its receipts are classical (not post-quantum), it’s Azure-locked, and it’s a closed box. PQ Transparency gives you the same attestation property on commodity Nitro hardware, pluspost-quantum signatures and fully open, offline verification. You don’t have to choose between hardware trust and quantum safety.

Ledger, now anchored

Here’s where it comes together. Every PostQ Ledger seal now gets anchored to the public Transparency log. When your Ledger checkpoints, it submits the signed tree head to PQ Transparency and stores the receipt. The result: your private audit trail gets an independent, public, timestamped anchor that a third party can verify — without ever touching your org’s data.

We also took the chance to harden the Ledger itself. Entry and Merkle hashing moved from SHA-256 to SHA-512for post-quantum longevity (256-bit security against Grover’s algorithm). Existing entries stay verifiable under their original hashes — no migration required.

The boring-but-important parts

• Keys never hit disk in prod. The log and witness load their signing key from an injected secret (PQT_SIGNING_KEY / PQT_WITNESS_KEY), not the filesystem.
• Rate limited. Per-IP token bucket on the public API; the main PostQ API and Ledger writes are now rate limited per API key too.
• Pure-Go, static binaries. SQLite via modernc, CGO_ENABLED=0— deploys as a single binary, ships with a Dockerfile and a Fly.io config.
• Stable receipt format. postq-transparency/v1— field names and signed-byte layout are a public contract.

Try it

Open the public explorer — you can verify any receipt right in the browser (the hash and Merkle checks run client-side via Web Crypto, no server needed). Or grab the CLI and submit your first artifact:

go install github.com/postqdev/postq-transparency/cmd/postq@latest
echo "hello post-quantum world" > artifact.txt
postq trans submit artifact.txt
postq trans verify artifact.txt artifact.txt.receipt.json --online

The whole thing — log, witness, CLI, and the Nitro-attested enclave — is open source. Transparency you can’t verify yourself isn’t transparency.