BharatChain – Imagining a Pan-India Blockchain Network for Government

Background Note

The post below is the original write-up, parts of which were published in The Economic Times here and here.

The concept of ‘BharatChain’ was first mentioned in a series of tweets on 20th June 2017 Tweet 1, Tweet 2, and Tweet 3.

This writeup aims to create a case for establishing a country-wide Blockchain framework for India through Use Cases and discuss its basic building blocks.

It does not wish to introduce Blockchain or talk about its technical aspects. However, to make this readable for those without any background in Blockchain, and for a technology which is complex even for the experts, it is just fair that we quickly cover the basics.

Note: ‘Bhārat’ and ‘Hindustān’ are other commonly used names for the Republic of India, hence ‘Bhārat’Chain

What is a Blockchain?

Basic Terminology of Blockchains

Blockchain: Conceptually, it is a framework which helps unknown people who may or may not trust each other carry out transactions without the involvement of a central ‘trusted’ agency or an intermediary like a Bank or a Government. Technically it means that if there are say, 10 people who do not know each other and do not trust each other, need to carry out a transaction, it can be done. How? By allowing everyone to access everyone else’s data (without disclosing the identity) and verifying every transaction that is undertaken within this group. Suggest reading ‘Blockchain in 3500 Words’[1] for the easiest explanation on how Blockchain works.

Nodes: Nodes are these 10 people who want to transact among themselves. As we will see during the course of this write-up, there can be nodes who are primarily there to validate and not participate in the transaction itself.

Consensus: Consensus is a process by which these nodes agree that the transaction taking place is valid.

Coloured Coins: The Bitcoin phenomenon is what brought Blockchains to the forefront and established it as a credible transaction framework. Once the framework was well established, everyone woke up to the multitude of possibilities of using Blockchain for other scenarios, for example: share allocations, banking settlements, land and property transactions and so on. In effect instead of just bitcoins, we now had other real world items associated with and being transacted. These real world items are known as colored coins.

Smart Contract: Instead of straight end to end transactions on a Blockchain, business logic can be built into it. For example, if A buys something from B, we can build a business logic whereby ‘once the good is delivered to A, pay X amount from A to B’; and this happens automatically without any intervention.

Double Spend / 51%: One of the most popular theoretical fraud that can occur on a Blockchain network. However, it completely depends on the Blockchain algorithm and its complexity if such frauds will be allowed to occur and the probability of them ever taking place. For example, in a Bitcoin scenario, with its Proof of Work consensus algorithm, such a fraud can be conducted.

Private Key: Since everyone on a Blockchain network stays anonymous and the Blockchain itself is supposed to stay secure, the only way to ensure that no one can carry out fraudulent transactions is by enabling the participants hold the key that guarantees that the transaction being initiated is by them and no one else. In effect, helping the other nodes to trust the initiation of the transaction.

Public Key: This is derived from a user’s Private Key. Here’s the fun part – this is a one-way ticket. You can derive the Public Key from a Private Key but not vice versa. This is how Blockchains remain secure.

Example of Keys: Think of Bank Account Number as Public Keys. You provide your bank account number to someone when you need them to send money to you. But the other person can never know how much you have in your bank account and they cannot initiate a transaction to withdraw money from your bank account. Only you can do that using your Password (on internet banking) or Signature (in traditional banking). So, in effect, your Account Number is your public key, and your Password/Signature is your private key.

In all fairness, it is a bit more complicated than that involving stages of encryption, decryption, hashing and cryptography but let us keep that aside for now.

Current Applications of Blockchain

Governments and private sector entities across the world are trying to modify and use the Blockchain technology for use cases specific to their needs. A few such examples are given below.


Bitcoin, Ethereum, Litecoin, Dash etc. are cryptocurrencies. Bitcoin was the first cryptocurrency and is a type of digital asset used as a medium of exchange. Think of it as money that is democratically managed by users the world over with no Central Bank or Government controlling it. Of the various cryptocurrencies, Bitcoin is also the most famous one, and arguably the reason why we are talking about Blockchain today.

Several Governments including India are planning to introduce their own Cryptocurrency ‘Lakshmi’[2] (Goddess of Wealth), under regulation of India’s central banking authority RBI (Reserve Bank of India). The genesis of cryptocurrency is ‘deregulation’ so we will have to wait and see how it all plays out.


Several Blockchain related programs and projects have been initiated by Governments all over the world[3]. Some notable examples are as follows:

  • Singapore is slowly embedding Blockchain into a lot of key areas[4] including Financial Sector. The Monetary Authority of Singapore (MAS) has undertaken an initiative to digitise the country’s currency (SGD) using Blockchain. Post successful proof of concept (POC) for interbank payments using Blockchain MAS is now looking at using Blockchain for cross border payments in order to make it easy and more economical. The Singapore Government has also undertaken a proof of concept to use Blockchain for trade finance, in order to reduce frauds.
  • Estonia has been testing Blockchain since 2008[5] and has operationalised its usage since 2012 in areas such as national health, judicial, legislative, security and commercial code systems.
  • Dubai has announced a plan whereby all the Government documents will be secured on a Blockchain by 2020.
  • Georgia is using Blockchain for land registry and validation of property related Government transactions.
  • State of Delaware in US is using Blockchain to store contracts and other corporate data on distributed ledger.

