This is a guest post by Mark Radcliffe, a partner at DLA Piper in Silicon Valley. Radcliffe is particularly involved in the legal issues raised by new technologies, such as blockchain, open source software, IoT and domain names.
Blockchain project governance is a widely discussed topic in the blockchain community. These governance discussions have focused primarily on the public “blockchain platforms” themselves, such as Ethereum. The most recent discussion started with an article by Fred Eshram Blockchain Governance: Programming Our Future on November 27 2017 and is continuing with a series of articles on Medium by a variety of authors including Vlad Zamfir and Steven McKie. The Ethereum blockchain, itself, is undergoing a fundamental governance change by shifting its basic consensus mechanism (which determines which blocks are added to the Ethereum blockchain) from Proof of Work to Proof of Stake.
However, a second level of blockchain governance has rarely been discussed: consortium project blockchain governance. Although some enterprise blockchain solutions will be run by a solution provider such as IBM running Food Trust, many enterprise blockchain solutions will be implemented by a “consortium” of enterprises building one or more applications on top of a “blockchain platform”. The blockchain solutions provided by solution providers are generally run by the solution provider and may not have a formal governance structure. However, more traditional consortiums are already forming in many industries to deal with the particular problems of those industries: they include B3i, and the RiskBlock Alliance in the insurance industry and we.trade and Voltron in trade finance.
Consortium project blockchain governance will be as important to enterprises as “blockchain platform” governance because the enterprises will work with this level of governance on a daily basis. Consortium project blockchain governance needs to address quite different issues from public blockchains. Susan Joseph, an experienced blockchain executive, notes that “Putting in the proper governance and leadership of a consortium is paramount to its success”.
The challenges of governance in blockchain governance consortia are very similar to those solved (and continuing to be solved) by open source software (“OSS”) projects, such as Linux and OpenStack. They are quite different from traditional “for profit” companies. Blockchain project consortia should look to the experience of OSS projects to take advantage of their experience (and avoid their errors). The governance structure should address the following issues: ensure that all stakeholder groups in the blockchain ecosystem are represented, determine intellectual property ownership and licensing and how to raise and spend funds to support the blockchain project.
Enterprises who are considering the organization of a blockchain consortium or joining a blockchain consortium should consider the following four key issues:
1. Entity Selection
Although many individuals in blockchain communities are eager to make use of “on-chain” governance and “virtual organizations” such as decentralized autonomous organizations (“DAO”), these approaches are new and have many uncertainties. In fact, the first major decentralized autonomous organization, “TheDAO”, was a failure due to errors in the “smart contracts” that were supposed to run the organization.
Consequently, most blockchain consortia will be governed through traditional entities. The selection of the type and the jurisdiction this entity structure will be driven by the location of the founding members and prospective members as well as tax issues.
For example, a consortium of enterprises incorporated in Europe is likely to select a governing entity located in Europe with Belgium and Switzerland being frequent choices. A consortium of enterprises which have all or a significant number of members incorporated in the United States is likely to choose a United States entity. Currently, the most commonly used US entity is a non-profit, non-stock corporation incorporated in Delaware.
2. Identifying Classes of Stakeholders
The stakeholders in the blockchain project consortium need to be identified in order to determine how such stakeholder classes will be represented and how the authority to make decisions will be allocated. For many blockchain projects, they will include companies in the industry, service providers to these companies (for example, freight forwarders in logistics blockchain project consortia), academic institutions, nonprofit institutions, software developers, and users of the blockchain project.
The companies who wish to participate may vary dramatically in revenue (particularly revenue attributed to this industry). Most OSS projects provide for corporate memberships with different fee levels and representation on the governing board such as the Board of Directors (“Board”). A general framework for such participation is described below:
Platinum: Annual fees are the highest and each class member receives a Board member
Gold: Smaller annual fees, potentially based on company revenues. The class has more limited Board representation (perhaps one out of three)
Silver: Modest annual fees, designed for smaller companies. Generally, one or no Board member.
Academic/Nonprofit: No or small fee. Generally, one or no Board member.
Developer Community: One or no Board member; possible Board observer.
The other stakeholders such as users who do not fall into these categories and third-party developers of applications and documentation may be represented by committees that report to the Board.
3. Form of Representation
Once the stakeholder classes have been identified, the organizers must decide how they will be represented in the organization and how the Board will be structured.
The major issues for the Board are: size, method of appointment or elections, term, quorum (the number of Board members needed to transact business), percentage votes for approval (and any special percentages for certain decisions), appointment of officers and affiliated entity board limits. If a Board becomes too large, it can be difficult to operate. On the other hand, the Board needs to represent the major participants in the blockchain project consortium ecosystem.
The OpenStack Foundation board has 24 members and operates well, but a Board of greater size might be difficult to operate effectively. As noted above, the highest level of corporate membership would generally have the right to appoint a member to the Board with the lower levels of corporate membership “electing” a representative of the class members.
The terms of the Board members will generally match the membership terms (which is usually annual). The quorum will depend on the size of the Board and the need that sufficient stakeholders are present to give the Board decisions legitimacy. Similarly, the percentage of votes will depend on the Board composition and the need to provide legitimacy for such decisions.
Frequently, the majority of Board members who form a quorum will be the requirement for routine decisions (my experience is that most Board decisions in well run consortia are unanimous or near unanimous). But certain decisions, such as changing the size of the Board, changing the allocation of Board seats among membership classes and approval of the budget may require percentage votes higher than a majority or a vote by the classes themselves (see below).
Officers appointed by the Board will manage the day to day operations of the consortium and the Board needs to decide which officers are needed to run the consortium. Many OSS consortia ensure that a single entity (or group of affiliated entities) does not obtain undue influence over the consortium by limiting the number of Board members who can be from a particular entity or group of affiliated entities.
This limit is frequently referred to as a “board diversity” requirement and also applies to an increase in the number of Board seats held by a single entity or group of entities arising due to a merger or acquisition. The organizational documents may also set up special Board committees to deal with particular issues such as management of trademarks, membership and audit. These committees may either report back to the Board or actually have authority to make decisions on behalf of the Board in their particular area.
4. Special Voting Rights for Critical Issues
Although Board approval is generally used for routine decisions for the project, the members may demand that some decisions require additional approval (such as the approval of the “class” of members).
The classes (such as Platinum Members or Gold Members) will probably require that any change in their rights must be approved by a majority or supermajority of the members of that class: these rights could include the number of Board seats for the class, the number of members of the class, the policy for admitting new members of the class, the method of election or appointment of Board members and the “director diversity” requirement.
The members could also require special “class” votes for other major issues such as the software license for the blockchain project, the policy for use of the trademark for the blockchain project and changes in decision making on determining future features of the blockchain project.
