Are private blockchains useful? What are concrete examples of where private blockchains make sense?


We recently had an AMA with Mohit Mamoria, who argued that he doesn’t believe in private blockchains.

He made a case against private blockchains, saying that public blockchains are like making a database public, so making it private again would essentially just make it a traditional database again.

One of our enthusiasts disagreed and said:

Blockchains are not about making a database public, it’s more about decentralizing consensus around a certain shared state. Even if the participants in the system are limited to certain specific nodes, as in a private blockchain, you can still benefit from achieving decentralized consensus between those nodes.

I’d love to hear arguments for whether private blockchains can serve a real use case, or not. If yes, what are concrete examples of where it’s useful?

For example, the argument I often hear is that a private blockchain can be useful among a consortium of companies (e.g. banks, supply chain manufacturers, etc) to reduce coordination costs by streamlining the coordination among the different parties.

Can we come up with concrete examples of this?


Really great piece by an ex-EY consultant who spent 4 years implementing private blockchains before realising they solved no business problem.

“What much of this comes down to, is the fact that you can never be half decentralized: any level of centralization will end up with the system coalescing around that central point of management.”



I read through the article, and I’m not very convinced about the author’s points.

Going with the above definition, a blockchain is typically touted as a beneficial system due to its ability to store and communicate data, with redundancy and protection from loss. The data is automatically reconciled across a large number of parties, allowing virtually instant data transfer and tracking. The data can never be changed and the data is fully transparent to prevent fraud.

Alternatively, if needed, you can encrypt the data so none of the other parties can see it. Finally, it allows you to run complex programs, perhaps even resembling legal agreements, that all parties can see and gain comfort that they will execute in a particular way.

The interesting thing here is that everything that has just been described is all achievable with a distributed database: technology that is widely used in industry, and was around for many years before bitcoin was released.

There is, however, one key difference between the two technologies that we’ve included in our definition: blockchains are specifically designed to prevent central governance.

How can a distributed database guarantee that the “data can never be changed”? How can it ensure transparency? How can it run programs and guarantee that they will execute in a particular way?

These properties are fundamental and unique to blockchains, yet the author claims that this can be achieved with distributed databases. He then makes the point that the key difference between the technologies lies in preventing central governance. This is kind of true, but in the context of what he said earlier is extremely misleading in my opinion. You simply need to fulfil that property to ensure the previous properties that he mentioned. Therefore, I fail to see the point that he makes here.

In a blockchain, every node stores all data. Every node runs every program, and every transaction is sent to everyone across the network. To make changes to a blockchain, new blockchain software would need to be created and distributed to all participants who would need to install over their current version. Each of these requirements adds a non-trivial technology and governance cost to the deployment and ongoing operation of the blockchain.

By comparison, to make changes to a database, the administrator makes the changes in the master and they instantly propagate across all nodes. Computation, also, is optimized. In a distributed database where all participants can have a copy of this data and any applications running, they would be able to monitor and review for any unauthorized changes or updates.

This is also quite misleading. From the way he describes it, I assume he is talking about forking the blockchain software (that’s the only reason why everyone would have to update their version, as far as I am aware). Saying “to make changes to a blockchain” is oddly unspecific; what does he mean by that? In terms of forks it can only mean changing the underlying protocol, which is something I don’t see should happen very often (especially in a non-public context). Also, within a consortium, I would imagine it would be a quite simple process since everyone is likely to agree on the change.

Actually, the more I read the above paragraphs the more unsure I am if I even understand what he is talking about. It makes a little more sense if he is talking about how every node in the network has to run every state changing process. However, in that case his description is just wrong. Maybe someone else can enlighten me here…

It may, therefore, be easiest to think of a blockchain as a distributed database with the ability to administer it taken away.

This statement kind of summarises the issue I have with this article. It is just not helpful at all to think of it this way. The reason is that, the very comparison between a database and a blockchain is once again very misleading and makes you miss the point of blockchains.