Financial Services

Of all the sectors, Financial Services is perhaps going to be the most impacted, primarily since the most expansive current usage of Blockchain (cryptocurrencies) is a direct challenge to the entire banking system. However, finally having realized its potential

  • NASDAQ conducted its first Blockchain based share transaction in December of 2015[6].
  • UBS is leading a 6 Bank consortium to create a digital cash system that would allow financial markets to make payments and settle transactions via Blockchain technology[7].
  • In India, banks such as ICICI, Axis Bank Ltd. and Kotak Mahindra Bank Ltd. have conducted pilot transactions using Blockchain[8].

There are several such use cases[9] being discussed across sectors and the ones mentioned above are a small and representative subset. What is important to note that it may not have been ‘necessary’ to use it. In a lot of scenarios where Blockchain is being used, the current usage is no more than what can be easily and simplistically achieved by using shared & replicated databases. However, that is a different topic of discussion and we will keep it out of scope of this write-up.

The Government Context

‘Government’ here is used in a broad sense and includes Public Sector undertakings.

In the context of Blockchain, as far as ‘intermediaries’ go, there is no bigger intermediary than the Government. And since dis-intermediation is the primary purpose of Blockchain, does it mean that use cases of Blockchain for Government will primarily focus on removing Government as the ‘central authority’ and a ‘single repository’ of a citizen’s trust and information? The answer to that question is both – Yes and No. It all depends on the context.

Context 1: Ease of transaction and accuracy of data

For this scenario, let us imagine a Government that is efficient, corruption free and trustworthy. In that case, the Government being the primary ‘trust keeper’ shouldn’t be an issue. However, with the availability of a framework such as Blockchain, it will help the Governments ensure ease of transaction and data accuracy, for perpetuity. For example, registering a property could need interaction with 8–10 departments, whereas with Blockchain, all it will requires is a Private Key.

Context 2: Systemic Inefficiencies in Government & Public Undertakings

In this scenario, just like the previous one, the Government still acts as the center of ‘trust’ for the country and the citizens have no option but to accept the word of the Government as true. However given the context, one can imagine the various pitfalls of such a system.

  • Unreliability of data accuracy
  • Potential fraud and corruption
  • Users getting duped with no recourse to recover their stakes (sounds eerily like immutability of Blockchain, however in a bad sense)

For example, let us say you want to buy a plot of land, and you get the information that Mr. X is the owner of this land. In the background, Mr. Y is the actual owner of this land and Mr. X bribed a Government official to change the title of this land to his name. Now you as a customer will pay Mr. X to the tune of what is owed. However, later Mr. Y stakes claim on this title. How would you know whether Mr. X or Mr. Y is the true title holder for the plot of land in question? Especially since both will have valid documents of ownership.

Context 3: Government as a user

This is a peculiar case which is shrouded in mystery as far as citizens are concerned. Governments across the world handle trillions of dollars every year – collecting taxes, investing in infrastructure, procuring items ranging from a coffee machine to fighter jets and so on. It is not uncommon to hear about bribery allegations in such scenarios, for example tilting the contract in someone’s favour or money earmarked for infrastructure or public welfare disappearing along the way, lining up the pockets of middlemen.

So, the obvious question is – is Blockchain the answer to these scenarios? The answer is ‘to a large extent’.


The Complexities

Nothing about India is simple. It is a vast country, 6th largest by area and 2nd largest by population, soon to be 1st. One Central Government, 29 State Governments and close to 100 medium to large public sector undertakings.

Centralized handling is undertaken for most citizen data and services, either at the State or Central Government level; moreover, a large part of citizen services and State level services are managed by the respective States i.e. the structure (IT and Processes) is vastly federated, and hence more complex.

  • Multiple processes and departmental touch points for the simplest of tasks;
  • Citizen is blind to what happens behind the scenes, who uses the citizen data, how and when;
  • For a specific Citizen service, unless the process is programmed to send alerts to the citizens, most are not aware of which stage the process is in;
  • In case of mistakes or fraud, it is difficult if not impossible to track down the perpetrator;
  • When defrauded, the citizen has a recourse via judiciary, however, such interventions run for extended periods of time, especially in cases of high-value assets.

These indicate that not only India is vast, it is complex from an IT and process perspective as well. So even while the wheels keep turning, it is largely inefficient, time-consuming and most importantly not necessarily transparent, and hence prone to gaming and fraud.

Having said that, there have been various efforts at automation, streamlining and centralization of processes by subsequent Governments.

Some of the significant achievements have been the automation of Passport department and more recently the massive drive to provide a Unique Id to every resident in India (the UID or ‘Aadhaar’ project), which includes capturing every resident’s biometrics data. This has resulted in Aadhaar being the world’s largest biometrics database covering over 99% of India’s 1.3 Billion population.

On the financial front, the introduction of UPI (Unified Payments Interface) is also starting to see wide adoption across citizens, eCommerce, wallet providers as well as private businesses and banks.

The important point to note about UID or UPI platforms are that they are open to be used by Government agencies, private and public sector alike, which helps in providing a common platform to service Citizens, which in turn helps in simplifying some of the complexities we touched upon earlier.

