Design considerations when using crypto currencies and distributed ledgers

Crypto currencies and distributed ledgers are the latest buzz in the financial services industry. Surprised! – Did not Bitcoin originate as a radical innovation and soon got dumped in to the dark side of underworld transactions? Central banks were concerned about how to control Bitcoin usage and warned of its risks, slowing down its adoption by mainstream. Nevertheless, researchers and innovators continued to build on Bitcoin and its technologies. Quietly, new innovations based on the utility of Blockchain and solutions to inherent issues in Bitcoin emerged. The technology has evolved from Bitcoin to Alt-coins to new technology layers on top of Blockchain to new peer to peer distributed ledgers very different from Bitcoin. Now, the world sees Bitcoin as an important nascent step in the evolution of crypto currencies and distributed ledgers.

While Bitcoin found it difficult to enter mainstream, these new technologies are making inroads into banks and financial institutions. One fundamental shift is that innovators are working towards aligning the technology to solve the problems in mainstream. Of late, many banks and financial institutions have started experimenting with these technologies – some looking at it to solve specific problems like simplifying cross border money transfers, some using the power of distributed ledgers in asset management. But there are lot of others who are still caught in the fancy of crypto currency and overlooking the fundamental design of crypto currencies and distributed ledgers. This blog is an attempt to demystify some of the important technical pieces when designing systems based on crypto currencies and distributed ledgers.

1. De-centralized and peer to peer system

Yeah, the technology is a ‘crypto currency’ but it is a ‘de-centralized and peer-to-peer’ network. Lot of people see only the crypto currency and miss the other part. Simply, trying to create a new coin system or just trying to forcefully push for de-centralization is not the right approach. The key is – the problem that you are trying to solve should require de-centralization and peer to peer value exchange. Ask if the use case really requires decentralization. For example, is there any value in using the technology for loyalty management system? Yeah, such systems create and distribute value digitally (rewards points). But, do they have to be a Bitcoin like system? Similarly, what about internal enterprise level use cases or for transactions involving value exchange among a closed group of entities. They probably need a good ledger software but not always a public, distributed, and peer to peer ledger with crypto currency.  There are valuable use cases for distributed ledgers like cross border payments, KYC and identity management, securities and asset management. But you don’t have to force fit the technology to every use case that requires a ledger and value transfer.

2. Scalability and latency of the consensus algorithm

A risk with distributed ledgers is the need to make sure all the ledger instances across the network is synced up with all the transactions that has passed through the network. This needs to happen very quickly, probably less than a minute and very often. Bitcoin includes about 7-8 transactions in a block which will take about 15-30 mts or sometimes more for validation and inclusion in the block chain. Compare this against the volume handled by VISA or MasterCard network – they handle about 2000 tps with a peak capacity of more than 50,000 tps. While this looks like an apples vs oranges comparison, it is important to think about how scalable is the consensus process underlying the distributed ledger. The degree of latency acceptable for the use case is very important. Today, a cross border money transfer could take many days or up to a week with the conventional system. So, even a latency of few hours is still valuable but the current latency in distributed ledgers will not be acceptable if you are using it for e-commerce payments. Of course, the space is evolving and new consensus algorithms like in Ripple are being developed that could further scale up the volume and reduce latency. Nevertheless, it is very important to consider the scalability and latency requirements of the use case when designing a system based on distributed ledgers.

3. Trusts and validators of transactions

Often, we hear that one’s strength is its own weakness and vice versa! Bitcoin (or rather its predecessor Bit Gold) showed the world that a very secure transaction validation method can be achieved without a central operator through the concept of Mining. However, mining as a process itself is turning into a major issue for Bitcoin. Another view that is very common is that Bitcoin is bad but Blockchain is good. We should recognize that Blockchain cannot exist without Bitcoin (the process of mining that validates, adds the block to the chain, and creates Bitcoin). What it means is that in decentralized and distributed ledgers, validation of transactions is a very important component of the design. It is important to think about who acts as validators and what the incentive is for them.  Ripple, a much talked about alternative for Bitcoin, particularly for cross border money transfers has a different model of trusted validators (currently centralized though). HyperLedger is another such upcoming player that encourages validators to work with contractual obligations.

There are few other important design considerations. For e.g. identity management and regulatory compliance check/reporting for transactions. These are to be considered as additional application layers on top of the distributed ledgers. Existing enterprise systems for identity, risk and regulatory compliance need to be integrated in the design.

Bitcoin started as a crypto currency and led the way to new developments where the focus now is on distributed ledgers and its benefits. The technology has lot of potential in financial services. Already, many banks are experimenting with these technologies. The three design considerations answer some of the fundamental questions to think about when experimenting with crypto currencies and distributed ledgers.

Author Details

Venkatakrishnan Balasubramanian

Venkatakrishnan is a Research Analyst with the Financial Services practice at Infosys. He works with large banks in Consumer Payments domain providing solution and architecture design. He specializes in Innovation Management and IT Management and has rich experience in IT industry that spans across product management, consulting, architecture, engineering, and technology development. He can be reached at

Leave a Comment

Your email address will not be published.