The value of databases are efficient handling and storage of data. The value of blockchains are decentralizing consensus regarding a certain state. By comparing blockchains to databases, and thinking that they are about storing data while looking at all the sacrifices you make by using one, then it will be difficult to see the value of it.

He then goes on about how a consortium needs to trust a central party for the development of the blockchain. I really don’t get this point either. The code is open and you can audit it, it’s the same with public blockchains. I won’t go into detail about this now since this post is getting a bit long, but I just don’t agree that it’s a valid point.

These are just my initial thoughts about it. Please correct me if I misunderstood something or if you think I am wrong!


How can a distributed database guarantee that the “data can never be changed”

Append-only databases like Uber’s schemaless are designed this way:

Saying “to make changes to a blockchain” is oddly unspecific; what does he mean by that? In terms of forks it can only mean changing the underlying protocol, which is something I don’t see should happen very often (especially in a non-public context)

Yes I would assume he means protocol change here, it would be pretty naive to assume that the protocol will never need to evolve. Making progress on the protocol when you have many distributed nodes who don’t trust one another is much harder than simply deploying a new version of the code to all machines that you control.

Also, within a consortium, I would imagine it would be a quite simple process since everyone is likely to agree on the change.

This is not a trustless system

This statement kind of summarises the issue I have with this article. It is just not helpful at all to think of it this way. The reason is that, the very comparison between a database and a blockchain is once again very misleading and makes you miss the point of blockchains.

When we are making comparisons to databases, it is purely for comparing cost difference, which will be a major factor in a business considering the adoption of blockchain applications to solve their business need.

Do you know of any examples of successful “private blockchain” implementations out in the wild today?

I’ve always thought about enterprises using the blockchain via a public ledger like the Ripple project and still don’t understand what a “private blockchain” is trying to achieve.


Append-only databases like Uber’s schemaless are designed this way:

This does not mean immutable in the blockchain-sense. If it is centrally controlled, then one player makes the rules, and has the power to change things.

Yes I would assume he means protocol change here, it would be pretty naive to assume that the protocol will never need to evolve. Making progress on the protocol when you have many distributed nodes who don’t trust one another is much harder than simply deploying a new version of the code to all machines that you control.

Sure, you could definitely argue that it would be harder. However, since the author is not really elaborating much on this, it is hard to say how significant the drawbacks are. I don’t see how it would be very significant at this point.

This is not a trustless system

Do you think the same of public blockchains, where people have to agree on changes as well? The companies within the consortium has to agree to use a blockchain together in the first place, but that doesn’t mean they have to trust each other, does it? When we talk about trust here, we are talking about who controls the state of the blockchain, simply (which no single entity does, but with a database this is not the case).

When we are making comparisons to databases, it is purely for comparing cost difference, which will be a major factor in a business considering the adoption of blockchain applications to solve their business need.

Do you know of any examples of successful “private blockchain” implementations out in the wild today?

I’ve always thought about enterprises using the blockchain via a public ledger like the Ripple project and still don’t understand what a “private blockchain” is trying to achieve.

That makes sense, but I suppose that the problem is that people are trying to use a blockchain instead of a database. That does not make much sense to me, as they have completely different use cases and one does not even exclude the other.

I don’t know of any successful private blockchain projects, but I’m the wrong person to ask about that. I’m just much more involved and interested in applications using public blockchains. Nonetheless, I don’t see how private blockchains cannot have use cases.

I don’t know much about Ripple, so I cannot comment on that.


“Actually, the more I read the above paragraphs the more unsure I am if I even understand what he is talking about.” alexmedkex

i was thinking this the entire piece

i found the reasoning in the coindesk article very flippant. i wont rehash everything alexmedkex said, i am fully onboard with the reasons why distributed consensus in a private setting could be a very desirable property. to me the crux of the debate is not whether a private blockchain has use but if this use is worth more than the cost for the specific situation. i am travelling so i dont have any evidence to add rn. i will do some research on possible areas to implement permissioned/private blockchains. though its clear (to me) that not finding a good use case currently in the market means very little and finding a good one means quite a bit. so the if they are so good where are they argument doesnt hold water with me. ie how we use falsifiability in trustories.