Digital India initiative by the Government is another important step that needs to be understood in this context. Looking at the wide adoption of mobile and broadband across age groups and social classes, Government is trying to bridge the geographical vastness with virtual connectivity by laying optic fibre across the length and breadth of the country ensuring it reaches even the remotest villages in India. This is just one major initiative of Digital India. Several other small and large initiatives are planned, including

  • Broadband highways
  • Mobility for all
  • Rural internet mission
  • Automation of certain other processes/workflows as a part of * National e-Governance Plan
  • Crowdsourcing of ideas through dialogue with citizens via mobile apps

So if Government is automating everything or at least trying to, in order to speed up servicing and bring down the efficiencies, what is the problem and why do we need something like a Blockchain?

The Need for Pan-India Government Blockchain Network

Even while Government automates the processes, a lot of underlying aspects haven’t changed.

Paper Trail: All Government dealings are on paper. Paper that can be lost, burnt, torn or just manipulated. Even if there is automation in a certain process, there is still paper at the end of it. Issue here is Information Security & Sanctity.

No control over citizen data, by citizens: Once a citizen declares their personal information to the Government as a part of any dealing, the citizen has no idea who else gets access to the data, how is it going to be used, when and where. Governments do not have a ‘Our Privacy Policy’ page. And lack of any specific policy or guideline around this issue has made it worse, except for a recent supreme court judgment upholding ‘Right to Privacy’ as a fundamental right although not in an absolute sense. Issue here is Privacy.

Citizen transaction with Government: This is an endless pit. Everything from birth to death requires citizens to transact with Government and get their ‘stamp’ to prove their entire lifecycle: birth, age, degrees, taxes, property titles, vehicle titles, license, passport, marriage, children, business holdings and so on until death. The fact that so many ‘fakes’[10] exist in almost each of these categories, including birth and death, no less, is enough reason to know that the system needs a massive overhaul. Issue here is Trust & Bureaucracy.

To summarize, the three issues that remain despite automation are,

  • Information Security and Sanctity
  • Privacy
  • Trust and Bureaucracy

Hence the question to ask is, if Blockchain has answers to these issues. And the answer again is Yes. By design.

Blockchain as we know it, has weathered ups and downs over the last 9 years, proving its platform worthiness; it has also shows that by design, the platform can handle the three primary issues mentioned here. Hence the only question now remains is that of Use Cases and Execution. Which is what we talk about next.

Blockchain Use Cases for Government of India

We have previously looked at how various Governments across the world have adopted Blockchain or are in the process to. In India the situation isn’t very different as far as use cases go but will likely be fairly different as far as execution is concerned, due to the structure and complexity involved.

Use Case 1 (UC1): Indisputable Citizen Identity

This must be the basis of Blockchain’s applicability for any Government. About India, it may be surprising, yet true that there is no one ‘truth’ by the way of which a citizen can prove that he or she is a citizen of India. Also, let us be clear, there are two issues here – one, identity of the person i.e. Mr. Anil Gupta is Mr. Anil Gupta and two, that Mr. Anil Gupta is a citizen of India.

While Aadhaar, Passport, Birth Certificate etc., standalone or in combination may be able to prove the ‘identity’ of a person, they are singularly still not enough to prove a person’s citizenship in India.

A Blockchain that can store the data of the person starting right from his Birth and continuing through all stages of his life can be a solution to this problem – each stage gets added to the person’s block and is locked until the next stage where new information gets validated, stored and locked. And once linked with Aadhaar as an identifier (which now covers over 99 of Indian residents), we can have not just a Unique Id for the person, but also a single source of ‘truth’ for the person’s residential Status. Additionally, the nature of Blockchain will ensure that this data cannot be altered or played around with.

The system can have options for people who may not be born in India and attain citizenship or resident status later in their lives or those who are in India on work visas, where their previous data can be verified and introduced in the Blockchain and new data can be added going forward.

It doesn’t stop there. The private key to this Blockchain should be nothing other the person’s biometrics – finger prints or iris scans or maybe both, for added security.

Imagine a person lands on Indian shores with a duplicate identity (hypothetically for causing trouble), claiming he has never stepped foot in the country before. At the airport itself, his Blockchain based data can be pulled up using his fingerprints. If the records show nothing, he is clean but if he is not, he is immediately caught and action can be taken accordingly.

What this basically means is that with this setup, any person who is a resident of India or who has ever stepped foot in the country at any point in their lived will have their entire history stored in the Blockchain network. And that will be the only source of truth.

I can’t start imagining the usefulness of having a single source of ‘truth’ for each person in the country. Confirming identity, availing benefits, transacting with Government or otherwise, providing authentication in any context, academic history, work history, voting rights, driving license and so on, everything will be just one step away.

And with the right technology in each person’s hands, we might not even need the person to visit a Government office to accomplish the abovementioned tasks. More on that in the Citizen Services Section.

Use Case 2 (UC2): Citizen Services & Transactions

Once UC1 is sorted, the rest becomes straightforward, including the oft discussed topic of Citizen Services in the context of smart countries and smart cities.

Instead of pontificating on this point, let me try and narrate this use case through an example.

Example: Driving License

Current process to obtain a driving license includes the following steps, give or take,

  • Fill in the application form (offline or online, though most States have now made it mandatory to fill the form online)
  • Upload documents for identity and address proof
  • Take a print of the documents for manual verification
  • Make payment, online or at the Regional Transport Office – RTO (like DMV in the US)
  • Take the driving test
  • Once status is updated, citizen is notified
  • License is couriered within 2–3 weeks

