The dialogue surrounding distributed ledger technology (DLT) within the financial services industry has evolved significantly from speculative intrigue to tangible, production-grade applications. As with any maturation of technology, focus of evaluation naturally shifts from mere feasibility to quantifiable measures of effectiveness. For STAC, an organization dedicated to rigorous testing standards, the question of what to measure, and how to compare performance is paramount; however, it is important to first understand where DLT is in its maturity cycle.

The core of our investigation is to determine whether a concentrated focus on developing a DLT performance benchmark is a valuable and timely endeavor for 2025. This requires a nuanced understanding of the technology's current deployment status, the real-world problems it is solving, and the expectations of the institutions that are increasingly reliant on it. Through this examination, we seek to establish a clear context for the benchmark/performance conversation. This also serves our broader goal of ensuring that STAC’s efforts (in DLT) are aligned with the needs of the broader financial services industry.

Refresher

As with anything that has fallen out of the current zeitgeist (no thanks to AI!) it helps to start our conversation with a recap of DLT or distributed ledger technology, in the context of the financial services industry.

At its heart, DLT is a shared, replicated ledger across a network of nodes, with blockchain being the most prominent branch of this technology (and Bitcoin its progenitor implementation). However, with FSI, an additional focus is on permissioned networks, where participants are known and vetted, as opposed to the public, permissionless model of early DLTs/blockchains.

The method for achieving agreement on this shared ledger is the consensus mechanism. For financial applications, the choice of consensus directly impacts the guarantee of finality; the point at which a transaction is irreversible. Enterprise DLT solutions have eschewed lottery-based mechanisms (like Proof-of-Work) with their probabilistic finality. Instead, they favor voting-based protocols that provide immediate finality, ensuring that once a transaction is committed by the requisite number of nodes, it is absolute.

Beyond simple record-keeping, modern DLTs are programmable through “smart contracts,” which define the logic for transactions and asset behavior (or more generally, how they affect the shared ledger). This programmability is the engine behind tokenization, the process of creating a digital representation of a real-world asset (like a bond, stock, or currency) on the ledger. The smart contract governs the asset's lifecycle, from issuance and trading to settlement and custody, providing automation and transparency not possible in legacy systems.

Furthermore, as more DLT networks have gone into production, interoperability has become a primary focus. The industry is actively working on standards and protocols to allow different DLT networks to communicate and transact with each other, preventing the creation of new, disconnected digital silos and enabling true cross-network asset movement.

Beyond Pilots

Companies involved in financial market infrastructure were among the earliest adopters of DLT, particularly for the settlement of securities. Traditional post-trade processes involve multiple parties and reconciliation over several days (e.g., T+2), creating settlement risk and operational overhead. DLT platforms provide a "golden source of truth" for asset ownership and transactions, enabling atomic settlement where the transfer of the asset and the payment occur simultaneously and finality is achieved in moments. An example of this is SIX’s fully regulated digital asset central securities depository. These earlier use cases of DLT (e.g., in the settlement process) focus on increasing operational efficiency and reducing settlement risk.

Building upon the increased operational efficiencies, there has been a recent shift toward adoption of DLTs that enable additional revenue. A 2025 industry survey has shown a new round of interest led by repo/ financing desks. These desks are focusing on DLT that enables more efficient cash and collateral utilization, e.g., assets tied for capital use. An example of this is Broadridge's Distributed Ledger Repo (DLR) platform which processes tens of billions in average daily volume, providing financial firms with intraday liquidity for repos. Another growing trend is the use of DLT as a means of increasing market share. Buy-side firms are increasingly tokenizing real-world assets or entire funds as a means of increasing customer base. For example, they are leveraging fractional ownership and liquidity enhancement for private assets. This interest has been fostered by BlackRock’s launch of its BUIDL money market fund in 2024 on Ethereum.

Network Solutions and Providers

As mentioned earlier, the industry focus on DLT is narrowly on permissioned networks, primarily due to privacy and regulatory concerns. Private networks are a form of DLT where nodes interact on a dedicated network, with participation permissioned centrally by the network owner(s). A common type of private network is one based on a public network’s protocol, typically Ethereum. Quorum (developed by J.P. Morgan) and Hyperledger Besu (part of the Linux Foundation) are examples of private Ethereum clients that leverage the vast Ethereum developer community and its mature smart contract capabilities (by way of support for EVM) while adding crucial features for business, such as permissioning and voting-based consensus, which enhance privacy and efficiency.

There are also private networks that are not based on any public network protocols, often designed to address shortfalls in public protocols for industry needs. Corda (by R3) is a permissioned DLT platform designed for finance that uses a novel consensus mechanism (not based on blockchain) and lacks a global ledger (for additional privacy). For further customization, there are frameworks such as Hyperledger Fabric (also part of the Linux Foundation) that have a modular architecture allowing for organizations to compose a private network[1] that is suited to their business needs.

