Skip to main content

Timestamp

This document presents the functional architecture of EBSI's Timestamp core service.

What it is​

The Timestamp core service anchors cryptographic hashes on the EBSI ledger. Once written, the record is immutable: it proves that a specific piece of data existed in an exact form at a specific moment in time. The service does not store the data itself, only its hash. Sensitive content can therefore be timestamped without exposing it on a public blockchain.

The Timestamp smart contract is deployed on the EBSI ledger, whilst the Timestamp Service exposes the data through a convenient REST API.

Two anchoring modes​

Timestamps​

A timestamp anchors a single hash at a point in time. It is the simplest form of anchoring:

  1. Compute a hash of your data (the API supports multiple hash algorithms).
  2. Submit the hash to the Timestamp smart contract through the Ledger Service.
  3. The Ledger Service writes the hash to the EBSI ledger smart contract and returns a transaction reference.

The on-chain record contains: the hash, the identity of the account that submitted it (timestampedBy), the block number, and the block timestamp.

Use this when you need point-in-time proof: a document signature, a credential issuance event, a contract conclusion.

Records​

A record groups multiple timestamps under a single identifier; each new timestamp becomes a version. Records provide a structured view of how data evolved over time.

A record tracks:

  • All versions of the data (ordered sequence of hashes).
  • Who owns the record.
  • Revocation status.

Use records when you need document version history: iterative credential schemas, evolving policy documents, or any artifact that changes over time and where each state must be independently verifiable.

How it works​

The Timestamp Service interacts with the Timestamp smart contract deployed on the EBSI ledger.

Write operations to the smart contract require an access token with the timestamp:write scope. Access is controlled by the Authorisation Service.

Client → Authorisation Service (timestamp:write token)
       → Ledger Service (submit hash to the Timestamp smart contract)
       → EBSI Ledger smart contract (immutable write)

The ledger's Proof of Authority (PoA) consensus ensures the record cannot be altered after it is written.

Use cases​

  • Credential issuance proof: anchor the hash of a VC at the moment of issuance so verifiers can confirm it was not backdated.
  • Document signing: prove that a contract or policy document had a specific content at a specific date.
  • Schema versioning: anchor each version of a Trusted Schema so downstream consumers can verify which version was in force at any time.
  • Audit trail anchors: record compliance-relevant events on-chain without exposing their content.

Further reading​

Last updated on