Heres a couple quotes I pulled from the article:

“I also believe it remains to be proven if permissioned blockchains provide a real business benefit at all. The reason I question whether there is a benefit is that I spent four years working with financial institutions who were trying to find it.”

so in 4 yrs they didn’t find a business case for permissioned blockchains? wow. at least they tried everything possible in a very mature industry. unless you could somehow prove the cost is strictly higher than the benefit this is just blowing smoke.

“A common theme, however, is they rarely define it in a way that differs from a distributed database or even more simply, Google Docs. And if it can’t be differentiated in the definition, then it shouldn’t be considered different at all.”

garbage logic. ok cool, they came up with a terrible definition. these things are similar but easily distinguishable. so I consider them different.

“institutions and individuals should be evaluating permissioned blockchains like any other technology: it isn’t magic, and it should be assessed like one would assess any other”

once again i will concede the cost is high. but you are actually getting some magic. the question is where is that magic value capture?

“Businesses conduct transactions with other entities all the time, and they establish contracts for these purposes.”

contracts introduce a lot of practical problems. my point is that you could build a more robust and self enforcing way to interact between all the entities in a consortium. a lot of times you have to spend a ton of time and money to prove a breach of contract and you don’t get even close to everything back. for example walgreens was completely duped by the fradulent Theranos. they invested 100m and even gave them a 40m loan. walgreens got back ~30m.

If all entities trust a central party to define standards and distribute updates, what is the benefit of a blockchain over a distributed database managed by the trusted central party?

rules are being set transparently. the rules must now be followed by everyone. if the rules are changed everyone would know. in the distributed database my understanding is the admin could do w/e.

“coordination is a human problem, not a technology problem.”

human problems can have tech solutions. the whole point is not to compel coordination from those who don’t want to. its to facilitate fluid coordination between willing parties.

“Consequently, additional technology is not needed, and certainly not technology that’s incredibly costly in its enforcement of that goal”

this is pretty thin. until we are operating businesses or interactions between groups of businesses literally perfect we can always try to perform better. certainly you could come up with a less absolute word. if the cost can be overcome we should try that shit.

“any forced attempts at decentralization are likely to come short”

who is going to force companies to use blockchain?


To add more value to the discussion, I’ll explain my view on how a consortium of companies might want to use a private blockchain:

If these companies need to share some data and/or transaction history, let’s say certain legal documents, then they can use a private blockchain to have a single source of truth regarding what that data is and which parties were involved. They might not even need to store the actual document, just a hash of it, which can serve as a simple proof. The data might be too sensitive and important to be handled by just one of the companies, or a third party. A private blockchain ensures a source of truth without trusting that task to one organization.

Why not use a public blockchain? Because if they don’t need the openness that it offers, then they might be better off with a private blockchain. Private blockchains are much faster and stable, run different consensus algorithms, can have private states, and so forth …


I think it could be useful in a decentralized database if all of the issues of blockchain gets resolved.

Here is what the author says: “Blockchains should be used as little as possible […] It is also worth addressing the often proposed solution of simply storing user generated data on a blockchain directly. On the spectrum of possibilities, this is by far the worst option. A blockchain is a cryptographic data structure that may be used by a decentralized application for the storage and retrieval of arbitrary data across a P2P network of untrusted nodes. However, as they exist today, blockchains are extremely inefficient and simply do not scale. Blockchains are not sharded (every node stores every record), they have very low transaction throughput, and rely on energy intensive Proof of Work (PoW) consensus, making them prone to centralization. Once written, data cannot be removed or changed, and the cost of writing that data is hideously expensive. While there are many proposed solutions to these problems, as of yet none of them have been demonstrated in a production setting.”

Please see Subspace Lab’s white paper.


I think John Wolpert is into the money with that call: By 2020, the concept of “public” versus “private” blockchain networks will be relegated to a historical footnote. We will not pit public networks against private networks. Instead there will be public transactions and private transactions , confidential contracts and open contracts , and they will coordinate their scope across bilateral, multilateral and public environments depending on the needs of users — just as messages today pass between private and public environments using common Internet protocols.