First question. Is this process fool-proof? Not at all. There are manual interventions throughout; the database can be altered from the back-end, and the documentary evidence can be very easily faked. Add to that bribery and corruption.

In addition to that, this entire process can take anything between 2 weeks to 2 months.

With Blockchain, and UC1 implemented, the process will look somewhat like this,

  • Citizen selects the service required on the website or a mobile app (new license, license extension, duplicate license etc.) and provides his public key (for a minute let us assume it is the Aadhaar Number) and sets up an appointment for the driving test.
  • On the said date, prior to the test, the citizen’s Private Key (Biometrics) are validated. No documents need to be submitted.
  • If the citizen checks out, he undertakes the test; immediately after the test, the inspector confirms whether he has passed/failed.
  • If he has passed, he is asked to go to a specific counter/kiosk machine, authenticate with his biometrics and collect his License Smart Card.

At the back-end, the new License data is added to the Citizen records and the chain is locked.

Time spent in this entire process: 2-3 mins to set the appointment online and 1–2 hours for the test and license collection. No paper trail, no document submission, verification, signatures. Nothing!

And in this example, one had to physically go for taking the test. Imagine a scenario for a passport application or license ‘renewal’. If the mobile companies and Government can work out standards for the fingerprint scanner and facial recognition on phones or mobile device, all a citizen would need to do is provide the authentication on their own mobile devices and request for Passport or renewal of driving license. And that too when he is issuing the Passport for the first time (since all his information is in the system anyway). Passport & license renewal should happen automatically, even without citizen intervention, since the system knows when the passport or license is about to expire.

Requesting for passports or other IDs would become as simple as ordering a check-book is today, since with a standardized biometric authentication (as the Private Key) and the citizen’s life history on the Blockchain, no other document or authentication would be necessary.

Afternote: While this example concerns just License, at a higher level I believe we dont even need so many ID cards (Aadhaar, License, PAN, Voters ID). If UC1 is implemented, we will just have one single card that will bear all the required information about us (until a time comes and we won’t even need that; probably carry our IDs on our mobile or literally in our ‘eyes’).

Use Case 3 (UC3): Title Ownership

This is probably the most favorite Use Case for most proponents of Blockchain for Government, and the reason is easy to see. Because worldwide it is the most disputed.

Real estate title ownership is in a mess, and not just in developing countries. Even organized and large institutions like Bank of America have made mistakes and have gone about foreclosing properties during the 2008 crisis that they never had mortgaged in the first place. That’s how bad it is. What would you do if your house was wrongly foreclosed? Or if someone suddenly appears at your doorstep and claims the house to be theirs with all the documentary evidence in place (bribery, forgery, fraud). And the more rural the area is, things get even murkier with land grabbers staking claim on land parcels with monetary or muscle power. Think about a corporate entity trying to buy land in a remote area in India. They find the land, like it and want to buy it. But? There is no clear owner; there are three parties who stake claim to it, and whats more, Government claims it is State’s land. Matters ends up in court and it just drags on. Because there is no clear evidence favoring or against any interested party.

You get the problem.

But here’s the biggest problem of it all. Given how deep this rabbit hole goes, it will take all the willpower that the Government can muster to get the house in order. And once it does, it would never want to get into this mess again.

That is where Blockchain comes in. Post the clean up, maintain it that way. Give the confidence to citizens that their title will be protected, for all the time to come. All the land and real estate title data will be public, protected and will have data sanctity.

We have focused here on land & real estate but the same is true for any high-value item that the citizen owns. Vehicles, jewelry, businesses and so on. But they are much easier to handle as compared to cleaning up land titles.

Pilots in India have already begun in two states.

Use Case 4 (UC4): Government Procurement

Government Procurement is another murky area; not by definition but by the various scandals that have occurred in the past. I am using the ‘Procurement’ term in a loose sense here and it includes all high-value transactions where Government gets involved either with another federal Government or Private agencies.

Government procurment process consists of broadly two parts:

  1. Tendering & Selection
  2. Supply of Goods and Payment

Tendering & Selection

Central Government and a majority of the State Governments now follow e-tendering or e-procurement process. Besides automation, one primary driver for such an initiative is to try and avoid instances of nepotism, fraud, conflict of interest, bribery etc. During the tendering process, there are multiple stages where such acts could occur and which are susceptible to manipulation:

  • Setting out the bid qualification criteria for the bidders. Criteria could be singularly manipulated by an interested member of the panel to favor a bidder.
  • Submission of financial bids. If financial bids are not sealed, they may be leaked to other players or panel members, and enable potential gaming of the marking system.

In each of these cases, even with Blockchain, it might not be possible to avoid this very human behavior, however where Blockchain will come handly is in keeping a track record of every single information change, including the timestamp and name of the person who did it. The current CVC (Central Vigilance Committee) guidelines have definitely helped improve things in this regard however in most cases it is difficult if not impossible to unearth a wrongdoing as well as pin-point the person who did it.

