BoardRoom, its Design and the Future of Blockchain Governance (Part 1)

In part one, I will provide an overview of BoardRoom’s contractual design.

Design Defaults and Possibilities

Leaving Room for Expansion

BoardRoom aims to provide a starting point for governance systems on Ethereum. The architecture is designed in a way that can be modularly reconstructed or altered in the future. By providing default components as a starting point, it allows for a marketplace of governance services to develop, with tailored services to meet specific market demands for these systems.

The idea here, is to provide defaults that make governance simple, but allow expansion and creative growth to take over in the future. At the core of each Board is an identity and transaction proxy that is so non-committal to its surrounding governance systems, the design possibilities are endless. One could build a default version of BoardRoom in one single governance structure, or one could build it in several modular contracts. Similarly, one can design a completely different governance system altogether, using BoardRoom defaults to get off the ground. Design defaults are good, because they allow a starting point, however, good smart contractual design underneath is what really allows for maximal flexibility with respect to changing governance systems in the future.

Some other points of interest are the default constitutional articles set out for the Board chair and executive positions. These positions are used, if stated in the constitution, for breaking even votes and signing off on specific constitutional or fund release Board operations. I must strongly emphasize that this is a design default and not the only design, and one that is completely interchangeable by boards at their own leisure in the future.

The default constitutional components are as follows:

1. A proposal system for handling the storage of votes, and proposals under a specific set of conditions
2. A voting or rule system which defines these conditions
3. A membership system which the voting system looks to for its conditional logic
4. A delegation system which allows the delegation of votes to other members
5. A family or subcommittee system which allows the registration of organizational structure

Single-Contract vs Multi-Contract Designs

When constructing smart-contract governance structures, organizations are presented with almost limitless architectural designs. But within these options there are two very broad fundamental design patterns, namely, single contract and multi-contract designs. A single-contract design would include all of its governance architecture, rules, data and components within a single, perhaps malleable, smart-contract. The multi-contract design breaks up these components into multiple contracts, that can be interdependent with each other thus breaking up concerns into various modules. Within the Ethereum ecosystem, there are pros and cons to each of these general design pattern models. Note, this taps into a deeper concern and design challenge that is innate within smart-contract ecosystems, that is, the price of modularity.

The pros of the single contract designs:

1. Lower gas costs
2. Simplicity

The pros of the multi-contract design:

1. Greater degree of Interchangeable modularity
2. Greater degree of changeability in general

The cons of a single contract design:

1. Limited interchangeable modularity
2. Limited degree of changeability

The cons of multi-contract design:

1. Higher gas costs
2. Higher operational costs

By default, BoardRoom offers a multi-contract design, which is moderately more expensive than its single contract counterpart, but allows for greater interchangeability of underlying governance components in the future. This default design breaks up various concerns including the Board’s very own identity, into their own contractual pieces.

Constituted DAOs and BoardRoom

BoardRoom contains a simple constitution, this can be optionally used throughout time, but is designed to store the locations (“addresses”) of other accounts or contracts. It’s a map or pointer system that is ingrained within the core of each Board. Constitutions provide the Board with a simple store which states the structure of the organization itself. Some constitutional articles may be proposed systems, membership systems, important accounts and even who started the Board. The benefit of binding a mapped constitution to a single Board identity is that it states in a contractual way, these are the contracts or accounts that we recognize as both important and integral to our organization. Constitutional components will use the Board’s stated constitution as the de facto definition of the organization, and most of the default BoardRoom components use it religiously to locate other components’ governance systems for Board operations. Moreover, this constitutional binding is very important especially as others look into the Board itself. While by design, the constitution is an optional component of the core Board contract and ultimately can be abandoned if need be, binding the constitution to the proxy can be an locatable and optional address store.

Constitutionally Binded Mesh-Construction

If an organization decides to construct their board with a multi-contract design, they can then build it with a constitutionally binded mesh-construction. This means that various pieces of the Board’s constitution can look to the Board’s constitution to identify other critical components that may affect the components in question. A single Board may be built with various components that are all looking to the Board and each other in order to define and allow for governance process flows. We can imagine these components to be constructed in a mesh formation.

Strictly-typed vs Loose-Leaf Proposals

Smart-contract governance proposals that are state-changing could potentially have serious consequences for Boards and other parts of the Ethereum ecosystem. If proposals are merely just sending bytecode (Ethereum computer code) into the network, how are Board members (potentially unskilled in computer programming) supposed to identity what each proposal can do? Yes, a Board member could state what it does, but this is easily cheatable, as a Board member can state one thing and have the bytecode potentially perform another operation. In essence Board members could and probably will cheat on each other to do things like release funds from the Board’s budget and allocate digital assets to their own accounts. A simple way to prevent this is to have a user interface that is always on the side of the user (Board member) constantly verifying and identifying what each proposal does. A second security mechanism is to type each proposal with a cryptographic hash or number, to state the intention of the proposal in the Ethereum ecosystem. By stating a strict type, the UI can identify if the proposal’s bytecode in question will do what the tabling Board member states it’s supposed to do.

A loose-type proposal’s bytecode could be analysed and verified by cryptographic hashing, however, if the proposal has new methods or code that the UI simply doesn’t understand, members may get confused as to what the proposal will do. Even worse, members may pass a proposal that looks like it does one thing, but in fact does another.

A proposal which is strictly typed thus doubly states the intention of a tabled proposal, because both an analysis of the bytecode in tandem with the type will allow users to get a clear idea of what the proposal is both intended to do and what it should do in the end. The BoardRoom UI and default contract design features strict typed proposals, in addition to databasing raw proposal data in a decentralized database so that other members can see, validate and understand what each proposal is supposed to do. As well, the UI could delve further into the destination of the proposal to see if the contract that the bytecode is being sent to does what it’s suppose to do or is up-to-standard with existing Ethereum contract standards. While strictly-typing proposals may cost the user a small amount more, it provides an additional level of security for the Board and its members by contractually stating in a rigid way (not just writing) what a tabled proposal is supposed to do.

Scalability Concerns: The Cost of Modularity and Future-Proofing

Designing contractual systems that are massively modular can increase deployment and operational costs dramatically, but have the benefit of being more easily interchangeable in the future. Boards and organizations will have to decide how much modularity they are willing to install within their structure. But we can assume that the larger the organization the more modular they could go, as more resources are available and the potential need for future interchangeability is more present. We can think of this dilemma of modularity as the cost of future proofing.

Two-Dimensional Constitutions

A Constitution could involve a two-dimensional design. This design is interesting because all of the systems could be contained within one contract and all the rules that govern this system could be in another. This would be the closest middle ground between a massively multi-contract BoardRoom and a rather simple single-contract BoardRoom, because there is just enough modularity to change the rules and just enough modularity to change the underlying governance systems.

In this model, all the rules for say, a token based democracy, could be stated within the Rule System and then all the day-to-day governance systems (i.e. tabling, voting and executing proposals) would be stated in the operational system. The Board would then state the two components in its Constitution with its implementor stated as the operational contract. The operational systems contract would look to the Rule System to figure out who can vote on, table and execute proposals. If the board wanted to change the Rule System but were fine with the operational system, they could deploy a new Rule System, then table a proposal to amend the Constitution to the new Rule System. If the Board wanted to alter its operational system, then it would deploy its new desired operational component, then amend its Constitution to that component. The Board may also alter both systems simultaneously with a multi-transaction constitutional amendment. This may be necessary if one new component invalidates another old component.

The Board as a Proxy Contract

The Maintenance of Identity with the Interchangeability of Structure

A proxy contract is very simple by nature: it contains an implementer, and a forwarding method. The implementor is a selected account that is allowed to forward transactions through the proxy contract. The core Board contract is a proxy contract by design. The implementor is either an entire or single governance component that through some governance mechanisms will then funnel transaction data through the proxy and into the broader ecosystem.

Proxies are beneficial because they allow a contractual system to maintain a single account over time with its implementor being any contractual system or account. This is perfect for BoardRoom as the implementer in question will be a governance structure. These governance structures can ultimately be changed or swapped out over time. It’s as simple as changing the implementor for the proxy, by the proxy, and through the governance structure itself. Put simply, the Board can table a proposal to change the governance structure, execute this proposal thus running the transaction through the Board proxy, to change the Board proxy’s implementor to another contractual system or account.

Because the core Board contract is just a proxy, all of its governing structure can be changed or redesigned over time while its identity and account in the state-transition system is held constant, thus improving its record of activities (by having all proposals and organizational consensus stated on an open-ledger) that could one day be used within a trust and reputation system. I believe this to be of central importance for organizations that choose to act as an org on the blockchain. Both the maintenance of identity and the ability to change structure to adapt to new contractual systems and services, allows for an enormously flexible and rudimentary system that will power every BoardRoom in the Ethereum ecosystem.

Constitutional Amendments and Reforms

Constitutions are very useful when building contractual infrastructure for governance on the blockchain. They allow a concise and organizationally selected list of contractual accounts that can define an organization. The amendment and reform process for these systems is relatively simple, and ultimately detached in many ways from the Board’s core proxy implementor. Members of the Board can table proposals to amend the constitution, execute them, thus sending transactions through the proxy to change its own constitutional system. Because proposals can have multiple transaction blocks, multiple constitutional changes can happen at once or through a single proposal. For example, a proposal can be tabled to alter the Board’s membership, proposal and delegations systems all at the same time. Or perhaps change the chair of the Board to another contract. Boards have the ability to alter their constitution at will through their selected governance structure.

Systemic constitutional reforms are slightly different. Perhaps a Board wants to scrap its default constitutional structure for one that is more sophisticated on the chain. They can do this by nullifying their constitution through an amendment proposal, then opting for a separated constitution on another contract. This would be a complete reform of the constitutional system altogether.

Constitutions act as a mapping device for other constitutional components while also being a single storage that defines a specific organization on the blockchain. Certain financial services may only choose to interact with orgs that demonstrate specific verifiable constitutional components. Other services may only work if the Board has a specific kind of component in their systems. An example of this is a crowdfund for democracy, that only allows donations from Boards that are democracies in nature and that do not have any executive powers or non-democratic features. While this is a narrow niche example, it demonstrates the broad and finite power of defining a constitution for an organization.

Everything is Wrong, So Plan For It

I assume that every governance component I’ve designed will be either outdated or just invalid within the near future, so I’ve left each Board’s core contract with the smallest possible amount of commitment to these systems. Boards may use the components we offer as a starting point, but should be aware that ultimately it is the design of the Board’s core proxy contract that will make or break an org’s capability in the future (as this is the central mechanism sending transactions and holding identity at a specific address on behalf of the organization within the blockchain). There is certainly the change that even the core proxy contract is improperly designed for the future, and in which case Boards will have to act accordingly to distance themselves. But at this current juncture, we can rest assured that most of the governance structures and components are all interchangeable through the default governance structures and that organizational identity and accounting should be maintained over time by the proxy system BoardRoom offers by default.

Multi-Transaction Block Proposals

With every new feature comes a new price tag. A simple contractual proposal system allows members to vote on a proposal, which in turn will establish organizational consensus, and then allow the execution of said proposal to effect the broader ecosystem. The execution of these proposals usually allows for a single transaction to be created per proposal. While the central benefits of this are simplicity and lower gas costs, they do limit functionality especially when your organization is built upon multiple governance components. The central issue is this, what if I want to change multiple constitutional components at once, or through one proposal with the Board’s proxy implementor set to the proposal system (which is a default BoardRoom design). Also, what if some components will invalidate each other in the process and thus halt all operational capacity for the Board for ever. Put simply, you update one component, and then other components are invalided and thus do not function. For now, I’ve been calling this a Board deep freeze, because all operations of the Board are halted by invalid components thus locking up all funds, and assets accounted to the Board’s core contract forever. In order to prevent this, and also allow the ability to upgrade Boards in a way that deep freezing is mitigated, proposals need to be a little more complicated than just single transaction release points. Thus the multi-transaction block proposal system is born. In this system, Board members can table multi-transaction block proposals, where the transaction blocks are sequenced and to be executed by members or anyone in a specific order and fashion. When tabling a proposal in this system, a member can state multiple transaction blocks going to potentially multiple destinations with varying values and transaction bytecode. This allows for proposals to become complex transactional utilities. Voting can still happen through common place voting logic, but execution will happen potentially multiple times in order to send all of the transactions blocked in the proposal. By design the execution process will happen in a linear fashion, so specific transactions can be triggered one after the other. As well, once execution has started all conditional logic that may prevent further execution is bypassed, for the reason that a some of that logic may be the very thing that is being changed on a previous execution. This kind of proposal system allows for complex transactional behaviour which ultimately expands the Board’s technical toolbox tremendously within the ecosystem. A multi-transaction block proposal system also allows for more commonplace features as well, such as doing payroll or registering multiple addresses with a global registry.

The Standardized Token as Defining Membership and Voting Weight

By default, the BoardRoom platform uses a standard token system as their definition of organizational membership and voting metrics. The ownership of a specific token by an account defines that individual to the Board as a member of the Board as well as their voting weight within system. Ultimately, these are just defaults and all of these dynamics can be changed in the end, but this is the system that is presently provided.

We can think of the standard token as a simple sub-ledger on the Ethereum ecosystem, that allows digital assets to be accounted for and securely allocated between those who hold tokens and other accounts. Tokens provide an elegant system of membership as they are accountable, transferable and can ultimately be financialized if need be. This allows membership and voting powers within an organizations to be transferred or sold in a transparent way. As Boards can issue their own token that they can debit and allocate to other accounts through their governance processes. Boards can create subcommittees by deploying a token, and issuing this token (through one proposal) the tokens to multiple accounts which will then become members of the new subcommittee Board. This is just one case example of tokens being used by a single Board, there are many others.

Standard tokens are a great way to define membership but other systems could define membership and voting weight as well. One example is the participation in a specific service, say in a prediction market. In this example, those who are active participants in predicting the future are now defined as members of the Board. This Board could be responsible for deciding what new features the prediction market should build or where funds for that service should be allocated. The rate or amount of participation in the market could determine voter weight. This is just one example and there are many others.

The default BoardRoom contract design has offshored membership to its own simple contract where this functionality (whether it be tokens or service participation) could be easily integrated. The default membership system is a simple method “isMember”, that allows any contractual service the ability to ask given a specified Board, and the existing membership system logic, is this account a member of this specific Board.

The Bigger Picture

DAO’s & Boards as Proxies With Rules and Storage Systems

Given my current architectural designs and we should talk about the bigger picture here. All these Boards are is proxy contracts with rules and storage systems. The storage is merely storing the organization’s intentions, and establishing consensus, while the rules define what storage or actions in the system can take place on behalf of the Board. The proxy is just a technical transaction gateway that looks to a governance structure of some design. At its most simplest form a BoardRoom is just a proxy contract and a governance system. That’s it. At its most complex, a multi-module constitutional governance structure with a mesh-construction that is massively replaceable or interchangeable through governance processes.

Organizations such as DAO’s will use this technology for performing governance and business process flows completely out in the open and on the Ethereum state-transition system. Non-profits are also a good candidate, as they often want their governance and fund allocation exposed in a transparent way for the public and their donors to see. This kind of infrastructure meets their needs perfectly.

Malicious Components

It’s safe to assume that organizations performing governance and process flows with BoardRoom will either make mistakes or be cheated for all their worth. It’s inevitable. One of the central goals behind BoardRoom, our default components and the user interface is to mitigate this risk as much as possible. One potential attack vector is a malicious governance component. These components either don’t do what they say they do or are simply there to invalidate the Board’s governance components and freeze their system altogether. These components will usually be integrated by constitutional amendment so we can expect there to be proposals that are tabled where one component could compromise the whole Board itself. They could be planted there by malicious actors within the Board or perhaps by a virus of some kind on one of the Board members computers. The prevention of such components is paramount to the future of blockchain governance going forward, and the best mechanism of previous is informing the Boards of such attacks, providing user interfaces (UI’s) that pickup on such attacks and careful oversight by qualified contractual and technical lawyers or engineers. Luckily, constitutional changes will be very clearly marked as “highly dangerous” within the BoardRoom UI, but we can’t help but think what some very nontechnical or unaware Boards will do.

Executive Power

A temporary kill-switch solution to tyranny of the majority fund allocation

There are some simple logical issues with doing organizational voting on a smart-contract system. One of which is malicious fund-withdrawal by a majority shareholder (the individual with a majority voting weight). The idea here is, if we did an open crowdfund, for example, and had contributions turned into equity voting weight, someone could just acquire more voting weight than everyone else then just withdraw all the Board’s funds to their own account. Some measures to prevent this kind of attack are, quadratic voting, prediction market voting and a kill switch or executive voting. I relate this attack to the philosophically old problem of the tyranny of the majority. The idea that majority can just do whatever it wants when ever. Luckily, we are hackers not philosophers, and I don’t need to get into the implications of such a problem. Put simply, it’s a big schematic problem with governance in general.

While I won’t go into detail about quadratic and prediction market based voting, as they are very complex and not used by BoardRoom’s defaults presently, I will go into that latter option of executive voting. The idea behind the executive is simple. Have one individual or account that the organization trusts to have the overriding power of stopping any fund release from the Board or changes to the core BoardRoom contract itself. This prevents unwanted fund-release, or constitutional changes while allowing some Board governance to happen outside of the executive powers.

Executive power is not meant to be a long-term solution to unwanted or malicious fund-withdrawal, but is instead a temporary solution to a hard problem in crypt-economics, blockchain voting and political philosophy. The level of executive power can be determined by the Board’s rule or voting system, and it may even be the case complete executive veto power may be needed to protect all digital assets the Board holds. Many companies may look at the executive as the something similar to the treasurer.

While the executive solution is centralized I believe it meets demand in a simple way. The executive is incentivised to not stop fund release of good allocations, because this may include their own pay and fate of the whole org. While the investors are incentivised not to use tyranny of the majority voting practices because they know it will be thwarted by the treasurer. Now yes, the treasurer and majority shareholder could collude, thus invalidating the whole system, but the idea here is, that in every company there is probably one individual we can give the veto power too initially. Someone or group who has the organization’s back, and wants to see it succeed. This individual or group should have the executive veto powers. Note, the executive position can be another BoardRoom, most commonly referred to as a Board or Trustees or a Board or Directors.

Membership Stated by Registry

A Board’s membership may be stated by almost limitless logic, but one form of membership I see as being common place will be membership defined by registry. Ethereum-like systems are very conducive to large, scalable account ledgers or registries. There will likely be many of the these registries for varying purposes. I see many Boards that will base its membership and voting rights on registry systems and not token systems. For example, we can imagine a large organization like a car insurance organization may have a massive registry of its users. Within seconds a Board could be setup to enable these members to vote on specific proposals. If you’re a client of the car insurance company, you have voting rights. We could even define the voting weight by the length of time the client has been with the company. I maintain that registries will be fundamental to blockchain governance, and that many governance structures will leverage them as their definition of membership.

Form and Formlessness

An interesting aspect of BoardRoom is that the governance structure which surrounds the core proxy, has form but is not committed to any particular form by contractual obligation. Arguably, there will need to be some form to use the proxy methods, but largely it’s an open question what governance structures can be designed around a Board. Perhaps there will be a system so enormously complex that it cannot exist within the Ethereum ecosystem alone, but does enter into the ecosystem by way of the governance structure or proxy in order to leverage the state-system. In a sense, the underlying proxy contract is so lean, you could have the governance structure completely outside of the Ethereum blockchain within its own system, but have it leverage and use the single Board identity via the proxy (like a portal into the ecosystem). This allows for systems that do not fit necessarily within the Ethereum ecosystem to be used, if and when they become available by the Board in the future. In a sense Boards will have form, but the form may eventually just exist outside of Ethereum somehow, we could say a formless governance structure contractually.

Boards Vote As, Own and Control other Boards

Mesh Governance Networks

The architecture of BoardRoom enables Boards to not only own and completely control other Boards but also vote as these Boards on other proposal systems. This type of modularity and ownership is extremely useful for things like a corporate takeover or acquisition where it could be stated contractually that the existing blockchain Board and the assets contained therein of the company that is being acquisitioned, be transferred, by way of changing the implementor, to the company making the acquisition. This allows the other Board to operate that Board, but as their former identity. This greatly reduces the time it would take to move or shift assets from one corporation to another, thus saving companies potentially millions in asset allocation costs.

Another interesting use cases for this design feature would be mesh governance where a distributed and decentralized mesh of governance hubs defines the greater governance of an entire network or company. We can imagine Boards linked to or interdependent with other Boards, some with access to assets some with executive powers over the other. As well Boards can even manufacture other Boards, so a subcommittee structure may opt to create another subcommittee for a specific purpose. All of which is done out in the open, in a completely transparent environment. Then these governing bodies are all part of a single Board structure, where each, through their own governance processes have voting rights. This allows for enormous modularity that can be as expansive as the blockchain allows.

Constitutional Component Design Patterns

After working with these proxy to governance design patterns, you realize that many components of the Board can be shared. Where the logic and storage of the components can be shared amongst multiple boards. While this may increase gas costs slightly, as you must define what Board you are interacting with for each component, it does save initial setup costs for the Board, as they don’t need to redeploy a proposal or voting system over and over again. Instead Boards can share proposal, voting, membership and delegation systems. Boards can just state which systems they would like to use in their constitution and wallah, they have a working governance structure, without really deploying any governance structures. This logic is similar to the global name registry logic, why have multiple registries for essentially the same use case? I think we all want reliable proposal systems for our governance contracts, why redeploy these over and over again. The downside to this, is that many organizations may want a whole lot more out of these shared systems and so they may end up deploying their own custom systems. I’ve found that using side registries to store things like decentralized file storage pointers (or hashes) as a good fix to add features to the proposals without adding any additional contractual logic to the proposal systems itself. A side registry or tagging additional data or consensus systems to shared governance components could become commonplace if it makes sense economically speaking.

Single use or custom governance components are customized to fit a specific governance need. These components will address a very specific or niche governance need that may only be used by one or a few Boards. Ultimately, these kinds of components are less secure as they have not been vetted by the community in the same way shared components will be. But they will provide those special bridges to custom logic that many firms and nonprofits will want in the end.

Some governance components may not be compatible with each other. This is inevitable even if all API methods are standardized and agreed upon before hand by the community. When amending their constitutions Boards must be very careful with this and it can lead to a deep freeze of Board operations. Several mechanisms will be put in place to prevent this, namely, a complex registry of all governance components, their compatible components and their API methods. As well as a BoardRoom UI that will hopefully be able to either warn or prevent a negative, malicious or invalid constitutional change from happening.

Many components will be released in governance components packages, where Boards will not want to interchange just one or two components but potentially most or all of their existing components for new ones. These packages may even contain new constitutional arrangements and sometimes enormously complex and massively modular mesh governance structures. We can think of the initial defaults provided by BoardRoom as being the first governance component package with many more to come in the future.

For more information, please visit our website http://boardroom.to or follow us on twitter @GoBoardRoom.

If you want a sneak peak at the Beta checkout:
http://github.com/web3-gov/meteor-dapp-boardroom

Written by: Nick Dodson
@IAmNickDodson
BoardRoom Founder

A special thanks too: Christian Lundkvist, Niran Babalola, Peter Borah, Simon de la Rouviere and Joseph Chow for your help with contractual design.

Footnotes

[1] Vitalik Buterin, (2013). “A Next-Generation Smart Contract and Decentralized Application Platform,” , available at https://github.com/ethereum/wiki/wiki/White-Paper (last visited Feb 4, 2015).

[2] David Yermack, (2016). “Corporate Governance and Blockchains” available at https://corpgov.law.harvard.edu/2016/01/06/corporate-governance-and-blockchains/ (last visited Feb 4, 2015)

[2] Becht, Marco, Patrick Bolton, Ailsa Röell (2002). “Corporate Governance and Control” (updated August 2004)

[3] Shleifer, Andrei, and Robert W. Vishny (1997). “A Survey of Corporate Governance,” Journal of Finance

[4] Oliver Hart (1989). “An Economist’s Perspective on the Theory of the Firm,” Columbia Law Review, 89(7)

[5] Bebchuck LA. (2004).The Case for Increasing Shareholder Power. Harvard Law Review.

[6] Ronald Coase (1937). The Nature of the Firm

[7] Nozomi Hayase (2015). “The Blockchain is a New Model of Governance”, available at http://www.coindesk.com/consensus-algorithm-and-a-new-model-of-governance/ (last visited Feb 4th)

[8] Morgan Rockwell “Bitcongress Whitepaper” http://www.bitcongress.org/BitCongressWhitepaper.pdf