ARC: I truly believe that the blockchain debate (private vs public) is rather contextual and like Steve Jobs say so well , you need to always build with the end users in mind or else it will be a disaster. As for private blockchain use case, I think that Estateably as a good one…


I come from the enterprise space, have worked in setting up corporate governance frameworks and been exploring Blockchain applications for enterprises, so can share my thoughts on why there seems to be disconnect between the message in the Angus’s Coindesk post, and the thoughts expressed by the Trustory cohort. My comments will be limited to Financial Services space, as that is the industry I am most familiar with. For a bit of background, Angus was one of the key blockchain solution leads for EY’s Financial Services team in the US. While I have not interacted with him personal capacity, I am aware that he has interacted with a range of leading financial services, and it would be reasonable to assume the following:

  1. Majority of his conversations are limited to exploration of permissioned blockchain solutions in the Financial Services space in US, and may be less relevant to non FS use cases (e.g., enabling supply chain transparency)

  2. Some of the conclusions can be expected to be derived from project experience - this is not purely an opinion piece

  3. In many instances, he may be bound by non-disclosure agreements, which is why some of his conclusions may seem to lack concrete evidence

It is helpful to breakdown the discussion into the following questions, and analyse each in turn:

What problems are private blockchain solutions attempting to solve for financial services?

Much like a distributed system, a group of enterprises often exchange information (e.g., terms of legal contracts) with each other to achieve some common goals (e.g., automation of a common business process). Ideally, enterprises want to automate the workflows supporting these information exchanges, as it helps reduce costs incurred mutually. However, automating workflows spanning organisations raises coordination costs:

  • Cost of developing standards: Enterprises can automate workflows for information exchanges if there is agreement on a set of protocols supporting the workflows (e.g., what certain contractual terms mean, how execution of these terms are implemented). If these information exchanges have significant manual work which results from lack of consistency/standardisation across enterprises, enterprises will set up dedicated consortiums which have representatives from each enterprise, and develop intercompany technical standards (e.g. ISO, SWIFT) which drive this standardisation across enterprises, and support automation of the workflows. This is the toughest part, and to Angus’ point, is largely a human/political problem, as you need representatives from competitors firm to think very deeply to identify common standards that apply across different operating models, and agree on terminology that can sometimes be impossible to agree on
  • Cost of implementation: Every party will ultimately have to integrate these protocols into legacy systems – depending on scale of project, this could take years to implement, and would require investment. (e.g., refer to consultation on ISO 15022 to 20022 messaging standards, which facilitates communications around payments and securities settlement – migration of securities messaging standards for some parties is expected to continue through to 2022!).
  • Cost of mitigating conduct risk: If poor implementation of these standards or protocols pose sufficient financial and reputational risk, enterprises will subsequently sign legal contracts which hold entities accountable should the protocols not be adhered to.
  • Costs of mitigating operational risk: If they believe the risks of contractual breaches is high (or very costly), and susceptible to “fat-finger” errors, they will additionally develop business process controls (e.g., reconciliation workflows) , and set of dedicated teams to perform those controls
  • Cost of governance: Additionally, dedicated committees will be set up to monitor these control failures, or contractual breaches, and will opine on how to mitigate them going forward, and also on designing or implementing changes to standards (these may very well be part of the consortiums)

Note: These are still oversimplifications to help develop a framework, and also are only a subset of the broader coordination costs I can envision.

In an ideal world, enterprises want to:

  1. maximise the development of automated intercompany workflows that reduce costs mutually ,
  2. minimise the costs of coordinating these workflows (brought out through requirement to develop technical standards, controls, committees, etc.).

What is a private blockchain, and what is wrong with them?

Private blockchains are networks operated by a consortium of entities which are using the network to support information exchanges. Typically, the information logged on the blockchain will be are append-only (meaning “immutable”), much like public blockchains, and the software network is mutually owned, and administered by the consortium members (although administration services can be node specific). One key difference between public and private blockchain is that enterprises in a private blockchain still continue to have legal relationships with each other, enforced through contracts. These contracts can be used to control against malicious behaviour, which limits the economic usefulness of on chain mechanisms that are more common in public blockchain applications.