Example: Say criteria A, B and C have been laid out as qualification criteria for a certain tender. Post discussion with bidders, criteria B & C are modified and tender goes through. Assuming there are 5 panel members for criteria selection, the criteria change will be initiated by one of the members and validated by the others. Now, if during an audit, it comes to note that a specific change in the criteria was never requested by the bidders and yet the change was actioned (possibly back-chanelled), it will be very easy to pin-point the exact panel member who initiated this specific change.

Similarly for financial bids, once they are submitted on a Blockchain, with only the nodes having access to it, it will be much easier to track potential leakage, if the scoring on other parameters seem gamed.

Supply of Goods & Payment

Securing payment from Government or Public Sector entities are a common issue – sometimes intentional and sometimes just bureaucratic delay. It is frustrating for the suppliers to keep on waiting for their payments especially after the goods have been delivered.

Blockchain can definitely help here with what is known as Smart Contracts. These are logic built into the Blockchain, which get triggered based on an event.

Example: Government decides to procure 1000 iPads for its staff. A Smart Contract can be coded on the Blockchain whereby,

  • Once Goods arrive at the destination, are checked by the concerned department and are tagged as ‘accepted’,
  • a transaction is automatically executed whereby the said amount is transferred from a pre-determined Government account to the supplier

And Smart Contracts can even be coded for exceptions including penalties. So if, for whatever reason, the pre-determined Government account doesn’t have enough money, automatic interest rate will be charged and back-up accounts will be looked up. On the other hand, the Contract can also hold that if any of the product turns out having a ‘manufacturing’ defect within 30 days of purchase, 1% of the product price will be refunded to the Government and product will be replaced. All the background work for the execution of the Smart Contract is done before hand and hence it might completely mitigate the need to have intermediaries like lawyers to ‘enforce’ this contract. Once coded, the Smart Contracts execute automatically.

Use Case 5 (UC5): Governance

Governance here relates to inter departmental dealings within the Government. In this case, the purpose of using Blockchain will be factors beyond just trust and transparency.

  • Chained Storage: Keeping complete records of Government files and dealings with all the required details and timestamps right from their inception until this moment. Policies, amendments, interdepartmental dealings, project approvals and so on. Replacing volumes of paper filing, Blockchain will serve as a trustworthy record-keeping medium.
  • Security: Inherent nature of Blockchain, with a distributed database, while at the same time having just ‘one’ version of the truth, will ensure that all the information stored stays secure.
  • Referenceable: Easily referenceable open and public data, hence potentially replacing the need for RTI (Right to Information) queries, with non-confidential information available on the go.

I believe these five Use Cases taken together would be the most imminent ones that Government of India, or for that matter most Governments should look into. They will have a deep impact all the way from Governance to Citizen Services.

Building Blocks for a Country Level Blockchain

Blockchain Fabric

Experimentation on different architectures of Blockchain is still underway. Some of the more popular ones today are Multichain, Ethereum, Hyperledger, Chain, Hydrachain, Open Chain etc. So which one should be selected?

Blockchain networks have expanded beyond the public, immutable network that runs Bitcoins. Let us examine the key characteristics of the blockBelow are the key characteristics of the Blockchain network,

  • Type of Network: There are three types of Blockchain networks – Public, Private and Permissioned. Government Blockchains will need to be permissioned; this is because all the nodes will be named and tracked since anonymity is not a requirement, only authorized nodes will be able to view the data and all validations will be done only by entrusted entities or individuals.
  • Mutability vs. Immutability: Immutability will be paramount; any mistake or erroneous entry will need to be corrected or reversed through validation further down the chain. No back-ended or back-dated data manipulation can be allowed.
  • Cost: Cost, while important will not play a major role in selection of Blockchain fabric for the country.
  • Technical Specifications: Such as (programming) languages supported will play a minor role in selection of the Government Blockchain.

Hence as per the current development status of Blockchain, Government of India should ideally implement a Blockchain fabric that is Permissible & Immutable. Low Cost and programming language support will be good to have, but should not be the driving factor.

Blockchain Network

Pan-country Blockchain will/should ideally be on a single fabric type. This is preferable to each State developing their own Blockchain fabric. Since this Blockchain network will need to fulfill multiple use cases that span Central as well as State Governments, interoperability in terms of data flow and communication is highly desirable. Hence a common fabric with multiple use-case specific Blockchains emanating out of it will be the ideal set-up. Something like what is shown below:

Core BharatChain Network:

‘C’ is the primary node of the Central Government of India, while S1, S2, S3 and S4… all the way upto S29 will be the Primary Nodes of the 29 respective State Governments. These nodes form the Primary Blockchain of the Country – The Core BharatChain Network (CBCN). CBCN will be used for use-cases that are pan-country such as Citizen Identity (Birth, Death, Passport, PAN Card, License, Education Records etc.), Tax, Business Registrations, Direct Benefit Transfer Records for Public Schemes and so on.

Multiple Blockchains across Primary Nodes & Sub-Nodes:

