Document timestamping
that proves it existed,
unchanged, at that moment
Sign any document with a post-quantum ML-DSA signature and receive a cryptographic timestamp certificate. Every certificate is linked into an append-only chain whose head is published and timestamped into the Bitcoin blockchain, so the date does not rest on our word either. Anyone can verify the whole thing — without an account, and without trusting us. Your document never leaves your browser: only its fingerprint is sent.
Four steps. Permanent proof.
Your document is hashed locally — the server only receives the fingerprint. Same zero-knowledge model as encrypted messaging and the encrypted vault.
Hash locally
Your browser computes SHA-256 and SHA-512 fingerprints of the document. The file itself stays on your device — zero bytes uploaded.
Sign with ML-DSA
You sign the hash with your ML-DSA private key (NIST FIPS-204). The signature mathematically proves you authorized this exact document.
Server timestamps
PQCServer adds a certified timestamp and countersignature. This anchors the document to a precise moment in time.
Notary Receipt
You receive a JSON receipt with a permanent verify URL. Anyone can check it anytime — no account needed to verify.
What you get
A self-contained cryptographic proof. Download it as JSON or share the verify URL.
"receipt_id": "NTR-x7k2p9abcd",
"verify_url": "https://pqcserver.com/verify/NTR-x7k2p9abcd",
// DOCUMENT FINGERPRINT (never the file itself)
"document": {
"hash_sha256": "a3f9c2e1...",
"hash_sha512": "7bc2d4f8...",
"filename": "contratto_2026.pdf",
"size_bytes": 245120
},
// YOUR ML-DSA SIGNATURE
"signature": {
"algorithm": "ML-DSA-65",
"value": "MEQCIA...",
"signed_at": "2026-03-17T11:30:00Z"
},
// SERVER TIMESTAMP + COUNTERSIGNATURE
"timestamp": {
"server": "pqcserver.com",
"issued_at": "2026-03-17T11:30:02Z",
"server_signature": "ABCDEF...",
"server_public_key":"base64..."
}
Who uses it
Contracts & Agreements
Prove a contract existed in its current form before signing with a traditional notary. Establish precedence in case of disputes about document contents or dates.
Intellectual Property
Timestamp creative works, inventions, research papers, or source code. Establish prior art without expensive patent filings during early development.
Medical & Clinical Records
Prove a medical report was issued on a specific date. Verify a clinical protocol has not been modified retroactively. Critical for compliance and liability.
Journalism & Evidence
Journalists can timestamp sensitive documents and evidence. Prove source documents were unaltered before publication. Protect whistleblower materials.
Construction & Real Estate
Timestamp project drawings, permits, inspections, and site reports. Essential when disputes arise years after a project about the state of documentation at a given date.
Software & Code Signing
Sign software releases, configuration files, and security policies. Verify that code deployed in production matches the signed version. Detect tampering.
Audit Trails
Timestamp log files, configuration snapshots or database exports at regular intervals. Creates a tamper-evident record that still verifies years later, long after the systems that produced it are gone.
Internal Approvals
Run internal document workflows — invoices, purchase orders, HR records — with ML-DSA signatures, without needing a qualified certificate authority for documents that never leave the company.
What the receipt proves — and what it doesn't
A timestamp is a narrow, precise claim. Being clear about its edges is what makes it useful as evidence.
What it proves
- A document with this exact SHA-256 and SHA-512 fingerprint existed
- No later than the recorded UTC timestamp
- And was signed by the holder of the corresponding ML-DSA private key
- That the file has not been altered by a single byte since — any change breaks the hash
- That the certificate occupies a fixed position in an append-only chain, so altering it breaks every certificate issued afterwards
- That the chain containing it existed by the time its head was committed to the Bitcoin blockchain, which no one — including us — can rewrite
- All of the above verifiably by a third party, without trusting PQCServer
What it does not prove
- The legal identity of the signer — there is no KYC or identity vetting
- That the signer had legal capacity or authority to sign
- Equivalence to a qualified electronic signature under eIDAS
- That the document is true, lawful, or means what it appears to mean
- An exact issuing time between two anchors — the chain proves order, and the anchor proves the whole chain existed by the moment it was published, so the bound is as tight as the anchoring interval, currently one hour
The distinction matters in practice. A receipt establishes integrity and precedence — this content, no later than this moment — which is what disputes about versions, dates and prior art actually turn on. It does not establish who someone is. If you need identity binding as well, pair the receipt with a signer identity you already trust: a registered PQCServer profile, a company key published on your own domain, or a traditional notarised signature on top.
Why you don't have to take our word for the time
Most timestamping services ask you to trust their clock. Here is the mechanism that means you don't have to trust ours.
A signature proves who and what. It says nothing about when — a signed hash carries no date, so the date has to come from somewhere else. On almost every service, it comes from a field in the operator's database. That field can be changed, and nothing in the certificate would show it.
Every certificate is linked
Each certificate carries the SHA-256 hash of the one issued before it, and its own position in the sequence. The chain is append-only by construction.
Back-dating breaks the chain
Changing a certificate changes its hash, which breaks the link in the next one, and in every one after that. Anyone holding a later certificate can demonstrate it.
The head is published hourly
The current end of the chain is written to /anchors/ as a plain file. Rewriting the chain to hide a change would no longer match what was published.
And committed to Bitcoin
Each anchor is submitted to OpenTimestamps calendars, which commit it into the Bitcoin blockchain. From that point the date is attested by a ledger nobody controls.
The practical consequence: to back-date a certificate we would have to rewrite the chain, republish every anchor, and alter the Bitcoin blockchain. The first two are possible for us and detectable by you; the third is not possible for anyone.
What this does not give you is a precise clock. Anchors are published hourly, so a certificate is proven to have existed by the time of the next anchor, not to the second. For establishing precedence — who had what document first, and whether it changed since — that bound is what matters. If you need certified time to the second, an accredited Time-Stamping Authority under eIDAS is the right instrument, and it is not what this is.
Certificates issued before the chain was introduced are marked as such and remain outside it. They could only be added by writing a history that did not happen, which is precisely what the chain exists to prevent. The verification page reports this honestly rather than treating them as chained.
Growing legal standing
ML-DSA is a NIST federal standard (FIPS-204, Aug 2024). Legal recognition of PQC signatures is actively evolving — the EU, US, and other jurisdictions are integrating it into their frameworks.
European Union
eIDAS 2.0 framework (2026) will incorporate PQC algorithms. ETSI is standardizing PQC signature profiles. ML-DSA receipts establish strong technical proof now, with formal legal recognition following the standards roadmap.
United States
ESIGN Act recognizes electronic signatures broadly. NIST FIPS-204 is already a federal standard. ML-DSA receipts can be used as evidence in many commercial contexts. Federal agencies must adopt PQC by 2030.
International
Many jurisdictions accept cryptographic evidence under electronic commerce laws. The UN Model Law on Electronic Commerce provides a broad framework. PQCServer receipts provide strong cryptographic proof admissible as evidence in most legal systems.
Works today
- Cryptographic proof of document integrity
- Proof of existence at a specific timestamp
- Private contracts between consenting parties
- Software and code signing
- Journalistic and research evidence
- Internal corporate document workflows
- Post-quantum resistant — RSA and ECDSA signatures are not
Not yet available
- eIDAS Qualified Electronic Signature (QES)
- Italian CAD / AgID accredited signature
- Notarial acts and deeds
- Court filings that specifically require a QES
- Real estate transactions
- ETSI CAdES / XAdES / PAdES profiles for ML-DSA (expected 2026–2027)
Frequently asked questions
Cryptographic timestamping, in plain terms.
What is a cryptographic timestamp?
It is a signed statement that a specific piece of data existed at a specific moment. Your browser computes a fingerprint (hash) of the document, you sign that fingerprint, and the server records it with a UTC timestamp. Because any change to the file produces a completely different fingerprint, the record proves both when the document existed and that it has not been altered since.
Do you receive a copy of my document?
No. Hashing happens in your browser and only the SHA-256 and SHA-512 fingerprints leave your device, along with your signature. Zero bytes of the file itself are uploaded. A hash cannot be reversed into the original document, so we could not read it even if we wanted to — and could not produce it if compelled.
How is this different from RFC 3161 timestamping?
RFC 3161 is the classic Time-Stamp Protocol, and it relies on RSA or ECDSA signatures from a Time Stamping Authority. Those signatures are exactly what a quantum computer would break. A timestamp is only useful for as long as its signature holds — an RFC 3161 token issued today may become worthless as evidence precisely when you need it in fifteen years. PQCServer uses ML-DSA (FIPS-204), which is designed to survive that.
How is this different from blockchain timestamping?
We use both, which gets the useful half of each. Publishing every document to a public ledger would be slow, costly per document and permanently public, so individual certificates stay private and instant. Instead the chain of all certificates is summarised into a single hash, and that is committed to Bitcoin hourly through OpenTimestamps. You get ledger-backed proof of the date without your document, its name or its hash ever becoming public.
Is it legally binding?
It depends on what you need it for, and the section above sets out the boundary honestly. For disputes about document versions, dates or prior art — and for private agreements where both parties accept the standard — a receipt is strong evidence today. It is not a qualified electronic signature under eIDAS, and does not replace notarisation where the law requires it.
What if PQCServer disappears?
The receipt is self-contained. It carries the document hashes, your signature, your public key, the server signature and the server public key, so a third party can verify the mathematics with standard ML-DSA tooling and no reference to this site at all. Keep a copy of the JSON alongside the document. The implementation is open source, so the verification procedure stays reproducible.
Do I need an account?
No. You need an ML-DSA keypair, which you can generate in your browser without registering. Verifying someone else's receipt needs nothing at all. A free account is only useful if you want a persistent public profile so others can check your signatures against a known key.
How much does it cost?
Nothing. There is no size limit, no per-document charge and no paid tier. The same applies to encrypted messaging and the encrypted vault.
Ready to timestamp your first document?
Free. No size limit. Document never leaves your browser. Permanent receipt. Publicly verifiable forever.