Architecture Overview All timestamping happens client-side first: users hash their files locally using SHA-256. Only the hash is sent to our API — no file contents ever leave the client.

The API then:

Creates a dual signature — one using ECDSA P-256 (current classical cryptography standard) and one using ML-DSA-65, the NIST FIPS 204–approved post-quantum algorithm (Dilithium-family).

Anchors both signatures into a Bitcoin transaction via OpenTimestamps, ensuring long-term public verifiability independent of our servers.

Publishes a daily JSON ledger of all timestamped hashes and their dual-signature proofs.

Verification Users can verify proofs in three ways:

On-site via the verification tool https://sasasavic.ca/verify/

Manually using OpenTimestamps and our public JSON

Or by validating the ECDSA and ML-DSA signatures independently

Why this matters Most timestamping systems are still vulnerable to future quantum attacks because they rely solely on ECDSA or RSA. By layering PQC (post-quantum cryptography) today, the proofs remain valid and independently verifiable even if quantum computing breaks classical cryptography later.

This API is free to use during beta, with full documentation here: https://sasasavic.ca/beta-api/

Would love feedback on:

-Implementation of ML-DSA vs Dilithium variants

-Any edge cases in JSON proof verification

-Suggestions for improving developer tooling or SDK design

Looking forward to seeing how developers use the API or integrate quantum-resistant timestamping into their workflows.