The way the pan-India Blockchain network will work is as follows:

  • Primary Nodes at the Center and State Government Levels will have further sub-nodes in the respective ecosystems for pre-defined use cases. For example ‘C’ Node at the Central Government will have further sub-nodes such as CN1, CN2, CN3… CN’X’ where X will depend upon the number of participants in the ecosystem. CN1 node could be the Ministry of Home, CN2 could be Ministry of Education and so on.
  • In various combinations, these Sub-Nodes will form Blockchains (one or more depending upon the number of Use Cases) amongst themselves, but with ‘C’ always as one of the Nodes. In the figure CBN1 is one such Blockchain. There could be others such as CBN2, CBN3 and so on.
  • Similarly, at the State Government level, the Primary Node S1, S2, S3 etc. along with their respective Sub-Nodes will form multiple Blockchains. One such Blockchain for each State is shown in the figure (S1BN1, S2BN1, S3BN1 and S4BN1). State 1 for example will have more Blockchains such as S1BN2, S2BN3 (shown in figure) until S2BN’X’ where X is the number of Use Cases for that State. In an ideal scenario, each State should have similar number of such Blockchains.


Now that we have a Primary Blockchain, and Secondary (or Child) Blockchains, each consisting of data that may be needed across the other Blockchains, we need a way to share this data.

Please note that all the Nodes are not on a single Blockchain, for example Node S1N1 and CN1 do not share a Blockchain Network and hence if the Blockchain CBN1 needs any data from Blockchain S1BN1, it won’t be possible using the Blockchain network.

So how do we share data between Blockchains?

Option 1: Sharing via a centralized database

Blockchain 1 –> Centralized Database –> Blockchain 2

In this method, we would create a common database which can be coded into the Blockchain algorithm to be used for any data information or validation purposes.

But, this method defeats the entire purpose of creating the Blockchains in the first place since on the one hand, the data again gets centralized and two, it moves out of the secure Blockchain network, hence prone to hacking or theft.

Option 2: Sharing using the Sidechain Concept

Sidechains[11] technology, which is still under development can conceptually allow specific data or assets to be transferred from one Blockchain to the other and back (2-way peg), hence allowing for interoperability across the core and ancillary BharatChain networks In actuality, the ‘transfer’ is creation of equivalent assets on the secondary Blockchain based on pre-defined rules. Sidechains in their current form may not satisfy the various use cases of BharatChain, since the data/assets will not be limited just to currencies, and hence ‘equivalent’ assets will need to be suitably defined.

In an unlikely scenario where a certain State decides to have its own version of Blockchain fabric, Sidechains technology can still ensure that the Core Blockchain is interoperable with it.

For example, the ‘Title Ownership’ Blockchain could be at a State Level and used by Urban Local Bodies along with other State level nodes including the Citizen, and it might be needed by the ‘Tax’ Blockchain at the Central Government Level since Property ownership declarations are required during Tax filing. Using the Sidechain, such information can be safely passed on from the State Level Blockchain to the Core BharatChain Network and on to Tax Blockchain at the Central Government Level. Extending this use case for Sidechain, a Citizen could own multiple properties and business across different States in India and all this data might be captured and maintained in different State Level Blockchains. Using the Sidechain, the Core Blockchain can access and act on all this data without impacting the veracity of the data itself. And for such time that the data is in use, the original ‘truth’ version of this data in the State Level Blockchain is locked so that no changes can be introduced until this data is ‘returned’ to the original Blockchains.

End Users

For the end users – whether Citizens or Government Officials, these complex Blockchain networks will be invisible since their interface will be through application layers; while at the same time, in the back-end the Blockchain network will allow for data to be kept safe and secure.

Data & Privacy Control

A very important benefit of Blockchain is that the Citizens will be acutely aware of when, where, who and how was their data used. In fact, a system can be devised whereby citizen data can be used only once the individual confirms it using their Private Key.

This mix of validated and controlled data, security and immutability will provide a very high level of efficiency, ease of use and surety to the citizens and administration alike.

The Ledger & Storage

Since Blockchain is essentially distributed ledger, it will need to be determined how the Storage for the same will be undertaken.

The factors that will determine the storage mechanism for the Blockchain database are,

  1. Replication Factor: Dependent upon the number of validating nodes
  2. Transaction Volume: Expected growth in the next X number of years
  3. Intercluster Communication Latency: Speed of communication between the data centers

Assuming replication factor of 6, it would obviously not make sense to keep all the 6 versions within one single Data Center (DC). However most States in India already have their own SDCs (State Data Centers), in addition to the Data Center at the Central Government level. So depending upon the replication factor, a specific Blockchain will be replicated across the State and Central DCs, irrespective of whether the specific Blockchain is for a State level process or Center level process. The Data Centers can be chosen based on proximity or keeping the DR statutes in mind. However it will be very important to establish a communication network that ensures lowest possible latency between these storage sites.

For Example, the Citizen Id Blockchain will be stored at Data Centers available with Central Government as well as across 5 other State Data Centers. Similarly a State Specific procurement Blockchain will be stored within that State Data Center as well as 5 other States Data Centers.

For oversight and neutrality, one or multiple interested Private sector entities could also be authorized to store specific Blockchains, in addition to the SDCs.

For example, in the case of Procurement, a consortium of legal entities could be authorized by the Government to act as an authorized node for Smart Contracts, and hence should ideally store a version of the Blockchain.


As we have determined that the Government Blockchain will be a permissioned system, it means Nodes will be assigned rather than keeping it open for all. Bitcoin and Ethereum type of networks have a different use case, where the primary actor is the Bitcoin itself, which is visible to all, but the users (nodes) are anonymous; besides anyone and everyone can become a node. In Government, that cannot be the case.