The blockchain allows enterprises to develop autonomous workflows using the programmable standards they have designed, and the built in audit trail provides them with assurance that the standards operate as expected, which reduces the reliance on “off-chain” coordination mechanisms (controls, committees, etc.).

Use of private blockchains for designing intercompany workflows, however, pose some challenges:

  • While automatable workflows lower costs mutually, reductions may not be allocated in a way that is mutually desirable, as some competitors in the platform may benefit more than others. This is precisely what happened with the TradeLens – IBM and Maersk’s DLT platform for supply chain of the shipping market (
  • A bigger challenge with private blockchains is that they do not sufficiently minimise the coordination costs either. Let’s take some of the above coordination costs in turn:
  • Cost of developing and implementing standards: Implementation of automatable standards (much like the ERC 20 token standard) on a blockchain will require that standards are developed as a pre-requisite. This will invariably require a coordination body (such as a consortium) to develop and implement, and organisations would need to devote resources to fund this cause. This also means a business case for a blockchain solution has to be very strong for a consortium to be formed and sustained, which may deter participants from agreeing explore a blockchain solution in the first place.
  • Cost of mitigating conduct risk: Organisations are legally registered entities, and still rely on laws of regulations of relevant jurisdictions to facilitate transactional exchanges, and enforce accountability should the parties act “maliciously”. One could argue that digitisation of legal contracts, and enforcement of clauses through a set of smart contracts could minimise reliance on the justice system, but in the enterprise world, we are not even close to getting there (refer to UCL paper on smart contract development, which provides an excellent overview of challenges that faced in digitising legal contracts -
  • Cost of mitigating operational risk and governance: I believe some of the controls and decision making processes can be developed into automatable standards, but again, this would require standards to be developed as pre-requisite.

Are there alternatives to automating intercompany workflows via private blockchain?

Yes, and some alternatives can offer lower coordination costs. One proposed model is development of “utility service”. The services could very well be the same set of workflows, but are deployed in a distributed database, centrally controlled and governed by a third party. It is upto the third party service provider to identify the common set of standards, and develop new utility services which can add value to multiple clients. While utility services have long existed in financial services (e.g.,, there are open questions on if they are cost efficient, and if a third party can develop the service quicker and better than the organisations themselves (who go on to enable the services via a private Blockchain).

A hybrid model (e.g., promoted by Corda platform, developed by R3 consortiums), splits services expected from a distributed database, and allows entities to take on different roles, and operate different parts of the database which allows them to offer different services that the Corda platform helps coordinate (this will encourage development of new business models which allows governance of some of services to be more decentralised - the following blog by Gideon Greenspan provides a great deep dive in to the Corda platform, and compares it to other private blockchain solutions:

What, then, is the Unique Selling Point of a private blockchain, and when does this make sense?

My personal view is that the only unique selling point of a private blockchain solution is the built in audit trail it provides, assuming it is designed as an append only ledger that parties can rely on to collect a “proof-of-process”. This audit trail will offer parties the guarantee that the workflows they have developed are indeed working, and reduce reliance on external processes that they currently need to develop (controls, committees, contracts, etc.) - this in turn will reduce some of the coordination costs currently seen.

Note that this “proof-of-process” service can also be provided by a centralised service provider, should the organisations want, which can explain Amazon’s foray into this space (, so the USP is not yet set in stone.

So will private blockchains ever make sense?
Yes, if the following conditions hold:

  1. If the cost reductions/benefits are shared by parties in a manner which is considered as “fair”
  2. If cost reductions/benefits relayed are substantially better than a centralised solution (e.g., a utlility service)
  3. If the coordination costs are lowered - this will happen when (part of an ever growing wish list):
  • More industry standards are developed
  • Consortiums have been made operational (or already existed before blockchains were being explored)
  • Infrastructure is tried and tested
  • “Smart legal contracts” are real, which reduced reliance on justice system, and adds more value to use of blockchains

Note, all of these are happening in parallel, and different industries are in different stages of maturity. These are general observations I have had from my explorations, and would be curious to learn if people disagree with above, or have anything more to add.


i found the article to be confusing as well, and i had to reread it a few times. scrolling down to your reply i see that you are confused as well! makes me feel better… :slight_smile:


Many incumbent companies from the finance, supply-chain, automobile industries have been testing private blockchain via industry consortiums such as EEA, R3 and Hyperledger. Someone has assembled a list of companies and their respective consortium (

So far it seems still lack of large scale production-ready and commercial-viable projects. But significant test pilots, investment, and research has been poured into consortium blockchain:

Financial Services:

  • We.Trade (IBM Hyperledger Fabric)
    A dozen of European banks developed a blockchain-based platform for coordinating international trade orders

  • DTCC (Depository Trust & Clearing Corporation)
    DTCC is working with 15 global banks to re-platform credit derivatives onto “distributed ledger technology” and cloud

Supply Chain:

  • Alibaba
    TMall launched a pilot to integrate blockchain into its global supply-chain platform.

  • Walmart
    Walmart is working with its suppliers and IBM to implement blockchain for food traceability

I agree with @zareef1992 that private blockchains make sense to collect a “proof-of-process” as shown in supply-chain examples of Alibaba and Walmart. Same apply to recording financial transactions on consortium blockchain to prove certain processes happened and reconcile them faster.

If private blockchain is of no value or need, there won’t be the emergence of Blockchain-as-a-service offered by tech giants like IBM, Intel, ConsenSys, Alibaba, etc.

Private consortium blockchain sacrifices the extent of decentralization in exchange of scalability, which can meet the transaction volume needs of current enterprises. It also allows industry enterprises and regulators to set agreeable rules among themselves (e.g. data accessibility), which is more practical for traditional business adoption comparing to a self-governance protocol.

Despite private blockchain is against the notion of true decentralization, it is a sensible solution for how the current state of business/government operate. Maybe we will see a slow transition from private blockchain to public blockchain in long-term future when interoperability hits, or even as @brunocecchini23 mentioned about the blurred line between private or public, but I think for now private blockchain is beneficial for all kinds of players be interested in exploring blockchain tech (when the true tech is still far away).


Interesting point @eddyso. I can see how self-enforcing rules (i.e. smart contracts) would help scale the interactions among a group of enterprise companies.

Perhaps this conversation should focus more on how smart contracts are useful in a consortium of enterprise companies, rather than a private blockchain/database.


I like your suggestion about focusing more narrowly on how smart contracts deployed on a permissioned blockchain are a useful component of a larger technology solution.


I concur with many of your points. Here are some of my own thoughts.

Private/consortium blockchains can be seen from two different perspectives:

  1. as Database++: Distributed databases but with the requirement for consensus to update the database (as opposed to updates being centrally coordinated by one entity).
  2. as Blockchain-- : Blockchain features with much reduced levels of decentralisation so much so that they really start to look like enterprise databases with a few bells and whistles added such as fancy cryptography and facade of a trustless system).

My view is that we should stop this binary mode of thinking Instead let us think of a continuum of alternative IT systems with hybrid characteristics that occupy the continuum between these two extremes - a full enterprise database vs a fully decentralised public blockchain.

I believe there is value to be captured at different points in this continuum for different enterprise and industry requirements.


I believe there is value to be captured at various points in the continuum between the extremes of an enterprise database vs a fully decentralised blockchain.
The real question is whether private blockchains should really be called blockchains or something else. That may eliminate some confusion and bias, because when people hear the word blockchain they invariably equate it to decentralisation.


If the consensus produce a chain of block that contain transaction, is a blockchain, plain simple… no fuzz and buzz, boring…


@preethi Wrote an article based on above question.


nice work.

PS: if you’re interested, you should join our small but tight-knit community where we discuss these things daily: :slight_smile: