A Proposal for Blockchains Governance
Disclosure: Very little of what is described in this post has been formally accepted by executive leadership. This post is in-part an effort toward that end. Further, some of what I describe Colony facilitating will require development, though Jack Du Rose and Auryn MacMillan have been exceptionally generous in providing feedback along the way, and grounding me in reality.
After months of research, internal dialogue, collaborative brainstorming, refinement of ideas, dead ends, drafts, and restarts, I’d like to introduce a high-level overview of my proposal for Blockchains’ distributed collaborative entity (DCE).
In an earlier post, I stated that Blockchains will be a company owned and governed by multiple, formalized stakeholder groups who will jointly contribute to and benefit from its success. I made my argument as to why that kind of collaboration is important and how it will differ from existing corporate models. I did not have much to say about the specifics. I have a lot more to say now. Though I won’t feign to have all of the answers, I believe I have enough to get started.
I will not be able to express all of the details in this post, but in my internal communications I have come to realize that I have spent a lot of time in the trees, without offering up a vision of the forest. This is my attempt to communicate the big picture.
This is my proposal:
Member Groups
Blockchains should be governed by a set of stakeholder groups granted membership status[^1] to the DCE: worker-members, resident-members, product-participants, philosophers, and investors.
Worker-members: the people employed by blockchains
Resident-members: the people who live in (and own businesses within) the smart city
Product-participants: the people we are serving and who support us through purchasing/using our services; we avoid language like “consumers” or “users” because those terms imply a one-way relationship, whereas we seek a collaborative association
Philosophers: the employees of a Web 3 nonprofit that seeks to promote ethical decentralized technology through education, reporting, and legislation; they will be tasked with the question, “What is the ethical thing to do?” (Jeff has historically stated his desire to found such a nonprofit.)
Investors: people who have financially invested in Blockchains. *Arguably not a member group, but we can come back to that.
At the time of incorporation, it is unlikely that all these groups will exist. I will conclude this post with a section about bootstrapping and adding additional groups as they come into existence.
Coordination Between Member Groups
All member groups (formalized stakeholder groups) will elect their own representatives to advocate on their behalf in the company’s core governance circle (think: board of directors). The core governance circle is responsible for establishing and holding the company’s mission and purpose, for managing company financial resources, managing risk, ensuring compliance to by-laws, and planning for the future of the company. This group may also include third-party advisors or industry experts elected by members, by way of Colony-enabled vote (more on Colony and specific election protocols later). The core governance circle does not decide which products to develop, though it may halt development or funding of a project if it finds the product to be outside of the company’s mission or ethos.
This structure means that the member groups and member-elected representatives directly and collaboratively make decisions about the company. To disallow any group from having power over another, every member group should have equal percentage of the total voting power in the company (though most decisions should not be made by ballot).
Avoiding an Unwieldy Core Governance Circle
Because each member group has core governance representation, the size of the circle could quickly become unwieldy as emergent groups are added. To address this concern, I propose the following rule:
If there are more than four member groups, each group gets one core circle representative, with the exception of the worker member group, which always has an executive and an employee delegate representative. If there are four or fewer member groups (including workers) active, each member group gets two core circle representatives. If a fifth member group is added, all representatives may complete their terms, but after that period each member group (other than the workers) may only have one representative.
Decision-making
The primary protocol for decision-making between member groups at the core governance level should be a modified version of dynamic governance. Dynamic governance (another term for sociocracy) is somewhat of a radical departure from traditional models, both autocratic and democratic: Everyone makes decisions together, and there is no voting. For most core governance circle matters, proposals are drafted and/or revised collaboratively, and decisions are made by consent between all circle members.
Dynamic governance is not a new governance model; it has been time-tested and proven across a wide range of organization types, from food cooperatives, housing communities, software companies, manufacturing companies, nonprofits, schools – you name it. I will not go deeply into the specific protocols for dynamic governance in this post, but I will offer an illustrative, if partial, example of how a modified version of this system could be used at the core governance level.
Imagine that the Company has made some amount of profits that can be distributed back to Member Groups. All circle participants at the core level[^2] would state their preference for how much of that money should be redistributed to member groups, and how much should be reinvested in the company. Each person would have the opportunity to explain, one at a time, their preferred profit allocation. After everyone has spoken, each individual may revise their suggested allocation. At that point, the circle facilitator (elected by consent of circle members) would draft a proposal they think everyone would consent to. Every circle member would then respond to the proposal, one at a time. The facilitator then could edit the proposal, if they think an edited version would better please the circle participants. Then, the facilitator would ask every individual if they could consent to the proposal. The allocation would likely not be totally aligned with anyone’s individual preferences, but this process will usually result in a proposal everyone can consent to. If any person objects, then the proposal does not pass, and a new proposal must be drafted (or the old one can be revised). In this way, no one person can be overpowered by the will of the majority, no matter how unpopular they are.
Some decisions will be made entirely by consent at the core governance circle level. However, this particular issue requires the input from member groups.
Once it has been decided how much of the total profits are to be distributed, it is the members themselves who will determine the distribution of that money to member groups. This is where Colony-enabled, member-wide, reputation-weighted voting can come in. Colony already has a collaborative budgeting software, Budget Box, which would allocate the funds algorithmically based on the pairwise preferences of all voting individuals. Every person would essentially be asked, “should more money go to X or Y? Y or Z? Z or X?” The collective responses would determine the overall budget.
I propose that profit-sharing allocations be decided in this way, and not by a predetermined percentage, as the size and significance of each group will change over time.
Internal Member Group Coordination and Governance
The precise means by which each member group elects its representatives and participates in governance vary according to degree of desired and expected coordination between members, but Colony’s software should provide the basis for much of the coordination within and between all groups[^3]. I will now provide an overview for or how each member group coordinates internally to distribute profit-shares or push forward proposals.
Product-Participant Member Group
The product-participant member group is a federated member group consisting of product-specific subgroups. For reasons of scalability and agility, decisions regarding the development, maintenance, and improvement of specific products does not take place in the core governance circle. While product-participants have elected representation in core governance, their role at that level is not to represent any one product, but as general consumer advocates. This structure is intended to enable united representation of consumer protections and interests at the core governance circle level, while allowing for members to more directly participate in decisions regarding the products they’re actually using.
Some Product-Specific Governance Decided Case-by-Case
While product-participants may engage in decision-making at the product-specific level, much regarding the specific decisions they would be included on is impossible to specify, because it would be highly variable between products. In some instances, end-users might have almost complete control of a product’s maintenance or governance (as is the case with existing DeFi DAOs), and in some, product-participants may only be included occasionally. For this reason, strategies for prosumer collaboration will need to be considered product-by-product. However, while the specific decisions they are included in are variable, the means by which they collaborate is defined.
Internal Member Group Coordination and Governance
There is a shared, overarching governance framework allowing all product-participants to elect representatives, collaboratively distribute profits, and to author and rally around governance proposals – within product-specific subgroups, within the entire member group, and all the way to the core governance circle.
The technological means by which product-participants engage in governance is relevant here, and some general knowledge of Colony’s architecture is assumed (you think this is dense, try reading their white paper). Product-participants are united as one Member Group via a shared colony. The root domain of the product-participant member group would hold the election for core governance representatives, so those representatives are not product- or service-specific (all members within this group can vote at this level).
Products are differentiated within the member group’s shared colony domain at the subdomain level, allowing ballots to be specifically targeted at individual prosumer groups, rather than at the whole member group. This allows for workers at Blockchains to create product-targeted ballots to gauge consumer preferences and needs. This federated model (and the technological framework offered by Colony to facilitate it) also means that any product-specific member can draft a proposal (or nominate a representative), to be considered by their product subgroup, the whole member group, or even the core governance circle. For example, if a person did not like some feature of the app they were using, they could draft a proposal and seek the support of other people using that app. If enough reputation voted in support of the proposal (probably proportionate to the total reputation in the subgroup), there could be some rule that the proposal must be considered or implemented. Likewise, if a person wished to nominate another person (or themselves) as core governance representative, they could do so at the member group level. If some minimum amount of support were reached, then that nominee would be added to a ballot.
Governing the Distribution of Profit Shares
Colony’s software makes the distribution of profit shares between product-participant subgroups and to individual product-participants straight-forward and uncomplicated. Once the core governance circle has determined the amount to be distributed to this group, that money will go to an account owned by the entire member group. From there, the money would automatically be allocated to individual product participants according to reputation, as described in the Colony white paper.
When Products Fall into Disuse or Lose Steam
Colony’s domain structure, and the federated model it creates for this group, makes the changing relevance of various products insignificant to board-level governance and profit-sharing; when a product falls into disuse or irrelevance, the voting power and reputation of its former users decay over time, organically shifting that power and profit-rights to the other product-participants[^4], while the overall power of the member group is unaffected. Similarly, the addition of new products does nothing to core governance, and only affects the distribution of reputation within this group. Moreover, Colony’s domain structure allows each product-participant subgroup to earn reputation in ways specifically geared to incentivize desired consumer behavior (promoting responsible money management or energy efficiency, for example).
Obscuring Complexity
The end user, however, would likely have no knowledge of the underlying software enabling their participation. For them, the voting contracts would be integrated into whatever app was associated with their product. For example, a mobile wallet would occasionally prompt its users to vote on an initiative or in an election. For some products, the app could also link to a member forum where they could coordinate around any concerns or needs. This could be made possible using an existing platform, such as Discourse, where participants can authenticate using their DCE membership credentials, such as their reputation.
Philosophers and Worker-Members
Worker-members and philosophers[^5] will participate in governance in much the same way. The nonprofit organization and Blockchains employees both have the advantage of regular communication and cooperation, much of which is in-person, or at least synchronous. We know each other, our roles, and our capacities. This allows for complex communication and negotiation, opening up methods for participation in governance to extend far beyond voting. For these groups, I propose a combination of Colony’s software and dynamic governance.
Decision-making
Dynamic governance dictates that teams (departments, etc.) make policy-level decisions by consent, as I described in the core governance circle example. Day-to-day operations can function according to traditional hierarchies, or by worker self-organization, but the stuff of governance is decided collaboratively, including the election of individuals to various roles within teams and within the organization more broadly. Each team is responsible for achieving its clearly stated mission, and its policies pertain to that mission. For example, a developer team might collaboratively choose to adopt the scrum framework as a policy, but during sprints developers are largely autonomous, free to attack the problem according to their expertise. Dynamic governance would be involved only in the first part.
Representation
To understand how members of this group make it to the core governance circle, you first must understand two more sociocratic practices: double-linking and elections. Consider Blockchains’ current hierarchy; there is the CEO and president, there is the executive vice president, a whole suite of VPs, and then departments underneath them, sometimes with departments underneath them. VPs attend meetings with the CEO and president, where the CEO and president dictate decisions to the VPs. The VPs also attend meetings with the departments they lead, where they are the ones dictating decisions to their teams – sometimes the decisions of the CEO and vice president, and sometimes over decisions specific to the department.
In dynamic governance, this general hierarchy could stand, but the principle of double-linking means that an individual from whatever team is directly below a VP would be elected by their teammates to participate in the executive-level meeting. It is important to note that this rule does not apply to all meetings, but only for meetings to decide on policy decisions (for example, if they were deciding whether to implement a new noncompete or IP policy). These meetings run according to the process I described for Core Governance Circle – through collaborative, consent-based decision-making. At this level, the elected delegate has full participation rights. This process is called double-linking because it means that every level of the hierarchy is linked to the next level up by two people; one who is the institutionally-decided leader, and one who is an elected representative. This is intended to help increase transparency and communication within the organization, and to make access to power more fluid.
Elections happen largely in the same way as I described the proposal process in the core governance circle, with only slight variation. Before anyone nominates a person as a delegate, the group first decides on the criteria a successful candidate should have. Then everyone in the circle would nominate someone and explain their choice. After that, everyone would have the opportunity to change their nomination if someone made a compelling case. According to many practitioners of dynamic governance, people often change their nomination. Then, the facilitator would choose one of the nominees (or there could be a system to randomly select one), and ask each individual if they would object to the proposed candidate. The intent is never to compare candidates against each other or argue who would be better; it is the facilitator’s responsibility to guide the conversation to discussing the nominee only in terms of whether they meet the qualifications. If everyone agrees that they meet those qualifications, that person is elected. If someone objects claiming they are not qualified, then the group explores whether there might be something to help the nominee meet the criteria, or whether they need to select a different candidate.
It is through the process of double-linking that the worker-member group and nonprofit philosopher group chooses their representatives. The nature of double-linking means that it is possible, though perhaps unlikely, that an individual from the lowest ranks of an organization could make it all the way to the core governance circle[^6]. I stated earlier that to keep the core circle to a reasonable size, there will likely be a time when membership to that circle is limited to one representative per member group, other than for the worker-member group. At this time, the highest circle of the philosopher member group will be responsible for selecting its representative, via the sociocratic election process.
But I said that these groups would be governed by a combination of dynamic governance and Colony’s software, and I haven’t mentioned Colony at all. All workers and philosophers will also have a reputation-based voting system to determine things like profit-sharing distribution, and to weigh-in on certain ballot decisions at the core and product levels (example: should we issue more investor stock?), to nominate candidates, or to allow for participation of the broader member group in a circle’s decisions (for example, if an IT circle wanted employee input on a policy it was deciding). Reputation in this context would be based on periodic peer-review performance evaluations, so people who perform better consistently will have more say in decisions. I have more specific pilot ideas for peer-review performance evaluations intended to make these as fair and accurate as possible, but this is beyond the scope of this proposal and will require piloting to determine an appropriate evaluation process. I recommend a study of existing evaluation processes as conducted by similar organizations in terms of desired culture.
Much like the product-participant group, profit-sharing allocation will also be done according to reputation distribution, though on a higher-level it could also be done using Budget Box, or a range-voting software like the Autark team made for Aragon. For example, if the worker-member group were allocated $100 (an easy number) from the core governance circle, then the workers could use Budget Box to decide that $10 of that would be split only between the founders, $12 to a good cause, and the rest spread between everyone else according to relative reputation.
Any Colony software used by these member-groups would could potentially be built-in as widgets to whatever payroll or internal communication software the companies use, though more likely this would be a separate web application, perhaps even Colony’s default UI. Whereas for other member groups it is unrealistic to expect them to download and learn a whole application just for participation in Blockchains governance, these groups are a bit different in that respect because they are participating in the organizations every day, and their IT departments could conceivably preload the software onto all company computers.
Resident-Members
Much of this group’s participation is not currently possible to meaningfully define, because so little is known about the population, scope, or shared resources of the community. I prefer to define only the minimum protocols to facilitate voting and profit-sharing distribution in this group, to allow for the full range of potential governance frameworks depending on resident and city needs.
This group will ostensibly have its own governing body of some kind, such as a city council. However, I propose that whatever profit-shares this group is offered go to a smart contract wallet, rather than a fund controlled by the council, and that the DCE and smart city governance be kept as separate as possible. Money in this wallet would then be allocated according to member-wide Budget Box vote, on a one-person-one-vote[^7] basis.
I see no benefit of a reputation-weighted voting system for resident-members; attempting to incentivize people with more voting power has too many complicated implications. For example, you might think it’s a good idea to incentivize civic participation by giving people who participate more power/money, but participation is easier for some people than others, giving an unfair advantage to people who have more time and mental energy than those who don’t. Additionally, then you’re creating an incentive for people to vote even when they do not really care, lessening the impact of votes by people who do.
Representation
While profit-sharing allocations and voting on ballot initiatives should be done according to a 1p1v system, electing core governance circle representatives warrants development of Colony-compatible rank-choice voting contracts. Rank choice would be most desirable for electing representatives, especially if we want to allow for the possibility that the DCE core governance circle representative could be someone other than one of the city council representatives. We could have a proposal process where residents could propose candidates, and then if they were to receive some minimum amount of support, that candidate would be included in the ballot with any other candidates. The Colony whitepaper describes a process by which an individual can back a proposed task with their reputation – the same type of system could be applied here: anyone could be nominated, but they would only be added to the ballot if the gain some minimum amount of support. Then resident members could rank their preferences on the ballot, and the person with the most support would win.
All of this could be built in to any smart city app, and most of the smart contracts are already written. Collaboration and participation in governance beyond voting and profit distribution will almost assuredly be possible and desirable, but until more is defined about their shared resources and the nature of property rights within the community, best practices are indeterminable.
Investors
There is little to say about investors, because they do not need to deal with profit-sharing allocations internally, and are arguably not a member group per se . Candidates for their elected representative in core governance will be selected by the circle, and each share will count as a single vote. Investors will be invited to vote on proposals as well, also on a 1 share 1 vote basis. There is probably no reason to facilitate this using Colony, though there will need to be some work done to integrate their votes into certain member-wide ballots; this is likely easier if their shares are security tokens, otherwise we would need to use some kind of oracle.
| Stakeholder Group | Representation in core governance? | Represented in product-specific governance circles | Reputation-weighted vote | Profit-shares collectively managed and allocated | Dynamic Governance | Collaboration w/ other stakeholders enabled via Colony | Profit shares distributed via Colony | Internal collaboration via Colony |
|---|---|---|---|---|---|---|---|---|
| Worker-Members | yes | yes | yes | yes | yes | Yes | yes | yes |
| Resident-members | yes | Only if the product is core to city architecture | no | yes | maybe | Yes | yes | yes |
| Philosophers (non profit) | yes | no | yes | yes | yes | Yes | yes | yes |
| Product-participants | yes | Yes, but only the users of the product being governed by that circle | yes | yes | no | Yes | yes | yes |
| Investors | yes | no | no | no | no | Maybe | no | no |
Conflict Resolution within Member Groups
I was recently asked, “What if someone in the worker member group is not being treated fairly, and the rest of the group does not want to give them any money?” My response to this is layered. On one level, the reputation-based profit allocation makes this impossible; payouts are automated. The only way this could happen is if the person did not have any reputation. If a person was denied reputation when they believed they deserved it, Colony has a tiered dispute resolution for dealing with that; a “jury” of your peers evaluates your case and makes a ruling. If you still disagree, you can elevate the conflict to the next tier, all the way up the domain structure until literally everyone in the colony was voting on whether you deserved reputation. If everyone agrees that you do not deserve reputation, then you probably don’t. If you do, that would suggest that the organization has some serious cultural issues that need addressing, and I would suggest hiring a professional in nonviolent communication full time – though really, if we are implementing dynamic governance, then we should already have one on staff and this should not be an issue.
Bootstrapping
I propose the DCE will begin with worker-members as the sole voting population, with Colony permissions enabling executive control (or majority voting power) if desired. Over time, as products come to market (with Colony’s system built in) and we begin accepting investor funds, voting power will be dispersed to include product-participants and investors as they come. The same will be true of the philosophers, if and when we choose to found said nonprofit.
In earlier writing, I imagined that each group might have some differing amount of the total voting power in the organization, and that the power of each new group would have to be individually decided. I no longer find much value in that and currently believe this would unnecessarily complicate things, especially since quantifying a group’s worthiness of power is an ethically fraught task that will likely enable easy gaming. Moreover, the specified member groups are explicitly chosen to represent particular interests (as laid out in this member group proposal) all of which are significant, and constant. The defined member groups are intended to represent the following interests: user experience (product-participants), financial (investors), ethical (philosophers), labor (workers), and civic (residents). Fixed, equal shares makes the most sense to me at this time, particularly because every group already has representation in core governance, and all decisions made there are by consent.
Within this relatively simplified structure, the core governance circle would still need to decide if and when to add or remove member groups, thus diluting or concentrating the power of existing member groups. I propose that the by-laws state membership rights for the five member group types specified in this proposal and that, barring amendment of bylaws (only possible with consent by all core governance circle members, or a majority shareholder vote), only groups of those five types can be granted membership to the DCE. The description of the allowable member groups should leave room for the philosopher member group to be some entity other than a specific nonprofit (though giving preference to one founded by our holding company), such that if one group fulfilling that role wanted complete separation from Blockchains governance, we could replace them with another group tasked with the responsibility of representing digital ethics. The other member groups are inalienably tied to Blockchains such that they are irreplaceable.
Within those member types, subgroups may be added, though those are decisions to be made within a given stakeholder group, except in the case of product-participants: By default, new product-participant subgroups are added when new products come to market.
Conclusion
I thought this was going to be a quick two-page high-level overview, when in fact even the high-level, completely non-technical, and analysis and context-lite version of the governance framework I have so far baked up is quite extensive. As I build out more and more ideas, it will only continue to become more complex. This is not my preferred approach. My preferred approach is to start building and implementing now and increase complexity as time goes on. But alas, I do not have the power to make this decision unilaterally, nor do I have the technical skills to make it happen or the budget to get someone else to build it for me. So, these are my asks to executive leadership:
-
I would like to work with Christoph and Colony to define the technical specifications for the worker-member group and start building out this system and implementing it within Blockchains. (In the meantime, I will expand some areas of this proposal and publish it as a whitepaper.)
-
I would like to implement dynamic governance pilots at Blockchains.
-
I would like to plan some campus visits to organizations implementing dynamic governance, so that I can see up-close the effectiveness and/or challenges these groups face.
-
I would like to hire either a consultant or a full-time staff member to help facilitate a shift toward dynamic governance.
-
I would like to collaborate with a consulting group and a Blockchains lawyer and/or finance person to learn more about FairShares Commons incorporation in Delaware to make this a legal reality.
END NOTES
[^1]: Let’s define our terms.
**Members and Member groups:** Member groups are the formalized
stakeholder groups with profit-sharing and voting rights who are
represented in Blockchains’ core governance circle. Members are the
individuals in those groups. Individuals may belong to multiple groups.
**Stakeholders:** Stakeholders are those who have the ability to affect
and be affected by the success of our company. Blockchains might have
many stakeholders, but not all of them will have a formalized place in
our company’s governance. For instance, the wild horses living on our
land and the activists advocating on their behalf certainly have a stake
in what we do here at Blockchains, but I will not propose that we give
wild horses or their advocates ownership of our company. It is not
practical that every stakeholder group be given formalized power at the
highest level of our organization’s governance, but it is confusing at
best and dishonest at worst to bestow stakeholder status only to those
who we allow membership.
[^2]: To improve scalability of this consent-based model, many proposals would
be drafted in smaller sub-circles (analogous to audit and risk committees), and
only ratified by the larger core governance circle.
[^3]: The investor group is the exception here, who will probably not use Colony
software at all. Though, if we were to issue stock via a security token (to my
knowledge we have no plans to do so), we could easily hook that smart contract
voting architecture to our Colony network.
[^4]: For product-participants, distribution of profit-shares would be
determined by reputation according to Colony’s mechanism for revenue-sharing.
Your share is proportionate to the amount of reputation you have relative to the
overall reputation in the colony/domain.
[^5]: This organization will be founded by us/our parent company, but will then
be independent. If it chooses not to adopt dynamic governance, then it can
borrow the governance processes and software of the product-participants and
resident-members, and this will not affect core governance.
[^6]: To increase the possibility of a lower-ranking worker/philosopher making
it to the core governance circle, we could implement an additional layer to the
nomination process at this level, whereby people outside this higher-level
circle could propose a nominee from any department for consideration by the
circle.
[^7]: Without identity solutions this can be a challenge, but we can either
integrate an identity software, or we can create a task where the person must
provide proof of identity to gain reputation (but where everyone is given the
same amount of reputation for completing the task).