For example, for the Citizen Id Blockchain, the nodes will be various,

  • The Citizen
  • UIDAI (for Aadhaar)
  • Health Department (Birth and Death Certificates)
  • Education Department (Education Certificates)
  • External Affairs (Passport)
  • Tax Department (PAN Card)
  • Election Commission of India (Voter Id)
  • Home Affairs (Criminal History)
  • Motor Vehicles Department (License)
  • Urban Local Bodies (Title Ownership, Residence)

and so on.

Here the Education Department in turn will have their own Blockchain with all the Schools and Universities across India acting as Nodes where data regarding a citizen’s education will be stored. Same is the case with Health Department who will have Regional Health Centres as well as Hospitals on its own Blockchain.

So will all of these Nodes have full access to write, read and validate data? No.

Nodes in this permissioned network will be of the following types:

  1. RWV Access: Read, Write and Validate e.g. Govt. Authorities
  2. RW Access: Read and Write but not validate e.g. Schools, Hospitals for their respective Blockchains
  3. R Only Access: Read only e.g. Citizens
  4. V Only Access: Validate only e.g. Government Authorities, School Federations, Universities, Legal Consortiums, Independent Third Party Validators and so on.

Even within these node types, in certain cases, access will be limited or controlled. For example, while every school will have RW access, they will have it only for the data pertaining to their school matched based on their School’s public key.

Consensus Mechanism

This is the mechanism based on which a new data or transaction introduced into the block is validated before it is locked into the Blockchain.

Bitcoin Blockchain network works on ‘Proof of Work’ consensus where anyone can become a node and provide proof of work to validate a block in the chain – a process known as mining. It needs enormous computing power and it is incentivised i.e. every node that successfully mines a block is given a certain number of Bitcoins.

It is easy to see why that won’t work for Governments.

Besides Proof of Work, there are various other Consensus mechanisms that have been devised viz. Proof of Stake, Proof of Activity, Proof of Capacity, Proof of Burn, PBFT and so on. Most of them, even while varying in the exact process, aren’t too different from Proof of Work, except PBFT (Practical Byzantine Fault Tolerance).

PBFT[12] primarily relies on consensus among ‘as many nodes’ as possible. And once the decided number or percentage of nodes have validated a transaction, it is accepted into the Blockchain. The reliability of PBFT increases with the number of nodes, however for Government, since it will be a permissioned network, the number of nodes cannot increase limitlessly. Hence a derivative of this consensus mechanism will need to be established.

A few consideration factors while determining the consensus mechanism for the Government:

  • Pre-decided nodes: Number of nodes on every Blockchain will be pre-decided, and hence limited; a leader node could be designated depending upon the use case of the Blockchain;
  • No incentives: There won’t be any incentive to validating a transaction, however there could be penalties to not validating a transaction within a pre-decided timeframe;
  • Criticality based consensus: Based on the criticality of the transaction on the Blockchain, different consensus mechanisms could be selected; for example, assuming there are 10 nodes to a said transaction. For a critical transaction, the algorithm could require validation from all 10 nodes; for a sub-critical transaction, validation could be required from 6 nodes including a designated ‘leader node’; and for non-critical transactions, a simple majority of 6 nodes without the ‘leader node’ validation will work.
  • Fail-safe mechanism: Algorithms need to be built in that can quickly point out any malicious play among a group of nodes or if a specific node is intentionally misbehaving;
  • Fault tolerance: This is crucial; one bad node, or an error on part of a node should not be able to take down the network;
  • Fast & Scalable: Transaction rate (per second) needs to be high and scalable.

Just like the rest of Blockchain, consensus mechanisms are also undergoing an evolution of sorts as stakeholders globally try to derive mechanisms that fulfil their requirement and it won’t be any different for the Government of India.

Private Keys

This is a very important aspect – probably most important since this literally holds the ‘key’ to locking in the user’s data safely in a Blockchain.

Private Keys for Government

Private Key belonging to a Government entity or an individual authority will need to have the following characteristics.

  • Should not be in a soft format that can be copied and potentially transferred;
  • Should not be visible to anyone;
  • Should be derived and used within the authorized systems with no way to possibly hack it.

Storage of these Private Keys will also be very important given the critical data contained in these Blockchain networks.

Private keys can be stored in multiple formats[13], and below is a quick overview of the most common ones:

  • OS or Browser based Key Stores: Most familiar in our daily use, it is built into Operating Systems and Browsers. Windows Certificate Store, iOS Keychain etc. are a couple of examples. Very user friendly but easily accessed and invoked, hence prone to hacking and circumvention.
  • File based Key Stores: These are files in .pfx and .jks formats which can be stored anywhere including on a hardware (flash or thumb drives). However, these are easily distributable and can be easily copied and stolen.
  • Cryptographic Tokens and Smart Cards: Stored on a single hardware that is cryptographic and needs a password to work. Safe option but not all devices may have the facility to use such cards.
  • Hardware Security Modules (HSM): Another version of cryptographic hardware based option for key storage. Now available in cloud modules and works via APIs. Hence can potentially be implemented on Government Cloud (G-Cloud).
  • Trusted Platform Modules (TPM): TPM used a method by which each device has its own Private Key that cannot be exported, copied or destroyed since it is stored securely in the chip itself. In the case of Government, this may have an application in case of Smart Properties[14], but not in the case of authentication mechanism involving individuals.
  • Physically Unclonable Functions (PUF): This is similar to the TPM in a sense that it is device specific. The key derivation is based on the unique physical properties of a chip’s SRAM memory. The unique property here is that the key is generated every time the device is powered up instead of being stored. Like TPM, PUF too will find greater applicability in Smart Properties rather than individuals.

