Standard-Compliant Blockchain Anchoring for Timestamp Tokens

Abstract

Traditional Time-Stamping Authorities provide reliable temporal evidence. However, they operate as single points of trust and do not supply a tamper-evident record of event ordering. This paper presents a standards-compliant extension that anchors each issued timestamp token to a blockchain ledger while preserving full compatibility with existing TSA clients. Our proposal is compliant with RFC 3161. The implementation uses an identifier in the token that is also included in the distributed ledger. Experiments were conducted on the Ethereum and Hyperledger Fabric networks. Our design allows for external verification of the existence and relative ordering of tokens without modifying the RFC-defined validation process. Experimental evaluation compares issuance latency, anchoring time, and transaction cost across both networks. Our work presents a practical and viable approach to enhancing trust in digital signature infrastructures by combining the regulatory reliability of qualified TSAs with the auditability and persistence of distributed ledgers.

1. Introduction

Digital signature infrastructures are widely used in public key infrastructures (PKIs) to provide authenticity, integrity, and non-repudiation of data. However, a digital signature is only valid as long as the associated certificate remains trustworthy. In most regulatory frameworks, including the European eIDAS Regulation (EU 910/2014) [1], this requires demonstrating that the signature was generated at a time when the certificate had not yet expired or been revoked. For this reason, timestamping is used as a supporting cryptographic service that binds data to a point in time using a trusted time source. The most widely accepted standard in this space is RFC 3161 [2], which defines how a Time-Stamping Authority (TSA) signs a token attesting that specific data existed at a certain time, using its own trusted time source and private key.

While RFC-compliant TSAs are effective in preserving the validity of signatures over time, they operate under a centralized trust model and do not provide external guarantees about the order in which events occurred. For example, in PKI workflows involving document signing, certificate revocation, and signature validation, the relative order of operations is often more relevant than their absolute timestamps. A signature is valid if it occurred before a revocation, but this can only be established if both the signature and revocation timestamps are available and can be ordered unambiguously. In traditional TSA systems, even if each token is individually valid, their sequence cannot be proven cryptographically. The validation relies entirely on the time values claimed by the issuing TSA, without external verifiability of event ordering.

While standard-compliant TSAs, such as those defined in RFC 3161, provide reliable temporal evidence, they do not address an equally critical property: the ability to prove the relative order between events. In PKI workflows, operations like signing, validation, and revocation are time-sensitive. The correctness of the signature validation process often depends on the order in which these operations occur. Existing TSA tokens, though verifiable, are issued in isolation and are not recorded in any public or durable log. As a result, relying parties cannot establish a tamper-proof sequence of operations across systems, users, or trust domains. Additionally, traditional TSA models place all trust in a single authority, with no distributed fallback or independent confirmation mechanism.

Although the academic literature has explored combining blockchain anchoring with timestamping to improve transparency and integrity, these approaches bypass the existing standards and do not produce RFC-compliant tokens. Consequently, they remain incompatible with existing PKI software and legal frameworks such as eIDAS. There remains a gap between experimental blockchain-based timestamping and regulated, standards-preserving trust services. To the best of our knowledge, a solution that combines both worlds (standard timestamp tokens and a distributed ledger) has not yet been implemented.

In this paper we propose a publicly available implementation of a timestamp authority capable of anchoring tokens into a blockchain network. This work is relevant especially if also other PKI services would transition to a similar architecture so that the relative order of events could be established without any doubt.

The rest of the paper is organized as follows. Section 2 presents a comprehensive technological regarding timestamping. It touches on the state of the art in terms of legislation, standards, open-source implementations, and research literature. Section 3 delves into the problematic nature of unique trust anchors and benefits of using a distributed trust source. The detailed proposed solution for timestamping is presented in Section 4. The results are presented in Section 6 together with the evaluation methodology in Section 5. For a better analysis of our work, we propose a discussion in Section 7. Finally, Section 8 is reserved for conclusions, limitations, and future work.

2. Background and Related Work

A digital signature is a cryptographic material which guarantees the integrity of the signed data. Besides that, it provides a way to authenticate the signer. To verify a digital signature, you need the associated digital certificate. A digital certificate has a limited lifetime of up to 3 years, but documents tend to be stored for a significantly longer time. Moreover, their respective digital signatures’ validity must be kept so that the data integrity and the non-repudiation of the signing act remain intact. As a consequence, the following problem arises: how to prove that the certificate of the key used to sign the data was valid at the time the signature was created?

Timestamping is a cryptographic service that provides verifiable proof that a piece of data existed at a specific point in time. It works by having a trusted third party, called a Time-Stamping Authority (TSA), digitally sign a hash of some data sent by a client, along with the current time. A key aspect about Time-Stamping Authorities is that their sole role is to bind data to a point in time. The client’s data can be anything from a PDF signed with a key whose certificate has expired or been revoked to some arbitrary binary data. The TSA job is kept simple and focused on one job: providing trusted and secure timestamps.

Using timestamping services together with digital signatures can solve the lack of future validity of signatures after the associated certificates have expired. If the timestamp obtained from a TSA is proper and it falls in the validity period of the certificate used to sign the timestamped data, then that signature is considered to be valid as well, even after the client certificate has expired.

2.1. Standardization

2.1.1. RFC 3161 and RFC 5816

The core standard for the Internet X.509 Public Key Infrastructure Timestamp Protocol is RFC 3161 [2]. Here, key aspects such as the ASN.1 structure definitions for timestamp token generation and verification are defined. The protocol is based on a simple client–server architecture. Between the two entities is a request–response exchange using Cryptographic Message Syntax (CMS) [3] containers. A high-level glance at the timestamp generation process would unveil the following steps:

• The client sends to the TSA a hash over the information for which timestamping is required (typically the data together with the generated signature for the respective data);
• The TSA constructs a structure containing the current time, the client’s hash value, and the associated metadata;
• The resulting structure is signed by the TSA and is sent back to the client.

A response from the server (i.e., the Time-Stamping Authority) contains a TimeStampToken [2]. Precisely, the structure contains the timestamp creation time, in UTC format, alongside with the accuracy, the hash of the message sent to the TSA, and other relevant information such as the serial number or nonce (used as a protective measure against replay attacks). The accuracy defines time deviation bounds (upper limit = timestamp + accuracy, lower limit = timestamp − accuracy) which relying parties should use to determine acceptable time windows for the issued token. The validation process of a token, as defined in RFC 3161 [2], comprises the following steps:

• Verify the response status;
• Validate the token fields, including the hash (must match the hash from the request), the nonce if present, and the accuracy/ordering requirements;
• Validate the token signature using the TSA public key;
• Verify the TSA certificate trust chain (validate the certificate chain up to a trusted root);
• Verify if the TSA certificate was valid at the timestamp creation time;
• Check the certificate revocation status via CRL [4] or OCSP [5];
• Verify that the TSA certificate has the extended key usage for timestamping (id-kp-timeStamping).

Furthermore, RFC 5816 [6] updates RFC 3161 [2] to support hash algorithms beyond SHA-1 [7] through ESSCertIDv2. The legacy ESSCertID structure hardcoded SHA-1 for TSA certificate identification, while ESSCertIDv2 introduces algorithm agility by explicitly mentioning the algorithm type in a field present in the response token.

2.1.2. eIDAS Compliancy and ETSI Standardization

If a TSA wants to become qualified under the eIDAS [1] regulation, it must comply with several ETSI standards which enhance the security and robustness of the offered services by employing stricter rules at the operational and technical aspects of such an entity.

Precisely, at the operational level, a TSA must meet the ETSI standards EN 319 421 [8], which defines the policy and procedures for a TSA, and EN 319 401 [9], which describes general requirements for a Trust Service Provider. Key aspects mentioned in these standards are the fact that the time source used must be traceable to a UTC(k) laboratory recognized by BIPM (Bureau International des Poids et Mesures) with an accuracy of 1 s or better. Furthermore, the key generation process must take place in physically secured environments (i.e., HSMs) by trusted personnel under dual control, with the cryptographic devices used meeting either EAL 4 or higher in accordance with ISO/IEC 15408 [10] or meeting the level 3 requirements identified in FIPS PUB 140-2 [11] and FIPS PUB 140-3 [12].

From a technical point of view, the EN 319 422 [13] mandates the token structure requirements. Besides requiring an RFC 3161 [2]- and RFC 5816 [6]-compliant token format, it enforces the presence of the accuracy field in the token, either the ESSCertID or ESSCertIDv2 certificate identifier and at least SHA-256 for hashing.

The standards and regulations discussed above and summarized in the Table 1 establish the technical and operational foundation for qualified timestamping services within the European Union. RFC 3161 and RFC 5816 define the protocol-level requirements that ensure interoperability across different implementations, while ETSI standards (EN 319 421, EN 319 422, and EN 319 401) specify the additional security, operational, and governance requirements necessary for a TSA to achieve qualified status under eIDAS. Together, these frameworks create a comprehensive regulatory environment that balances technical rigor with legal recognition. Having established the standardization landscape, we now examine how these requirements are implemented in practice by European Trust Service Providers and how blockchain technology is being integrated into commercial timestamping offerings.

Table 1. Timestamping standards and their purpose.

Standard	Purpose
RFC 3161 [2]	Core standard for timestamping protocol
RFC 5816 [6]	Algorithm agility
EN 319 421 [8]	How TSA operates (policies and procedures)
EN 319 422 [13]	What timestamp tokens must contain
EN 319 401 [9]	General TSP requirements

2.2. Enterprise Landscape

The European Union maintains a public list of active Trust Service Providers through the European Union Trusted List (EUTL). These providers are divided into two categories: qualified and non-qualified. Qualified Trust Service Providers are entities authorized to provide high-security digital trust services under eIDAS regulation and are regularly audited by national supervisory bodies to verify their compliance with ETSI standards. One such service offered by QTSPs is a qualified timestamping service.

The qualified timestamp service is audited and certified for compliance to ETSI standards EN 319 401 [9], EN 319 421 [8], and EN 319 422 [13]. In case of a legal dispute, a qualified electronic timestamp can be used as a legitimate source of information as it possesses the quality of accurately indicating the date and time at which the timestamp was created for its respective data.

As blockchain started to become a relevant solution for businesses to market and offer distributed trust solutions, various European companies integrated blockchain anchoring in their timestamping services. These alternatives provide tamper-proof evidence and enhanced data integrity by recording timestamp-relevant information on a distributed ledger.

