This webpage is an interface to create and/or verify timestamp proofs using the OpenTimestamps protocol and its free public Bitcoin calendar servers. [If in a hurry, skip the following introduction at your own risk and go straight away to timestamping.]

A timestamp demonstrates that a document existed in a specific status prior to a given point in time, providing a document with a certain sure date (e.g. postmark). Law requires dates to be usually certified by public officials and notary services; for digital documents, timestamping is based on the digital signature of a Certification Authority (CA).

Digital data can be securely timestamped though the attestation of its hash value in a blockchain transaction: the transaction extends its native blockchain timestamping to the included hash value, therefore proving its existence at a given point in time. The hash value 'uniquely' identifies the document (as if it were its digital fingerprint): as a result, its blockchain attestation proves the existence of the original document itself prior to the timestamp moment.

The timestamping and content of a blockchain transaction are secured by the amount of computational effort performed after its inclusion in a block of the chain. Indeed, the more blocks are added to the chain after a given block, the more computationally intensive is tampering with the data of that block; even just trying to alter the timestamp of a transaction becomes technically and economically prohibitive, especially in the Bitcoin case.

Although there are many ways to realize a timestamp, OpenTimestamps is a vendor-independent blockchain-agnostic open protocol that defines a set of operations for creating provable blockchain timestamps and later independently verifying them; as such, it allows for third party auditability and is suitable for regulatory prescriptions.

OpenTimestamps attestation proofs can be verified independently from any server, vendor, or centralized infrastructure, simply using a local copy of the blockchain (e.g. a Bitcoin full node). Trust minimization is achieved because of this distributed, decentralized, independent, uncensorable, and cross-jurisdictional design. This webpage interface is just a facility and, since a webpage cannot access the local filesystem, relies on public Bitcoin block-explorers (e.g. for verification.

To avoid the inefficiency of one blockchain transaction for every timestamp, an OpenTimestamps server provides aggregation of multiple hashes in a Merkle tree> data structure and performs their attestation in a single transaction (attesting only the tree root hash). Aggregation before attestation results in almost unlimited scalability.

While anyone could timestamp with any permissionless blockchain by paying the appropriate transaction fees (using the OpenTimestamps protocol or any alternative approach), for convenience there are multiple public OpenTimestamps calendar servers (e.g., free to use without any registration or API key. A single calendar server can offer its services to multiple remote OpenTimestamps clients: verifiable timestamp are created almost instantly. The public free OpenTimestamps calendar servers use Bitcoin as timestamp notary, i.e. they make the Bitcoin transactions that will ultimately attest hash values in the Bitcoin blockchain.

Timestamp and Verify

Use the box below to:

  1. Submit (the hash value of) a file for timestamping
    When a file is dropped in the box:
    1. its hash value is calculated locally inside the browser without disclosing the document to third parties, preserving privacy;
    2. the hash is then submitted to multiple redundant public OpenTimestamps servers to obtain an attestation proof of its existence (timestamp);
    3. a submission receipt is downloaded (as .ots filetype); this is not an attestation proof yet: it is incomplete and it cannot be verified immediately, as it can take up to few hours for the transaction to be included in the blockchain.
    In time, the hash value will be attested in a block: then, the servers it has been submitted to will be able to upgrade its submission receipt to attestation proof. As long as at least one server is properly functioning, the timestamp is ensured.
  2. Upgrade a submission receipt to attestation proof
    If the file dropped in the box is a submission receipt (filetype *.ots):
    1. an upgrade to proof attestation is downloaded from the calendar servers if available;
    2. the proof, if any, is verified using public Bitcoin block-explorers.
  3. Verify an attestation proof
    If the file dropped in the box is an attestation proof (filetype *.ots):
    1. an updated proof is downloaded from the calendar servers if available;
    2. the most recent proof available is verified using public Bitcoin block-explorers.

Drop here a file to timestamp it or a receipt/proof (*.ots) to verify it.


Attestation proofs can be verified independently from any OpenTimestamps server or facility. The same is not true for the submission receipt, which can only be upgraded to proof using the OpenTimestamps calendar(s) used for submission.

The user is responsible to store both the stamped document (which has never been shared with the OpenTimestamps servers) and its attestation proof (which technically might be stored by the OpenTimestamps servers).

While the OpenTimestamps protocol is blockchain agnostic, a timestamp is as reliable as the used blockchain:

  • very reliable when using Bitcoin because that blockchain is secured by huge computational power (proof-of-work);
  • much less reliable with other public permissionless blockchains;
  • when used with a private permissioned blockchain its reliability depends on the trustworthiness of the chain governance: in this case a traditional certification authority is probably better.

It should be obvious, but it is worth mentioning that timestamping (using the OpenTimestamps protocol or any alternative approach):

  • can be selectively revealed to show convenient evidence and hiding inconvenient evidence (e.g. timestamping a bet on a given outcome and its opposite, later revealing only the realized one);
  • does not prove authorship (that should be proved using a digital signature);
  • can be repudiated if not digitally signed
  • does not ensure veracity, validity, correctness, or accuracy¬†of the timestamped document.