To fulfil the Private Key characteristic for the Government mentioned previously, the only viable option is to store the Government User’s private keys on a hardware module; this could be one of the options mentioned above such as Cryptographic Tokens, Smartcards or HSM, or some derivative thereof.

Private Keys for Citizens

In the case of Citizens, given the sensitivity surrounding their data, the system will need to rely on a mechanism whereby every citizen is able to keep their Private Key safe. With a population of 1.3 Billion and growing, that’s a tough ask.

So, the Private Key for Citizens should be such that,

  • Can be kept safe always
  • Cannot be stolen
  • Cannot be replicated
  • Can be remembered/produced when needed

A password/passcode based Private Key is an option, but looking at the research on most common passwords[15], will probably be a very bad option. Hackers won’t even have to try hard.

I believe that the best possible Private Key option for any citizen will be none other than their Biometrics. It could be their fingerprints or IRIS scan or both taken together and hashed in real time. To make the Private Key even stronger, the hash can be further encrypted using a passcode that every citizen will need to remember.

This will provide a 3-way authentication for every citizen and even if someone gets hold of their passcode, it will be useless without their IRIS scan and fingerprint.

Even without the passcode, the idea is that while it is great to trust every citizen to keep their Private Key safe, yet given the stakes at hand, it might not be the most practical proposition and will risk identity theft of the gravest kind. Hence it is best to have a Private Key that is with them at all times (Biometrics) and yet they do not have a burden of keeping it from being stolen; coz having the Private Key of a Citizen stolen will potentially create a mess that will be very difficult to contain in the era of immutability that Blockchain will unleash.


Over the past couple of years, Businesses and Governments alike have realised the potential of Blockchain and have moved to embrace it rather than fight it. While the technology, framework and the supporting ecosystem is in a rapid development phase, it is becoming evident that a single Blockchain solution will not be able to satisfy all stakeholder requirements and use cases.

India has itself grown rapidly over the past two decades and even while a lot of initiatives are underway to rein in the complexities arising out of growth, the time is right to take a revolutionary leap rather than tread along at an incremental pace.

Implementation in Mission Mode

Aadhaar, the national UID program, was wildly successful in terms of timelines given the enormity of the task. Reaching out to 1.3 Billion citizens is no mean task and yet it was done in record time. A very important factor contributing to its success was that the entire implementation of UID project was done by a special authority led by a technocrat, with best technical minds at their disposal and Government putting its weight behind the authority in terms of funding and timely interventions, to ensure that it never hit a roadblock.

We need a similar level of Government commitment if BharatChain has to become a reality.

Even while Blockchain implementation does not need to reach out to each and every citizen, it will be as complex as the UID project on account of the following:

  • A substantial number of Government processes will undergo fundamental changes;
  • Massive training effort will be required to ensure that those managing and using Blockchain based applications are able to do so effectively (since mistakes are irreversible);
  • Immense coordination effort will be required to intelligently integrate the vastly disparate IT landscape across the Central Government and 29 State Governments;
  • Standards will need to be defined with respect to authentication, consensus, Key management so that Government & Private players (Schools, Hospitals, Businesses etc.) can seamlessly participate as Nodes across the Blockchain network;
  • Long list and short list of use cases will need to be defined. Long list for ‘exhaustive implementation’ and shortlist for ‘immediate implementation’. So why both? Because even with immediate implementation, the architecture, fabric and network need to be built in a way that will take care of the ‘exhaustive’ implementation as well. It will be very costly if one or more important use cases in the future fail to integrate on to an existing Blockchain network.

Blockchain is still nascent and under development, but the data explosion and process complexities are not waiting for it. Step wise, this is what Government of India needs to do:

  • Form a close circle of technocrats and arrive at the first set of standards, enough to start off a bare minimum Blockchain network; it is important that this group is highly qualified and small, since a high number of stakeholders will only slow down the process;
  • Create a POC Blockchain network at the Central Government level;
  • Move a couple of simple processes onto the Blockchain network to test its robustness and at the same time allow users – both Government and Private to get used to it;
  • Start extending the Blockchain network to ‘early adopter’ States and repeat the POC process;
  • Once all the States are covered in this manner, pick up Use Case 1 since that is fundamental to most of the other use cases.
  • Follow up by implementing the other Use Cases.

Final Words

There is no doubt that Blockchain will touch almost every single aspect of our lives in a few years from now, and even while we might not necessarily see it in action, since it will be hard at work in the background, we will hopefully sleep better at night knowing that our identity is safe and our private data is secure. And we will still own the house that we live in when we wake up in the morning!


[1] The ultimate, 3500-word, plain English guide to Blockchain:












[13] Cryptographic Key Storage Options & Best Practices:

[14] Smart Property – Bitcoin Wiki:

[15] The Most Common Passwords In 2016 Are Truly Terrible:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s