The blockchain capabilities are used in several key ways for augmenting the timestamping process. The most common approach involves hash anchoring, which simply creates a hash of the document or data, records the hash in a blockchain transaction, and uses the ledger as a proof of existence for that hash at a specific time. One such solution is WordProof (The Netherlands), which provides blockchain timestamping for web content. It works by generating a hash for each piece of published content and stores the result on a blockchain. This way, the original publication time can be easily proven. Another way of leveraging the blockchain is the use of the OpenTimestamps Protocol. This is a specific protocol for anchoring timestamps in a Bitcoin network. It creates a Merkle tree of multiple document hashes and anchors only the root hash in a Bitcoin transaction. One company using this method is Intesi Group (Italy). The Intesi Group approach is fully compliant with RFC 3161. The company also authored an IETF draft specification (draft-intesigroup-dlts) (https://datatracker.ietf.org/doc/html/draft-intesigroup-dlts-00, accessed on 20 September 2025) defining how to extend a timestamp token to support blockchain anchoring. It is important to mention that the IETF draft describes a backward-compatible extension to RFC 3161, not a replacement. Precisely, a traditional timestamp is issued and then the blockchain transaction hash and proof are added to the timestamp token as a non-critical extension. The Guardtime approach, unlike most solutions using public blockchains, operates a proprietary KSI (Keyless Signature Infrastructure) blockchain first developed in 2008 for the Estonian Government. The keyless signature approach relies on hash functions rather than cryptographic keys, making it quantum-immune. The newest version does not use the RFC 3161 timestamp format, as the data structures involved are more complicated and public key cryptography is not used to directly sign timestamps (https://m.guardtime.com/files/gt-ksi-tsa-gtsp3-v2.0-1.pdf, accessed on 20 September 2025). ANF AC operates as a QTSP across 28 EU member states. The company provides RFC 3161-compliant timestamping with proprietary blockchain infrastructure. According to ANF AC, the company operates an international infrastructure of servers functioning as Timestamp Units (TSUs), where each TSU manages a list of hash chains. The approach is similar to Intesi Group, in the sense that it is hybrid, using a classic RFC 3161-compliant solution with blockchain used to augment the timestamping process.

The enterprise implementations examined above, as summarized in the Table 2, diverse approaches to integrating blockchain technology with timestamping services. While some providers, such as WordProof and Guardtime, have developed proprietary solutions that prioritize innovation over standards compliance, others like Intesi Group and ANF AC have pursued hybrid models that maintain RFC 3161 compatibility while adding blockchain anchoring as a supplementary security layer. These commercial deployments reveal a market trend toward leveraging blockchain’s immutability and transparency properties without completely abandoning established PKIs. However, the technical details of these implementations remain largely proprietary, and their approaches to balancing regulatory compliance with blockchain integration vary significantly. To gain deeper insight into the architectural patterns, security models, and technical trade-offs involved in blockchain-based timestamping, we now turn to the academic research literature, which provides more detailed analysis and empirical evaluation of various design approaches.

Table 2. Blockchain-based timestamping solutions.

Company	Blockchain Leveraging	RFC 3161 Compliant	eIDAS Compliant
WordProof	Hash anchoring	No	No
Guardtime	Proprietary KSI blockchain	No	No
Intesi Group	Bitcoin via OpenTimestamps	Yes	Yes
ANF AC	Proprietary blockchain	Yes	Yes

2.3. Relevant Research Literature

One of the earliest and most influential approaches to using blockchain technology for trusted timestamping is presented by Gipp, Meuschke, and Gernandt in “Decentralized Trusted Timestamping using the Cryptocurrency Bitcoin” [14]. The authors propose a decentralized mechanism, called OriginStamp, which leverages the Bitcoin [15] blockchain to store timestamping data in a tamper-proof and anonymous manner. In this system, a user can upload a digital document or directly submit its cryptographic hash. All client-side processing, like the generation of the document’s SHA-based hash, is performed locally, ensuring that sensitive data never leaves the user’s environment. On the server side, OriginStamp collects multiple hashes over a defined period, typically 24 h. Once a predefined threshold of submissions is reached, the hashes are concatenated and combined into a single aggregated hash. This aggregated hash is then converted into a valid Bitcoin address, to which the system transfers the smallest possible transaction amount. The resulting transaction is broadcast to the Bitcoin network and permanently stored within a block.

This approach significantly reduces transaction fees by grouping multiple user requests into a single blockchain transaction. However, for users requiring immediate confirmation, the system also allows for instant publication of individual hashes on the blockchain, at an additional cost. From an architectural standpoint, the method relies on the structure of the balanced Merkle tree, where transactions form the leaf nodes ensuring cryptographic integrity and immutability of the stored data. Overall, OriginStamp [14] represents a practical blockchain-based alternative to conventional RFC 3161 [2]. It demonstrates how public blockchains can be integrated as a globally verifiable, tamper-resistant time ledger without relying on centralized trust models. Nevertheless, the proposed approach also faces several limitations concerning its scalability, adaptability to existing enterprise workflows, and potential for global adoption.

Another blockchain-based timestamping approach is introduced by the paper [16], which proposes a scheme that utilizes the immutability of blockchain ledgers to generate secure and verifiable timestamps. The approach aims to prevent both the back-dating and the forward-dating of digital files, ensuring the integrity and chronological authenticity of stored data. In traditional blockchain timestamping methods, the block’s embedded timestamp is typically used to determine when data was recorded. However, such timestamps are subject to inaccuracies caused by network delays. Chronos [16] addresses this issue by designing a scheme that provides highly accurate and verifiable timestamps independent of these block-level inconsistencies. The proposed architecture consists of three core entities: the User, the Chronos Log Server, and an Authenticated Auditor. The User generates a digital file along with its corresponding cryptographic signature and then sends the pair to the Log Server. The Log Server integrates the received data into a Bitcoin transaction, effectively anchoring it into the blockchain. Once the transaction is confirmed and recorded, Chronos derives the file’s timestamp not directly from the block’s timestamp field but from the block height—a unique and sequential property of each block within the chain. Specifically, the system defines a time interval representing the moment when a file was created:

• The time at which the previous block was appended to the blockchain indicates the earliest possible creation time of the file;
• The time when the block containing the transaction is confirmed represents the latest possible creation time.

In summary, Chronos enhances conventional blockchain timestamping by addressing the problem of unreliable block timestamps and introducing a verifiable mechanism that guarantees precise temporal proofs. Building upon the foundations of the initial approach [16], an improved system, referred to as Chronos+ [17], was later introduced, aiming to improve efficiency and scalability in blockchain-based timestamping. This new design introduces a batch timestamping mechanism, allowing multiple user requests to be processed collectively rather than individually, thereby optimizing system throughput. The research further analyzes the temporal dynamics of data operations in cloud infrastructures and introduces the Window of Timestamping (WoT) as a performance indicator. This metric captures the elapsed time between the user’s initial request and the blockchain’s confirmation of the timestamp. Chronos+ [17] focuses on minimizing this window to achieve a more responsive and dependable timestamping process. The proposed framework establishes a secure and efficient mechanism for timestamp generation by leveraging the Ethereum blockchain network. It integrates symmetric encryption techniques alongside the concept of the WoT to ensure both the confidentiality of stored data and the precision of the recorded timestamps.

A different approach was introduced in this article [18], which proposes a timestamping model built directly on the Ethereum blockchain. The system is based on a decentralized mechanism that combines smart contracts with multiple independent time sources, rather than relying solely on the inherent block timestamps. Within this framework, users can request a timestamp by sending a transaction containing the data to a dedicated smart contract. Subsequently, a set of volunteer nodes submit their own timestamps, representing the exact moment when they detect that transaction. The contract then discards inconsistent reports and computes the most accurate timestamp by selecting the earliest consistent value among all submissions. This collaborative validation process enhances both accuracy and trust decentralization, as it mitigates the dependency on any single source of timestamping. Therefore, the closer the selected timestamp is to the actual time of the user’s request, the higher the precision and reliability of the generated timestamp. The process starts when a user sends a blockchain transaction to the smart contract containing the data that needs to be timestamped and a small fee to reward miners and providers. When the transaction appears on the network, several providers record the exact time they first see it and send this information back to the smart contract. The contract compares all received timestamps, selects the most accurate one, stores it permanently on the blockchain together with the data, and then shares the fees among the participating providers.

Several studies have highlighted that blockchain-based timestamping can achieve a purpose similar to that of TSA-issued timestamps, namely, providing evidence that data existed at a given point in time, while eliminating the need to trust a single centralized authority [19]. Blockchains offer key advantages for this application: the distributed consensus mechanism ensures that the ledger is resistant to tampering and widely verifiable. However, relying solely on blockchain for timestamping presents certain limitations compared to qualified timestamps. One notable concern is the precision and trustworthiness of the timestamp itself. The granularity of block times, for example, Bitcoin’s 10 min interval, may be insufficient for applications that require highly precise temporal resolution [19]. In contrast, a qualified TSA can anchor its timestamps to an official time source, providing accuracy at the level of seconds or better, along with a verifiable cryptographic audit trail of the time source, as mandated by relevant standards. Another limitation of blockchain-only approaches relates to legal recognition: at present, a hash recorded on a public blockchain does not automatically carry the same legal status as a qualified timestamp token. This shortcoming has motivated research into hybrid solutions that combine blockchain anchoring with qualified timestamping, aiming to leverage the strengths of both approaches [19].

Recent studies illustrate the potential of blockchain-based timestamping as an alternative to traditional TSAs. The work [20] presents a system for healthcare emergency events, where critical timestamps (e.g., ambulance dispatch; treatment times) are hashed and recorded on an Ethereum-compatible blockchain via smart contracts, removing reliance on a central authority. While no qualified TSA is used, the approach ensures immutable, transparent event records at low cost. The authors demonstrate that their approach maintains an auditable and tamper-resistant record of event times at relatively low cost, suggesting it could serve as an alternative to traditional trusted timestamp servers in similar operational contexts [20]. Nevertheless, for applications and services requiring legal admissibility, integration with qualified trust services, such as a qualified TSA, remains necessary.

Recent bibliometric [21] analyses acknowledge the increasing role of blockchain as a mechanism for ensuring data integrity in security-critical systems. The authors provide a large-scale survey of cryptographic techniques used to secure AI (Artificial Intelligence) systems and highlight that blockchain is frequently employed to guarantee tamper-resistant storage and transparent auditability in distributed environments. However, their study remains focused on trends in AI security and does not address digital services offered by TSPs. Across contemporary research efforts, the literature review [22] offers a comprehensive analysis of publications on electronic voting security, highlighting trends in modern cryptography and the emerging use of blockchain for transparency and auditability. Their work identifies the cryptography primitives, thread models, and security trends shaping modern e-voting research. One of their main findings is the increasing reliance on blockchain and distributed ledger technologies as trust anchors, based on their transparency, immutability, and resistance to single point of failure attacks. The review highlights that blockchain has become a recurring component in security-sensitive systems, particularly where auditability and tamper-evidence are required.

The work presented in the paper [23] proposes a blockchain-based timestamping framework for tracking AI model lifecycle events, highlighting the need for immutable and independently verifiable evidence. The system anchors cryptographic commitments of training, validation, and deployment artifacts on a blockchain network, eliminating the need for centralized component. The study provides strong motivation for blockchain adoption in security-sensitive audit environments and acknowledges the historic foundation of trusted timestamping defined in RFC 3161 [2]. The article provides a valuable conceptual perspective on how blockchain-based anchoring can enhance trust in digital processes. In comparison, our work extends this direction of research by providing an implementation-ready, RFC 3161-compliant timestamping architecture together with practical experiments across multiple blockchain networks.

A recent contribution [24] provides a legally oriented examination of blockchain-based timestamping, focusing on its applicability to digital evidence submission in judicial environments. The study combines a literature review, a statistical analysis, and simulation experiments on Ethereum and Hyperledger Fabric blockchain networks. The results highlight blockchain’s value in strengthening evidence authenticity, reducing reliance on centralized authorities. The paper positions blockchains as an auxiliary trust mechanism but also notes some adoption barriers such as regulatory uncertainty and the need for harmonized legal frameworks. Although the article offers an insightful legal analysis of blockchain-based timestamping, it remains largely conceptual and simulation-oriented. Our work complements this perspective by providing a fully specified architecture, concrete implementation, and reproducible experiments across Ethereum and Hyperledger Fabric networks. By detailing concrete components and processing flows, we provide a practical foundation for evaluating real-world performance and integration feasibility. This practical evaluation extends prior approaches b y demonstrating how blockchain anchoring can be integrated into a functioning timestamping service.

In summary, current studies indicate that combining blockchain technology with qualified timestamp authorities proposes an effective approach to improve both the trustworthiness and legal validity of timestamps. Blockchain ensures records are decentralized, tamper-proof, and long-lasting, while traditional TSAs provide accurate timekeeping and legal recognition. Recent research has investigated ways to leverage these complementary advantages together.

The research literature reviewed above and summarized in the Table 3 presents a comprehensive view of blockchain-based timestamping approaches, ranging from purely decentralized systems like OriginStamp to hybrid models that attempt to balance blockchain immutability with traditional time source accuracy. While these academic contributions have advanced our understanding of distributed timestamping mechanisms, they collectively highlight a persistent tension between innovation and standardization. Solutions that prioritize decentralization and cost efficiency often sacrifice RFC 3161 compliance and legal recognition, while approaches that maintain compatibility with existing standards typically do not fully leverage blockchain’s transparency and auditability properties. Furthermore, most research implementations focus on proof-of-concept demonstrations rather than production-ready systems that address the operational, security, and governance requirements necessary for deployment in regulated environments. This analysis of both academic research and commercial implementations reveals specific gaps and opportunities that our proposed architecture aims to address.

Table 3. Summary of blockchain-based timestamping solutions.

Ref.	Blockchain	RFC 3161 and Actual PKI Compliance	Key Contribution
[14]	Bitcoin	No	Aggregated hash transactions
[16]	Ethereum	No	Log server recording hashes, timestamp derived from block height
[17]	Ethereum	No	Log server with batch processing, Window of Timestamping metric
[18]	Ethereum	Partial	Smart contract with multiple time sources, earliest timestamp selected
[20]	Ethereum	No	Smart contract records hashes of events from distributed healthcare system, ensuring immutable logs of event times

2.4. Gaps and Opportunities

Some of the blockchain-based timestamping approaches analyzed in the previous section, [14,16,17,18,20], share several limitations, with the following two considered particularly notable:

• Absence of a trusted TSA: None of the systems rely on a traditional Time-Stamping Authority (TSA) to sign the timestamps. Therefore, the trustworthiness of the timestamp depends solely on the blockchain component. This introduces issues regarding the reliability and verifiability of the timestamp and also reduces interoperability with existing trusted timestamping infrastructures and public key infrastructures (PKIs);
• Non-compliance with RFC 3161: All four solutions do not fully adhere to established timestamping standards, which could reduce compatibility with systems expecting RFC-compliant timestamps.

When analyzing the limitations specific to each solution, further distinctions emerge. In the case of OriginStamp [14], while batching requests reduces transaction costs, it also introduces significant delays in recording individual hashes unless users pay additional fees. Also, the timestamp accuracy is limited by Bitcoin’s block interval (approximately 10 min) and the batching mechanism (typically 24 h aggregation). While the system records the time per transaction, it does not provide a precise timestamp for each individual hash, making it unclear exactly when a specific hash was received and processed on the server side. The blockchain relies on a Proof-of-Work consensus, where a new transaction block is added only after a node successfully solves a complex cryptographic puzzle. This process introduces unpredictable delays in timestamping, as the exact confirmation time depends on how long it takes to validate and append the block. Additionally, if an immediate timestamp is required, such as for financial transactions, this delay can pose a significant challenge. Additionally, maintaining security against 51% attacks where an attacker controls the majority of validation nodes requires a large and widely distributed network of active nodes.

Regarding the proposed scheme in the Cronos [16] article, this can pose a security concern in certain scenarios, as the exact creation time is not unique. Ideally, a single, precise timestamp should be used. Chronos++ [17] improves upon the original by supporting batch timestamping and optimizing the Window of Timestamping (WoT). However, there still exists a delay between a user’s request and the final blockchain confirmation. Related to the proposed solution in the paper [18], timestamp accuracy depends on how quickly volunteers report the transaction time. Insufficient participation or reporting delays can reduce precision. Moreover, coordinating multiple time sources increases system complexity and may present potential vulnerabilities if selection strategies are not robust.

Despite the limitation highlighted above, all the analyzed solutions have introduced significant improvements in the field of blockchain-based timestamping and have highlighted clear research directions. Each of the proposals contributed innovative mechanisms for securing timestamps, optimizing processing, and addressing decentralization challenges. However, there remain opportunities for further enhancement, which this work aims to address:

• Implement a blockchain-based timestamping solution that is fully compliant with existing cryptographic standards and RFCs, such as RFC 3161 [2] and RFC 5816 [6];
• Integrate a trusted TSA (Time-Stamping Authority) to sign the timestamps, providing interoperability with current PKI-based systems;
• Ensure that timestamps are universally verifiable and can be more broadly adopted;
• Bridge the gap between decentralized blockchain-based timestamping and traditional trusted timestamping infrastructures.

3. Threat Model

This section emphasizes the adversarial model we considered when designing the presented solution. Besides the adversarial model, we also clearly specify the attacks that are out of scope for our implementation.

3.1. Assumptions and Adversary Model

We consider a realistic adversary model for timestamping infrastructures extended with blockchain anchoring. The adversary is assumed to have full control over the communication channels (Dolev–Yao model), including the ability to delay, replay, or drop messages. However, cryptographic primitives such as digital signatures and collision-resistant hash functions are assumed secure.

Clients interact with the Time-Stamping Authority (TSA) via the standard RFC 3161 protocol, typically over HTTPS. Since the timestamping request includes only a digest of the original data and the TSA response is digitally signed, the confidentiality of the transmitted messages is not critical to security. The attacker cannot forge valid tokens or tamper with timestamps post issuance.

The TSA is assumed to follow the specification correctly but is considered honest-but-curious. It may collect metadata about usage or collude with external parties. Moreover, we consider post-compromise scenarios in which the TSA becomes unavailable or untrustworthy, and verifiers must rely on external anchoring evidence to validate a token’s issuance and order.

3.2. Threats in Centralized TSA Models

Traditional TSA deployments are exposed to several risks due to their centralized architecture:

• Single point of failure: A compromised or unreachable TSA renders verification impossible.
• Undetectable misbehavior: The TSA may backdate tokens or issue conflicting records without detection.
• Absence of auditability: No external ledger records exist to provide proof of issuance or sequencing, limiting long-term verifiability.

These threats motivate the adoption of a distributed anchoring layer to create tamper-evident logs of timestamp issuance.

3.3. Threats Introduced by Blockchain Anchoring

Blockchain anchoring significantly enhances transparency and resilience compared to traditional TSAs. However, this augmentation introduces its own class of threats, specific to distributed and decentralized infrastructures [16]. We organize these threats based on the architectural components of our system, followed by a STRIDE analysis.

Blockchain Finality and Reorganization. Public blockchains such as Ethereum may experience temporary forks or reorganization, leading to delayed or inconsistent anchoring confirmations. This may affect short-term verifiability of timestamp issuance. To address this, we enforce a minimum number of confirmations (e.g., $N=12$ on Ethereum) before considering a timestamp anchor as final.

Smart Contract Vulnerabilities. Smart contracts may contain bugs or flawed logic, especially if developed without formal verification. Although our anchoring logic is intentionally minimal, the risk of exploitation exists. Regular auditing and adherence to best practices can mitigate this vector.

Consensus-Level Attacks. Blockchains rely on consensus protocols to validate and order transactions. Public blockchains are exposed to 51% attacks, while permissioned blockchains may face validator collusion. These threats are mitigated via blockchain selection policies and redundancy (e.g., anchoring on multiple chains).

Validator Censorship and Anchoring Delays. In permissioned networks like Hyperledger Fabric, malicious or dominant validators might censor anchoring transactions. Distributed governance and endorsement policies requiring multi-party agreement help reduce this threat.

Side-Channel and Metadata Risks. While our system hashes only the token and avoids sensitive data anchoring, metadata leakage via timing, access patterns, or SN format could be exploited. Techniques like salting or commitment schemes can further harden the design.

To systematically analyze these risks, we adopt the STRIDE framework [25], commonly used in threat modeling, to classify threats by component. Table 4 summarizes our analysis. The STRIDE framework accounts for six different threat types:

Table 4. STRIDE threat analysis for blockchain-anchored TSA components.

Component	Threat	Description	Mitigation
Blockchain Network (Ethereum, Fabric)	S	Fork-based anchor reordering	Accept anchors after N confirmations
	T	Submission timing exposed on-chain	Salted hashes before anchoring
	R	Validator collusion or reordering	Anchor to multiple independent ledgers
	I	Transaction censorship or pattern leakage	Use Fabric endorsement and batching
	D	Anchoring delays or mempool congestion	Retry logic with failover ledger
	E	Use of untrusted consensus nodes	Select governed and audited blockchains
Smart Contracts	T	Field injection/storage misuse	Minimize input fields and metadata
	R	Inconsistent anchor formats	Enforce SN schema and structure
	E	Logic flaws or upgrade abuse	Use static analysis and audits
Token Generation	S	Forged serial number (SN)	Bind SN to token digest, hash signed
	R	SN reuse or malformed fields	Enforce format and uniqueness
Verification Logic	S	Replay with old valid SN	Require globally unique SNs
	E	Parser crash on malformed SN	Bounds checking and hardening

• Spoofing.
• Tampering.
• Repudiation.
• Information Disclosure.
• Denial of Service.
• Elevation of Privilege.

3.4. Out-of-Scope Attacks

We do not address attacks that compromise the underlying cryptographic primitives (e.g., hash collisions; signature forgery), nor the broader PKI trust infrastructure (e.g., certificate authority compromise). Client-side misuse of keys or request tampering is also considered out of scope.

4. Proposed Architecture (Standards-Preserving)

In light of the gaps and limitations identified in existing blockchain-based timestamping schemes, this section introduces our proposed standards-preserving architecture that integrates blockchain technologies (Ethereum [26]; Hyperledger Fabric [27]) with the traditional PKI model. The proposed approach aims to maintain full compliance with existing timestamping standards and RFCs, such as RFC 3161 [2] and RFC 5816 [6], while leveraging the immutability, transparency, and decentralization offered by blockchain networks. By embedding the TSA component within a blockchain-anchored environment, the system ensures both interoperability with existing trusted infrastructures and enhanced verifiability through on-chain evidence. In this model, the TSA continues to issue and sign timestamp tokens in compliance with current standards, while the resulting timestamp data is securely anchored on a blockchain ledger.

This combined approach leverages two complementary mechanisms, a trusted Time-Stamping Authority (TSA), providing cryptographic signatures with legal recognition, and a blockchain record secured by decentralized consensus, providing a redundant proof: even if the TSA’s signature becomes invalid over time, the blockchain entry continues to demonstrate that the data existed at the specified moment. The following subsections describe the design goals proposed, the architecture diagram and its core components, and the interaction flows.

4.1. Design Goals

The design of our proposed solution is guided by several fundamental goals intended to ensure interoperability, reliability, and compliance with established trust models:

• RFC 3161 [2] and RFC 5816 [6] compliance: The system is fully compatible with existing timestamping RFCs, ensuring that timestamps are interoperable with current PKIs. This allows for broad adoption and integration with legacy systems and guarantees that timestamped documents are legally recognized.
• Trusted timestamp generation: TSA signs each timestamp request, providing authenticity and non-repudiation. This addresses trust concerns inherent in purely decentralized systems while maintaining the benefits of blockchain immutability.
• Blockchain anchoring (Ethereum [26] and Hyperledger [27]): Ethereum is leveraged for its smart contract functionality, enabling automation of operations and verification processes, by using smart contracts. Hyperledger Fabric is used as a permissioned blockchain, suitable for enterprise environments where controlled access and governance are required. The blockchain stores only the hash of the timestamp token response and a unique identifier for each timestamp, protecting sensitive data while ensuring integrity and auditability.
• Interoperability: The architecture maintains standard data formats and validation methods to integrate seamlessly with existing TSA clients and PKI systems.
• Efficient processing: Timestamp issuance is optimized to reduce delays, using asynchronous interactions with the blockchain environments.
• Cost efficiency: By storing only hashes and identifiers on the blockchain, the system reduces transaction fees while maintaining security and immutability.
• Transparency and auditability: All timestamping events can be independently verified on the blockchain, ensuring accountability and public verifiability.
• Data privacy: Only timestamp token hashes and unique identifiers are stored on the blockchain, preventing any exposure of the actual data content.

4.2. High-Level Architecture

Figure 1 illustrates the overall architecture of the proposed blockchain-based timestamping system.

Figure 1. High-level architecture of the proposed blockchain-anchored timestamping system. The architecture shows the interaction between the client, the TSA server, and the blockchain anchoring module. The client submits a hash of the document to the TSA, which generates a timestamp token according to RFC 3161. A unique serial number (SN) associated with the token is also anchored in a blockchain (Ethereum or Hyperledger). This architecture preserves the standard TSA workflow while adding verifiable anchoring in a distributed ledger.

The architecture consists of several interconnected components that collectively manage the full lifecycle of a timestamp, from generation and signing the timestamp request to blockchain registration and later verification.

In the following, each component of the proposed architecture is described, highlighting its role and interaction within the overall timestamping issuance and verification processes:

• Apply Timestamp Client: This is the client-side component responsible for initiating the timestamping process. It allows the user to upload the document that requires a trusted timestamp, or can directly upload the document’s hash. Before any data leaves the client’s environment, a SHA-256 hash [7,28] of the document is computed locally. Only this hash value is transmitted to the server, ensuring that no sensitive information or document content is exposed. This design enhances both privacy and data security, as the original document never leaves the user’s control.
• Issue Timestamp Handler: This is the server-side component responsible for receiving the hash generated by the client and embedding it into a timestamp request compliant with the RFC 3161 [2]. The formatted request is then sent to the TSA for the actual issuance of the timestamp. While the request format remains fully compliant with the RFC 3161, ensuring interoperability with existing TSA-based systems, the TSA module in the proposed architecture has been extended to include an additional mechanism that records timestamp data on the blockchain, enabling verifiable, tamper-resistant storage without altering the standardized request and response structure.
• Time-Stamping Authority (TSA): The TSA receives the client’s hash, verifies the request, and records the exact current time. It then generates a TimeStampToken object containing the hash, timestamp, serial number, and metadata, and signs it with its private key, ensuring the timestamp is secure, tamper-proof, and verifiable. The TimeStampToken defined in RFC 3161 [2] is encapsulated as a CMS SignedData structure RFC 5652 [3], ensuring integrity and authenticity of the timestamp information. Beyond the basic TSA functionality, our implementation extends its capabilities with modules that manage interactions with blockchain networks, including Ethereum and Hyperledger Fabric. All blockchain-related operations are performed asynchronously, while the Issue Timestamp Handler immediately receives the timestamp token as soon as it is computed and generated. The only change we introduced on the TSA response token side ensures that it remains fully compliant with the standard; no additional fields or changes were made that could break conformity. Our contribution lies in a different method of generating the serial number (SN) on the TSA side, which facilitates verification on the blockchain. Depending on the target blockchain network for storing the timestamp token hash, the first four bytes of the SN are used to identify the network type. For example, for the Ethereum network, the first 4 bytes of the 20-byte SN are set to ETH:
• Ethereum and Hyperledger Fabric Modules: These modules are integrated within the TSA to manage operations and communication with the Ethereum and Hyperledger Fabric network, respectively. Based on the RFC 3161 timestamp token generated by the core TSA component, these modules compute a hash over the entire response token, which is then stored on the blockchain. These operations are executed through smart contracts developed in Solidity, which provides the necessary functionality to record a new pair of SNs (16 bytes):Hash(timestamp token) on the specific blockchain network. We use the last 16 bytes from the total 20 bytes of the SN, excluding the first 4 bytes which represent the blockchain network type. This dual-network approach enables flexibility and adaptability to different use cases.
• Ethereum Blockchain: We utilize Ethereum as a public blockchain due to its widespread adoption and support for smart contracts. This allows the system to efficiently manage the storage of timestamp hashes and their verification, with configurable transaction fees for each operation.
• Hyperledger Fabric Blockchain: We utilize Hyperledger Fabric because it is a permissioned blockchain, providing controlled access and governance. This makes it suitable for scenarios where privacy and restricted participation are required while still ensuring secure storage and verification of timestamps.
• Verify Timestamp Client: This client-side component is responsible for validating a timestamp. It receives an RFC 3161-compliant timestamp response token from the user and extracts the associated SN. The extracted serial number is then forwarded to the Verify Timestamp Handler for finding and receiving the timestamp token hash for further validation.
• Verify Timestamp Handler: This component receives an SN and determines the blockchain network used for the timestamp integration based on the first 4 bytes of the SN. Using the functions provided by the smart contract deployed on the respective blockchain network, it searches for the hash of the timestamp response token associated with that SN. The retrieved hash is then returned to the calling application.
• Actors (User; Verifier): These represent the client-side applications or end-users who interact with the system. The User initiates the process by requesting a timestamp for a document to be securely recorded on the blockchain, while the Verifier requests the validation of the timestamp of an existing document to ensure its authenticity and integrity. ETH:.

4.3. Detailed Timestamp Workflow

Figure 2 illustrates the sequence diagram for the process of generating a timestamp token and recording it on the blockchain. The diagram highlights the interactions between the client, TSA, and blockchain modules, showing the flow of data and operations step by step.

Figure 2. Sequence diagram of the timestamp generation process. This figure outlines the protocol steps from the initial hash submission by the client to the issuance of the timestamp token and the corresponding blockchain anchoring transaction. Each step shows which party is responsible for generating or transmitting a specific artifact (e.g., token, serial number, and transaction). The anchoring occurs asynchronously, allowing the client to receive the signed timestamp without waiting for the on-chain confirmation.

• Step 1. Send_document: The user uploads the document to the client timestamping application, which resides within the client-side infrastructure. Also, the user has the possibility to directly upload the document’s SHA256 hash.
• Step 2. Compute_hash–Step 3. Send_hash: During these steps, a SHA-256 hash is computed over the original document only if the client uploads the full file; otherwise, a precomputed hash can be used directly. The resulting hash is then sent to the Issue Timestamp Handler component for further processing and timestamping.
• Step 4. Send_RFC3161_request: In this step, the timestamp request is created based on the hash received from the client, fully conforming to RFC 3161. In addition to the client-provided hash, the request also includes other necessary details, such as the protocol version and the hash algorithm used.
• Step 5. Generate_token: In this step, the timestamp response token is generated in full compliance with RFC 3161 [2] and the CMS SignedData structure defined in RFC 5652 [3]. The generation process involves several sub-steps, one of the most important being the creation of a serial number (SN), which will later be embedded in the response. The SN is 20 bytes long by default. To facilitate later storage and verification on the blockchain, the first 4 bytes are used to identify the target blockchain network. The remaining 16 bytes are sufficient to uniquely identify the timestamp token. The first 4 bytes encode the blockchain network acronym: for Ethereum, ETH: is used, and for Hyperledger Fabric, HYF:. Depending on the specified network, the timestamp token will be recorded on the corresponding blockchain via the smart contract functions developed for that network.
  Once the SN is configured, the timestamp data is signed using the TSA’s private key. The signature covers all data required by RFC 3161, including the version, hash algorithm, message imprint, and generated SN. This ensures the authenticity and integrity of the timestamp token. The generated timestamp token is immediately returned to the client, while the recording of the token hash on the blockchain occurs asynchronously through the smart contract functions. This allows the system to provide the client with the generated timestamp token without waiting for the blockchain transaction to complete, ensuring both compliance and efficiency.
• Step 6. Asyn_Save_SN_hash: For the communication with the blockchain, we developed dedicated modules for each network type (Ethereum Module and Hyperledger Fabric Module). These modules are integrated within the TSA, and they expose asynchronous methods to connect, interact with, and invoke the corresponding smart contracts on the respective blockchain network. Depending on the network type specified, the TSA calls the appropriate module. While the connection mechanism differs per blockchain, the steps for recording the timestamp token remain the same:

  –

  Receives the timestamp token generated and signed, and the SN, from the TSA;

  –

  Identifies the blockchain network for integration;

  –

  Extracts the last 16 bytes of the SN, which are used as a unique identifier for storage on the blockchain. The first 4 bytes always encode the network type and remain fixed;

  –

  Applies a SHA256 hash over the entire generated timestamp token;

  –

  Connects to the corresponding blockchain network according to the network type;

  –

  Calls the save function provided by the deployed smart contract to store the data as key–value pairs of the form SN (16 bytes):Hash (timestamp token). This ensures that each token hash is uniquely identifiable via the 16-byte portion of its SN, making subsequent retrieval and verification easier. For Ethereum, this write operation incurs a gas fee, which introduces certain costs; these will be discussed in more detail in subsequent sections.

• Step 7. Return_transaction_confirmation: In this step, the TSA’s blockchain communication module asynchronously waits for confirmation that the pair SN (16 bytes):Hash (timestamp token) has been successfully stored on the network. Based on the status of the received response, relevant information is logged within the TSA, allowing us to track when the complete storage process on the blockchain has finished. Because the storage operation is not instantaneous, all interactions with the blockchain are handled asynchronously. This approach prevents significant delays in the response time returned to the client.
• Steps (8–10). Return_RFC3161_token: These steps involve returning the generated timestamp token back to the client, passing successively through each integrated module. At the end of this process, the client receives the fully generated token, containing all the necessary information for subsequent validation. An important point to emphasize is that the returned timestamp token is fully compliant with the above highlighted RFCs, maintaining compatibility with tokens issued by TSAs in existing PKIs.

4.4. Detailed Verification Workflow

Figure 3 illustrates the sequence diagram for the process of validation of a timestamp token. The diagram highlights the interactions between the client application, the verify timestamp handler, and the blockchain network:

Figure 3. Sequence diagram for timestamp validation and blockchain consistency check. This figure shows the detailed interaction between the client, verifier, TSA certificate, and blockchain node during the validation phase. It begins with the client presenting a timestamp token, followed by standard RFC 3161 validation steps such as signature verification and certificate checking. The diagram extends this logic by introducing a blockchain query to verify that the serial number (SN) from the token was previously anchored. This step ensures that the timestamp is both authentic and immutably recorded.

• Step 1. Send_timestamp_token: The user uploads the generated timestamp token to the validation application, Verify Timestamp Client, which runs within the client-side infrastructure.
• Step 2. Extract_Parse_SN: Upon receiving the timestamp token, the client-side validation application parses it, knowing that it follows the standard RFC 3161 format. During parsing, the SN is extracted. The first 4 bytes indicate the blockchain network where the token’s hash was stored, while the remaining 16 bytes serve as a unique identifier to locate the corresponding hash within that network.
• Step 3. Send_SN_BlockchainType: In this step, the last 16 bytes from the SN and the type of blockchain network where the token’s data was stored are forwarded to the Verify Timestamp Handler for further processing.
• Step 4. Find_hash_by_SN: In this step, the Verify Timestamp Handler communicates with the corresponding blockchain network to locate and retrieve the hash associated with the timestamp token. Upon receiving the relevant information from the validation client, the Verify Timestamp Handler invokes the appropriate methods provided by the smart contract deployed on the respective blockchain network.
  Both on the Ethereum network and on Hyperledger Fabric, the deployed smart contracts offer query methods that allow for searching using the unique identifier extracted from the last 16 bytes of the SN. This identifier corresponds to the stored hash of the timestamp token. The operation is performed synchronously, since reading data from the blockchain is much faster than writing it. The retrieval involves only a query that incurs no gas fees. Once the mapping between the 16-byte identifier and the token hash is accessed, the corresponding hash is returned to the client. If no match is found, a specific error message is provided.
• Step (5–6) Return_timestamp_hash: These steps involve returning the extracted hash of the validated timestamp token back to the client validation application, passing successively through each integrated module.
• Step 7. Validate_timestamp_token: At this step, the timestamp token is validated using all relevant information: the timestamp token itself and the timestamp token hash retrieved from the blockchain. The validation process involves the following steps:

  –

  Compute the SHA256 hash of the timestamp token received from the client;

  –

  Compare the computed hash with the hash retrieved from the blockchain;

  –

  If the two hashes match, it confirms that the timestamp token has not been altered or tampered with since it was issued and signed by the TSA. This ensures that the timestamp within the token accurately reflects the valid state of the document at that given time. The fact that the token hash was stored on the blockchain during the generation of the timestamp token provides a high level of security and authenticity, as the immutability and distributed nature of the blockchain prevent unauthorized modifications;

  –

  If the hashes do not match, the timestamp token is considered invalid, indicating that it has been altered since issuance.

• Step 8. Return_vlidation_status: At this stage, the validation result of the timestamp token is sent back to the user, indicating whether the token is valid or invalid.

4.5. Implementation Details

In this section, we describe the practical implementation of the proposed system, focusing on the technologies, programming languages, and frameworks used for the development of each component. The implementation process covers the development of the TSA component and its integrated modules, the integration with Ethereum and Hyperledger Fabric blockchain networks, and the client-side applications. The implementation of the proposed timestamping solution was designed following a modular architecture, where each service is responsible for a specific and well-defined functionality. This design approach ensures a clear separation of concerns, improves scalability, and simplifies maintenance and further system extensions. Each module operates independently while interacting with other components through standardized interfaces, primarly using RESTful interfaces.

The client-side component, Apply Timestamp Client, and the Issue Timestamp Handler were implemented in Python programming language (version 3.14), chosen for its simplicity, portability, and extensive library support for cryptographic operations and ASN.1 encoding. The implementation uses the FastAPI framework [29] to expose a lightweight RESTful interface that allows clients to upload documents or precomputed hashes for timestamping. Cryptographic operations, including the SHA-256 hashing process and the creation of timestamp requests conforming to RFC 3161 [2] and RFC 5652 [3], were implemented using the hashlib [30] and asn1crypto [31] libraries.

The TSA component was developed in Go programming language, chosen for its efficiency and suitability for building high-performance backend services. The TSA acts as the core service of the system, receiving timestamp requests generated by the client in RFC 3161 format via an HTTP endpoint. Upon receiving a valid request, the TSA parses and processes the structure according to the standards, extracts the message imprint (the hash of the client document), and generates a compliant TimeStampResp object. The response is digitally signed using the TSA’s private key, ensuring authenticity and integrity. Beyond the above highlighted RFCs, the TSA was extended to support blockchain integration. To extend the standard TSA behavior, two dedicated modules were implemented for blockchain anchoring: the Ethereum module and the Hyperledger Fabric module. Both are integrated at the TSA level and can be dynamically invoked depending on the target blockchain identified in the timestamp’s SN.

The Ethereum module, developed in Go, provides flexible connectivity options, supporting both the Sepolia [32] Ethereum test network (for public testing and validation) and a local Hardhat [33] instance (for development and debugging). The module computes a SHA-256 hash over the generated timestamp token and records it on-chain using a custom smart contract written in Solidity. The Hyperledger Fabric Module, also written in Go, extends interoperability with a permissioned blockchain infrastructure. It connects to the Fabric network via a gRPC [34] gateway, authenticating with digital managed identities. Once connected, the module hashes the timestamp token using SHA-256 and invokes the chaincode function AddDocument to persist the mapping between the SN and the timestamp hash. Blockchain transactions are constructed and signed with a private key configured at the TSA level and then broadcast asynchronously to the selected blockchain network. Once mined and confirmed, the transaction permanently anchors the hash, ensuring verifiable and tamper-proof timestamp integrity.

The Ethereum module connects via Web3 python [35]-specific functions and interacts with a deployed smart contract that manages simple key–value mappings between a timestamp’s SN and its corresponding SHA-256 hash. The contract is deployed using Web3 python scripts, which connect either to a local Hardhat node or to the Sepolia test network. Deployment involves compiling the Solidity contract, loading the generated Application Binary Interface (ABI) and bytecode, and broadcasting the deployment transaction using one of the preconfigured accounts.

The Hyperledger Fabric required the compilation and deployment of a smart contract, referred to as chaincode in the Hyperledger ecosystem. Unlike traditional smart contracts that deploy directly to the blockchain, chaincode in Fabric follows a multi-step lifecycle that emphasizes governance and consensus among network participants. In this implementation, the chaincode package was first installed on the peer nodes of both organizations participating in the network. Following installation, both clients were required to approve the chaincode definition for their respective organizations before it could be committed to the channel. This approval process ensures that all participating organizations explicitly consent to the business logic and terms encoded in the chaincode, preventing unilateral deployment of potentially malicious or unwanted code. Once both organizations approved the chaincode definition, it was committed to the channel and became available for invocation.

The client-side verifier component, Verify Timestamp Client, and the Verify Timestamp Handler were implemented in Python programming language. The implementation uses FastAPI for REST API endpoints, hashlib for SHA-256 hashing, asn1crypto for handling RFC 3161 timestamp requests/responses, and Web3 python-specific functions for interacting with Ethereum smart contracts. Communication between the client and handler components is performed through the REST API exposed by the handler.

4.6. Time-Stamping Authority

For our Time-Stamping Authority, we used and extended the open-source Sigstore timestamp server (https://github.com/sigstore/timestamp-authority, accessed on 12 October 2025) by modifying its underlying timestamp response generation mechanism. Specifically, we customized the Digitorus timestamp protocol Go package (https://github.com/digitorus/timestamp, accessed on 12 October 2025), which Sigstore uses to create RFC 3161-compliant timestamp responses. Here, the modifications to include the serial number mapping and the two blockchain anchoring mechanisms mentioned earlier have been made. Precisely, the generateTSASerialNumber() function was modified to include either the ETH: or HYF: prefix, and the two anchoring methods were implemented using the two additional functions AnchorOnHyperledger() and AnchorOnEthereum(). The anchoring method is configured through a .env file located in the timestamp server binary’s directory, where the ANCHOR_TYPE environment variable dynamically selects the target blockchain. Our implementation requires only minimal changes to the Sigstore timestamp server: replacing the original Digitorus timestamp protocol Go package with our extended version. This design seamlessly incorporates blockchain anchoring into the timestamp response generation workflow without compromising RFC 3161 compliance.

4.7. Blockchain Networks

The two blockchain networks used for timestamp anchoring are Ethereum and Hyperledger Fabric. These networks were selected for their complementary characteristics and different architectural approaches to blockchain technology. Ethereum, a public permissionless blockchain, provides global accessibility and immutability through its decentralized network of validators, ensuring that anchored timestamps are publicly verifiable by anyone. Hyperledger Fabric, a permissioned enterprise blockchain, offers fine-grained access control, high transaction throughput, and configurable privacy—making it suitable for organizational use cases requiring controlled access to timestamp records.

Ethereum’s primary advantages for timestamping include strong censorship resistance, as no single entity can prevent or alter anchored timestamps once confirmed on the blockchain. The network’s global reach and widespread adoption ensure long-term persistence and verifiability without requiring trust in any specific organization. Additionally, the public nature of Ethereum enables independent verification by any third party, enhancing the trustworthiness of timestamped data. However, Ethereum presents notable challenges: Transaction costs (gas fees) can be significant and variable depending on network congestion, making high-volume timestamping economically impractical. Confirmation times are also variable (especially on mainnet or testnet), typically ranging from seconds to minutes, which may not suit time-critical applications. Furthermore, all anchored data is permanently public and visible on the blockchain, which may conflict with privacy requirements in certain use cases.

Hyperledger Fabric offers complementary advantages, particularly for enterprise environments. Transaction costs are minimal or negligible compared to public blockchains, enabling cost-effective high-volume timestamping operations. The network provides deterministic and fast transaction finality, typically within seconds, making it suitable for time-sensitive applications. Channel-based architecture allows for selective data sharing and privacy, ensuring that timestamp records are only visible to authorized participants. The permissioned nature also facilitates compliance with regulatory requirements regarding data access and auditability. However, Fabric’s architecture introduces different trade-offs: The network’s security and persistence depend on the trustworthiness of the consortium members operating the network, creating potential single points of failure. Timestamps anchored on Fabric cannot be independently verified by external parties without network access, limiting transparency. Additionally, the setup, configuration, and maintenance of a Hyperledger Fabric network require significant technical expertise and infrastructure investment.

By implementing both anchoring methods, our TSA provides organizations with the flexibility to choose the blockchain network that best aligns with their specific requirements—whether prioritizing public verifiability and censorship resistance (Ethereum) or operational efficiency and privacy (Hyperledger Fabric).

4.8. Interoperability and Communication Security

Given the heterogeneous technology stack employed across the architecture, maintaining seamless interoperability between modules necessitates deliberate design decisions and careful implementation. To address this challenge, the system relies on standardized communication mechanisms, primarily RESTful and gRPC APIs, enabling each module to operate independently while ensuring consistent interaction patterns across component boundaries. Moreover, the adherence to RFC 3161 serves a dual purpose: it guarantees protocol compliance for timestamping operations while simultaneously establishing a stable contract between components, ensuring that updates maintaining RFC 3161 conformance preserve overall system integrity without disrupting functionality. The modular design ensures clear separation of concerns, where each service is responsible for specific and well-defined functionality, improving scalability and simplifying maintenance and system extensions. Components are coupled only through their API contracts and standard cryptographic formats (ASN.1; CMS SignedData), not through implementation-specific details.

Security across these communication channels is maintained through industry-standard transport layer protection mechanisms. All RESTful API endpoints can be secured using Transport Layer Security (TLS), which provides encryption, authentication, and integrity protection for data transmitted between the Python-based client components and the Go-based TSA services. Similarly, the gRPC communication channels employed for Hyperledger Fabric integration support native TLS encryption and mutual authentication through digital certificates, ensuring that all interactions with the permissioned blockchain network are protected against eavesdropping and unauthorized access. These transport-level security measures complement the cryptographic integrity guarantees provided by the TSA’s digital signatures, creating defense-in-depth protection across the entire system architecture.

4.9. Long-Term Cryptographic Security and Forward Compatibility

Ensuring long-term validity is a well-known challenge for qualified timestamp tokens, as cryptographic algorithms may weaken or become obsolete after several decades. In the proposed architecture, long-term verification is supported through the combination of a standard RFC 3161 timestamp token and an immutable blockchain anchor. Even if the TSA’s signing algorithm becomes outdated, the blockchain-anchored hash still serves as independent, tamper-resistant evidence that the timestamp token existed in its exact form at the moment of anchoring. The security of this evidence relies on the underlying blockchain consensus rather than the cryptographic strength of the original TSA signature, providing long-term resilience.

A key feature that supports future-proofing is hash agility. Since the system stores only a cryptographic hash of the timestamp token on-chain, it can seamlessly transition to newer algorithms when required by standards or when older algorithms become vulnerable. If the currently used hash function is considered insecure (e.g., SHA-256 becomes susceptible to collision attacks), the client can simply compute the timestamp token’s hash using a stronger function (e.g., SHA-3 or a post-quantum hash) and request a new timestamp, without modifying the underlying RFC 3161 structure. The TSA can issue re-hashed versions of older timestamp tokens, ensuring that long-term integrity is preserved across cryptographic generations. This provides forward compatibility and prevents the system from being bound to a single algorithm’s lifetime.

In addition, the proposed architecture supports re-anchoring (periodic re-timestamping). If a hash algorithm used in older anchors becomes weak, the timestamp token, or even the previously anchored hash, can be hashed again using a more secure function and anchored on-chain a second time. This creates a verifiable sequence of integrity proofs, each anchored using the strongest cryptograhical algorithms available at the time. Re-anchoring maintains continuity of evidence without invalidating older records. Using this flow, a verifier can check that an early record existed at time T0, and that this record was later re-hashed and re-anchored at time T1, extending its lifetime indefinitely.

Furthermore, regarding the blockchain itself, major networks such as Ethereum and Bitcoin also rely on cryptographic hash functions, primarily in block headers, and proof-of-work or data structures like Merkle trees. If these hashing algorithms ever became obsolete, the integrity of old blocks would not instantly collapse, because altering historical blocks would still require re-computing all subsequent blocks and overtaking the chain’s cumulative consensus. Both Ethereum and Bitcoin communities have long-term upgrade paths for transitioning to new algorithms if needed, ensuring continuity without invalidating historical data. Therefore, even in the unlikely scenario of hash-level vulnerabilities, the blockchain-anchored hashes stored by our system remain extremely difficult to falsify. Combined with re-anchoring and hash agility, this ensures that legacy timestamps remain verifiable and that the system can adapt to new cryptographic standards over time.

5. Evaluation Methodology

In this chapter, we describe the methodology used to evaluate the proposed timestamping system, including the metrics, workload, and experimental setup employed to assess its performance, security, and compliance with cryptographic standards and RFCs (RFC 3161; RFC 5816) and regulatory frameworks/standards discussed in this work. Performance tests were conducted using Apache JMeter [36] to evaluate system throughput and response times under concurrent requests.

5.1. Experimental Setup

The experimental setup is designed to evaluate the performance and correctness of the proposed timestamping system. The tests were conducted on hardware with specifications 1 × AMD EPYC 7313 16-core processors (64 threads total), 124 GiB of RAM, and 1 TB of storage. The software components included Python and Go programming languages, Gin Web framework, FastAPI, Web3 python packages, Hyperledger Fabric SDK, and other necessary libraries for cryptographic operations.

For blockchain integration, both Ethereum and Hyperledger Fabric networks were used. Ethereum experiments were performed on a Hardhat local network and Sepolia testnet, while Hyperledger Fabric tests were executed on a permissioned network with 2 peers, 1 orderer, and 1 channel.

The size of the documents is not highly relevant for the evaluation, as the hashing of the document is performed on the client side and can be performed prior to initiating the timestamping process. Consequently, the input to the system is effectively of fixed size, corresponding to the 256-bit output of the SHA-256 hash function.

5.2. Metrics

To evaluate the performance and efficiency of the proposed timestamping system, we define a set of key metrics. These metrics capture different aspects of the system, including responsiveness, scalability, operational cost, and resource usage. The main metrics considered are as follows:

• Issuance latency: Time elapsed from when the client sends a request to when the TSA issues the timestamp token;
• Anchoring latency: Time taken specifically to record the timestamp hash on the blockchain;
• Throughput: Number of timestamp requests processed per second, both in steady-state operation and during burst traffic;
• Cost: Gas consumption per on-chain anchor and the overall cost per timestamp;
• Timestamp token size: The size of the generated timestamp token, which affects storage and transmission;
• Verifier time: Time required to fully validate a timestamp token against the blockchain;
• Verifier throughput: Number of validation requests processed per second, both in steady-state operation and during burst traffic.

5.3. Workload

To evaluate the system under realistic usage scenarios, we generate a workload consisting of multiple concurrent timestamp requests. In our experiments, we employ 10 parallel threads, each submitting 1000 timestamp requests. This setup was chosen for several reasons:

• It reflects real-world scenarios where multiple clients interact with the system simultaneously;
• It allows us to measure system scalability and throughput under load;
• Using a large number of requests per thread (1000) ensures that we can observe steady-state performance as well as potential bottlenecks;
• Parallel processing reveals response time variations and potential conflicts in client–server and blockchain interactions.

6. Results

To ensure reproducibility and clarity of the evaluation, we briefly summarize the key benchmarking parameters used throughout the experiments. As detailed in Section 5, all tests were executed using 10 parallel threads, each issuing 1000 timestamp requests, resulting in a total workload of 10,000 requests per experiment. Measurements were collected for both synchronous and asynchronous operation modes, depending on whether blockchain confirmation was required before responding to the client. The hardware used in all experiments is described in Section 5 (AMD EPIC 7313 CPU, 124 GiB RAM), and all benchmarks were executed under identical conditions to ensure reproducibility.

The blockchain environments used were as follows:

• Hardhat local Ethereum network configured with fixed gas price (1.875 Gwei) and instantaneous block mining;
• Sepolia testnet, which operates with an artificially low gas price determined by testnet validators (0.001 Gwei);
• Hyperledger Fabric network composed of 2 peers, 1 orderer, and a single channel.

All components communicated over standard HTTP/REST interfaces within the same local network, without introducing artificial latency of bandwidth constraints. The Hardhat Ethereum network was ran locally on the same machine as the TSA backend, accessed through its RPC interface. Sepolia interactions were performed through a public RPC endpoint, and Hyperledger Fabric communication used the default gRPC ports of the network.

To ensure statistical reliability and reproducibility, all experiments were executed multiple times under identical workload conditions. The values reported in this section represent the arithmetic mean across repeated runs. Performance metrics such as issuance latency, anchoring latency, verification time, and throughput were collected using Apache JMeter’s aggregate reports, which provide consistent measurements under concurrent load.

The following section presents the results of the experimental evaluation of the proposed timestamping system. All results obtained are summarized in Table 5, Table 6 and Table 7, following the metrics and test data described in Section 5. The results presented in the tables represent the average values obtained from the tests performed.

Table 5. Basic TSA performance.

Metric	Basic TSA
Issuance latency	93 ms
Anchoring latency	N/A
Throughput	105.7 req/s
Timestamp token size	670 bytes
Cost	N/A
Verifier time	50 ms—partial verification (no blockchain anchoring)
Verifier throughput	194.8 req/s

Table 6. Ethereum-based TSA performance.

Metric	Hardhat Asynchronous	Hardhat Synchronous	Testnet Asynchronous	Testnet Synchronous
Issuance latency (ms)	93	100	93	107,287
Anchoring latency (ms)	7	7	107,194	107,194
Throughput (req/s)	105.7	91.5	105.7	0.126
Timestamp token size (bytes)	670	670	670	670
Cost (ETH)	0.00008676	0.00008676	0.00002324	0.00002324
Verifier time (ms)	N/A	75	N/A	540
Verifier throughput (req/s)	N/A	133	N/A	18.5

Table 7. Hyperledger Fabric-based TSA performance.

Metric	Hyperledger Fabric Asynchronous	Hyperledger Fabric Synchronous
Issuance latency (ms)	93	117
Anchoring latency (ms)	24	24
Throughput (req/s)	105.7	81.6
Timestamp token size (bytes)	670	670
Verifier time (ms)	N/A	51
Verifier throughput (req/s)	N/A	195.6

6.1. Latency and Throughput

The issuance latency remains the same for the basic, Hardhat asynchronous, Sepolia testnet asynchronous, and Hyperledger Fabric asynchronous TSAs because the process of generating the timestamp token follows the same flow in all cases. Since blockchain anchoring is performed asynchronously in the Hardhat async, Testnet async, and Hyperledger Fabric async setups, it does not affect the response time received by the client. In contrast, the issuance latency for the Hardhat synchronous TSA is 93 ms, and for the Sepolia testnet synchronous TSA it is 107,287 ms. Also, for Hyperledger synchronous it is 117 ms. In these synchronous scenarios, the client receives the timestamp token only after the hash has been successfully written and confirmed on the blockchain. The significantly higher latency on the Sepolia testnet is due to the fact that it simulates the Ethereum mainnet environment, where transactions are not processed simultaneously, and new blocks are published less frequently, leading to longer confirmation times.

Regarding the anchoring latency, for the Hardhat setup it is approximately 7 ms for both synchronous and asynchronous operations. In the case of Hyperledger Fabric, the anchoring latency is about 24 ms. The underlying steps for writing/saving the timestamp hash to the blockchain are identical. The only difference in the complete workflows is that in the asynchronous case, the client receives the timestamp token immediately, without waiting for the transaction to be confirmed. However, the measured time until the transaction is confirmed on the blockchain remains the same regardless of whether the communication is handled synchronously or asynchronously. The same principle applies to the Sepolia testnet, where anchoring latency is approximately 107,287 ms for both synchronous and asynchronous configurations, since the actual blockchain confirmation process does not change. In both cases, the difference affects only the client-facing response time, while the effective anchoring latency remains unchanged.

Regarding the throughput, for the basic TSA, Hardhat, Sepolia testnet, and Hyperledger Fabric asynchronous configurations, the measured throughput is approximately 105.7 requests per second. Since the client receives the timestamp token immediately without waiting for blockchain confirmation, the processing time per request is minimal. In contrast, Hardhat synchronous operations show a slightly lower throughput of 91.5 requests per second. This is because the client must wait for the blockchain transaction to be confirmed before receiving the response, increasing the time required to process each request. Longer block confirmation times increase the response time for each request, thereby lowering the number of requests processed per second. The Sepolia testnet synchronous configuration exhibits a much lower throughput of 0.126 req/seconds, meaning 5.56 requests per minutes. Furthermore, the throughput values for Hyperledger and Ethereum Hardhat synchronous environments are relatively close at −81.6 req/s and, respectively, 91.5 req/s. The difference can be attributed to a lower issuance latency in the Hardhat setup, which is approximately 17 ms shorter compared to Hyperledger.

6.2. Cost Analysis

Cost considerations differ depending on the underlying infrastructure. In the case of the basic TSA, no direct expenses are incurred, as it does not involve storing data on a blockchain. However, in a real PKI deployment, costs may be associated with the usage of timestamping services provided by a TSA operated by a Trusted Service Provider (TSP).

In contrast to a basic TSA, blockchain-based timestamping involves a cost due to gas fees required for storing the timestamp token hashes on-chain. For the Hardhat network, both synchronous and asynchronous modes result in the same gas consumption. In our setup, a single timestamp save operation consumes 46,304 gas units, which corresponds to the cost of executing the smart contract function that stores a hash on the blockchain. Considering 10 parallel threads, each sending 1000 requests, the total gas consumed amounts to

$$\mathrm{46,304}\times 10\times 1000=\mathrm{46,304,000}\mathrm{gas}\mathrm{units}$$

(1)

Given a gas price of 1.875 Gwei (1,875,000,000 wei), the total fee is

$$\mathrm{463,040,000}\times \mathrm{1,875,000,000}\mathrm{wei}=\mathrm{867,600,000,000,000,000}\mathrm{wei}=0.8676\mathrm{ETH}$$

(2)

This represents the total cost for all 10,000 requests (10 threads × 1000 requests each), under the experimental workload. Dividing by the total number of requests, the average cost per timestamp is approximately

$${\displaystyle \frac{0.8676\mathrm{ETH}}{10\times 100}}\approx 0.00008676\mathrm{ETH}\mathrm{per}\mathrm{request}$$

(3)

For the Sepolia testnet, the total gas fee for saving hashes on the blockchain is calculated as follows:

$$\mathrm{23,240}\times 10\times 1000=\mathrm{232,400,000}\mathrm{gas}\mathrm{units}.$$

(4)

Using the gas price of 0.00100001 Gwei per unit, this corresponds to a total fee of approximately 0.2324 ETH for all 10,000 requests (10 threads × 1000 requests each). Dividing by the total number of requests, the average cost per timestamp is roughly

$${\displaystyle \frac{0.2324\mathrm{ETH}}{10\times 100}}\approx 0.00002324\mathrm{ETH}\mathrm{per}\mathrm{request}$$

(5)

It appears that the cost per request is lower on the Sepolia testnet than on Hardhat, which may seem surprising at first. However, this could be expected because Hardhat, being a local simulated network, allows for manually setting the gas price—in our tests, a higher value (1.875 Gwei) was used to evaluate transaction behavior and gas consumption. The higher gas price on Hardhat corresponds to the default value provided by the local Hardhat configuration, which was used in our experiments.

On the testnet, the transaction cost appears lower, not because it simulates mainnet prices (which are higher) but because using the testnet requires a real wallet and test ETH, which can be obtained from different faucets. Typically, the amount received from these faucets is small but sufficient for general testing purposes. If testnet costs mirrored mainnet prices, testing various flows, especially parallel executions, would have been much more complicated due to the higher expenses involved.

Despite this, the Sepolia testnet effectively simulates as much as possible the behavior and operation of a mainnet in terms of transaction processing times, validation, and block publication. From a cost perspective, testing on a local Hardhat network can be more convenient, as it allows you to set a custom gas price and simulate expenses closer to real-world scenarios, whereas mainnet costs are higher.

Furthermore, the system’s throughput could be increased on the Sepolia testnet network or even on mainnet by allocating a higher gas price or priority fee for transactions. This approach enables faster inclusion of transactions in blocks, reducing latency and improving scalability, at the expense of higher operational costs per issued timestamp. Thus, the system can flexibly balance cost and latency depending on operational requirements. Unlike Ethereum-based networks, Hyperledger Fabric operates in a permissioned environment where no gas fees or transaction costs are incurred. Therefore, no cost calculations are applicable for this setup.

To address the limitations highlighted in the experimental setup, it is important to clarify that neither Hardhat nor Sepolia provides a realistic cost model comparable to the Ethereum mainnet. Hardhat uses a fixed, locally configured gas price that does not reflect real network dynamics, while Sepolia operates with artificially low gas prices imposed by faucet-based token distribution and testnet validators. Consequently, the measured gas fees should be interpreted as relative indicators for comparing the performance of different configurations, rather than as accurate projections of operational costs in production environments.

Moreover, the gas price on the Sepolia testnet (0.001 Gwei) is not representative of Ethereum mainnet conditions. In practice, mainnet gas fees are orders of magnitude higher and fluctuate significantly based on network congestion and market activity. Testnets are intentionally designed to maintain low and stable gas prices to support experimentation without financial overhead.

For these reasons, the cost evaluation presented for Sepolia should be viewed strictly as a functional performance benchmark, not as an estimate of real deployment expenses. Running experiments on the Ethereum mainnet was avoided because real transactions are significantly more expensive, making large-scale testing unrealistic for this research. Any real-world deployment would require recalculating the cost model using up-to-date gas prices from the Ethereum mainnet.

6.3. Verification Performance

Our proposed timestamp token verification involves retrieving the corresponding hash from the blockchain network and comparing it with the hash newly computed over the timestamp token. In the case of the basic TSA, this full validation cannot be performed because there is no blockchain for storing the timestamp token. Here, validation is limited to verifying the TSA’s signature on the token data, but the overall authenticity of the token cannot be guaranteed, as there is no trusted anchor recording the initial hash.

In terms of timestamp token verification, the operation that can introduce variability in time is the communication with the blockchain to retrieve the hash needed for validation, whether on the Hardhat, Sepolia testnet, or Hyperledger Fabric network. We observe that the validation time is slightly higher on the Sepolia testnet compared to Hardhat or Hyperledger. This is because Sepolia simulates a distributed network with real block propagation delays, whereas Hardhat runs locally with immediate access to the blockchain state, resulting in faster hash retrieval for verification.

Verifier throughput was measured at approximately 194.8 req/sec for the basic TSA implementation. However, this value does not represent a full verification process, as the blockchain anchoring component is not integrated in that basic setup. For the Ethereum Hardhat synchronous configuration, the verifier throughput is higher compared to the Sepolia testnet synchronous case. This difference comes from the fact that the verification process on the testnet involves real network latency, making each request approximately seven times slower on average. In terms of the number of verification requests successfully processed per second for synchronous setups, the Hyperledger Fabric achieved slightly higher efficiency compared to Ethereum Hardhat. This improvement is primarily due to the shorter verification time per request, approximately 51 ms on Hyperledger versus 75 ms on Hardhat. Regarding the asynchronous environments, verifier throughput values are not reported in the table. This is because the verification process necessarily includes retrieving the timestamp token’s hash from the blockchain, an inherently synchronous operation that prevents true parallel execution in the current implementation.

7. Discussion

This section discusses key aspects and implications of the proposed timestamping system. We analyze its security properties, privacy considerations, compliance with relevant legal framework, RFCs and standards, and the alignment with eIDAS requirements. The discussion highlights both strengths and potential limitations of the current design, providing context for practical deployment and future improvements.

7.1. Security Analysis

The security analysis of the proposed timestamping system considers several potential threats and their corresponding mitigation strategies, which are discussed in detail in the following sections.

7.1.1. Rogue TSA

If a TSA component is compromised, it could theoretically issue fraudulent timestamp tokens with incorrect issuance times. In such a scenario, clients relying solely on the TSA’s response would be unable to detect any discrepancies. In our system, each timestamp token is anchored to the blockchain via the Ethereum or Hyperledger module. By comparing the locally generated token hash with the blockchain-anchored hash, any tampering with the token can be detected after the fact, limiting the potential damage.

Nevertheless, this mechanism has limitations. While the blockchain ensures immutability of the recorded hash, it cannot prevent a compromised TSA from temporarily issuing fraudulent tokens before anchoring occurs. External factors, such as malicious insiders or attacks on the TSA infrastructure, could affect token generation within the short window between issuance and anchoring. The system mitigates this risk by ensuring rapid, asynchronous anchoring, reducing the time during which fraudulent tokens could exist unrecorded. This anchoring mechanism introduces a decentralized verification layer that reduces the potential impact of a compromised TSA.

7.1.2. Chain Reorganization Risk

In public blockchains like Ethereum, a chain reorganization can occur when two competing blocks are mined almost simultaneously, and eventually one block is discarded. Transactions included in the discarded block are temporarily left unconfirmed. In the context of our solution, this risk is minimal. Reorganizations do not occur on the Hardhat local network, whereas they are rare on the Sepolia testnet and Ethereum mainnet. Even if a chain reorganization happens, the timestamp token has already been issued to the client, and its hash can still be verified against the blockchain once the new canonical block is established. On Hyperledger Fabric, which is a permissioned network, deterministic consensus ensures that reorganizations cannot occur, eliminating this risk entirely.

7.1.3. Layer 2 and Off-Chain Considerations

In our proposed system, Ethereum-based timestamp anchoring could benefit from Layer 2 (L2) technologies or off-chain techniques to reduce transaction costs and improve scalability. While the mainnet or testnet anchors every timestamp on-chain, using L2 networks such as Optimistic Rollups [37] or zk-Rollups [38] could allow for batches of timestamp hashes to be processed and finalized off-chain, with periodic commitments to the main chain. This approach reduces gas fees and transaction congestion while maintaining cryptographic verifiability of the anchored timestamps. These solutions are especially useful for high-frequency timestamping while still maintaining the integrity and trust guarantees ensured by the underlying blockchain.

7.1.4. Proof Longevity

By anchoring timestamp token hashes on the blockchain, our timestamping proposed scheme involves long-term verifiability independent of TSA availability. Even if the TSA or client-side infrastructure fails in the future, the hash stored on the blockchain provides an auditable, immutable record. This enhances the system’s assurance that operations cannot be denied or disputed.

7.1.5. Permissioned Collusion

While collusion risks are more relevant in permissioned networks like Hyperledger Fabric, where a limited set of participants could potentially coordinate malicious actions, public blockchains like Ethereum are less susceptible to such collusion due to their broader decentralization and larger number of independent validators.

However, permissioned networks implement several mechanisms to mitigate collusion risks. First, governance frameworks establish clear roles, responsibilities, and accountability measures for network participants. These frameworks typically include multi-signature requirements for critical operations and mandatory audit trails that make coordinated malicious behavior more detectable. Second, endorsement policies in Hyperledger Fabric can require approval from multiple organizations across different jurisdictions or business domains, reducing the likelihood of successful collusion. Third, the transparency of blockchain transactions, even in permissioned networks, creates a deterrent effect as all actions are recorded and can be audited retrospectively.

7.2. Privacy Considerations

The proposed solution preserves data confidentiality by anchoring only document hashes on the blockchain, without exposing the original content or any identifiable metadata. To further enhance privacy, the hashing operation is performed exclusively on the client side, ensuring that raw documents never leave the user’s environment. Additionally, the system can also accept precomputed hashes directly, allowing users to maintain full control over their sensitive data while still benefiting from blockchain-based integrity verification. This ensures that sensitive information remains local to the client or TSA, while the blockchain serves as a tamper-evident proof of existence.

Following the principle of metadata minimization, the system stores only the cryptographic hash of the generated timestamp token on the blockchain, along with a minimal identifier derived from the timestamp token’s serial number. Specifically, only the last 16 bytes of the SN are retained, which uniquely identify each timestamp token without exposing additional metadata.

Regarding off-chain logs, the system records only minimal information necessary for auditing or process tracking, such as the timestamp token’s SN or the current processing status. No full document content or other document-specific metadata is stored off-chain, ensuring that user privacy is preserved while still enabling traceability and operational monitoring.

To further strengthen privacy, techniques like salting or commitments can be applied on the client side before hashing:

• Adding a salt to the document before hashing makes it infeasible for an attacker to find the original content from the stored hash or by using precomputed hash tables;
• Commitments allow clients to commit to a document’s hash without revealing the content while enabling later verification of timestamp-original data correspondence.

Integrating these techniques would protect against potential disclosure of information if the blockchain is publicly accessible, enhance resistance to preimage attacks, and provide stronger guarantees of confidentiality. In our current system, this would require the client to compute the salted or committed hash before requesting the timestamp, and during verification, the same salt or commitment value must be provided to recompute the hash and confirm the validity of the timestamp token.

7.3. Legal and Standards Considerations

Our proposed timestamping system is designed to align with existing standards and RFCs for digital timestamping and trust services. By adhering to RFC 3161 [2], RFC 5816 [6], RFC 4634 [7], and FIPS 180-4 [28], the system ensures compatibility with widely accepted protocols for timestamp token generation and verification, including support for hash algorithm agility and robust token structure. For real-world deployments, the system could be integrated with qualified TSAs following ETSI standards (EN 319 421, EN 319 422, and EN 319 401). The modular architecture allows for substitution or integration with compliant TSAs to meet certification criteria.

From a blockchain perspective, anchoring timestamp tokens using Ethereum or Hyperledger Fabric does not conflict with these standards and adds an additional layer of integrity and auditability. However, legal compliance still requires that the cryptographic operations, key management, and TSA policies meet regulatory expectations if the system is deployed in production.

7.3.1. eIDAS Alignment

The system is also designed with eIDAS [1] alignment in mind. The use of secured cryptographic operations, including hashing, and blockchain anchoring provides immutable proof of existence for the timestamped data. A fully eIDAS-compliant TSA requires extra security measures such as a certified/qualified TSA, secure key handling, and audit logs, and our system can support these. Using RFC-compliant timestamp tokens together with blockchain anchoring improves the reliability of the timestamps and makes it easier to meet legal and trust framework requirements for electronic transactions.

As standards and regulations continue to evolve, such as the ongoing updates to eIDAS to address emerging technologies, we can anticipate a closer integration of blockchain solutions with qualified trust services, resulting in timestamping systems that are both more secure and legally robust. Further efforts in standardization, clear regulatory frameworks, and interoperability analysis will be required before these hybrid approaches can be integrated seamlessly into existing trust services and infrastructures.

7.3.2. Legal Admissibility

Although the proposed system integrated RFC 3161 [2]-compliant timestamp tokens with blockchain anchoring, the legal admissibility of blockchain timestamps in court or regulated entities required careful consideration. In the current regulatory landscape, blockchain anchoring alone does not grant a timestamp the legal status of a qualified timestamp under eIDAS [1]. Only tokens issued by a QTSP operating a certified TSA benefit from automatic legal recognition. As such, blockchain anchoring must be viewed as a supplementary security mechanism, not a replacement for qualified timestamping.

From a practical perspective, blockchain anchoring strengthens evidence by adding a secondary, tamper-resistant proof of existence, but it does not replace the responsibilities that TSPs must meet such as operating reliable time sources, certified key material, and compliance with ETSI standards (EN 319 421, EN 319 422, and EN 319 401). However, integrating blockchain at the TSA level, rather than replacing it, introduces several significant benefits. It enhances transparency, provides long-term integrity, and offers a verifiable trail independent of the TSA’s own infrastructure.

This hybrid approach is consistent with ongoing trends in European digital identity systems, such as EBSI (European Blockchain Services Infrastructures) [39] and EU Digital Identity Wallet architectures, both of which explore blockchain as a trust anchor for verifiable credentials and long-term authenticity guaranties. The maturity of the blockchain-based trust mechanism in EBSI suggests that blockchain can be a credible security layer in regulated environments when used alongside standardized trust services.

Nevertheless, practical adoption faces several challenges. First, legal frameworks currently lack explicit provisions for blockchain-anchored timestamps, meaning courts may accept them only as supporting evidence rather than primary proof. Second, operational integration would require QTPSs to update their infrastructures and policies to integrate an anchoring mechanism while maintaining certification requirements. Third, interoperability across blockchain networks and long-term verifiability must be addressed through clear ETSI and eIDAS standards.

Overall, timestamp blockchain anchoring does not conflict with existing standards but complements them. The solution proposed in this work can therefore be viewed as an incremental enhancement of the traditional timestamping model. It remains fully compatible with current legal and technical requirements while adding extra transparency and long-term security. As European institutions increasingly explore the use of blockchain technology in trust services, such hybrid approaches are becoming more relevant and may soon lead to the hybrid timestamping model being considered for inclusion in official recommendations and standards.

7.4. Positioning Relative to Existing Hybrid Approaches

While blockchain-based timestamping has been explored in tools such as OpenTimestamps, OriginStamp, or Chronos, these typically introduce custom token formats, require protocol extensions, or act as wrappers around non-standard APIs. In contrast, our implementation anchors standard-compliant RFC 3161 tokens directly to a blockchain without altering their structure or requiring changes to client validation logic. This ensures compatibility with existing PKI workflows and validation tools.

Moreover, our system integrates anchoring logic directly into an operational TSA implementation, rather than acting as a post-processing layer. This internal anchoring is agnostic to the underlying blockchain (public or permissioned) and supports verifiable event ordering—a critical need in long-lived PKI contexts (e.g., sign-revoke-verify vs. revoke-sign-verify). To our knowledge, no prior solution offers this combination of interoperability, generality, and anchoring transparency.

7.5. Limitations and Future Work

While our system anchors RFC 3161-compliant tokens on the blockchain without modifying their format, some limitations persist. The integrity guarantees offered by blockchain anchoring rely on the continued availability and trustworthiness of the chosen ledger. Public ledgers like Ethereum introduce fluctuating costs and confirmation delays, while permissioned ledgers may reintroduce centralization risks via consortium governance. Moreover, anchoring provides proof of issuance and ordering but does not attest to the semantics or intent behind the data.

Future work includes extending the anchoring logic to other PKI trust services, such as certificate issuance, validation, signing, and revocation. This would allow for anchoring multiple trust events in a unified timeline, enabling cryptographically verifiable orderings across signature workflows. Additionally, integrating Merkle-based batching or Layer 2 mechanisms could improve scalability while reducing anchoring costs.

8. Conclusions

This paper introduced a blockchain-anchored timestamping system that extends a standard-compliant TSA architecture without altering the timestamping protocol or the format of issued tokens. Our design integrates distributed ledger anchoring as a supplementary verification mechanism, enabling durable and independently auditable evidence of timestamp issuance and event ordering. Unlike prior approaches that rely solely on blockchain consensus or deviate from RFC 3161, our implementation preserves compatibility with existing PKI-based infrastructures and verification tools.

We implemented the system using both a public (Ethereum) and a permissioned (Hyperledger Fabric) blockchain, demonstrating flexibility across deployment models. Experiments show that the proposed anchoring mechanism adds minimal issuance latency while providing verifiable proofs of timestamp existence and relative order. Additionally, the cost and throughput characteristics of the system are suitable for practical adoption, particularly when batching or asynchronous anchoring is used. Verification workflows remain compatible with existing standards, while the blockchain component enhances the system’s transparency and resilience.

By bridging traditional TSAs and blockchain-based registries, the proposed architecture offers a viable migration path toward distributed trust without requiring changes to current validation software. Future work may focus mainly on integrating the other relevant events (certificate issuance, certificate revocation, etc.) in the blockchain. In this manner, we might obtain a system capable of more reliable signature validation, since the relative order of different events is established.

In addition, long-term cryptographic resilience remains an essential aspect for any timestamping architecture. Although the proposed system builds on mature cryptographical primitives such as SHA-256 and the widely adopted RFC 3161 timestamp token format, it is designed to remain adaptable as security requirements evolve. The anchoring mechanism is designed to be independent of the specific hash algorithm used, allowing for future migration to stronger digest functions without altering token structure or breaking interoperability. Moreover, the blockchain record provides durable, algorithm-independent proof of existence, ensuring that evidence remains verifiable even if the TSA’s original signature scheme becomes obsolete. As cryptographic standards progress, particularly in the context of post-quantum security, timestamps can be re-anchored using newer algorithms.

Furthermore, it is worth noting that major public blockchains such as Ethereum already incorporate long-term upgrade paths for their underlying cryptographic primitives. Even if a hashing algorithm used in older blocks were to be deprecated, the integrity of historical data would remain protected by the chain’s cumulative consensus security. This inherent resilience, reinforced by re-anchoring and algorithm-agility mechanisms, ensures the long-term verifiability of anchored timestamps.