Comment on page
📊
Polls
An overview of governance, consensus, democracy, and meritocracy in token creation. And the guideline on how governance for token, community, and marketplace works on Unit Network.
Similar:
Google Forms
Survey Monkey
Snapshot.org
Governance - Unit Teams Governance Guideline
If you are planning to create your own token, community, and/or marketplace on Unit or are simply curious to learn more about governance on the Unit platform, you are in the right place.
On Unit, you are able to create and populate your own network while successfully developing and managing it together with other members of Unit through diverse tools including amongst others: tokenization platforms, marketplaces, voting polls, contests, events, and many more.
As Unit gives you the power to create the conditions allowing individuals to gather into a group including the structuring of how group’s resources are managed and shared (economies), you will have similar responsibilities of a government, or as we like to see it, a “tribe leader”. You will have to think of different groups' aspects including culture building, individual and collective values, and processes for decision making and enforcement of such decisions.
In this guideline, we are offering you a non-exhaustive whilst comprehensive guide and list of best practices around the topics of access governance (or simply “access”) and governance of a token ecosystem, organization, or project on Unit.
Moreover, to complete the governance toolkit, we will be sharing the tools to be used to work with the governance structure chosen namely: norms, rules, and code.
Unit operates on a token basis. The term Token refers to any utility token issued on the Unit platform, which could be an Industry Token, an Organisation Token, or a Business Token. Please read more on token case studies in Tokens section.
Access governance can be defined as the set of rules a network initiator or community builder puts into place in order to control (or not) who accesses the group.
These conditions can range from very loose structures requiring only a Know Your Customer and Anti-Money-Laundering screening process (“KYC-AML”) to face-to-face interviews, professional accreditations or referrals from peers who are already part of a group.
Before diving into the different access modalities, a prerequisite for anyone to access the platform and purchase the Tokens is to complete a KYC-AML process to ensure that precautionary measures for preventing individuals from accessing the network for illegal ends including but not limited to the money laundering have been put in place. Unit offers the basic technology allowing you to perform basic KYC-AML screening, although it is your own responsibility to ensure that sufficient measures have been taken to protect the ecosystem from abuse. These measures may include:
- Requesting individuals proof of identity;
- Verifying individuals identity against internationally recognized watchlists (UN Sanctions List, OFAC Sanctions List);
- Denying access to nationals of High-Risk countries.
Beyond the KYC-AML mandatory verification for accessing your Token ecosystem, you may decide to set up other parameters for granting individual access. The range of measures lies in between the permissionless access policy and the restrictive permission-based approach.
Permissionless means, as the word suggests, that after completing a KYC-AML process an individual can have access to the ecosystem without further checks. This route is at the core of the most prominent blockchain projects such as Bitcoin and Ethereum.
The advantages of developing a permissionless ecosystem are many including the diversity of the ecosystem, its exponential growth, its inclusiveness and equality, and relatively low cost for processing ecosystem access. The downsides of such an open approach are its difficulty in handling governance, weak group coherence and decision making, difficult community development due to great diversity, individuals’ possible lack of commitment to take action on policies within the ecosystem and generally reduced compliance with applicable regulations, including data protection and privacy.
The other side of the coin is permission-based access, which is the to-go strategy for corporate blockchain solutions such as Hyperledger or smaller communities who want to build a certain culture and keep a close personal relationship among the members. Such access policy could also be advantageous when creating/defining the shared values and group meaning at an early stage or testing features on your platform. Opting for permission-based access to your ecosystem can have several advantages such as building strong relationships with your community, being able to implement policies and monitor their enforcement, creating a niche based community of individuals with a specific set of knowledge, not to mention more manageable compliance with privacy and other applicable regulations. In contrast to the permissionless almost hands-free access process, permission-based access may require an expensive top-down curation process and a significant investment in building the community and meeting individuals’ expectations.
We at Unit have opted for a solution that combines organic and open growth of the Unit ecosystem with a peer-permission-based model through member invitation. After an initial closed/permission growth approach of the ecosystem adopted by the Unit founders, we decided to give such power to Unit Members who are now allowed (and incentivized) to invite friends to the ecosystem by simply sharing a link. Unit believed that this “evolutionary” strategy from top-down filtering to peer-based access was a natural way to create an initial safe space for the network that then allowed for an organic, grass-roots, adaptive, and trust-based community to be developed by its peers.
When deciding how loose or close your membrane is, it is worth paying attention to the relationship between access and governance, which are tightly coupled with one determining the nature of the other in a dynamic way. The access modality you opt for indeed often influences the choice of governance, depending on factors such as the number of peers, their capability to self-organize, the community dependence on top-down control etc.
In short, it’s not a black and white decision between strictly permissionless or permissioned access, but your network building can be the result of the mixture of both or evolve from closed to open (and vice-versa) depending on the network’s purpose, governance structure and capabilities.
Governance can be seen as the set of different processes which allows a group of individuals to interact with one another, make decisions, and take action. Governance processes may range from a simple handshake between two people to representative democracy, group consensus all the way to anarchy and self-organization.
Group processes can be boiled down into three basic and general types of governance:
- Consensus
- Meritocracy
- Democracy
The description below is an oversimplification of the options available and intended to inspire your vision towards building the most desirable solution for your project.
In its strict interpretation, the consensus model is based on the premise that a decision is made when all parties come to an agreement over a certain matter. The consensus mechanism often entails long discussions, meetings, and negotiations before a satisfactory decision is made. This sort of models well suits small communities with personal bonds between each member or to build a solid culture to afterwards decide on a meritocratic system to handle rapid-decision making. To differentiate this type of model from democracy, in a purely consensual process everyone should neither feel left out nor unheard. If there is a win-lose outcome from the process, you are most probably looking at a democratic system. The consensus mechanism is the ideal system for small group coherence or at a very early stage (startup) whereby it is easy to get to hear and integrate everyones’ perspective into a “group felt” action. Pure consensus, however, is slow as a decision-making process, and when the community grows to a level where including every member’s perspective into the decision-making process becomes too cumbersome and is detrimental to the evolution of the community or project, it is a sign the group needs to move to other decision-making mechanisms. Indeed, especially when decisions need to be implemented rapidly, systems of meritocracy may be better fitted for the task.
A process is put in place to select an individual or a small group who is entrusted with deciding on matters and take actions on behalf of the whole group (e.g. from software, the Apache Software Foundation, which operates a so-called “flat” structure whereby anyone can contribute to decisions, although members who get recognition for their community contributions gain more influence over the decision making process). The reader should bear in mind that meritocracy can morph into a dictatorship when for instance, the interests of the whole are suffocated by the person or small group on the top.
When built with transparent processes, and ways for the whole to evaluate the “merit” of an individual or group, meritocracy is the preferred option to govern large communities, as it allows for policies to be drafted and enforced rapidly. Moreover, systems of meritocracy often allow for well-informed decisions to be taken, as individuals with better skills or simply more involved and active with community concerns are better suited to know the direction to take.
On the other hand, hierarchies with a very centralized decision-making structure governing large communities often result in information bottlenecks, whereby the decision-makers are lacking necessary bottom-up information to properly act.
In very simple and generic terms, a democratic model offers several options regarding a decision to be made in a community of people. These options are presented, often with rhetoric and influence, and voted by all members of the community, and the ones getting the majority of the votes will be implemented and will have its effects on the whole. Leaving out obvious examples of representative democracy in developed nations, examples of such governance structure in the technology sphere are the EOS Delegated Proof of Stake (DPoS) that arguably resemble the liquid democracy model and Democracy. Earth offers several models for democratic decision-making.
As with meritocratic models, democracy is well suitable for medium to large side communities, with the advantage (compared to meritocracy) that democratic systems ensure equal power when it comes to voting over a certain decision.
On Unit, you can work with Polls system to involve members of your network to vote on a wide variety of matters pertaining to the whole.
Democratic processes, however, should not be used to replace a consensus process in instances where community cohesion is key, as it is on matters of ethics, culture, or changing a process of merit (who gets to take decisions for the whole).
When it comes to dealing practically with governance, you might ask yourself: “so how do I get this group to choose governance structure?”
The answer for the appropriate form of governance can be found in norms, rules, and codes.
Norms can be understood as shared understanding about reality and values between a group of people. Norms were the way humans dealt with governing groups (from families to villages) for thousands of years before laws were introduced to ensure coherent behavior was followed by (and imposed on) an ever-increasing number of people, whereby personal ties were not sufficiently tight to ensure peaceful co-living and group policing.
You might experience norms as “common sense”, or principles which are not codified or strictly imposed but are part of a group or “social agreement”. Examples of such norms could be “not interrupting” someone while he is talking, helping the ones who are in need, being on time, don’t hurt a living being, respecting each other's space, and so on. Norms form cultures, from a family setting to a group of friends to companies and at national levels. Some groups decide to write down those norms as a reminder or a statement of what a group or community stands for in terms of values, which can be helpful especially when coping with a multicultural or dynamic open community.
Norms are not prescriptive but followed when a felt sense of rightness/justness is intrinsic in someone's behavior.
In communities (off- or on-line), norms are usually not written and followed by the individuals and “enforced” implicitly by the power of the network itself and for the fear of being disregarded when behaving against the norms.
Rules in contrast are a well-defined set of statements which apply to the members of a certain group that being a state, your customer base, the user of the platform, etc, and are usually agreed upon by either express consent (agreement), implied consent (if you participate you implicitly agree to the rules) or by natural cause, such as being born within a certain jurisdiction. The importance of rules is that they are written, accessible by the public, and give a sense of order and trust when individuals don’t know each other but need to still interact (think of online business, city interactions, or international commerce). As the lack of ties between individuals in a community does not allow for norms to be followed implicitly or through peer pressure, rules need to be enforced by someone in order to give them validity.
We all know national and international laws, but contracts such as Terms of Use, Privacy Statements are also legally binding understandings between individuals that can be enforced by the state, or by the private parties (ex. denying access to a platform) depending on the nature of the breach, the rules being breached and who has the jurisdiction over a certain matter. Rules are therefore inseparable from roles which are formal functions given to certain individuals to enforce the rules itself, these being a policeman on the street, a judge, or the owner of a platform with which user have a contractual relationship. In contrast, norms can be applied or enacted by anyone in the community/network.
When there is a shared feeling or understanding in the community that the laws and their enforcement are equal, fair, or represent shared values we usually refer to these rules as being “just” or assume the existence of “justice”.
If you are building a team, project, or community on the Unit platform, we recommend you set up some Terms and Conditions of use of the platform, especially if the access governance structure is open, and you start to lose touch with who is joining. In smaller communities, norms and the network itself will often be sufficient to allow coherent growth and the building of a safe container for all peers.
Lastly, the concept of code is quite exciting whilst should be taken seriously as it’s design can have an important effect on the development and safety of the community/ecology that is subject to it. Code shouldn’t be confused with codes of conduct or ethics (norms) or the Civil Code (rules), but should be seen as a separate category on its own, and the most primordial type of governance enabler which existed before humans started to walk on this planet.
In society code is defined by what we called “laws of nature”. This code runs by itself and governs relationships between different species, it’s the design of molecular structures, the digestive systems in our bodies, and all other rules you can think of when you look at how nature works.
Code is therefore both the most ancient way living beings have dealt with each other in a someway deterministic fashion and something human beings can now design through technology, which arguably changes or replicates and co-exists with the laws of nature (ex. IoT, DLT). It's in other words automatic, and no human interaction is needed (think of the code governing a self-driving car), apart from the ones who actually design that code in the first place which brings about reasonable concerns about what is an ethical code, what is good design etc.
Unit has developed code for its Financial Model and Tokenization, which serves the purpose of governing how tokens (resources) are distributed on the Unit chain in a cooperative fashion and the way the value of Unit Token is calculated.
An example of code when you begin a community online through Unit are the algorithms embedded on the Unit platform and all modifications you make (add functionalities) to, for instance, token economics you chose to follow, the automatic distribution of resources through the community, the design of an autonomous organization (DAO like), a rating/reputation system, or an identity management system you operate to give individuals access to your community. Especially with decentralization and blockchain, whereby the power of decision-making shifted from humans’ discretion to algorithms or algorithmic consensus mechanisms, the discussion on code and code design for governance is crucial.
There is no rule of thumb on what governance “tools” should be used for a chosen governance structure, although some combinations might appear more obvious than others to you.
Small groups that function through consensus might well be driven by common-sense and implicit principles for their interaction. Processes for dispute resolution might be put in place however which might look more like rules than norms but are still perceived as ways to fulfill the shared value system emerging from the community interaction.
Larger groups of people lacking strong connections between peers and functioning on democratic structures might benefit from rules which support members’ accountability for action taken against the community and helps create a sense of safety when dealing with strangers in a digital network.
Code might be used to automate certain processes and be encoded (for instance) in smart contracts which allow for the automatic enforcement of certain straightforward rules, avoiding human bias and intervention when that is not necessary.
We hope that you now are equipped with a few tools you can use to start sketching access policies and governance structures for your Unit project.
The ideas presented are not set in stone, but meant to be taken as a general starting point, and leave out the technicalities as well as interpersonal dimensions that should be considered when building up a project with a group of people. If you want to deep-dive into the technicalities of decision making, here is a great article from Polkadot on those matters, including an explanation on how PoS, and PoW work. Another useful resource in relation to the concept of code and the development of protocols for decentralized collaboration is the DAO Stack. On a more interpersonal and community management level we suggest having a look at holacracy, a method which sets some valuable principles on how to manage decentralized organizations. Another useful resource on how to enhance group bonds and coherence can be found on the MicroSolidarity website.
There are some remaining matters we want to mention and which are worth stressing before ending this guideline. We have listed those in a question-and-answer format as we believe every journey should begin with addressing meaningful questions.
Firstly, before choosing an access policy, governance structure, and the norms and/or rules and/or code, as with any other Design Thinking process (Empathize, Define, Ideate, Prototype, Test) empathize with your target audience, being the community of professionals you want to attract in your Unit Community or the customers to whom you offer your products and services on the Unit Marketplace. Ask yourself, how tech-savvy are they? Are they used to top-down control or are they likely to be free-spirited and self-organizing members? Will they be involved in the projects, or passive? Is the crowd I am attracting competitive and individualistic, or more collaborative and looking for relationships and support? Are they likely to turn around when faced with too many access hurdles, or they understand the process from previous experience? These are just a few questions that could help you navigate various access and governance options.
Secondly, put on the evolutionary lens for a moment and imagine what could be the long-term developments, similar to a project roadmap. As mentioned earlier, most likely, as we have experienced at Unit, the access and governance process you set up to build your project/community early stage will change as the community evolves and its needs and interactions change. Ask yourself, how will the relationship change as the group grows? What is the maximum capacity of the network I want to build? Will small, self-organizing groups likely develop? If so, how will governance change? If diversity is essential to the community I want to build, how do I ensure that the ecosystem keeps its variety of and does not attract the same group of people (ex. cults, eco-chambers).
Lastly, a few more questions we had to face ourselves at Unit and that you may want to attempt to address for your consideration on the above topics. How will I handle the resolution of controversies in the community? What is a fair way to distribute resources through the community? In a democratic system, how do I ensure actors have access to enough knowledge to enable them to make informed decisions? How do I ensure the engagement of individual members? What policies should I put in place and enforce for a healthy community to emerge and to eventually sustain itself? What are the ethics underlying the building of code? Who should be accountable for the consequences of its (code) automated enforcement?
We very much hope this guideline inspired you to begin or keep working on developing your community on the Unit platform where we love to help teams navigate governance matters, so feel free to reach out to us if you need any support.
Last modified 1mo ago