Tokenized assets are moving from pilots toward critical financial market infrastructure. Central banks are exploring digital currencies. Commercial banks are testing tokenized deposits. Market operators are studying delivery-versus-payment workflows on programmable ledgers. Assets, rules, and settlement logic can live on shared infrastructure, reducing reconciliation and making transactions faster and less error-prone.
Regulated asset settlement must combine governance, privacy, resilience, auditability, and performance. A national-scale payment or settlement system cannot depend on a single operational point of failure, nor process transactions at boutique speeds. If tokenized finance is to support real markets, the ledger must keep up while preserving trust.
That challenge drives Fabric-X, an IBM Research effort, to scale Hyperledger Fabric for asset exchange. In a paper accepted to the SIGMOD 2026 Industry Track, we present a re-architecture designed to push permissioned distributed ledger technology closer to the needs of central bank digital currency (CBDC), tokenized money, and regulated settlement.
Hyperledger Fabric validation flow.
Figure 1: Fabric validation flow shows how transactions move through endorsement, ordering, validation, and commit before ledger update.
Why the original architecture hits limits
Hyperledger Fabric is an important permissioned blockchain platform for enterprise use. Its execute-order-validate model fits private networks: transactions are simulated and endorsed before ordering, then validated before commit. This structure supports modular trust, pluggable consensus, and smart contract execution.
Demanding financial workloads expose limits in the standard implementation. A Fabric peer combines endorsement, validation, committing, and state management in one process. This monolithic design creates resource contention and I/O bottlenecks. As throughput rises, CPU, network, storage, signature verification, and serial validation compete inside the same boundary.
Ordering adds another challenge. Traditional ordering paths carry full transaction payloads through consensus, increasing network load. Validation can also become sequential, even when many transactions are independent. Together, these bottlenecks make it difficult to hit throughput and latency targets for regulated asset systems.
Fabric-X starts from a different assumption: build the ledger as independently scalable services, each optimized for its role.
Re-architecting Fabric for horizontal scale
Fabric-X decomposes the peer into specialized services for endorsement, validation, and committing. This is more than deployment refactoring; it changes how the system exposes concurrency.
Fabric-X proposed architecture with separate endorser, validator, and committer services.
Figure 2: Fabric-X architecture separates endorser and committer responsibilities so each path can scale with its own workload.
Endorsement services scale with smart contract execution demand. Validation and commit services scale with transaction intake. Storage and verification paths can be tuned separately instead of forcing every peer to carry every bottleneck.
Fabric-X uses a transaction dependency graph to identify conflicts, allowing independent work to proceed concurrently while preserving correctness. This matters for asset exchange because many transfers do not touch the same inputs or outputs. Treating them as one serial stream wastes capacity.
For a CBDC-style application, Fabric-X demonstrates a UTXO-based transaction model at the application layer. UTXO models are natural for token systems: transactions consume existing outputs and create new ones. This makes double-spend detection explicit and pairs well with dependency-aware validation.
Arma: ordering less to move more
The other major component of Fabric-X is Arma, a scalable Byzantine Fault Tolerant ordering service. Ordering is often the heart of blockchain performance: participants must agree on transaction order, and agreement protocols are sensitive to bandwidth, latency, and party count.
Arma reduces pressure on consensus by ordering compact transaction digests rather than full transaction payloads. Heavier transaction data is disseminated outside the narrowest consensus path, so the ordering layer spends less bandwidth on repeated payload movement and more capacity on agreement.
Arma splits ordering into pipelined and sharded components to increase throughput while retaining Byzantine fault tolerance.
Figure 3: Arma separates transaction dissemination from ordering, pipelines the ordering path, and uses shards to increase aggregate throughput.
Arma pipelines the ordering service and shards work across parallel lanes. Pipelining keeps stages busy instead of making each batch wait for the previous one. Sharding lets throughput grow with added resources. Arma also retains Byzantine fault tolerance, so the system can operate correctly even when some participants fail or behave incorrectly.
This matters for regulated infrastructure. Financial networks must consider crashes, insider threats, compromised nodes, and operational faults across institutions. Byzantine fault tolerance gives the architecture a stronger foundation for multi-party deployment.
What the evaluation shows
In our evaluation, Fabric-X shows that permissioned DLT performance can be pushed far beyond common expectations. Arma reached about 430,000 transactions per second in ordering experiments with four parties and four shards, while maintaining sub-second latency in the tested configuration. Broader experiments show how execute, order, validate, and commit stages can scale separately.
Arma ordering throughput scales with shards, reaching more than 400,000 TPS in the evaluated setup.
Figure 4: Arma’s ordering layer reaches 400,000+ TPS-scale throughput in the evaluated setup, showing the impact of digest ordering, pipelining, and sharding.
One benchmark number does not solve every deployment question. Real financial systems must account for network geography, governance, identity, privacy, compliance, disaster recovery, and application logic. The result matters because it shows that the performance ceiling is architectural, not inherent to permissioned ledgers.
By removing avoidable bottlenecks, Fabric-X shows that a permissioned ledger can be engineered for modern financial infrastructure.
Fabric-X has been open-sourced as part of Linux Foundation Decentralized Trust under the Hyperledger Fabric-X project, including fabric-x, fabric-x-orderer, and fabric-x-committer. Open implementation lets the broader community inspect, test, extend, and adapt the architecture.
For IBM Research, Fabric-X is part of a broader effort to make distributed trust practical for enterprise and financial systems. Tokenized regulated assets need more than cryptographic elegance. They need systems engineering: separating hot paths, reducing bandwidth, scaling services independently, and designing for failures from the start.
Permissioned DLTs can preserve governance and controlled participation while adopting performance techniques from modern distributed systems. For CBDC, tokenized deposits, securities settlement, and other regulated asset platforms, that combination may be essential.
As tokenization moves from experiments to infrastructure decisions, the question is whether programmable ledgers can be resilient, private, governable, and fast enough for real markets. Fabric-X shows that with the right architecture, the answer can be yes.
Authors:
Senior Research Scientist