While private networks remain popular for B2B (or interbank) use cases, there has also been a shift towards public permissioned networks by those seeking to increase market reach through DLT. Another potential factor driving the shift is the liquidity and ecosystem benefits that public networks provide over isolated private networks. Notable examples of public permissioned networks for enterprises are Canton Network, R3’s Solana Toolkit and Hedera. The architecture of public permissioned networks can differ significantly between networks but typically involve trusted validators and/or consensus mechanisms that are more scalable than first generation public permissioned networks.

The case for Benchmarking DLT

Some of the information in this section is sourced from a white paper by the Hyperledger Performance and Scale Working Group.

Unlike other technology benchmarks, we must look beyond the narrow scope of a single system and adopt a network-wide perspective for DLT. The performance of a single node is less important when considering the required interaction across nodes to perform an action; therefore, what matters is the performance of the entire System Under Test (SUT)[2], defined as the hardware, software, and network configuration of all participating nodes. Within this context, two key metrics as defined by the Hyperledger Performance and Scale Working Group are:

1. Transaction Throughput: This is the rate at which valid transactions are successfully committed across the entire network, typically measured in Transactions Per Second (TPS). It is a measure of the system's capacity.
2. Transaction Latency: This measures the time from when a transaction is submitted by a client until its result is finalized and usable across the network. This includes network propagation time and the time required to achieve consensus.

How latency is defined depends on the network's consensus mechanism and its guarantee of finality[3]. Voting-based consensus protocols (e.g., PBFT) offer immediate finality; thus, latency is defined as the time until 100% of nodes have committed a transaction. In contrast, lottery-based protocols (e.g., Proof-of-Work) offer probabilistic finality. A transaction is only considered final after a certain number of subsequent blocks have been added, making it computationally infeasible to reverse. Here, latency must be measured against a network threshold (e.g., time to commit on 95% of nodes), a metric that carries an inherent risk profile (tied to use case)[4] Hence, any performance comparison of SUTs must be within the context of the finality types induced by their respective consensus mechanisms.

On the surface, there is typically a trade-off between the number of validating nodes in a network and its performance. For example, the additional communication overhead required to achieve consensus of a larger network translates to increased latency. Furthermore, the validating nodes may be placed in different geographic locations, increasing communication times between nodes. Validating node size and their location are important considerations for the resiliency of the network to attacks or outages; thus, the real trade-off is between network security/availability and performance. Therefore, a comparison of network performances is incomplete without a comparison of their resiliency.

Some DLT are designed to speed transaction natively processing via parallel execution of (independent) transactions on the mainnet, typically using an architecture that does not rely on a blockchain (which is sequential in nature) and does not have a “global” ledger. However, these networks require other mechanisms to ensure validity of transactions; these mechanisms (often unique to each DLT) can introduce (different) performance bottlenecks, such as transaction history length and interconnectedness. Thus, a benchmark potentially requires careful crafting of its workloads to match real-world patterns[5] to ensure evaluations are realistic.

Conclusions

First, it is important to distinguish between benchmarking and performance evaluation, a concept acknowledged and discussed by Hyperledger Performance and Scale Working Group in its white paper. There exist many tools and companies that evaluate the performance... (synthetically/simulated, such as Hyperledger Caliper, or empirically, such as chaininspect); however, a relevant benchmark requires a clear use case with a common set of requirements to ensure fair competition.

The prevailing DLT trends in Finance have only started recently, and it remains to be proven whether they will persist, especially when factoring external trends such as AI that the industry is also focused on. This makes identifying use cases (the basis of a benchmark) difficult; otherwise, the relevancy of benchmark formulation and the longevity of its results will come into question.

The factors discussed in the earlier section are but few of the many that contribute to the complexity of comparing performance results across different DLTs. Without some constant/minimum requirement across systems or methods of normalization, merely looking at throughput and performance is misleading and uninformative. Identification of these requirements or normalizing factors is dependent on specific use cases, and even if identifiable, they may not be controllable nor replicable for all systems under consideration, especially when considering public permissioned networks (e.g. the inability to change or set the resiliency of public networks).

Together, this makes developing a DLT benchmark in today’s environment a three-way trade-off between relevancy/longevity, specificity, and general comparability: not necessarily ideal.

Lastly, relative performance between DLTs may not be the defining evaluation dimension (just yet). When applied correctly, most DLT enable tremendous efficiencies compared to traditional solutions; therefore, any head-to-head performance evaluation, while meaningful, is less important when considering the speed both have over traditional solutions. Given the current phase in the maturity cycle, other factors such as interoperability, developer talent pool, and wider ecosystem benefits are equally, if not more, decisive in differentiating DLTs. This is echoed in the current development goals of several public chains. This or other directions of development could change how we think about evaluating performance, e.g., shifting from a single network to network-of-networks.

[1] There are also several cloud providers who offer “DLT-as-a-service” that is based on Hyperledger Fabric.

[2] Maybe more appropriately called Network Under Test.

[3] See earlier section for definition

[4] Alternatively, latency of a probabilistic finality SUT can be represented as a curve in a 2D space and comparing latency of SUTs amount to comparing different curves; similarity, the latency of immediate finality SUT are points in a 1D space.

[5] Beyond request speed or concurrency.