DAOrayaki Research |Colony：A DAO Framework that Effectively Reduces the Transaction Costs of Market Suppliers
DAOrayaki DAO Research Grant：
Fund Address: 0xCd7da526f5C943126fa9E6f63b7774fA89E88d71
Voting Result：DAO Committee 5/7
Grant Amount：200 USDC
Category: Domains and permission, Transaction Cost, Reputation Mining, Market Suppliers, Colony V2，Transaction Cost Economics (TCE) theory, Collaboration
Contributor：黑白QB, DAOctor@Daorayaki
Launch date: Online time: Colony in 2017; Colony V2 soft launched in February 15, 2021
Token: CLNY (ERC-20)
Chinese Version：https://daorayaki.org/quan-mian-jie-du-colony-v2-you-xiao-jiang-di-shi-chang-jiao-yi-cheng-ben-de-daoji-chu-she-shi/
The Focus Problem
Talent is highly distributed, yet opportunity is highly centralised. Many people would like to start or work on startups, and though starting up is easier than ever, there are still significant barriers to entry. Consequently, the passion, talent, and energy these people might otherwise commit to commercial projects are often channeled into online communities, free open source software projects and other hobbies.
What is Colony？
Colony is built on open source smart contracts using the Ethereum network. It features ownership according to contribution, influence according to merit, and fair reward. The fair reward system on Colony works when a Colony member makes money, and the money is automatically shared through prior agreed upon smart contract agreements to the Colony member and others. Fair rewards are distributed based on the proportion of tokens and reputation Colony members hold.
What does Colony do？
Colony is a social collaboration platform for distributed organisations. Users can start projects online and build a workforce to help make them a reality.
Because it aligns the incentives of the workforce around being productive, it is possible for people anywhere in the world to work on a project without the need for hierarchical management.
The platform incentivises users to compete to be the most skilled and productive workers by distributing cryptoequity in proportion to the value of each user’s contribution.
The platform automates the project management process, aggregating the collective intelligence of the workforce in suggesting tasks, making decisions, assigning tasks to the best candidates and providing feedback on people’s work.
Every aspect of the platform employs game mechanics and behavioural design to ensure a compelling experience which encourages repeat engagement.
Colony currently runs on xDai and supports the following features.
1. Organize communities into departments or teams with a threshold for joining.
2. Manage token pools and apply budgets to different teams and programs.
3. Support a variety of different payment methods.
4. Customize member entitlement distribution permissions, such as influence gained through participation in governance, based on the organization’s specifics.
5. Raise funds through token sales, donations, or revenue.
6. Provide multiple decision-making mechanisms to accommodate different use cases and arbitrate disputes when they arise.
7. DAOs can make arbitrary transactions with other contracts on the same chain as them, and if your DAO needs to manage another protocol or interact with Defi, Colony can help you do it.
Overall, decentralization is Colony’s philosophy of governance, and we believe that voting is undesirable, so we strive to avoid it when possible. Given that any organization is different, Colony has a modular design, which means that organizations can plug-in extensions that can be manipulated as needed to provide their organization with the tools they need.
What is the difference between Colony V1 and V2?
Due to the complete data decentralization, the system processing speed is prolonged, the system public infrastructure is not completed, and the community participation is insufficient. The Colony began to shift to Colony V2 in early 2021 gradually. It has been migrated from the main Ethernet network to the xDAI network.
The changes are as follows:
Permissions
Colony’s access control framework. The access authority is based on the Ethereum address, and the authorized Ethereum address can access certain privileged functions (similar to the underlying system call). There are six permissions, sorted from high to low: restore permissions, root permissions, arbitration permissions, structure permissions, funding permissions, and manage permissions. Each permission represents a semantic package of functions. Permissions can be granted at different levels of the domain hierarchy, thus enabling complex authorization systems. In addition, since permissions can be granted to any address, it is possible to develop independent, smart contracts and “plug” independent, smart contracts into Colony to expand its functions.
Extensions.
Granting any Ethereum address access to privileged functions means that it can be very flexible in developing and testing arbitrary mechanisms and interfaces based on these functions. Based on the above concept of permission design, Colony naturally derives the idea of extending functions. For example, a unique budget mechanism can be established around the “funds” authority, allowing addresses to transfer tokens between different domains. By developing extended functions that can be adjusted between the underlying functions and various mechanisms, each Colony can more effectively explore the design space of the organization or try to use more direct management control and a distributed decision-making mechanism that does not require permission.
Stake Management.
Many extended functions may require users to pledge tokens before taking action. For example, an extended function on voting can enable users to initiate arbitrary voting by pledged tokens. If other users believe that the vote is malicious (or treat the vote as spam), then the voter may (as expected) lose their pledged tokens. Considering that the contract for the expansion function is independent, the user has to track the pledges made to many different contracts, bringing a considerable burden to the user. In addition, it is necessary to ensure the security of the extended function contract holding these pledge tokens, which brings a significant burden to the development of the extended function. The colony has developed a standard interface for extended functions (or administrators) to manage pledges on behalf of users without actually holding funds to solve these problems.
Reputation Mining.
Although the design of the reputation mining process has not changed, the Colony team has made many implementation choices, which are very different from the choices given in the original white paper. Most importantly, it includes switching the data structure of the reputation tree from the conventional Merkle tree to the more efficient Merkle-Patricia tree.
What are the characteristics of Colony?
Transaction costs include specifying requirements, finding suppliers, receiving and comparing offers, agreeing on contract terms, managing delivery, invoicing and accounting, quality control, dispute resolution. DAOs have no other option but to coordinate supply through market mechanisms.
A practical DAO framework must reduce the transaction costs of market-based supply mechanisms. Nevertheless, unfortunately, the problem with all DAOs except Colony is that they increase transaction costs. Their complex decision-making process with a strategy of requiring token holders to vote on every decision made by the organization is absurd and completely unscalable.
With this in mind, Colony decided to address these issues using a combination of approaches where we allow DAOs to scale by creating multiple teams and sub-teams and not requiring a token vote on every decision. Instead, individual expertise is quantified by using influence proportional to the value of the DAO’s contribution, thereby empowering individuals administratively.
Moreover, at Colony, voting is the last resort. Our governance works through “inert consensus,” where a proposal automatically passes after a safe delay as long as there are no objections. In other words, if you see a proposal that you agree with, you do nothing. If you find something you disagree with, you can object and force a vote.
Founder Team：
Jack du Rose
CEO at Colony, Graduated from University of the West of England. Former CEO of Collectively Intelligent Ltd, Mentor of Outlier Ventures.
Collin Vine
Co-founder of Colony, former co-founder of Zirtual.com. He’s most interested in the future of work, inclusive of how cities, economies, and organizations are and will be influenced by technology.
Alex Rae
Co-founder of Colony.Alex has a mind as sharp as the finely honed blades of Hattori Hanzo. He combines practicality and pragmatism with a creativity tempered by deep experience of scientific best practices.
Detailed introduction:
1、Background
Theory of the firm
Companies exist to coordinate the production of goods and services. Transaction Cost Economics (TCE) theory, popularised by Ronald Coase’s Theory of the Firm, postulates that companies form, employ people, and invest in capital because there is a threshold at which it is more efficient to control the factors of production directly than to coordinate production via the market mechanism, once transaction costs are accounted for. These transaction costs come in three flavours:
• Search & information: Costs associated with finding information to inform decisions, and discovering and evaluating suppliers.
• Bargaining: These are costs associated with reaching an agreement with a supplier. Bargaining costs can be very low (e.g. buying a coffee), or very high (e.g. buying a company).
• Monitoring & enforcement: The costs of ensuring adherence to the terms of an agreement (e.g. that widgets are manufactured on time and to the agreed quality). People often deviate from the agreed terms due to chance, negligence, or malice, and potentially high enforcement costs (e.g. legal fees) are required to resolve disputes.
TCE theory states that firms are more efficient than the market mechanism at coordinating production due to imperfect information and bounded rationality. Given perfect information, companies would not be necessary, as market forces would provide the necessary mechanisms to incentivise and coordinate production — everyone would know the exact value of their and other’s contributions.
As this is not the case in traditional markets, these knowledge and trust barriers are overcome by due diligence and contracts, and require a legal system to provide recourse when things go wrong. These processes are expensive, and so traditional firms often find that replacing free-market bargaining with command-and-control hierarchy makes them more efficient and competitive.
As new technologies have improved the diversity and flow of information, new organizations are emerging which are able to merge the efficient decision-making of a market with the shared valuecapture of a traditional firm. Gig economy platforms (e.g. Uber, Airbnb), market networks (e.g. eBay, Amazon Marketplace), and cryptocurrencies (e.g. Bitcoin, Ethereum) have demonstrated that if the product is sufficiently well defined, and the supply sufficiently large, fungible, or diverse, then it
is possible to dramatically reduce the transaction costs of the market mechanism by making search and information discovery easy, bargaining straightforward, and having policing and enforcement provided essentially for free by the platform. This has enabled these new platforms to be orders of magnitude more efficient than had they attempted to coordinate equivalent supply within the hard boundaries of a firm.
Confidence and trust
The firm is able to coordinate complex production at scale by organising labour into a management hierarchy. Seniority within the hierarchy (ideally) represents the amount of confidence the company has in the employee, and in the Platonic ideal of a firm, confidence is a pure function of competence.
The more confident the company is in their employee, the higher their competence, and thus the greater their responsibility, influence, and compensation. Across the internet however, it’s hard to have confidence in other people. Up to now we’ve relied on platform operators to mediate relationships between parties in online transactions (often via various rating and reputation systems), and in some cases (such as payment processing), to underwrite the risk of those transactions. On the blockchain it’s even harder, as all you know about a counterparty is that they control a public key. It is difficult to imagine how a traditional organization or hierarchy could exist in this pseudonymous, adversarial environment. A blockchain has no geographical boundaries and cannot differentiate between who or what controls public keys.
As Richard Gendal Brown put it in his twist on Peter Steiner’s classic meme:‘On the blockchain, nobody knows you’re a fridge.’ Internet Organizations must thus assume the lowest common denominator: that every member is rationally self interested and focussed entirely on maximising personal utility and profit, and given incentives accordingly. This gets to the heart of Colony: a protocol seeking to facilitate the same kind of meritocratic division of labour and authority that the idealised model of the corporate hierarchy should, except from the bottom up, and less prone to error. Decentralised, self-organising companies, where decision-making power derives from a fairly-assessed contribution of value.
Work therefore, is where we start. A colony member is compensated for the value they create for the colony, in the form of ETH, any ERC20-compatible token, or Reputation, a non-fungible, time-decaying measure of aggregate past contributions. Active colonies are likely to have a variety of types of work ongoing at any given time; in order to ease the management of work (and their budgets), colonies can be divided into Domains. Domains are how you structure your colony. You can think of them as teams, departments, circles, or what ever makes sense in your context. These make it easy to group related tasks together and separate them from other unrelated work in other domains, and make it possible to incorporate contextually appropriate decision-making logic (in which one domain may be controlled by an administrator, while another is controlled by reputation-weighted voting).
When a colony member gets paid in the colony’s internal token, they also receive Reputation for the Skills they used, and in the Domain in which the value was created. Reputation is used to quantify the historical contributions of members to a colony, and to make sure they are fairly rewarded. By earning Reputation in a Skill (e.g. Javascript) and a Domain (e.g. BigCo Client Project), the recipient earns proportional influence in decisions pertaining to those skills and domains.
Reputation is not transferable between accounts, and slowly decays over time. This decay ensures that any reputation a member has is as a result of recent behaviour deemed beneficial to the colony (and thus a function of the judgment of the current membership). As the calculations involved are too complex to carry out on the Ethereum blockchain, updates to a member’s reputation are calculated off-chain, with an on-chain reporting mechanism secured by economics and game theory.
Many decisions within a colony can be made by informal consensus. Members are expected to verify their colleagues conduct, but hopefully will only rarely need to intervene. Intervention in this context means ‘making a motion’ . Decision via vote is infrequent within Colony because it is slow and carries a high coordination cost; costs which are justified in the (hopefully rare) case of dispute resolution. The dispute resolution system allows for many kinds of decisions to be put to a contextually-relevant vote of some or all members of the colony. Ballots are weighted meritocratically, according to voters’ contextually-relevant reputation.
Colonies may be voluntary, non-profit, or for profit. A revenue-generating colony may elect to pay out a portion of its revenue to its members. When the colony pays out rewards, the amount a member receives is a function of their combined token and reputation holdings; this ensures those who have contributed the most gain the greatest benefit. Members maximise rewards by contributing to a colony over its whole lifetime (thus maintaining high levels of reputation) rather than sitting on early accumulations of tokens.
We want people to use Colony for as many different workflows as possible, even those that are not immediately apparent as being able to leverage the Colony protocol.
- Structure of a Colony
Colonies exist to enable collaboration between their members, and direct collective efforts towards common goals. Facilitating effective division of labour, management of incentives, and allocation of resources are therefore some of the most important functions of the Colony protocol.
2.1 Domains and permissions
The essential structure of the colony revolves around domains and the permissions that accounts may have in them. These two concepts jointly define the structure and security of a colony and provide a flexible framework for creating colonies of many kinds.
2.1.1 Domains
Like any organization, without structure, a large colony would quickly become difficult to navigate due to the sheer number of participants and interactions taking place — domains solve this problem.
A domain is like a folder in a shared filesystem, except instead of containing files and folders, it can contain subdomains, funding, and expenditures. This simple modularity enables great flexibility as to how an organisation may be structured. Domains could be used to represent teams, departments, projects, tribes, circles, and so forth.
It is ultimately up to individual colonies to decide how they wish to use domains — some might only use them for coarse categorisations, whereas others may use them to precisely group only the most similar expenditures together, or even multiple expenditures that other colonies would consider a single expenditure. Some might use domains to represent long-lived organizational departments, while others might use them more ephemerally, to represent projects with start and end dates.
We aim to provide a general framework that colonies may use however they see fit, and to be prescriptive only where necessary.
Among other things, this compartmentalisation of activity provides an essential benefit to the colony as a whole by making reputation contextual. When arbitration occurs, it occurs at a specific level in the colony’s domain hierarchy. This means that people with relevant contextual knowledge can be included for their opinion, and that when arbitration occurs, the whole colony is not required to participate in the process.
2.1.2 Permissions
Access control in a colony is organized around the concepts of permissions. There are six different permissions (roughly in order of influence): recovery, root, arbitration, architecture, funding, and administration, each unlocking a bundle of semantically-related functionality.
With the exception of the recovery and root permissions, all permissions are domain-specific (much like permissions in a Unix file system are directory-specific), with the rule that permissions held in a parent domain are inherited in all child domains. Put another way, have a permission in a domain gives you that permission in the entire subtree rooted in that domain. To implement this inheritance, permissioned functions require a domain proof of the following arguments:
• permissionDomainId — The (parent) domain in which the account holds the permission.
• childSkillIndex — The index of domainId in permissionDomainId’s children array.
• domainId — The (child) domain in which the action is being taken.
These arguments can be evaluated on-chain in constant time to determine whether the account is authorized to call the privileged function.
Permissions are held by Ethereum accounts. This means that permissions may be given to human administrators, or assigned to contracts which implement more complex behavior (such as voting mechanisms). These types of contracts are known as extensions. The use of extensions to flexibly ‘plug-in’ various decision-making mechanisms is a key concept in the Colony protocol.
It is worth noting that the list of accounts that have the permission in question have the full permission; no additional restrictions exist at the protocol level. In some cases, these are extremely powerful capabilities (such as emitting arbitrary reputation penalties) and require absolute confidence in whomever or whatever controls it. We anticipate therefore that in many cases, extension contracts will be used to offer varying degree of moderation to the underlying permissions.
Recovery
The recovery permission gives accounts access to the colony’s emergency ‘recovery’ functionality, which allows for arbitrary state-changes to the colony’s data.
Root
The root permission gives accounts access to high-level administrative functions in the colony, such as setting colony-wide parameters, upgrading the colony, and minting new internal tokens. This permission also gives accounts the ability to assign permissions throughout the colony (including in the root domain).
Arbitration
The arbitration permission gives accounts the ability to make domain-specific state changes, meant as a means of resolving motions. This permission also enables accounts to emit reputation penalties (but not reputation increases).
Architecture
The architecture permission gives accounts the ability to create new domains in a colony, as well as assign permissions in those new domains. Unlike root, accounts with this permission cannot edit permissions in the domain in which they hold the permission, only in subdomains.
Funding
The funding permission gives accounts the ability to move tokens between funding pots. In practice, this means that this permission is responsible for allocating money amongst domains and for funding expenditures.
Administration
The administration permission gives accounts the ability to create and manage (but not fund) expenditures, the basic incentive unit in a colony.
Broadly, permissions are designed as a ‘separation of powers’: different permissions must work in concert to carry out the functioning of a colony. For example, administration can create an expenditure, but only funding can actually provide the resources, while arbitration resolves motions as they arise. Complex extensions may require multiple permissions in order to function properly (such as ‘tasks’, which requires both arbitration and administration).
The intention is that, since permissions are grouped into semantic bundles of functionality, it will be possible to develop specialized mechanisms for mediating access to the underlying functionality (i.e. specialized funding mechanisms and specialized dispute-resolution mechanisms, as opposed to a general-purpose ‘voting’ mechanism meant to handle all possible decisions).
Colony’s long-term vision is of trustless organizations; organizations in which members can safely collaborate and manage shared resources, without needing to know or trust each other. Early colonies may find that a larger emphasis on human moderators to be useful, while more mature colonies may find reasons to devolve increasingly more decision-making to extensions implementing trustless functionality. We will refer to colonies which make substantial use of these extensions as trustless colonies.
2.2 Funding and expenditures
All tokens and currencies are administered by the colony contract; it is responsible for all the bookkeeping and allocations. The former are managed via funding pots, the latter via expenditures.
2.2.1 Funding pots
Each domain and each expenditure in a colony has an associated funding pot. A funding pot can be thought of as a wallet specific to a particular domain or expenditure, and are used to move funds around within a colony. To each funding pot, the colony contract may associate any number of Ether or ERC20-compatible tokens it holds. Depending on context, the funds in a funding pot may be referred to as the payout, bounty, budget, salary or working capital. In addition to the funding pots, there is a special rewards pot which accumulates tokens to be distributed to members as rewards .
Only accounts holding the funding permission may move tokens; the rule is that they may move tokens between any two pots in the subtree rooted in the domain in which they hold the permission. It is the expectation that this permission will in many cases be given to an extension contract implementing a specialized decision-making mechanism.
2.2.2 Expenditures
The basic payment primitive of a colony is the ‘expenditure’. Expenditures are used to transfer funds out of a colony to any Ethereum account. An expenditure has several properties:
• An owner (the account address which created the expenditure).
• A status (active, cancelled, or finalized).
• One or more recipients.
• payouts for each recipient, denominated in one or more tokens.
• Optionally, a per-recipient skill.
• Optionally, a per-recipient payout Modifier.
• Optionally, a per-recipient claimDelay
The owner is responsible for setting the properties of the expenditure. The recipients are simply Ethereum accounts. While it is anticipated that recipients will be individuals, there is nothing to prevent these accounts being contracts under the control of multiple people.
Once the expenditure is finalized, all properties become locked (but subject to arbitration) and payouts can be claimed (and reputation awarded). Prior to finalization, the owner has the ability to cancel the expenditure entirely. Any funds that have already been assigned to the expenditure can be reassigned to the domain that the expenditure was created in.
Defining the payouts for each recipient, of course, does not provide the funds — this must be done through the funding mechanisms in Colony. Payouts do not have to all be in the same token, and an expenditure’s payouts can be made up of an arbitrary number of tokens.
The expenditure is meant to be an abstract primitive which can support many types of workflows, and so contains optional attributes to support more complex behavior. For instance, the payoutModifier and claimDelay can be used to implement a rating and review system, where good or bad reviews lead to an across-the-board reputation increase (or payout decrease) for a recipient, while the claimDelay is set to allow for any relevant motions to be decided before funds can exit the colony.
Once the tokens have been received by an account, they are under the control of the recipient-there is no way to reclaim the funds. The funds have to cross the ‘Cryptographic Rubicon’ somewhere in the system (by the nature of the blockchain), and it makes sense to do so here.
2.3 Internal tokens
Every colony has its own ERC20-compatible ‘internal token’. These are the tokens that, when earned as an expenditure payout, also generate reputation for the receiver (and thus distribute control within the colony). What these tokens represent apart from this is up to the colony to decide. For example, they may have financial value, or they may be purely symbolic.
In addition, colonies may ‘bring their own token’ and designate an existing ERC20-compatible token as reputation-bearing. While this may be advantageous in some contexts, it’s worth noting that this weakens the incentive alignment underpinning the game theoretic security of trustless colonies, in that the value of the token is divorced from the performance of the colony. Note that the internal token cannot be changed once a colony has been created, so choose wisely. In cases where a colony creates a new token, that colony is in control of the supply of the token.
Specifically, root permission holders can mint tokens at-will. In some cases, this may look like a founder managing the token supply unilaterally, while in other cases colonies may manage the minting process via an extension contract.
A common question is why only internal tokens (as opposed to all tokens) are reputation-bearing. The reason for having a single token be reputation-bearing is that it avoids tricky exchange-rate problems, such as incentives to receive more of a less valuable token to earn more reputation.
2.3.1 Token use-cases
Ultimately, internal tokens are used to distribute reputation, and thus both ownership and decisionmaking power. Since users with more reputation can both exercise more influence over the activity of the colony, as well as claim a greater share of the rewards, reputation functions to align incentives among the members of colony. Here we give a few examples of different use-cases for internal tokens, demonstrating the variety of schemes colonies may adopt for distributing ownership and influence alongside cash compensation.
Tokens as early rewards One of the chief benefits of a colony having its own token is that it can offer rewards for work before it has any revenue or external funding to draw on. A new colony may offer token payouts for expenditures with the hope that the reputation earned by these token payments (and the future revenue earned by the colony) will eventually lead to financial rewards. By allowing ‘spending’ before fund-raising, the financial burden during the start-up phase of a new colony is eased. Once a colony is profitable, payment in tokens may be the exception rather than the norm.
Tokens representing hours worked We could imagine a colony in which all expenditures are paid in Ether, but include a number of the colony’s own tokens as well, equal to the expected number of hours worked. The members of the colony would be responsible for assigning ‘correct’ token and Ether payouts to expenditures.
This extra responsibility would also ensure users doing the same amount of work received the same reputation gain, rather than the reputation gain being dependent on the rates they charged.
Tokens as performance-based bonuses Alternatively, we could imagine a colony which seeks to balance predictable compensation (i.e. salaries) with performance-based incentives. Such a colony could pay out salaries in a token such as Ether or DAI, and reserve their internal token for performance-based bonuses (i.e. for hitting quarterly OKRs). Such an approach makes reputation (and decision-making power) a function of achievement, without making members of the colony feel as though their ability to pay rent depends on their ability to hit quarterly goals.
2.3.2 Colony’s Token contract
Colony has developed a customized Token contract, with some additional functionality:
• mint — lets the token contract owner introduce new tokens into circulation.
• burn — lets anyone permanently remove tokens from circulation.
In addition, Colony’s Token contract introduces the idea of ‘locking’ — tokens being nontransferrable until a one-way boolean flag is flipped. This is useful for colonies which want more control over how and when their tokens can be liquidated and exchanged.
This contract underlies the Colony Network Token and is the default token contract for new colonies, although colonies are free to choose any ERC20-compatible token.
2.4 Revenue and rewards
A colony may sell goods and services in exchange for Ether or any ERC20-compatible tokens, and this revenue may be sent to the colony’s address. Whenever a colony receives such payments, we say that the colony has earned revenue. Revenue is distinct from a colony’s working capital: the latter is the sum of all tokens held by the colony in various domains, while the former is implicitly defined as the colony’s token holdings not yet accounted for in any of the existing pots.
There is an expectation that some fraction of any Ether or other tokens received by the colony are paid out to their members. ‘Members’, in this context, means accounts holding both tokens and reputation in the colony. Whenever a colony distributes a portion of revenue to its members, we say that the colony is paying out rewards.
2.4.1 Processing revenue
Revenue accumulates as the colony receives transfers of tokens. In order to be processed, any user can make a special claimColonyFunds transaction, indicating for which token they wish to process accumulated revenue.
The transaction then calculates the amount of token-denominated revenue that has accumulated since the last such transaction, and transfers some proportion to the colony’s rewards pot. The remainder is then made available to the colony as working capital. The percentage split is configurable by the root permission via the setRewardInverse function.
2.4.2 Claiming rewards from the rewards pot
Rewards accumulate in the rewards pot. To trigger a payout to users (i.e. to make rewards claimable), a root user makes a special startNextRewardPayout transaction (no more than once every 60 days), initiating a process by which all members may claim a payout based on the reward pot’s holdings.
This reward payout transaction includes the specific currency that should be paid (reward payouts for each token are handled separately). Once the process begins, all users’ tokens are locked until they claim their payout. Locking is necessary because the token balance of each account factors into the rewards formula of equation. Locking is done by incrementing the token’s totalLockCount.
Our TokenLocking contract contains a locking mechanism ensuring that a user cannot move tokens while they have (token-weighted) votes to reveal; we use the same mechanism here to ensure that a user cannot move tokens after a payout is approved by the members of the colony but before the user has claimed their rewards. The colony has a counter for each user that is incremented whenever they claim a payout; they can also waive their claim to a payout that will increment this counter.
Rewards are only available to accounts that hold both tokens and reputation, and the amount claimable by each account depends on both token balance and reputation. Therefore we need to have a similar behaviour to ‘lock’ the reputation of the users for the payout. When a payout is activated, the current state of the reputation tree is recorded in the payout itself. Users are paid out according to their reputation in this state, rather than the most recent state, to ensure all users get an appropriate payout and to avoid exploiting the system (which might otherwise be possible via e.g. delaying reward collection until after completing an expenditure, increasing their reputation).
2.4.3 The rewards formula
The amount that each user (ui) of a colony © is entitled to claim (pi) is a function of their colony token holdings (ti) and their total reputation in the colony (ri):
This is a (normalised) geometric average of the user’s token holdings and reputation. We note that this is very unlikely to payout all the tokens set aside for a payout — the only way it would do so is if everyone had the same proportion of reputation in the colony as they did proportion of tokens in the colony. However, the geometric average is the natural way to fairly capture the influence of two variables with different ranges, and ensures that large token holders must earn large amounts of reputation to get the most from the payouts. The total reputation and user eputation in the colony are all provable on-chain at claim time via a Merkle proof that the ReputationRootHash contains some values claimed by the user; the user’s balance of colony tokens and the total number of tokens issued is trivial to lookup.
After some sufficiently long period of time (60 days), all unclaimed tokens can be reclaimed on behalf of the colony by a user, and the payout closed. Any users that have not claimed their payout by that point will still have their tokens locked, and they will remain locked until they issue a transaction waiving their claim to the payout (indeed, they already passively did this by not claiming it in a timely fashion). Unclaimed tokens are returned to the rewards pot and become part of the next reward cycle.
2.5 The reputation system
Reputation is a number associated with each user which attempts to capture the value of that user’s contributions to the colony over time. Reputation is used to weight a user’s influence in decisions related to the expertise they have demonstrated, and to determine amounts owed to a colony’s members when rewards are disbursed. Because reputation is awarded to users by either direct or indirect peer assessment of their actions, we argue that influence and rewards can be seen as being (roughly) distributed by merit. Colony’s aim is that the reputation system will enable an emergent and dynamic decision-making hierarchy in which all of the right people are in the right places.
Colony aims to be broadly meritocratic. Consequently, the majority of decisions in a trustless colony are weighted by the relevant reputation. Unlike tokens, reputation cannot be transferred between accounts, as it represents an appraisal of the account’s activities by their peers. Reputation must therefore be earned by direct action within the colony. Reputation that is earned will eventually be lost through inactivity, error, or misbehaviour.
2.5.1 Types of reputation
Reputation by domain
Reputation in this hierarchy, and a user has a reputation in all domains that exist — even if that reputation is zero. When a user earns or loses reputation in a domain, the reputation in all parent domains changes by the same amount. In the case of a user losing reputation, they also lose reputation in all child domains, but in this case the child domains lose the same fraction of reputation that was lost in the original domain. If a reputation update would result in a user’s reputation being less than zero, their reputation is set to zero instead.
An example makes this clearer. Suppose a colony has a ‘development’ domain which contains a ‘backend’ domain and a ‘frontend’ domain. Any time a member of the colony earns reputation for work completed in the backend domain, it will increase their backend reputation, their development reputation and their reputation in the all-encompassing root domain of the colony.
Reputation earned in the development domain will only increase the development and root domain reputation scores of the user.Later, the user behaves badly in the ‘development’ domain, and they lose 100 reputation out of the 2000 they have in that domain. They also lose 100 reputation in the parent domains, and 5%(100/2000) of their reputation in each of the child domains of the ‘development’ domain (which in this example, includes both frontend and backend domains).
2.5.2 Earning and losing reputation
There are three ways to receive reputation in a colony.The first (and by far the most common) is through receiving a payout via an expenditure. The second is through the arbitration process. The third is upon the creation of a colony and the associated bootstrapping process.
Reputation losses broadly occur as the result of arbitration, and extension contracts makes it possible to implement mechanisms which involve reputation penalties (such as tasks and disputes). In addition, all reputation earned by users is subject to a continual decay over time.
Reputation change via expenditures
Whenever an expenditure recipient receives a payout denominated in the colony’s internal token, the recipient also receives some amount of reputation, scaled by that recipient’s payoutScalar. A value of 1 gives reputation equivalent to the token payout, but a multiple of up to 2x is possible.
The reputation is earned in the domain (and all parent domains) of the expenditure, and divided equally among any skills associated with that recipient.
Reputation change as a result of arbitration
Arbitration permission holders have the ability to emit arbitrary reputation penalties (but not increases) in both domains and skills. While this might seem to be a significant power available to arbitration permission holders, recall that this permission will in many cases be assigned to extension contracts, which will mediate this ability via various mechanisms, such as the motions system.
Bootstrapping reputation
Since a trustless colony’s decision making procedure rests on reputation weighted voting, we are presented with a bootstrapping problem for new colonies. When a trustless colony is new, no-one has yet completed any work in it and so nobody will have earned any reputation. Consequently, no motions can be made and no disputes can be resolved as no-one is able to vote. Then, once the first expenditure is paid out, that user has a dictatorship over decisions in the same domains or skills until another user earns similar types of reputation.
To prevent this, when a colony is created, the creator can choose accounts to have initial reputation assigned to them in the root domain to allow the colony to bootstrap itself. The reputation assigned to each user will be equal to the number of tokens received, i.e. if a member receives ten tokens, they also receive ten reputation in the root domain. Given that reputation decays over time, this initial bootstrapping will not have an impact on the long-term operation of the colony. This is the only time that reputation can be created without an associated expenditure being paid out. Users receiving reputation are presumably the colony founder and their colleagues, and this starting reputation should be seen as a representation of the existing trust which exists within the team.
We note that the same is not required when a new domain is created in a colony. We do not wish to allow the creation of new reputation here, as this would devalue reputation already earned elsewhere in the colony. This bootstrapping issue is resolved by instead using reputation within the parent domain, when a child domain contains less than 10% of the reputation of its parent domain. A domain below this threshold cannot have domains created under it.
Reputation decay
All reputation decays over time. Every 90 days,4 a user’s reputation in every domain or skill decays by a factor of 2. This decay occurs every 1 hour, rather than being a step change every 90 days to ensure there are minimal incentives to earn reputation at any particular time. This frequent, network-wide update is the primary reason for the existence of the reputation mining protocol, which allows this near-continuous decay to be calculated off-chain without gas limits, and then realised on-chain.
The decay serves multiple purposes. It ensures that reputation scores represent recent contributions to a colony incentivising members to continually contribute to the colony. It further ensures that wild appreciations in token value (and the corresponding decrease in tokens paid per expenditure) do not permanently distort the distribution of reputation but instead serves to smooth out the effects of such fluctuations over time.
One might wonder why we have chosen to decay reputation, rather than pursue a strategy of reputation dilution via inflation. In one sense, they are equivalent: decaying reputation that is earned at a constant rate is the same as earning reputation at increasingly inflated valuations.
Mathematically, however, decay is the cleaner approach, and so the use-case for inflation is that it is more feasibly calculated on-chain. In the case of Colony, reputation cannot be calculated on chain, since reputation updates effect an unbounded number of reputation nodes (due to the unbounded size of the domain tree). Since reputation cannot be calculated on chain, we choose to decay reputation in our off-chain reputation mining process.
2.6 Managing stakes
Staking is a key concept in trustless systems, as a way to ensure that participants have ‘skin in the game’ and can be incentivized towards good behavior. As Colony wishes to enable an ecosystem of extensions implementing various cryptoeconomic mechanisms, a shared system for managing stakes improves usability and security by saving users from needing to send and retrieve tokens to and from many different contracts. In colonies, all stakes are denominated in that colony’s internal token.
2.6.1 Storing Tokens
All stakes are stored in the network-wide TokenLocking contract. A singleton contract has the advantage that in scenarios where a user is a member of multiple colonies sharing the same internal token, a single deposit suffices for all colonies.
Any slashing of stakes occurs as a result of a function call coming from the colony and is a result of colony-specific arbitration logic.
2.6.2 Approvals and Obligations
Stakes are managed via a sequence of approvals and obligations. Users approve an account to then obligate them up to the maximum amount of their approval. If an obligation is made in excess of the deposits held in the TokenLocking contract, the transaction will fail. Once an obligation is made, a user cannot withdraw tokens if the withdrawal would result in a balance less than their obligations. At any time, the approved extension can deobligate the user, freeing the tokens for withdrawal. In practice, we expect that the same underlying deposit will be obligated and deobligated repeatedly without the user needing to move any additional tokens.
While an obligation is active, any arbitration permission holder can slash the stake up to the amount of the obligation. We reiterate that this is a powerful ability and in most cases should be mediated by an appropriate extension.
For reasons of security, approvals are keyed by domain, as well as by address of approvee (i.e. approve(approvee, domain, amount)). Otherwise, a malicious actor could use any arbitration permission holder in the colony to slash a stake, rather than arbitration permission holders in the intended domain inheritance path. However, because TokenLocking does not know about the domain structure of specific colonies, the obligations in TokenLocking are aggregates of all colonyand domain-specific obligations.
Overall, this design allows arbitration to be generalized and separated from the implementation of any particular extension: extensions obligate a stake (and define the period of obligation), while during that period separate arbitration processes can slash that stake.
2.7 Upgradability and security
2.7.1 Upgradability
We foresee the Colony Network being continuously developed. roviding an upgrade path is important to allow people to use Colony without preventing themselves from using new features as they are added to the network. We intend to allow colonies and tokens to be upgraded by using the pattern made available under the name EtherRouter . This implementation uses two contracts in addition to the contract(s) providing the functionality implemented. The first additional contract is the EtherRouter contract, which passes on transactions — via delegatecall — to the contract that implements that function. The second additional contract is the Resolver contract, where the accounts of the contracts that implement the desired behaviour are defined. Whenever a transaction is received by the EtherRouter contract, it looks up the contract that implements that function (if any) in the Resolver, and then delegatecalls that contract. In order to upgrade, new contracts are deployed with new functionality, and then contracts that the Resolver contract points to must be changed to point to these new contracts. In order to avoid a situation where the contract partially implements both old and new functionality, a new instance of Resolver will be deployed for each upgrade, and then a single transaction can point EtherRouter at the new Resolver. From the perspective of the colony, an upgrade is then simply swapping out one address (the Resolver) for another.
The choice of upgrading the underlying Colony contract will always fall to the colony, and never the Colony Network. While the network is in control of what upgrades are available, they are not able to force any colony to upgrade the underlying contracts. The colony itself must decide that it wants to upgrade to a new version.
2.7.2 Security
While we aspire to bug-free contracts, bugs are inevitable, and so the adoption of a ‘defensive programming’ mentality will limit the impact of any vulnerabilities that may be discovered in the deployed contracts.
The ultimate fallback is known as ‘recovery mode’. In this state, whitelisted accounts (those with the recovery permission) are able to access special functions that allow the state of the contract to be directly edited — in practise, this will correspond to access to the functions to allow setting of variables, as well as being able to upgrade the contract. With the agreement of multiple whitelisted accounts, the contract will then be able to be taken out of recovery mode once the contract has been returned to a safe state. Removal from recovery mode requires the approval of multiple whitelisted accounts. This ensures that a single whitelisted account cannot, in a single transaction, enter recovery mode, make a malicious edit, and then exit recovery mode before the other parties on the whitelist have had a chance to react.
It is conceivable that colonies will be able to deactivate the recovery mode feature in the future, once the network and contracts have matured sufficiently.
In general, the contract may enter recovery mode due to:
• A transaction from a whitelisted account signalling that the contract should enter recovery mode.
• Something that should always be true of the colony not being true — for example, after an expenditure payout checking that the amount of funds promised to expenditures and not yet paid out is still less than the balance of the colony. If not, then abort the transaction and put the contract into recovery mode.
• A qualitative trigger suggesting something may be amiss — perhaps too many tokens have been paid out in a short amount of time.
Any approvals from whitelisted accounts to leave recovery mode must be reset whenever a variable is edited. A whitelisted account agreeing to leave recovery mode records the timestamp at which the agreement occurred, and any change of variables also update a timestamp indicating the last edit. When attempting to leave recovery mode, only agreements made after the last edit are counted towards meeting the threshold.
The first recovery permission holder is set at colony creation and is the creator of the colony. Additional recovery permission holders can be added by the root permission
2.8 Arbitrary transactions
Of course, it is possible that a colony will want to engage in some behaviour that we haven’t foreseen, that could be implemented in a contract outside the control of the Colony Network (such as changing a parameter in a contract when the colony as a whole is responsible for governing that contract). To that end, we wish to have a mechanism by which a colony can create an arbitrary transaction on the blockchain to interact with contracts and tokens without requiring the network to explicitly support them. As they are powerful, such transactions should be rare occurrences requiring root authorization.
3、Extending Functionality
The vision of Colony is the creation of decentralized, trustless organizations, in which decisions are driven by reputation, not a subset of moderators. Yet, at the level of the core Colony contracts, access is mediated by permissions, not reputation.
The decision to make ‘permissions’ Colony’s core access-control logic is doubly motivated. First, it makes it possible to launch a Colony which is admin-controlled (appropriate for small teams with substantial existing trust) and to transition to a more decentralized, trustless style of operating as the organization matures. Second, the permissions-based approach makes it possible to experiment with a wide variety of mechanisms without needing to continually deploy new Colony contracts.
Much like the distinction between kernel space and user space in the design of operating systems, permissions can be thought of as providing the system calls needed to give end-user applications (extensions) the ability to securely manipulate the underlying resources of the system. Just as this model has proven very successful in enabling a wide variety of software applications to safely share computing resources, so do we think that the colony-and-extensions model will be successful here.
3.1 Tasks
Unlike an expenditure, which represents an abstract transfer of resources, the ‘task’ represents a more concrete exchange of labor for value, and a unit of work requiring no further subdivision or delegation. A task has three roles associated with it:
• Manager -responsible for defining and coordinating the delivery of the task.
• Worker-responsible for executing the task.
• Evaluator-responsible for assessing whether the work has been completed satisfactorily.
The manager (initially the creator of the task) is responsible for selecting the evaluator and worker and setting additional metadata for the task:
• A dueDate.
• payouts for each of the manager, worker and evaluator.
• A specificationHash: the address of a specification on IPFS, used by the worker to guide the work, and the evaluator for assessing the satisfactory completion of the task.
In order to create a task, the manager must have the administration permission. Future variations of the ‘tasks’ extension may instead impose minimum reputation requirements and/or staking, making task creation trustless.
Defining what the payouts for each role should be, of course, does not provide the funds -this must be done through the funding mechanisms in Colony. Payouts do not have to all be in the same currency, and a task’s payout can be made up of an arbitrary number of currencies. If a payout for the task is denominated in the colony’s token, the recipient will also earn reputation when the task is completed as long as their work was well received.
If no worker has been assigned to a task, the manager has the ability to cancel the task entirely. Any funds that have already been assigned to the task via funding proposals may be reassigned to the domain of the task.
Assigning either the worker or the evaluator requires the mutual agreement of the manager and the assignee. Once assigned, changes which involve either the worker or evaluator (such as changing the task brief or due date, cancelling the task, or changing assignments or payouts) require mutual consent (i.e. multisig approval), or can be triggered via the motions process.
After the task has been assigned, the worker has until the due date to make a ‘final submission’, which includes some evidence that the work has been completed.
Once the due date has passed or the worker has made their submission, the evaluator may rate the work. Regardless of whether the rating is positive or not, the task enters a state in which motions to the change final state of the task can be raised and disputes can be initiated . Once the motions period has elapsed, payouts are eligible to be claimed.
As mentioned, the performance of the user who has completed the work is determined after the work is submitted. At this point, the evaluator grades the work submitted by the worker, and the worker rates the manager’s ability to coordinate delivery of the task, on a scale of one to three points. In the case of the evaluator, a rating of one point counts as them rejecting the work and a rating of two or three points counts as accepting the work. The rating received determines the reputation change the user will experience:
1 point: User was unable to complete the task. Reputation penalty equal to 1x payout.
2 points: User completed the task acceptably. Reputation gain equal to 1x payout.
3 points: User completed the task superbly. Reputation gain equal to 1.5x payout.
The worker receives reputation both in the domain (and parent domains) and the skill(s) of the task, while the manager receives only in the domains, not in the skill(s) as they have not actually done the task. While it is likely some knowledge is required to coordinate delivery of the task, this is not always the case; we believe that skill reputation should exclusively demonstrate ability to perform tasks.
Upon completion of a task, the evaluator also earns domain reputation (with an implicit rating of “2”). There is no explicit rating of the evaluator, but as with all other payouts a motion can be made before a payout is claimable; the outcome of the motion may be a reduction of payout or an explicit reputation penalty.
Tasks are built on expenditures, and implementing tasks as an extension contract makes use of the arbitration and administration permissions — the latter to manipulate the expenditure and the former to implement consequences of the rate-and-reveal flow.
When the task is finalized, the underlying expenditure’s claimDelays are set to allow for motions to be made. Based on the rating recipients receive, their payoutModifiers are set to give a reputation boost (for an excellent review) or reduce the payout they can claim (for an unsatisfactory review). Also in the case of an unsatisfactory review, a reputation penalty is emitted.
3.2 Funding queues
Section 2.1 describes the funding permission, which is used to transfer funds in between funding pots. This permission is powerful — for daily operations, it is better to mediate the allocation of funds via a more specialized mechanism. One such mechanism is the funding queue, which leverages time as a driving factor to enable collaborative, asynchronous, and trustless decision-making, without voting.
The essential idea behind the funding queue is that tokens are continuously allocated over time, rather than all at once in a pass/fail fashion, with user inputs controlling the speed and direction of the allocation. As an analogy, one can think of water running down a mountain, where the shape of the mountain determines the direction and speed of the flow. With funding queues, users determine this shape. Whereas with voting-based systems, unpopular proposals fail entirely, with a funding queue, unpopular proposals simply take a very long time to be fulfilled, while popular proposals are fulfilled quickly.
Any member of the colony may create a funding proposal. The proposer must have 0.1% of the reputation of the domain that is the most recent common ancestor of the source and target pots, and stake an equivalent amount of the colony’s tokens. This stake is used to help discourage spamming of funding proposals and provide a mechanism whereby the creator can be punished for bad behaviour.
A funding queue contains of a series of funding proposals, each with the following attributes:
• Creator — The person that created the proposal.
• From — Funding pot funds are coming from.
• To — Funding pot funds are going to.
• TokenType — The token address (0x0 for Ether).
• CurrentState — The state of the proposal (i.e. inactive, active, completed, cancelled).
• TotalPaid — Amount transferred thus far.
• TotalRequested — The total amount requested.
• LastUpdated — The time when the proposal was last updated.
• Rate — Rate of funding, a function of the backing reputation.
We distinguish between two types of funding proposals: Basic Funding Proposals (BFP) intended for normal use, and Priority Funding Proposals (PFP) intended to be used when a basic proposal is inadequate, or for unusual circumstances. The basic funding proposal may start funding the target straight away, whereas a priority funding proposal must be explicitly voted on before it starts directing funds.
Furthermore, for a basic funding proposal the target pot must be a direct descendant of the source in the hierarchy whereas a priority funding proposal has no such restrictions. Priority funding proposals should be used when funds need to be directed somewhere that is not a direct descendant of the source, when the funding rate needs to be very high (including immediate payment), or when multiple funding proposals must occur in parallel (e.g. in the case of paying of salaries).
3.2.1 Attributes in detail
From, To and TokenType The purpose of a funding proposal is to move tokens of TokenType from pot From to pot To. The TokenType may be Ether or any ERC20-compatible token. The From field must be a funding pot associated with a domain or an expenditure in the colony, while the To field may be any funding pot. If the funds are to move ‘downstream’ from a domain to one of its children, a basic funding proposal is often sufficient.
CurrentState The state of a funding proposal is either inactive, active, completed or cancelled. Only an active funding proposal is in line to channel funds. A basic funding proposal begins in active state while a priority one begins inactive (i.e. it must be activated by a vote). A funding proposal is active until it is either completed (when its TotalPaid reaches TotalRequested) or cancelled.
The creator of a funding proposal may cancel it (setting CurrentState to cancelled) at any time. This is analogous to the creator of a task being able to cancel the task if it has not yet been assigned a worker. Note that if an expenditure is cancelled, funding proposals that have that expenditure’s funding pot as their target (To) are automatically cancelled when they are next pinged, and no funds are reallocated.
However, the funds that had already been transferred are not automatically returned; it may require a PFP to return the funds ‘upstream’. TotalPaid and TotalRequested The total number of funds that a funding proposal wishes to reallocate is called its TotalRequested amount. Due to the mechanism by which funding proposals accrue funds over time, it is common that a funding proposal will have received a part but not all of its TotalRequested amount. The total number of tokens accrued to date are stored in its TotalPaid amount. The creator of a funding proposal may edit the TotalRequested property of a funding proposal at any time, but doing so resets the reputational support that the proposal has in the funding queue to zero. The intention here is for changes to funding to be potentially quick to achieve with the agreement of others in the colony if the requirements for the recipient pot change (e.g. the scope of a domain increases).
Rate and LastUpdated
When a funding proposal is eligible to accrue funds, it does so at a specific Rate, denominated in ‘tokens per second’. Since nothing happens on the blockchain without user interaction, the funding system uses a form of lazy evaluation. To claim funds that the proposal is due, a user may ‘ping’ the proposal — i.e. the user manually requests a pro-rated distribution of funds. When pinged, the time since LastUpdated is multiplied by the Rate to determine how many tokens the proposal would have accrued in the interim if funding flow were continuous. This amount is added to TotalPaid, the funds are transferred, and the current time is recorded as LastUpdated.
3.2.2 Basic funding proposals
A basic funding proposal (BFP) is a funding proposal from some domain’s funding pot to one of its children’s. It starts out in the active state and is thus immediately eligible for funding. It may be cancelled at any time by the Creator.
Ordering of BFPs
When created, a basic funding proposal gets placed at the back of the queue. Users can give a proposal ‘backing’ weighted by their reputation in the source domain at the time of backing.
The more reputation backs a proposal, the higher up the queue it is placed. Every transaction that adds backing to a proposal (or otherwise updates the backing level) inserts the proposal in the correct place in the queue. Only the proposal at the front of the queue accrues funds.
There are no costs to backing a proposal (other than gas costs) and the users obtain no direct benefits; it does not represent them putting their earned reputation at risk, nor any tokens — it merely helps the proposal achieve funding in a more timely fashion, and benefits them indirectly by helping the colony run better.
The rate of funding for BFPs
The more reputation backs a proposal, the faster it is funded. The rate scales linearly, and at the limit, if 100% of the reputation in the source domain backs a basic funding proposal, then that funding proposal will be funded at a rate of 50% of the domain’s holdings (of TokenType) per week.
The goal is a steady and predictable allocation of resources directed collectively by the domain’s (reputation weighted) priorities. When a user backs a proposal, both the user and their reputation at the time are recorded.
Consequently, the user is able to update their backing at a later date. However, we note that such an update is not automatic and even if a user loses reputation due to bad behaviour, their backing level remains unchanged until explicitly updated. Anyone is allowed to make this update — imagine a scenario where a user lost a lot of reputation due to bad behaviour, and other users wanted to stop a funding proposal backed by that user from continuing to accrue funding.
We emphasised that a user could back a proposal with their reputation at the time of backing because the reputation backing a proposal will not change when that user’s reputation does so. If by a quirk in this system, the reputation recorded as backing a funding proposal ends up higher than 100% of the total of that reputation in the colony, then the funding occurs no quicker than it would at 100%.
Completing a BFP
If an update finds that a proposal is fully funded (i.e. TotalPaid = TotalRequested), it is removed from this queue to allow the next-most-popular funding proposal to accrue funds. Explicitly, the following steps need to happen:
1. The time at which the funding proposal was fully funded is calculated.
2. TotalPaid is set to TotalRequested.
3. The BFP is removed from the queue.
4. The next BFP in the queue is promoted to the top of the queue, and its
LastUpdated time is set as the time calculated in 1.
Three days after the BFP has been fully funded (and thus complete) the creator’s stake is released. Until that time, the stake can be slashed by the arbitration permission.
3.2.3 Priority funding proposals
A priority funding proposal (PFP) is a funding proposal that can request funds to be reallocated from any pot to any other at any rate. PFPs begin in the inactive state and can only become active via an explicit vote. The vote is based on reputation in the domain that is the most recent common ancestor of the two pots that money is being transferred between. We imagine PFPs will be used to:
• reclaim funds from child domains.
• reclaim funds from cancelled tasks.
• fund tasks across domains.
• set aside funds designated as a person’s salary.
• make large, one-off payments.
Unlike Basic Funding Proposals, Priority Funding Proposals are not ordered in a queue -all active PFPs are eligible to receive funding at any time. Note that, since the amount of funds transferred is ultimately a function of the funds available, too many large PFPs can interfere with each other (and the leading BFP) by substantially reducing the amount of funds available in the funding pot.
3.3 Budget box
As an alternative to funding queues, colonies may instead choose to use a Budget Box to allocate funding between subdomains (or to divide funds among multiple recipients of an expenditure). Compared to funding queues, in which items are funded serially, Budget Boxes allow items to be funded in parallel, proportionally out of some fixed budget.
3.4 Motions and disputes
The most successful organisations are those which are able to effectively and efficiently make decisions, divide labour, and deploy resources. Often, these many decisions are structured via management hierarchies. But trustless colonies are intended to be low trust, decentralised, and pseudonymous — a hierarchy is not suitable.
In most DAO frameworks, the mechanism of collective-decision making is usually voting, but Colony is designed for day-to-day operation of an organisation. In a colony, voting on every decision is wholly impractical. The emphasis should be on ‘getting stuff done’ and not about ‘applying for permission’. Therefore, Colony is designed to be permissive. Task creation does not require explicit approval, nor do basic funding proposals or any number of administrative actions throughout a colony.
The Motions System provides a self-regulating mechanism which, via a balanced set of incentives, lets users keep their colony running harmoniously. It is there to resolve disagreements and to punish bad behaviour and fraud. The motions system allows colony members to signal disapproval of and potentially force a vote against users who have acted inappropriately.
When a member of a colony feels that something is amiss, they may make a motion. By doing so, they are fundamentally proposing that either a) a variable, or more than one variable, in the colony should be changed to another value, or b) a user, or more than one user, should receive a reputation penalty. For this reason we call supporters of the motion the ‘change’ side and opponents the ‘keep’ side.
The user making the motion must also put up a stake of the colony’s internal token. In essence, they are inviting the rest of the colony to disagree with them. In the spirit of avoiding unnecessary voting, the motion will pass automatically unless someone else stakes on the ‘keep’ side and thereby elevates the motion to a dispute.
We say that a dispute has been made whenever a motion has found support on both the ‘change’ side as well as the ‘keep’ side. Once raised, disputes must be resolved by voting.
3.4.1 Making motions
The user making a motion submits the following data:
• The data that should be changed, or users to receive penalties.
• The reputation(s) that should vote on this issue (a maximum of one from each of the domain and skill hierarchies).
• Proof that these reputations should be allowed to make the change in question.
The first item identifies the subject of the motion, and what the appellant believes the state should be. The second and third points concern appeals. The basic rule in Colony is: you cannot appeal a decision to higher management, you can only appeal to larger sets of reputation.
For example, suppose that the motion concerns a task in the ‘frontend’ domain. The appellant could choose to have all ‘development’ reputation vote on it -we say the decision was ‘appealed to the development domain’. In this example, the third point would be a proof that the domain ‘frontend’ was indeed a subdomain of ‘development’. The highest domain any decision can be appealed to is the root domain, where all domain reputation is entitled to vote.
Whenever an appeal occurs, we need to ensure that the reputation we are appealing to is a parent of the reputation associated with the variable being changed. This is possible to do efficiently because of metadata that is placed on the reputations (for domains) when they are created, which includes pointers to at least the direct parent. When a user makes a motion, instead of directly specifying the domain they are appealing to, they provide the steps needed to get there from the domain associated with the variable that is to be changed. This ensures that the domain they appeal to is a direct parent of that associated with the variable.
3.4.2 Costs and rewards
Cost of making a motion
To make a motion, a user must possess enough reputation and must also stake some number of the colony’s tokens. The reputation they need to be able to make the motion depends on the domain they are appealing to; the ‘higher up’ the decision goes, the higher the reputation requirement (and potential loss). To be able to create a motion, the user must have 0.1% of the reputation in the domain and must stake 0.1% of the corresponding fraction of tokens. Thus, if a motion involves 13% of total colony reputation, then the motion requires 0.013% (0.1% of 13%) of reputation and the required stake is 0.013% of all colony tokens.
If the initial user does not have the required number of tokens or reputation, they can still create such a proposal by staking as little as 10% of the tokens required, which requires them to have a correspondingly smaller amount of reputation. In this case the motion will not be ‘live’ until other users stake tokens, and take it over the 0.1% threshold. The amount of tokens required to be staked for a particular motion is recorded at the time when it is created. Users can only stake tokens in proportion to the reputation they have. For example, if they wanted to stake 40% of the tokens required, they must have at least 40% of the reputation that would be required to create the motion outright.
Cost of opposing a motion
Once enough tokens have been staked on a motion it becomes active and, barring any further actions for three days, the suggested change will take place (when the motion is ‘pinged’ by a user).
However, if there are users who oppose the suggested ‘change’, they may stake tokens in support of the ‘keep’ side. If the keep side receives sufficient support, a dispute is created.
If the ‘change’ side does not garner enough support in three days, the motion fails and is rejected. If, three days after the ‘change’ side had enough tokens staked and the ‘keep’ side does not, then it is assumed that the change is acceptable.
Voting on disputes
If both sides stake the required number of tokens within the time limit, then the dispute goes to a vote. The weight of a user’s vote is the sum of their reputations in the skills chosen by the user who originally made the motion.
The duration of the poll is determined by the amount of reputation eligible to vote as a fraction of reputation in the colony. If a larger fraction is eligible, the longer the poll is open for. The minimum duration is two days and the maximum is seven. This is a trade-off between allowing disagreements between small groups to be resolved quickly, but to also allow adequate debate to occur when more people are involved.
Voting takes place using a commit-and-reveal-scheme. This scheme is desirable because votes are kept secret during the voting period, preventing users from being influenced by what they perceive to be the majority opinion.To make a vote, the user submits a hash that is keccak256(secret, optionId), where optionId indicates the option that the user is voting for. Once voting has closed, the poll enters the reveal phase, where a user can submit (secret, optionId) and the contract calculates keccak256(secret, optionId) to verify it is what they originally submitted.
As the secret is revealed it cannot be sensitive. It must also change with each vote so that observers cannot establish what people are voting for after they have revealed their first vote. While there are many reasonable schemes for generating secure secrets, we suggest a (hash) of the consequence field of the poll signed with their private key, as it is easily reproducible by a client at a later date with no local storage required.
To combat voter apathy, 10% of the staked tokens are set aside to pay voters when they vote: if a voter has 1% of the reputation allowed to vote on a decision, they receive 1% of this pot that is set aside. They receive this payout when they reveal their vote, regardless of the direction they voted in or the eventual result of the decision. This ‘payout regardless of opinion’ is to avoid us falling victim to the Keynesian beauty contest, in which due to receiving a reward for being “correct”,
voters are incentivised to vote for what they believe most other people will vote for, rather than what they independently believe. Any tokens that would have been awarded to users who abstained from voting, or are not revealed in the reveal window, are sent to the root domain funding pot once the poll closes.
Once a vote has been in the reveal phase for 48 hours, a transaction may be made to finalise the vote. Any subsequent reveals of votes do not contribute to the decision being made, but serve only to unlock the user’s tokens if it was a token-weighted or hybrid vote.
Consequences of the vote If the ‘change’ side wins the vote then the change in question is made, but only if the reputation that voted for this outcome is more than previous votes on the same variable. If the ‘keep’ side wins, then the variable is not changed. In either case, the fraction of total reputation in the colony that voted for the winning side is noted.
At the conclusion of the poll, losing stakers receive 0–90% of their staked tokens back and they lose the complementary percentage of the reputation that was required to stake. The exact amount of tokens they receive back (and therefore reputation they lose) is based on:
• The fraction of the reputation in the colony that voted.
• How close the vote ultimately was.
At the end of a vote, if the vote was very close, then the losing side receives nearly 90% of their stake back. If the vote is lopsided enough that the winning side’s vote weight (w) reaches a landslide threshold (L) of the total vote weight, then they receive 0% of their staked tokens back. L varies based on the fraction of total reputation in the colony that voted (R):
So for a small vote with little reputation in the colony being allowed to vote, the decision has to be close to unanimous for the losing side to be punished harshly. For a vote of the whole colony, the landslide threshold L reduces to 67% of the votes — i.e. the reputation of the colony overall was split 2-to-1 on the decision.
Between these extremes of a landslide loss and a very slim loss, the loss of tokens and reputation suffered by the losing side beyond the 0.1 minimum (∆) varies linearly:
and so the total loss (0.1 + ∆) varies between 0.1 and 1.
What happens to the tokens lost?
Any tokens lost beyond the initial 10% are split between the colony and those who staked on the winning side, proportional to the amount they staked. Half of the reputation lost beyond the initial 10% is given to those who staked on the winning side, and half is destroyed (the colony as a whole having reputation has no meaning, unlike the idea of the colony as a whole owning tokens).
The motivation here is efficiency — it aims to discourage spurious motions and disputes. A close vote is a sign that the decision was not a simple one and forcing a vote may have been wise.
Therefore, the opposition should not be harshly punished. On the other hand, if a vote ends in a landslide, it is a sign that the losing side was going up against a general consensus. We encourage communication within the colony. Members should be aware of the opinions of their peers whenever possible before motions are made.
Repeated motions
In order to reduce the number of repeated motions and disputes over the same variable, the fraction of total reputation in the colony that voted for the winning side is recorded after every vote. This is the threshold that must be exceeded in any future vote in order to change the variable again.
We reiterate that this value is updated after every vote on the variable, even if the decision was to maintain the current value of the variable.
This requirement is the primary driver of the appeals process. If a decision was made in a domain, with low voter turnout, then it may be possible to reverse the decision by holding another vote in the same domain (along with a more vigorous off-chain get-out-the-vote campaign). However, if a large fraction of the domain’s reputation participated in a vote, then the only way to gain the support of a larger body of reputation (necessary to reverse the decision) would be to appeal the motion to a higher domain, or to a larger body of skills.
There is one exception to this rule: to ensure that a variable can always be changed if necessary, this threshold for changing the variable is ignored if the motion was appealed to the root domain of the colony. Anytime a vote is held in the root domain, regardless of prior votes on the variable, the variable can be changed.
3.4.3 Types of vote
Depending on the context and potential consequences of the vote, Colony supports three types of voting. The type of vote a particular action merits is predetermined based on the action, and is not a choice of the appellant.
Reputation-weighted voting
Most votes in a colony will be due to motions related to tasks. In these cases, the weights of the users’ votes is proportional to the reputation that each user has in the domain and skill that the vote is taking place in. When such a vote starts, the current reputation state is stored alongside the vote. This allows the current reputation state to be ‘frozen’ for the context of the vote, and prevents unwanted behaviours that might otherwise be encouraged (for example, delaying submission of a task until closer to voting so that the reputation earned has not decayed as much).
When revealing their vote, the user also supplies a Merkle proof of their relevant reputation contained within the reputation state that was saved at the start of the vote. The total vote for the option they demonstrated they voted for is then incremented appropriately.
Token-weighted voting
While Colony encourages the use of reputation as the primary sibyl-resistance mechanism, there are situations where tokens are more appropriate. Specifically, if reputation is a stand-in for ‘labour’, and tokens are a stand-in for ‘capital’, then token-weighted votings are appropriate whenever a decision must be made by capital, rather than by labour. Whenever a decision would be made by ‘investors’ or ‘shareholders’ in a conventional firm, a token-weighted vote may be appropriate.
Unlike with reputation, we do not have the ability to ‘freeze’ the token distribution when a vote starts. While this is effectively possible with something like the MiniMe token, we envision token-weighted (or hybrid) votes will still be regular enough within a Colony that we do not wish to burden users with the gas costs of deploying a new contract every time.
When conducting a token-weighted vote, steps must be taken to ensure that tokens cannot be used to vote multiple times. In the case of ‘The DAO’, once a user had voted their tokens were locked until the vote completed. This introduced peculiar incentives to delay voting until as late as possible to avoid locking tokens unnecessarily. Our locking scheme avoids such skewed incentives by locking tokens only during the reveal period.
Instead, once a vote enters the reveal phase, any user who has voted on that poll will find themselves unable to see tokens sent to them, or be able to send tokens themselves — their token balance has become locked. To unlock their token balance, users only have to reveal the vote they cast for any polls that have entered the reveal phase — something they can do at any time. Once their tokens are unlocked, any tokens they have notionally received since their tokens became locked are added to their balance. This global lock prevents a scenario, for example, where one user would reveal their vote and then send tokens to a colluding user, who would then reveal their vote using theaugmented token balance.
It is possible to achieve this locking in constant gas by storing all submitted secrets for votes in a sorted linked list indexed by closeTime. If the first key in this linked list is earlier than now when a user sends or would receive funds, then they find their tokens locked. Revealing a vote causes the key to be deleted (if the user has no other votes submitted for polls that closed at the same time).
This will unlock the tokens so long as the next key in the list is a timestamp in the future. A more detailed description of our implementation can be found on the Colony blog.
Insertion into this structure can also be done in constant gas if the client supplies the correct insertion location, which can be checked efficiently on-chain, rather than searching for the correct location to insert new items.
Hybrid voting
A hybrid vote would allow both reputation holders and token holders to vote on a decision. We envision such a vote being used when the action being voted on would potentially have a sizeable impact on both reputation holders and token holders.
This would include altering the supply of the colony tokens beyond the parameters already agreed or when deciding whether to execute an arbitrary transaction.
In order for a proposal to successfully pass through a hybrid vote a majority of both reputation and token holders who vote must agree that the change should be enacted.
3.5 Miscellaneous
3.5.1 Token management
While root users can mint tokens at-will, in many cases it will be desirable to mediate this ability via an extension contract. Here we describe such an extension.
Token generation and initial supply
When the extension is deployed, the TokenSupplyCeiling and the TokenIssuanceRate are set.
The former is the total number of colony tokens that will be created and the latter is the rate at which they become available to the root domain to assign to subdomains or expenditures. The number of tokens available to the root domain can be updated at any time by a transaction from any user (i.e. a public function will determine the pro-rated amount of tokens to generate since the last distribution).
Increasing the TokenSupplyCeiling
It is advised that new tokens not be generated without widespread consensus — especially if tokens have a financial value. Consequently, such decisions require a vote with high quorum and majority requirements involving both the token holders and reputation holders.
Changing the TokenIssuanceRate
The TokenSupplyCeiling represents the total number of tokens that the token holders have granted to the colony in order to conduct business: to fund domains and expenditures, and to incentivize workers and contributors.
The TokenIssuanceRate controls how rapidly the colony receives the new tokens. If the rate is ‘too high’, tokens will accumulate in the funding pot of the root domain (or other funding pots lower in the hierarchy). If the rate is too low, this signals that the colony has a healthy amount of activity and that the issuance rate has become a bottleneck. In such situations it may be desirable to increase the rate of issuance without necessarily increasing the maximum supply.
Increasing and decreasing the TokenIssuanceRate by up to 10% can be done by the reputation holders alone and this action can be taken no more than once every 4 weeks. Larger changes to the issuance rate should additionally require the agreement of existing token holders.
3.5.2 Compensation Modalities
Using expenditures, it is possible to implement many types of compensation modalities. In addition to the ‘task’, we can conceive of a number of additional modalities of compensation.
Salaries
Tasks imply colony-worker relationships are mostly transactional. In many cases, it is desirable to represent more long-term relationships via a salary.
A salary can be as simple as a recipient, amount, and period, and lastClaimed. At any point, the recipient can ping the salaries contract, at which point the contract will create an expenditure made out to the recipient, with funding equivalent to the pro-rated amount since the last salary payout. If the recipient is willing to pay the gas costs, they could conceivably claim (a fraction of) their salary daily, or choose to claim weekly, monthly, or at whatever cadence suits them. It would be the responsibility of the colony to ensure that adequate funding is available in the domain out of which salaries are to be paid.
This extension would need the funding and administration permissions to manipulate tokens and expenditures on behalf of the recipients.
Recurring or Automatic Tasks
While for certain kinds of work, tasks are unique and must be individually scoped out and subjectively evaluated. However, we can imagine situations where work can be done by many people and/or evaluated automatically by computer (such as rewarding users for participating in a referral program). In these cases, a variation of the task which contains logic for evaluating the work, and allows anyone to submit the work, would be appropriate.
This extension would need the funding and administration permissions to manipulate tokens and expenditures on behalf of the recipients.
3.5.3 Awarding reputation for work not captured by tasks
This prevents a permanent ‘reputation aristocracy’ and allows reputation to remain relevant even after major changes in the colony token’s value.
Reputation is awarded when a user receives payment of a colony’s internal token- most commonly as payout from an expenditure, but sometimes from motions resolution and, in the case of the Metacolony, from the reputation mining process. We can use the expenditure mechanism to award users extra reputation when there is consensus to do so.
Consider the scenario in which a founder, or an important early contributor to a colony has almost no reputation left by the time the colony starts earning revenue; perhaps the development of the product took a long time or perhaps the reputation decay rate was sub-optimally high for the particular colony. Or perhaps the founder was doing a lot of intangible work to get the colony off the ground in the first place and so was never compensated properly on-chain. To get around the limitations of the reputation system and to re-integrate the founder (and make them eligible to receive their rewards), the colony can create an expenditure that is solely designed to award the reputation they are due. To qualify for the payout of tokens (and thereby the reputation), the user in question would have to give the same number of tokens back to the colony. Again, a good frontend abstraction could make such reputation awards easy and intuitive.
Another important scenario concerns absences due to maternity/paternity or illness -the reputation system should not implicitly discriminate against these users. While ‘pausing’ reputation decay is not a viable option, various mechanisms of giving reputation ‘for free’ can be used to ensure that these users retain their reputation during periods of unavoidable absence.
The important point is that any limitations imposed by the system can be weakened if there is consensus to do so. The system should not stand in the way of consensus, it should just provide conflict resolution mechanisms for those times in which there is dissent.
3.5.4 Motions by non-members
Having reputation is a prerequisite for creating a motion or staking an opposition. Therefore, if an outsider is hired by a colony to perform a task, they will not, on their own, be able to make a motion in defense of their work. However, a good colony frontend may allow them to create the template for a motion, effectively calling for members of the colony to support it and submit the motion to the colony network on-chain on their behalf.
This is analogous to a member staking only 10% of the required amount and waiting for further support from their peers, with the difference being that without any third party support, the motion would never be processed on-chain.
4、The Colony Network
The Colony Network is a collection of contracts on the Ethereum blockchain. At the core of the network is the ColonyNetwork contract. This contract is primarily responsible for managing the reputation mining process, but also for general management of the network: deploying new colonies, setting the fees associated with using the network, and releasing new versions of the Colony contracts. These actions will be mediated by a special colony, the Metacolony.
4.1 Revenue model
The Colony Network must be able to sustain itself. In particular, the Metacolony (which controls the Colony Network) maintains the contracts that underpin the network and develops new functionality for the network — development of which needs to be paid for. Long term, the development and maintenance of the network (including the reputation system) needs to be financed by the network itself.
4.1.1 The network fee
We propose a fee levied on expenditure and reward payouts. When a user claims a payout, some small fraction will be paid to the network. The fees are sent to either the Metacolony (if the payment was in Ether or another whitelisted ‘currency’ token) or the Colony Network contract (if it is any other ERC20-compatible token).
This idea of a fee is a little unusual for such a decentralised system. One of the appeals of decentralised systems on Ethereum is that other than gas costs, they do not seek rent and are free to use. However, the network fee is key to ensuring the game theoretic security of the Colony Network’s reputation mining and governance processes, by providing underlying value to the CLNY held by Metacolony members. Importantly, this fee is not payable to any centrally controlled entity, but rather to the Metacolony. As anybody may contribute to the Metacolony, anyone may claim a share of these fees proportional to their contribution. We believe that the benefit of being part of a secure, well maintained network will be appealing enough that a small fee to pay for its existence will be acceptable.
The presence of this fee means we have to make some considerations which would otherwise be irrelevant. Primarily, we will need to make ‘piggyback’ contracts as hard as possible to make that might e.g. be used to pay out an expenditure payout when a expenditure was finalized, but without sending the fee.
4.1.2 The token auction
As the network fee may be denominated in any ERC20 token, there is a need for a mechanism to liquidate arbitrary bundles of tokens: the token auction. The tokens collected are auctioned off by the Colony Network Contract, with the auctions denominated in Colony Network Tokens, the proceeds of which are burnt. These auctions-one for each type of token collected-occur on a regular basis of once a month.
We believe such a mechanism will be beneficial for the Colony Network Token holders (whose tokens gain value by having an explicit use beyond reputation mining) and the Metacolony itself (by reducing the supply of Colony Network Tokens and thus making any future minting more valuable).
It also provides an immediate mechanism of price discovery for a colony’s internal tokens, which are unlikely to be traded on third-party exchanges until much later in the lifetime of the colony.
By auctioning off the collected tokens, we also prevent the Metacolony collecting a large number of different tokens that it has to manage, which would prove cumbersome and annoying.
4.2 The Metacolony and CLNY
The Metacolony is a special colony which governs the Colony Network. Tokens in the Metacolony are known as CLNY and will be initially generated during the Colony Network distribution period.
4.2.1 Role of CLNY holders and the Metacolony
CLNY holders have two primary roles. The first is to participate in the reputation mining process. The second is management of the Colony Network itself. There will be permissioned functions on the Network Contract to allow fundamental parameters of the network to be set, which can only be called by the Metacolony. For these permissioned functions to be called by the Metacolony, a vote open to all CLNY and reputation holders must be conducted. Management of the Colony Network also includes making updates to Colony contracts available to colonies. CLNY holders are not necessarily responsible for the development of these updates, but are required to vote to deploy them. They are therefore responsible for at least ensuring due diligence is done, either by themselves or by service providers, to avoid introducing security weaknesses or other undesirable behaviour. In return for the responsibility of the development and maintenance of the Colony Network, the Metacolony is the beneficiary of the network fee.
Reputation in the Metacolony can be acquired by earning CLNY tokens by via expenditure payouts just as in any other colony. Reputation in the Metacolony can also be earned by participating in the reputation mining process, which is unique to the Metacolony.
4.2.2 Handing off decision-making power to the Metacolony
Colony Network Token holders are responsible for reputation mining from the start, but decisions about the underlying properties of the network will initially be made by a multisignature contract controlled by the Colony team. As the network develops and is proved to be effective, control over these decisions will cede to the Metacolony.
Stage 1: Colony team multisig in control
Initially, the Network Contract’s functions will be root-permissioned to only allow transactions from the multisig contract under the control of the Colony team to change these properties of the network.
Stage 2: Colony team multisig approval required
At a later date, an extension contract will be set up and given the root permission. This contract will allow the Metacolony (as a whole, via the governance mechanisms provided to all colonies) to propose changes to be made to the Colony Network Contract. The intermediate contract will have functionality such that all changes will have to be explicitly allowed by the account under the control of the Colony team. In other words, the Metacolony will be able to propose changes, but the team must sign them off.
Stage 3: Colony team multisig retains veto
The next stage will be a second extension contract operating similarly to the first, but after a timeout — with no interaction from the Colony team’s account — the change will be able to be forwarded to the Colony Network Contract by anyone. The Colony team’s role will be to block changes if necessary. Thus at this stage the Metacolony will be able to make changes autonomously, but the Colony team retains a veto. The proposal to move to this contract will have to come from the Metacolony itself.
Stage 4: Metacolony fully controls the network
Finally, the specialized extension contract will be removed and replaced with a generic voting extension, and the Metacolony will have direct control over the Colony Network Contract with no privileged control available to the Colony team other than that provided by any CLNY and reputation held.
- Reputation Mining
The reputation system is a core component of any decentralised colony. By carefully balancing the rewards and penalties we aim to keep every users’ incentives aligned with the colony and the colony network. Since reputation can only be earned and not transferred between accounts, the system fosters a more meritocratic form of decision making than pure token-weighted voting can hope to achieve. The continuous decay of reputation ensures that the influence conveyed by reputation is
recently earned and up-to-date. As such, it prevents a reputation aristocracy and allows for a fluid passing of control from one set of contributors to another over time.
Due to the combined complexity of reputation scores across multiple colonies, domains, and skills, reputation scores cannot be stored or calculated on-chain. Instead, the calculations will all take place off-chain, the results of which will be reported to the blockchain by participating CLNY holders -in a process resembling a proof-of-stake blockchain consensus protocol. We call this procedure Reputation Mining.
The reputation calculation whose result the miners are submitting is determined by the activities that have taken place in the colonies and can be fully deterministically derived from the Ethereum blockchain. Game-theoretically the system is protected similarly to the off-chain calculations of TrueBit in that, while the calculation cannot be done on-chain and a correct submission can never be proved true, an incorrect calculation can always be proved to be wrong.
Appendix
Decentralized Capital Allocation via Budgeting Boxes
The cornerstone of this mechanism is a novel component called a Budgeting Box, implementing a simple, general, and powerful governance algorithm, budgeting boxes aggregate and process sets of pairwise preferences. Our approach involves converting our set of pairwise preferences into a Markov transition matrix M, and using this matrix to find an eigenvector v corresponding to a probability distribution over the items, which we may alternatively interpret as a budget or ranking. Intuitively, we can think of the final probability as the likelihood of that item being “the most important thing”, based on the observed preferences.
Our voting information converted into an irreducible, aperiodic, ergodic Markov matrix guaranteed to possess a unique principal eigenvector interpretable as a probability distribution over the items, or alternatively as either a ranking or allocation of a budget. A number of methods exist for finding eigenvectors; we will use power iteration, a straightforward algorithm returning v to a precision of E.
Intuitively, every iteration first asks “which items are the most popular?”
and then “for every item, which items are even more popular?” Over time, probability mass converges to the items which have been relatively preferred, as popular items accumulate more probability, which they then “send forward” to items more popular than they.
1、Scalability
A limit of K items per box does not restrict a mechanism to K items overall, as multiple budgeting boxes can be composed to accommodate larger sets of items. One approach to the composition is to assemble boxes into a tournament bracket); another approach is to compose them into a recursive hierarchy of “abstract to concrete” (think public services → education → primary schools).The composition of budgeting boxes reduces cognitive complexity in tandem with computational complexity. For 100 items, there are 4,950 possible pairs; compare this to 10 · 45 = 450 pairs when this same 100 is divided into 10 groups of 10. These 450 pairs are a subset of the original 4,950 –but not a random one. If we posit that these 100 items can be ordered by quality, and that only comparisons between items of similar quality provide useful information, then subdividing the set of items into subsets of items of similar quality allows us to avoid making 4,500 low-value comparisons: a 10x improvement in cognitive efficiency.
2、Leagues and Lanes
To make the best use of the limited attentional resources of the voters, we divide the set of items into two categories: those in the leagues (each league being essentially a thin wrapper around a budgeting box), and the remainder in one of several lanes of the pool. All items begin in the pool; items which receive sufficient of support will be promoted to the leagues Items in the leagues are then compared against each other in a pairwise fashion and ranked; items which rank highly may be promoted to higher leagues and become eligible for larger rewards.
3、Scoring the Lanes
Projects in the leagues receive rewards, paid out via the Colony task mechanism. The pool, on the other hand, serves as a reservoir of projects hoping to get into the leagues; projects in the pool do not receive rewards.
Consequently, in comparison to the high-stakes, high-attention leagues, the mechanism for processing projects in the pool is simpler, providing only a coarse filter. The pool is divided into L “lanes”, each of which can hold up to 256 projects. Projects enter a lane by staking some fixed amount of CLNY tokens. Once in a lane, projects receive votes of approval only; projects receive scores equal to the reputation-weighted sum of their approvals.
At the end of the voting period, we have an ordering of each pool lane in which projects are ranked based on their total backing reputation. The staking requirement is intended as an anti-spam mechanism. As a further protection against low-quality submissions (which drain voter attention), projects in the pool with a score less than 0.2 of the median will have their stakes burnt. To prevent projects from withdrawing their stake in anticipation of being burnt, we allow projects to leave the pool only during the first third of the voting period.
4.、Moving Between Leagues
Our mechanism functions much like a sports league, in which those that rank at the bottom at the end of the season are relegated to a lower league, while those that rank highly will move to a higher one. A “season” in our case is one voting period. At the end of a voting period, all the projects are scored, rewards are paid out where appropriate, and the projects are assigned a league for the following period.
The reassignment is governed by the parameters Z and a “shuffling factor”C, which determines how many projects move between periods. As the leagues are arranged in a binary tree, it is possible to index every node and traverse the tree.
Moving from one League to another，The bottom (after sorting by score) 2C projects in league g are swapped with the top C + C projects from league J, where the demotion from g to J happens in alternating fashion.
Moving from the Lanes to the Leagues, Projects that rank at the bottom of the bottom-tier leagues are expunged from the system (with their stake returned). They are free to reenter the pool by posting a new stake. The newly vacated spots are filled by the top projects in the pool lanes. We aim to have no more than half of the pool enter the leagues at any one time, thus each lane can support a maximum of leagues and so. When there are multiple lanes, they are assigned to leagues in a roundrobin fashion for a leaf league.
Conversely, we denote the leagues associated with a lane by leagues(l). The goal is to replace the bottom 2C projects in all the leaf leagues with the top 2C |leagues(l)| projects in the pool lanes. So for each lane we replace on of candidate quality balanced amongst the leagues, the implementation should interleave the swap in a round-robin fashion such that the strongest candidates are distributed evenly amongst the leagues which they enter.
5、Determining Allocation
Once projects have been voted on and the votes processed, but before they are moved between leagues, their final budget allocations are determined.
Only projects in the leagues receive an allocation, governed by v. A damping factor d which allows for evening out the distribution over all projects in the league.
Relatedly, we must decide how to distribute the available budget across the leagues.
This allocation is governed by a parameter Q ∈ [0, 1], which guides us between two extremes: at Q = 1 we have a uniform allocation over all leagues, and at Q = 0 an exponentially diminishing allocation. Knowing Q we have the total budget available to league.
- Expanding the Mechanism
In that the mechanism can be expanded to accommodate an arbitrarily large number of projects. Note that the mechanism’s capacity is driven by three parameters:
Z, which determines the number of leagues, K, which determines their size, and C, which determines the degree of movement; jointly they determine the size of the pool, which we require to be able to hold twice the number of projects which can enter the leagues in any period.
As the Colony Network matures and the number of projects looking to participate in this mechanism grows, the mechanism can be expanded by incrementing Z; every increment will double the size of the leagues and create new lanes as necessary. Note that as lanes are added, existing candidates are not redistributed, creating a type of “arbitrage opportunity” where projects can stake themselves into lanes where competition is less intense; this will naturally lead to an even distribution of project quality amongst the lanes.
7、Voting Process
In order to make this mechanism Sybil-, bribery-, and collusion-resistant,
we first appeal to the Colony reputation system. With reputation-weighted voting, those with the most influence also have the most to gain from the growth of the Colony Network, and are thus the least incentivized to accept immediate payouts (bribes) in exchange for worse long-term prospects. Further, as reputation derives from work done for the Meta Colony, those with more influence ostensibly have better knowledge of the ecosystem and can make better determinations about the relative value of projects.
In order to encourage participation, we will set aside a portion of B for voter compensation, with per-voter compensation a function of relative reputation. Making compensation proportional to reputation serves the dual purpose of Sibyl-resistance and encouraging those with the most influence to expend the most effort in making judicious decisions (to increase their long-term rewards) and further decrease the relative incentive to accept bribes in exchange for favorable treatment. If BR is the portion of the budget set aside for voter compensation, then the per-voter compensation be is determined as follows:
Voting Subdivision，Another consideration is the subdivision of the voting process. Should a “unit of voting” involve voting on every pair and project? Or should reputation holders be able to contribute smaller units, as motivation permits?
Fortunately, the “pool and leagues” organization of projects leads to a natural compartmentalization of work. Voting on one league or one lane constitutes one “unit” of voting. The per-unit voting requirement should be set in advance.
8、Conclusion
As described above, the mechanism as a whole is governed by a number of hyperparameters: K, which determines the size of the leagues; Z, which determines their number; C, which determines the degree of movement between periods; B, which determines the total budget; and d and Q, which affect the distribution of budget within and between the leagues, respectively.
Unlike the pairwise votes, which capture personal preference, these hyperparameters capture political preference, as they define the behavior of the system as a whole: the size of the payouts, the number of projects eligible to compete, the permissible level of inequality in the payouts going to the popular versus unpopular projects, and the speed with which the allocation a specific projects can rise or fall.
All of these parameters, except for the fixed K, can be updated via reputation-weighted voting in the Meta Colony. Our expectation is that Z and B will begin small and be increased over time as the network matures and the number of projects increases. We anticipate that d, Q, and C will be updated less frequently to fine-tune the behavior of the mechanism; we expect to launch the mechanism with low values of each, such that payouts become meaningfully larger in higher leagues, that “losing” projects in higher leagues will still earn more than “winning” projects in lower leagues, and that movement between leagues is slow enough that projects have a meaningful time horizon of income.
It is intentional that winning projects will accumulate reputation and influence in the Meta Colony over time. As these projects both support and depend on the Colony Network, it is appropriate that they are able to both participate in the governance and share in the rewards of the network.
In our introduction, we introduced a number of possible attack vectors
and failure scenarios, and claimed to have developed defenses against them.
We will take them point by point:
1. Spam. Soln: minimum stake makes spamming expensive.
2. Scammers. Soln: low initial payouts makes scamming uneconomic.
3. Bribes. Soln: reputation-weighted voting aligning long-term incentives.
4. Self-voting. Soln: eurovision rule.
5. Collusion. Soln: nonlinear vote interactions, random walks.
6. Voter apathy. Soln: engaging experience, voter compensation.
7. Cognitive biases. Soln: nonlinear vote interactions.
8. Random voting. Soln: reputation-weighted voting and compensation.
9. Sybil attacks. Soln: reputation-weighted voting and compensation.
It is important to note that no mechanism can ever be fully resistant to attack or failure; every mechanism, even proof-of-work, functions conditional on some reality. The mechanism we describe assumes a reasonably diverse set of engaged reputation holders looking to benefit from the long-term success of the Colony Network. The goal of this mechanism is not to provide a fool-proof framework for decision-making, but rather to solve a specific set of problems without introducing a large set of new ones.
We believe that the use of pairwise preferences to solve collective ranking and budgeting problems represents an important tool in the decentralized governance toolkit.
Contact Information:
Home page: https://colony.io/
Recruitment: https://angel.co/company/colony
Blog: https://blog.colony.io/
LinkedIn:https://ph.linkedin.com/company/colony-io
Twitter:https://twitter.com/joincolony
Address: 5th Floor, Genesis Building,Genesis Close, PO Box 446,Grand Cayman,, Grand Cayman KY11106, KY
Welcome to submit your DAO research and send it to this email address:daorayaki@dorafactory.org ,Share the 10,000 USD grant pool!
Welcome to DAOrayaki official website:（daorayaki.org）
Learn More：
Learn More：
DAOrayaki Research |GovenorDAO：Govenor as a services
DAOrayaki Research |Comprehensive analysis of DAOhaus governance mechanism
DAOrayaki Research |Alchemy： Blockchain Developer Platform and Node Services
DAOrayaki Research |DAOMaker: a tokenized startup incubator and fundraising platform
DAOrayaki Research |SourceCred: a contribution-based Calculating Cred tool
Gnosis Safe: a flexible and secure digital asset management tool
