Blockchain Governance: Turning Competition into Teammates

Share this via:

Collaboration has become the norm in many professions, with professionals spending roughly 80% of their workdays engaged in some form of collaboration. Over the past two decades, the time spent by managers and employees in collaborative endeavors has increased by 50% or more. In short, collaboration has taken over the 21st century workplace.

That’s not the case, though, when it comes to entire industries. Firms understandably have a hesitancy to collaborate with potential, or perhaps even direct, competitors. Questions of intellectual property, decision-making, accountability and governance can immediately complicate firm-to-firm collaboration. As a result, most decisions regarding software and innovation traditionally have happened within a single firm rather than across firms.

As Dale Chrystie, business fellow, blockchain strategist at FedEx, aptly states, blockchains, however, are “a team sport … We have to work with our competitors on things that improve the entire industry.” Turning the competition into a teammate is what blockchain often requires. That notion, though, runs counter to most long-held business wisdom and practices. Blockchains require competition, where firms must cooperate with its natural competitors to achieve goals.

This counter-intuitiveness explains why “the pace of enterprise blockchain diffusion has been sluggish.” Shared applications like blockchain, unsurprisingly, require shared governance. But what governance options exist? Which one is best for your endeavor? Can you change governance models or have multiple ones? Can a governance model evolve over time? All of these are questions industry professionals have been asking. Addressing these questions is the goal of Blockchain Center of Excellence’s white paper, “Blockchain Governance Models: Insights for Enterprises.” In this paper, Mary Lacity, Zach Steelman and Paul Cronan examine the various governance models as well as the ways they can fit different organizations’ needs.

If you are new to blockchain and want to learn more about it, visit the Blockchain Center of Excellence website.

Why Governance Matters

Governance will never grab headlines the way scalability or transaction speeds can. While it may lack the business press buzz of transaction speeds, governance affects everything: you can barely discuss mission, participatory rights, validation rights, data policies, liability, ownership rights, software updates or funding models without governance edging its way into the conversation. So, why does governance keep inserting itself into other conversations? Is it simply ill manners? Is it jealousy over not getting its fair share of the headlines or is there something deeper at play?

Firms, as stated above, have little experience with cross-firm collaboration and shared control. So, when governance questions arise, those questions might be ones that firms don’t know how to answer. As “Blockchain Governance Models: Insights for Enterprises” demonstrates, blockchains currently use a variety of governance models, from very centralized (benevolent dictatorships and oligarchies) to completely decentralized, democratic models. While your blockchain’s governance should lean toward decentralization, you should also know the advantages and disadvantages of each governance model and how they affect your applications’ stakeholders and users. Different stakeholders will prefer different models and different users will likely have elevated or diminished rights of access within the blockchain application. One thing that will remain the same, however, despite all of these differences is the need for all stakeholders to have a fluid, ever-evolving understanding of governance.

Inclusion vs. Efficiency: Your Governance Options

What do you value? Including and empowering every user and building unity around decisions or clear control, accountability and swift, efficient decision making? Chances are, you’ll value different things at different times and for different reasons throughout the lifecycle of your blockchain application.

Most blockchains begin centrally, with a benevolent dictator or oligarchy holding power at first before transitioning into more decentralized governance models. Most blockchain ecosystems are launched by a group of committed, engaged founders. Bitcoin, the very first blockchain application, was formed by Satoshi Nakamoto in 2009. Nakomoto, given the 2008 Global Financial Crisis, did not trust traditional large financial institutions and governments and created a currency based on cryptography and computer algorithms. Nakomoto, who remained anonymous, did not seek personal fame; his anonymity increased the amount of trust like-minded coders had in his blockchain application. By 2010, Martti Malmi and Gavin Andresen were given access rights to update Bitcoin’s website and source code repository, respectively, with Andresen eventually becoming the lead developer of the client software for the bitcoin network.

Ethereum also had a similar start, with Vitalik Buterin’s December 2013 white paper proposing the need for a new platform alternative to Bitcoin. Buterin argued for a platform with a more general scripting language and joined with several others (Mihail Alisie, Amir Chetrit, Charles Hoskinson, Anthony Di Iorio, Joseph Lubin, Gavin Wood and Jeffrey Wilke) to co-found Ethereum in 2014. Having a centralized core of decision makers allowed both of these blockchain applications to grow quicker than most. That said, both of these applications moved more towards a meritocratic and democratic governance model. Bitcoin operates off of a meritocracy in that its community of miners, developers and investors vote on the Bitcoin Improvement Proposals based on the merit of said proposals. To date, 35 of 322 proposals have been finalized, a rate of 10.8%. Likewise, Bitcoin and Ethereum miners democratically vote on source code changes by either installing or failing to install changes to said code.

But what if neither highly centralized nor highly decentralized fits your application’s needs? Fortunately, there’s wide swath of governance models existing between these two poles. Some blockchain applications, notably the Facebook-proposed Libra, initially used a staked oligarchical model, or stakeocracy. The Libra Association proposed to govern via proportional power, where a stakeholder’s voting power is directly proportional to the size of their stake. The association was to be governed by council members who would purchase at least $10 million in Libra Investment Tokens. In order to prevent Libra from being a purely pay-to-play model, a cap existed to prevent one party from taking over the association.

As proof of the need to evolve the governance portfolio over time, the Libra Association did not launch as initially proposed. Once announced, regulators expressed deep concerns, particularly over Facebook’s influence as initiator of the project. As of 2020, the Libra Association lost some of its founding members – including PayPal, Mastercard, eBay and Vodafone. In December 2020, the Libra Association was renamed Diem Association. Diem’s white paper, originally published by the Libra Association in June 2019, was re-issued as a stand-alone update in April 2020. The governance model of the Diem Association is not linked to funding. It now follows a 1 member, 1 vote approach. There are 27 members of the association today and each contributes to the governance via the association's council through appointing a delegate who is empowered to vote on matters arising with the long-term governance of the project. There are member representatives on the association's board and members also contribute to other aspects of the project, including the technological roadmap, which benefits from a Technical Steering Committee, as well as a Social Impact Advisory Board.

Other organizations, such as Hyperledger, use a federation model. For example, Hyperledger’s general structure is a set of very specialized projects: decentralized groups specialize on disparate parts of a given project whilst coordinating with a central governing body to integrate solutions. As a result, its steering committee operates as a representative meritocracy: operators must prove their merit to become eligible for the committee. Users must demonstrate their worthiness in order to receive votes from other members.

Speaking of worthiness, many applications – such as the VeChain Foundation – use a steering or advisory committee to govern its operations. While these committees generally lack decision-making authority, they possess a recommendatory power. They ensure that major decisions remain transparent and usually help set the rules for the community to ensure that solutions mutually benefit all members. The IBM Food Trust, MediLedger and TradeLens use these sorts of committees in their respective governance models.

(Not the) Same Differences: One Blockchain, a Portfolio of Governance Models

While the above models referred to the blockchain application as a whole, blockchains typically contain a variety of governance models within them. This aspect of governance makes sense, as governance not only refers to the rules of engagement within a blockchain but also decision-making rights, namely what parties possess which decision-making rights. Just as there is no one-size-fits-all way to govern a blockchain, having one method of treating a variety of different stakeholders and users the same is simply not feasible.

Regardless of whether your blockchain application is public (Bitcoin and Ethereum) or private (IBM Food Trust, MediLedger, and TradeLens), you’ll have to answer these questions. Having a portfolio of governance models allows both public and private blockchains greater flexibility. For example, Bitcoin – as public and decentralized as it is – operates as a meritocracy with regard to improvement proposals and as a democracy with regard to source code changes. The proposals are judged via their merit whereas the adoption of source code changes are entirely up to each individual user.

Aside from the recommendation to move toward a more decentralized governance, no one-size-fits-all approach exits with regard to blockchain governance. The flexibility of a portfolio approach to governance makes so much sense because it allows organizations to have its proverbial cake and eat it, too. Administrators and developers can control who has what rights and access privileges while also allowing a modicum of decentralized governance that represents the hallmark, if not reason for being, of blockchains.

A Portfolio Approach: What Leadership Should Consider

Have you ever visited the omelet station at a hotel restaurant while traveling? You can have spinach and mushrooms, cheese, caramelized onions, bacon, ham or whatever else you want in it. All you have to do is figure out what goes well with what else. And, of course, what you are hungry for at the moment!

Think of blockchain governance in the same manner – although, perhaps, on a full stomach – your application’s governance structure should consist of whatever your enterprise requires and what you, from an executive position, are comfortable sharing with other users and other players in your industry. Think toward the next meal: what sort of governance is going to provide you with the nutrients that will allow you to accomplish your goals in the short and long term? What sort of mutual benefit and information sharing are you comfortable with at the moment and going forward? What decision-making rights do x users get vs. y users? What constitutes a decision maker in a given instance: a key stakeholder, a steering committee member or just a general user of your application?

Alternatively, let’s say you are wary of the omelet station and are more of a biscuits and gravy or fruit and toast sort of person. When do you make the switch? When do you decide to change your normal habits? These sorts of questions make sense if you’re not willing to be a first mover. Every enterprise must decide whether to lead in app development, participate closely in said development or wait until it’s a bit mature and then join in later. There are obvious costs and benefits to each – first movers bear the brunt of the risk whereas more risk-averse partners have fewer choices upon entry.

One solution to consider is a minimum viable ecosystem (MVE), which enlists a few partners (or coopitators) to create an ecosystem that builds a minimally viable product to get it all started. You can govern this as an oligarchy or stakeochracy and then have a clearly-mapped plan or sunset date for a more decentralized governance model after certain thresholds are reached.

At the heart of your development – instead of being focused solely on scalability or other headline-grabbing features – give more attention to governance. As Mike Walker, who serves as the senior director of applied innovation at Microsoft said, “It’s vital to be business outcome driven with governance.” If you don’t think about governance thoroughly, you might not attract other participants beyond the MVE.

Governance, in an application such as blockchain, cannot be an afterthought. Governance, like a good omelet ingredient, has to be cooked into the overall product in order for it to serve its purpose.