DAOrayaki DAO Research Bounty Pool.
Grant Address: 0xCd7da526f5C943126fa9E6f63b7774fA89E88d71 Voting Progress: DAO Committee 5/7 Passed Total Bounty: 200 USDC Research Categories: DAO, Colony, Domains and permission, Transaction Cost, Reputation Mining, Market Suppliers, Colony V2, Transaction Cost Economics (TCE) theory, Collaboration Contributors: Black and White QB, DAOctor@Daorayaki
Launch date: Launch in 2017, soft launch on February 15, 2021
Token: CLNY (ERC-20)
Talent is highly fragmented and opportunities are highly concentrated. Many people want to start a business, and while it is easier than ever to do so, the barriers to entry are still large. As a result, the passion, talent, and energy these people may put into business projects is often channeled into online communities, free and open source software projects, and other hobbies.
What is Colony?
Colony is built on top of the ethereum platform. It features ownership by contribution, merit impact, and fair rewards. colony’s fair rewards system works when colony makes money and automatically shares the money with colony members and others through a pre-agreed smart contract agreement. Fair rewards are distributed in proportion to the tokens and reputation held by members.
What does Colony do?
Colony is a social collaboration platform for distributed organizations. Users can start projects online and build a workforce to help make those projects happen. Because it combines workforce incentives with productivity, it is possible for anyone anywhere in the world to work on a project without the need for hierarchical management.
The platform incentivizes users to compete to be the most skilled and productive by assigning rights and benefits in proportion to the value each user contributes. The platform automates the project management process, bringing together the collective intelligence of members in suggesting tasks, making decisions, assigning tasks to the best candidates, and providing feedback on their work. Every aspect of the platform employs gaming mechanisms and behavioral design to ensure a compelling experience that encourages repeated engagement.
Colony currently runs on xDai and supports the following features.
- organizing the community into departments or teams with a threshold for joining
- Manage token pools and apply budgets to different teams and programs.
- Support a variety of different payment methods.
- Customize member entitlement distribution permissions, such as influence gained through participation in governance, based on the organization’s specifics.
- Raise funds through token sales, donations or revenue.
- Provide multiple decision-making mechanisms to accommodate different use cases and arbitrate disputes when they arise.
- 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 are able to plug in extensions that can be manipulated as needed to give their organization the tools they need.
Differences between Colony V1 and V2 versions
Due to the extremely slow processing speed of the system caused by complete data decentralization, the unfinished public infrastructure of the system, and the lack of community participation, etc. Colony started to gradually move to Colony V2 in early 2021. has been migrated from the main Ethernet network to the xDAI network
The changes are as follows.
Colony’s access control framework. Access permissions are granted to Ethernet addresses, and those with permissions can access certain privileged functions (similar to the underlying system calls). There are six types of permissions, ordered from highest to lowest as follows: recovery permissions, Root permissions, arbitration permissions, architecture permissions, funding permissions, and administrative permissions. Each permission represents a semantic package of functionality. Permissions can be granted at different levels of the domain hierarchy, thus enabling the creation of complex authorization systems. In addition, the ability to grant permissions to any address enables the development of standalone smart contracts, which can then be “plugged” into Colony to extend its functionality.
Giving privileged access to any Ethernet address means that it is very flexible to develop and experiment with any mechanism or interface based on these functions. For example, a dedicated budget mechanism could be built around the ‘funding’ permission, allowing addresses to transfer tokens between domains. By developing extensions that can be reconciled between the underlying functionality and the mechanisms, Colony can explore the design space of the organization more effectively, or experiment with more straightforward administrative controls and distributed decision-making mechanisms that do not require permission.
Pledge Management (Stake Management)
Many extensions may require users to pledge tokens before taking action, such as a voting extension that enables users to initiate arbitrary votes by pledging tokens. If other users consider the poll to be malicious (or treat it as spam), the poll initiator may (and rightfully so) lose the tokens they pledged. Considering that the contracts for the extension are independent, then users would have to keep track of pledges made to many different contracts, which can be quite burdensome for users. In addition, the burden of securing these pledged tokens held by the extension’s contracts places a significant burden on the extension’s development. To address these issues, Colony has developed a common interface for extensions (or administrators) to manage pledges on behalf of users without actually holding the funds
While the design of the Reputation Mining process has remained largely unchanged, the Colony team has made a number of implementation choices that differ significantly from those given in the original whitepaper. Most importantly, these include switching the data structure of the reputation tree from the regular Merkle tree to the more efficient Merkle-Patricia tree.
Transaction costs include specifying requirements, finding suppliers, receiving and comparing offers, agreeing on contract terms, managing deliveries, invoicing and accounting, quality control, dispute resolution, etc. DAOs have no other choice but to coordinate supply through market mechanisms
An effective DAO framework must reduce the transaction costs of market-based supply mechanisms. But unfortunately, the problem with all DAOs except Colony is that they increase transaction costs, and 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.
Given this, Colony decided to solve these problems by using a combination of approaches where we allow DAOs to scale by creating multiple teams and sub-teams and by 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 a 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.
Jack du Rose (Jack du Rose)
CEO of Colony, graduate of Western University, UK. former CEO of Collectively Intelligent Ltd, mentor of Outlier Ventures.
Collin Vine (Collin Vine)
Co-founder of Colony and former co-founder of Zirtual.com. He is most interested in the future of work, including how cities, economies and organizations are and will be impacted by technology.
Co-founder of Colony, has a creativity that combines practicality and pragmatism, honed by a wealth of practical scientific experience.
A comprehensive explanation of Colony
Theory of the firm
The firm exists to coordinate the production of goods and services. The theory of transaction cost economics (TCE) is an extension of Ronald Coase’s theory of the Firm, which assumes that firms are formed, hire employees, and invest capital because there is a threshold under which direct control of factors of production is more efficient than coordinating production through market mechanisms, once transaction costs are accounted for. These transaction costs are of three types.
-Search and information: costs associated with finding information to inform decisions, discovering and evaluating suppliers.
-Negotiation: These are the costs associated with reaching an agreement with a supplier. The cost of bargaining can be low (e.g., buying coffee) or high (e.g., buying a company).
-Monitoring and enforcement: The cost of ensuring compliance with the terms of the agreement (e.g., producing widgets on time and to the agreed quality). Due to chance, negligence, or evil, people often deviate from the agreed terms, and resolving disputes can require high enforcement costs (e.g., legal fees).
TCE theory suggests that firms coordinate production more efficiently than market mechanisms due to imperfect information and limited rationality. With perfect information, the firm would not be necessary because market forces would provide the necessary mechanisms to incentivize and coordinate production-each person would know the exact value of his or her own and others’ contributions.
Since this is not the case in traditional markets, these knowledge and trust barriers can be overcome through due diligence and contracts, and require legal systems to provide recourse when problems arise. These processes are expensive, so traditional firms often find that replacing free-market bargaining with a hierarchy of command and control makes them more efficient and competitive.
As new technologies increase the diversity and fluidity of information, new organizations are emerging that can combine the efficient decision-making of the marketplace with the shared value capture of traditional firms. Sharing economy platforms (e.g., Uber, Airbnb), marketplace networks (e.g., eBay, Amazon Marketplace), and cryptocurrencies (e.g., Bitcoin, Ether) have demonstrated that if products are well enough defined and supply is sufficiently large, substitutable, or diverse, by making the discovery of search and information easy, negotiations simple, and provided by platforms essentially free policing and enforcement, the transaction costs of market mechanisms can be significantly reduced. This makes these new platforms several orders of magnitude more efficient than if they were trying to coordinate equivalent supply within the hard boundaries of the firm.
Confidence and trust
Companies are able to coordinate complex mass production by organizing labor into a hierarchy of management. Seniority in the hierarchy (ideally) represents the degree of confidence the company has in its employees, and in the company’s Platonic ideal, confidence is purely a function of competence. The more confidence the company has in its employees, the more competent they are and therefore the more responsibility, influence and compensation they will have.
However, it is difficult to have confidence in other people on the Internet. Until now, we have relied on platform operators to coordinate between parties to online transactions (usually through various rating and reputation systems) and in some cases (such as payment processing) to take the risk of those transactions. It’s even harder on the blockchain, because you only know that the other party controls the public key. It’s hard to imagine a traditional organization or hierarchy that could exist in this pseudonymous, adversarial environment. Blockchains have no geographical boundaries to distinguish who or what controls the public key.
As Richard Gendal Brown adapted Peter Steiner’s classic meme: “On a blockchain, no one knows you’re a refrigerator.” Internet organizations must therefore assume the lowest common denominator:each member is a rational egoist, completely focused on maximizing personal utility and profit, and incentivized accordingly. This goes to the heart of colony: a model designed to promote the ideal corporate hierarchy should have the same elitist division of labor and division of power protocols, except from the bottom up, and without being prone to error. Decentralized, self-organizing companies where decision-making authority comes from fairly assessed value contributions.
Thus, work is our starting point. colony members are compensated for the value they create for the colony, in the form of ETH, any erc20-compatible token, or reputation (an irreplaceable, time-decaying measure of cumulative past contributions). Active colony may perform various types of work at any given time; to simplify the management of work (and its budget), colony can be divided into domains. Domains are how you structure your colony. you can think of them as teams, departments, circles, or things that make sense in your environment. These make it easy to group related tasks and separate them from other unrelated work in other domains, and make it possible to make decision logic appropriately in context (where one domain can be controlled by an administrator and the other by a reputation-weighted vote).
Reputations are not transferable between accounts and decay slowly over time. This decay ensures that any reputation of a member is the result of recent behavior considered favorable to the colony (and thus a function of current member judgment). Because the calculations involved are too complex to be performed on the ethereum blockchain, member reputation updates are calculated off-chain, with on-chain reporting mechanisms ensured by economics and game theory.
Many decisions within a colony can be made by informal consensus. Members are expected to verify the behavior of their colleagues, but are expected to intervene less. In this case, intervention means “making a motion”. Within colony, decision-making by voting is uncommon because it is slow and costly to coordinate; it is used reasonably in the (hopefully rare) case of dispute resolution. The dispute resolution system allows many kinds of decisions to be put to a vote of some or all members of the colony, depending on the situation. Votes are weighted by the elite system based on the background-related reputation of the voters.
A colony can be voluntary, non-profit, or for-profit. An income-producing colony may choose to pay a portion of its income to its members. When a colony pays out rewards, members receive an amount that is based on a function of combined token and reputation holdings; this ensures that those who contribute the most receive the greatest benefit. Members maximize their rewards by contributing to colony throughout its lifetime (and thus maintaining a high level of reputation) rather than sitting on tokens accumulated early on.
We want people to use Colony for as many different workflows as possible, even those that don’t immediately show up as being able to take advantage of the Colony protocol.
- Structure of Colony
Colony exists to enable collaboration among its members and to direct collective efforts toward common goals. Thus, promoting an effective division of labor, managing rewards, and allocating resources are some of the most important functions of the colony protocol
2.1 Domains (domains) and permissions
The basic structure of colony revolves around the domain and the permissions that an account may have. Together, these two concepts define the structure and security of groups and provide a flexible framework for creating multiple types of groups.
As with any organization, without structure, a large group will quickly become difficult to navigate because of the sheer number of participants and interactions – domains solve this problem.
A domain is similar to a folder in a shared file system, except that instead of containing files and folders, it can contain subdomains, funds, and expenses. This simple modularity allows for a great deal of flexibility in the structure of the organization. Domains can be used to represent teams, departments, projects, tribes, circles, etc.
Ultimately it is up to individual groups to decide how they want to use domains – some groups may use them only for coarse classification, while others may use them to group only the most similar expenses together precisely, or even multiple expenses that other groups consider to be a single expense. Some may use domains to represent long-standing organizational units, while others may use them to represent items with start and end dates.
Our goal is to provide a general framework that colony can use in any way they see fit, and to specify only when necessary.
Beyond that, this division of activities provides an important benefit to the colony as a whole, as it gives context to the reputation. When arbitration occurs, it occurs at a specific level of the colony domain hierarchy. This means that people with relevant background knowledge can be included in their opinions and that the entire colony does not need to be involved in the process when arbitration occurs.
2.1.2 Permissions (Permissions)
colony’s access control is organized around the concept of permissions. There are six different kinds of permissions (in roughly the order of impact): Recovery, Root, Arbitration, Architecture, Funding, and Administration, each of which unlocks a set of semantically related functions.
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), and the rule is that permissions held in a parent domain are inherited in all child domains. In other words, having permissions in a domain makes you have permissions in the entire subtree of that domain. To implement this inheritance, the authorization function takes the following arguments for the domain proof
-permissionDomainId – The (parent) domain in which the account has permissions.
-childSkillIndex – Index of the domainId in the subarray of the commissionDomainId.
-domainId – The (child) domain where the operation is being performed.
These parameters can be evaluated at a fixed time in the chain to determine if the account is authorized to invoke privileged functions.
Permissions are held by the Ether account. This means that privileges can be granted to manual administrators, or assigned to contracts that implement more complex behaviors (such as voting mechanisms). These types of contracts are called extensions. The use of extensions to flexibly “plug in” various decision mechanisms is a key concept in the Colony protocol.
It is important to note that the list of accounts with the permissions discussed has full permissions; there are no other restrictions at the protocol level. In some cases, these are very powerful features (e.g., arbitrary imposition of reputation penalties) that require absolute confidence in who or what is controlling it. Therefore, we expect that in many cases, extended contracts will be used to provide varying degrees of auditing for the underlying permissions.
Recovery permissions allow accounts to access colony’s emergency “recovery” feature, which allows arbitrary state changes to be made to colony’s data.
The Root permission allows accounts to access advanced administrative features in colony, such as setting colony-wide parameters, upgrading colony, and creating new internal tokens. This permission also enables the account to assign permissions throughout colony (including the root domain).
The Arbitration permission gives accounts the ability to make domain-specific status changes, which is meant to be used as a means of resolving motions. This permission also allows the account to issue reputation penalties (but not reputation increases).
The architecture permission enables accounts to create new domains in a cluster and assign permissions in those new domains. Unlike root, an account with this permission cannot edit permissions within the domain in which it holds that permission; it can only use it within subdomains.
The fund permission enables accounts to move tokens between funding pots. In practice, this means that the permission is responsible for distributing funds and fund expenditures between domains.
The Administration license gives the account the ability to create and manage (but not fund) expenses, which is the basic incentive unit of colony
Broadly speaking, licenses are designed to be “discrete”: different licenses must work together to achieve a colony’s function. For example, the executive branch can generate expenditures, but only funds can actually provide resources, while arbitration can resolve motions as they arise. Complex extensions may require multiple permissions to work properly (e.g. “tasks”, which require arbitration and management)
The intent is that because permissions are grouped into semantic packages of functionality, it will be possible to develop specialized mechanisms to mediate access to underlying functionality (i.e., specialized funding mechanisms and specialized dispute resolution mechanisms, rather than a generic “voting” mechanism to handle all possible decisions).
colony’s long-term vision is to build information-free organizations; organizations where members can safely collaborate and manage shared resources without needing to know or trust each other. Early groups may find it useful to place more emphasis on human auditors, while more mature groups may find reasons to delegate more and more decisions to trustless functional extensions. We will refer to a colony that makes heavy use of these extensions as an unreliable colony.
2.2. Funding and expenditures (Funding and expenditures)
All tokens and currencies are managed by the colony contract; it is responsible for all bookkeeping and appropriations. The former is managed through the funding pot and the latter through expenditures.
2.2.1 Funding pots (Funding pots)
Each area and each expense in colony has an associated funding pot. Funding pots can be thought of as wallets specific to a particular domain or expense and are used to move money around within colony. For each funding pot, a colony contract can associate any number of Ether or erc20-compatible tokens it holds. Depending on the circumstances, the funds in the funding pot may be referred to as payments, bounties, budgets, salaries, or operating costs. In addition to the funds pot, there is a special rewards pot that accumulates tokens to be distributed to members as rewards.
Only accounts with a fund permit can move tokens; the rule is that they can move tokens between any two jars in the sub-tree. It is expected that in many cases this permission will be granted to extended contracts that implement specialized decision mechanisms.
The basic payment method for Colony is “expenses”. Expenditures are used to transfer funds from colony to any Ether account. Expenditures have several properties.
-Owner (the address of the account that generated the expenditure).
-Status (active, cancelled or finalized).
-One or more recipients.
-Payment for each recipient denominated in one or more tokens.
-Optionally, the skills of each recipient.
-Optionally, payment modifiers for each recipient.
-Optionally, a claim delay for each recipient
The owner is responsible for setting the properties of the expenses. Recipients are only Ether accounts. While it is expected that the recipients will be individuals, there is nothing to prevent these accounts from being under the control of multiple people under contract.
Once expenditures are finalized, all properties are locked (but subject to arbitration) and payment can be claimed (and reputation granted). Until finalized, the owner has the right to cancel the expenditure entirely. Any funds already allocated to an expense can be reallocated to the domain where the expense was created.
Of course, defining expenses for each recipient does not provide funding – this must be done through colony’s funding mechanism. Expenses are not necessarily all in the same token; expenses can be composed of any number of tokens.
Spending is an abstract primitive that can support multiple types of workflows, and therefore contains optional properties to support more complex behavior. For example, payoutModifier and claimDelay can be used to implement rating and review systems where a good or bad review results in an overall reputation increase (or expense decrease) for the recipient, while claimDelay is set to allow any related motions to be decided before the fund exits the colony.
Once an account receives tokens, they are under the control of the recipient – there is no way to recover the funds. The fund must cross the “Rubicon of ciphers” somewhere in the system (by the nature of the blockchain), and it makes sense to do so here.
2.3 Internal tokens
Each colony has its own ERC20-compliant “internal tokens”. These tokens, when earned as expenses, also generate reputation for the recipient (thus assigning control within the colony). Beyond that, it is up to the colony to decide what these tokens represent. For example, they may have financial value or they may be purely symbolic.
In addition, colony can “carry their own tokens” and designate existing ERC20-compatible tokens as reputation bearers. While this may be advantageous in some cases, it is worth noting that it weakens the incentive consistency that supports the security of trustless colony game theory because the value of the token is disconnected from the performance of the colony. Note that once a colony is created, internal tokens cannot be changed, so please choose wisely. In the case of a colony creating a new token, that colony controls the supply of tokens.
Specifically, the root permission holder can create as many tokens as he or she wants. In some cases, this may look like the founder is unilaterally managing the token supply, while in other cases, the colony may manage the minting process through an extension contract.
A common question is why only internal tokens (and not all tokens) have reputations. The reason for having a single token assume reputation is that it avoids the thorny exchange rate problem, for example, by encouraging people to accept more tokens of lower value in order to earn more reputation.
2.3.1 Token use cases
Ultimately, internal tokens are used to assign reputation and thus include ownership and decision-making power. Because users with more reputation can both exert more influence on group activities and claim a larger share of rewards, the reputation function can adjust the incentives among group members. Here, we give several examples of different use cases for internal tokens, demonstrating the various schemes groups can use to distribute ownership and influence as well as cash payouts.
One of the main benefits of a colony having its own token is that it can provide a reward for work before any revenue or external funding is received. A new colony might offer token payments, with the hope that the reputation gained through these token payments (and the future revenue earned by the colony) will eventually lead to financial rewards. By allowing “expenses” prior to fundraising, the financial burden of the new colony’s launch phase is reduced. Once a colony is profitable, token payments may be the exception rather than the norm.
We can imagine a colony where all expenses are paid through Ether, but also includes some of the colony’s own tokens, which are equal to the expected number of hours worked. members of the colony would be responsible for allocating the “correct” tokens and Ether expenses.
This additional responsibility also ensures that users receive the same amount of prestige for completing the same amount of work, rather than relying on the fees they charge.
Alternatively, we can imagine a colony that seeks a balance between predictable pay (i.e., salary) and performance-based incentives. Such a colony could be paid in tokens such as Ether or DAI and use their internal tokens for performance-based bonuses (i.e., reaching quarterly okr). This approach makes reputation (and decision-making power) a function of achievement, without making the members of the colony feel that their ability to pay rent depends on their ability to achieve quarterly goals.
2.3.2 Colony’s Token Contract
Colony has developed a custom Token contract with some additional features:
-mint -Lets token contract owners 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 are not transferable until the one-way Boolean flag is flipped. This is useful for colony who want to have more control over how and when tokens are liquidated and exchanged.
While colony is free to choose any erc20-compatible token, the contract is the basis for the colony network tokens and is the default token contract for new colony.
2.4 Revenues and rewards (Revenue and rewards)
colony can sell goods and services in exchange for Ether or any erc20-compatible tokens, and these revenues can be sent to the colony’s address. Whenever a colony receives such a payment, we say that the colony has earned revenue. Revenue is different from a colony’s working capital:the latter is the sum of all tokens held by the colony in each domain, while the former is implicitly defined as token holdings that the colony has not yet accounted for in any existing pot.
There is an expectation that a portion of any Ether or other tokens received by colony will be paid to its members. In this context, a “member” is an account that holds both tokens and reputation in colony. When a group distributes a portion of its revenue to its members, we say that the group is paying out rewards.
2.4.1 Processing revenue
Income accumulates when colony receives a token transfer. To process, any user can make a special claimColonyFunds transaction indicating which token they wish to use to process the accumulated income.
This transaction then calculates the token-denominated revenue accumulated since the last such transaction and transfers a portion of the revenue to the colony’s rewards pot.
The remainder is provided to colony as working capital. the percentage split can be configured via root access via the setRewardInverse function.
2.4.2 Receiving rewards from the rewards pot
Rewards are accumulated in the rewards pot. To trigger a payment to the user (i.e., to make the reward claimable), the root user performs a special startNextRewardPayout transaction (no more than once every 60 days) that initiates a process through which all members can claim a payment based on the reward jar’s holdings.
This RewardPayout transaction includes the specific currency in which the payment is due (reward payments are handled separately for each token). Once the process starts, all users’ tokens will be locked until they request a payment. The lock is necessary because each account’s token balance is factored into the equation’s reward formula. Locking is accomplished by increasing the totalLockCount of tokens.
Our TokenLocking contract contains a locking mechanism that ensures that users cannot move tokens while they have (token-weighted) voting rights; we use the same mechanism here to ensure that users cannot move tokens after payments have been approved by colony members but before they claim their rewards. colony has a counter for each user, and whenever they request a payout, the counter is incremented; they can also drop their claim payout will increase this counter.
Rewards are only available to accounts that hold both tokens and reputation, and the amount each account can claim depends on the token balance and reputation. Therefore, we need to have a similar behavior to “lock” the reputation of the paying user. When a payment is activated, the current status of the reputation tree is recorded in the payment itself. Users are paid based on their reputation in that state, not their most recent state, to ensure that all users are paid appropriately and to avoid exploiting the system (which might otherwise improve their reputation by delaying reward collection until after they finish spending).
2.4.3 Reward formula
The amount each user (ui) of colony (C) is entitled to claim (pi) is a function of their colony token holdings (ti) and their total reputation with colony (ri).
This is the (normalized) geometric mean of user token holdings and reputation. We note that this is unlikely to pay out all the tokens set aside for payouts – the only way to do this is if each person has the same proportion of reputation in colony as they have tokens in colony. However, geometric averaging is a natural way to fairly capture the impact of two different range variables and ensure that large token holders must acquire a large amount of reputation to get the most out of their payouts. Both the total reputation in the population and user replacement are provable on-chain at the time of claim, by Merkle proving that the reputation roothash contains some value of the user’s claim; the user’s colony token balance and the total number of tokens issued are insignificant for lookup purposes.
After a sufficiently long period of time (60 days), all unclaimed tokens can be reclaimed by the user on behalf of colony, and the payment ends. Any user who has not requested a payment by that point will still have their tokens locked, and they will remain locked until they post a transaction abandoning their payment request (in effect, they have passively done so by not requesting it in a timely manner). Unclaimed tokens are returned to the reward pot and become part of the next reward cycle.
2.5 Reputation System
Reputation is a number associated with each user that attempts to capture the value of that user’s contribution to colony over time. Reputation is used to measure a user’s influence in decisions related to the expertise they demonstrate and to determine the amount owed to colony members when rewards are paid. Because reputation is awarded to users through direct or indirect peer assessment of their behavior, we believe that influence and rewards can be considered (roughly) merit-based. colony’s goal is that the reputation system will enable an urgent and dynamic hierarchy of decisions in which all the right people are in the right places.
The goal of colony is to implement elite management broadly. Thus, in an untrustworthy group, most decisions are weighted by the associated reputation. Unlike tokens, reputation is not transferable between accounts because it represents peer evaluation of account activity. Therefore, reputation must be earned through direct actions within the colony. Reputations earned will eventually be lost through inaction, error or misconduct.
2.5.1 Types of Reputation
Reputation in the domain
In this hierarchy, users have reputations in all domains that exist – even if the reputation is zero. When a user gains or loses reputation in a domain, the same change in reputation occurs in all parent domains. In the case that a user loses reputation, they also lose reputation in all subdomains, but in this case the reputation lost in the subdomain is the same as the reputation lost in the original domain. If a reputation update would result in a user’s reputation being less than zero, set their reputation to zero.
Here is an example to illustrate this point. Suppose a colony has a “development” domain containing a “back-end” domain and a “front-end” domain. Any time a member of the colony earns a reputation for work done in the back-end domain, it will increase their back-end reputation, their development reputation, and their reputation in the colony root domain.
Reputation earned in the development domain only increases the user’s development and root domain reputation scores.
Later, the user behaves badly in the “development” domain, and they lose 100 out of 2000 reputations in that domain. They also lose 100 reputation in the parent domain and 5% (100/2000) in each subdomain of the “Develop” domain. (In this example, both front-end and back-end domains are included)
2.5.2 Reputation Profit and Loss
There are three ways to gain reputation in colony: the first (and by far the most common) is through expenses. The second is through the arbitration process. The third is by creating a colony and the associated bootstrapping process.
Reputation loss occurs extensively as a result of arbitration, and deferred contracts make it possible to implement mechanisms involving reputation penalties (such as assignments and disputes). In addition, all reputations earned by users are subject to decline over time.
Reputation change through spending
Whenever an expense recipient receives an expense denominated in colony’s internal tokens, the recipient also receives a certain amount of reputation, measured by that recipient’s expenses. If the value is 1, the reputation is equivalent to the token payment, but can be a multiple of 2.
Reputation is earned in the domain of the expenditure (and all parent domains) and is distributed equally among any skills associated with that recipient.
Reputation changes due to arbitration
Arbitration license holders have the ability to impose arbitrary reputation penalties (but not increases) in both domains and skills. While this appears to be an important power granted to the arbitration license holder, recall that in many cases this license will be assigned to the extension contract, which will mediate this ability through various mechanisms, such as the motion system.
Since the decision process for untrusted groups is based on reputation-weighted voting, we propose a bootstrapping problem for new groups. When an untrusted colony is new, no one has done any work yet and therefore no one will earn any reputation. Therefore, since no one can vote, no motions can be made and no disputes can be resolved. Then, once the first expense is paid, that user has exclusive power over decisions in the same field or skill until another user gains a similar type of reputation.
To prevent this, when creating a colony, the creator can choose the account in the root domain to which the initial reputation is assigned, 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 10 tokens, they will also receive 10 reputations in the root domain. Given that reputation declines over time, this initial self-direction will have no impact on the long-term operation of colony. This is the only time reputation is built without associated expenses. The users who gain reputation are likely to be the founders of colony and their colleagues, and this initial reputation should be seen as representative of the existing trust in the team.
We note that the same approach is not needed when creating a new domain in a colony. We do not want to create a new reputation here, as this would devalue the reputation already earned elsewhere in the colony. When a child domain contains a reputation that is less than 10% of its parent’s reputation, this bootstrapping problem can be solved by using the reputation in the parent domain. Domains below this threshold cannot have domains created under them.
All reputations decline over time. Every 90 days,4 a user’s reputation in each domain or skill decays by a factor of 2. This decay occurs every 1 hour, rather than a step change every 90 days, to ensure that there is minimal incentive to earn reputation at any given time. This frequent, network-wide update is the main reason for the existence of reputation mining protocols, which allow this near-continuous decay to be calculated off-chain without gas limitations and then implemented on-chain.
Decay has multiple uses. It ensures that the reputation score represents recent contributions to colony and motivates members to continue contributing to colony. It further ensures that the significant appreciation in token value (and corresponding decrease in tokens paid per expense) does not permanently distort the distribution of reputation, but rather helps to eliminate this fluctuating effect over time.
Some may wonder why we have chosen to weaken reputation rather than pursue a strategy of reputation dilution through inflation. In a sense, they are equivalent: a decaying reputation earned at a constant rate is the same as a reputation earned at an increasingly inflated valuation.
Mathematically, however, decay is a much more concise method, so the use case for inflation is that it is more feasible to calculate on the chain. In the case of colony, reputation cannot be computed on the chain because reputation updates affect an infinite number of reputation nodes (due to the infinite size of the domain tree). Since reputation cannot be computed on-chain, we choose to decay reputation in our off-chain reputation mining process.
2.6 Managing equity (stake)
Equity is a key concept in untrustworthy systems, it is a way to ensure that participants “share the risk” and can be motivated to behave well. Since Colony wants to enable an extended ecosystem that implements various crypto-economic mechanisms, a shared system for managing stakes increases usability and security by saving users the need to send and retrieve tokens to many different contracts. In colony, all interests are denominated in that colony’s internal tokens.
2.6.1 Storing tokens
All entitlements are stored in a network-wide TokenLocking contract. The advantage of a single instance contract is that a single deposit is sufficient to pay for all colony in the case where the user is a member of multiple colony sharing the same internal token.
Any deletion of equity is the result of a function call from the colony, and is the result of colony-specific arbitration logic.
2.6.2 Approvals and Obligations
Equity is managed through a series of approvals and obligations. A user approves an account and then forces them to reach the maximum amount they have approved. If an obligation is assumed that exceeds the deposit in the token lock contract, the transaction will fail. Once an obligation is raised, users will not be able to withdraw tokens if the withdrawal results in a balance less than their obligation. At any time, an approved extension can release the user’s access and release the tokens for withdrawal. In practice, we expect that the same underlying deposit will be repeatedly forced and released from collateral without requiring the user to move any additional tokens.
When an obligation is valid, any arbitration license holder can cut the stake to the amount of that obligation. We reiterate that this is a strong ability and should be mediated by appropriate extensions in most cases.
For security reasons, approval is keyed by domain as well as by approval address (i.e., approval (approval, domain, amount)). Otherwise, the malicious actor can use any arbitration permission holder in the colony to cut the take instead of using the arbitration permission holder in the expected domain inheritance path. However, since TokenLocking does not know the domain structure of a particular colony, the obligations in TokenLocking are the set of all colony- and domain-specific obligations.
Overall, this design allows generalizing arbitration and separating it from the implementation of any particular extension: the extension name specifies the interest (and defines the duration of the obligation) during which a separate arbitration procedure can reduce that interest.
2.7 Scalability and Security
We anticipate that group networks will continue to evolve. Providing an upgrade path is important to allow people to use Colony without preventing them from using new features added to the network themselves. We intend to allow colony and tokens to be upgraded by using the model provided under the Ether Router name. This implementation uses two contracts in addition to the contract that provides the functionality implemented. The first additional contract is the EtherRouter contract, which passes transactions to the contract that implements the functionality via delegatecall. The second additional contract is the resolver contract, which defines the account of the contract that implements the desired behavior. Whenever the EtherRouter contract receives a transaction, it looks in the resolver for the contract that implements that functionality, if any, and then delegatecalls that contract. In order to upgrade, new contracts are deployed using the new functionality, and then the contracts pointed to by the resolver contracts must be changed to point to these new contracts. To avoid a situation where the contract partially implements the old and new functionality, a new resolver instance is deployed for each upgrade, and then a transaction can point the EtherRouter to the new resolver. From a colony perspective, an upgrade is simply a change of one address (resolver) to another.
The choice to upgrade the underlying colony contract always falls on the colony, not on the colony network. While the network can control which upgrades are available, they cannot force any colony to upgrade the underlying contract. colony itself must decide to upgrade to the new version.
While we desire bug-free contracts, bugs are inevitable, so adopting a “defensive programming” mentality will limit the impact of any vulnerabilities that may be found in deployed contracts.
The ultimate fallback is called “recovery mode”. In this state, whitelisted accounts (those with recovery privileges) have access to special features that allow direct editing of the contract state – in effect, this would correspond to access to features that allow setting variables, as well as the ability to upgrade the contract. With the consent of multiple whitelisted accounts, once the contract is restored to a safe state, the contract can exit recovery mode. Removal from recovery mode requires the approval of multiple whitelisted accounts. This ensures that a single whitelisted account cannot enter recovery mode in a single transaction, make a malicious edit, and then exit recovery mode before other parties on the whitelist have a chance to respond.
It is conceivable that colony will be able to deactivate recovery mode functionality in the future once the network and contracts are sufficiently mature.
In general, contracts may enter recovery mode for the following reasons.
-Transactions from whitelisted accounts that indicate the contract should go into recovery mode.
-Things that should always be done correctly in case colony is not real -For example, after spending, check that the amount of funds committed to be spent but not yet paid is still less than the colony balance. If not, abort the transaction and put the contract in recovery mode.
-A qualitative trigger indicates that there may be a problem-maybe too many tokens were paid out in a short period of time.
Any approvals from whitelisted accounts to exit recovery mode must be reset whenever a variable is edited. Whitelisted accounts that agree to exit recovery mode will record the timestamp of when the agreement occurred, and any changes to the variable will also update the timestamp indicating the last edit. When attempting to leave recovery mode, only agreements reached after the last edit are counted as reaching the threshold.
The first recovery permission holder is set when the colony is created and is the creator of the colony. Additional recovery permission holders can be added via the root permission.
2.8 Arbitrary transactions
Of course, it is possible that a colony may want to engage in behaviors that we do not foresee and that can be implemented in a contract outside the control of the colony network (e.g., changing parameters in a contract when the colony as a whole is responsible for managing the contract). To this end, we would like to have a mechanism by which colony can create arbitrary transactions on the blockchain that interact with contracts and tokens without the network explicitly supporting them. Since they are powerful, such transactions should rarely occur and require root user authorization.
- Extended functionality
colony’s vision is to create a decentralized, untrustworthy organization where decisions are driven by reputation, not by a subset of moderators. However, at the level of the core group contract, access is mediated by permissions rather than reputation.
The decision to make “permissions” Colony’s core access control logic has a dual motivation. First, it can initiate a colony controlled by administrators (for small teams with a large number of existing trusts) and transition to a more decentralized, less trusted way of operating as the organization matures. Second, a permission-based approach allows for experimentation with a wide variety of mechanisms without the need to constantly deploy new colony contracts.
Much like the distinction between kernel space and user space in operating system design, permissions can be thought of as providing the system calls needed to enable end-user applications (extensions) to safely operate the underlying resources of the system. Just as this model has proven very successful in enabling a wide variety of software applications to securely share computing resources, we believe that the colony and extension models will be successful here as well.
Unlike expenditures, which represent an abstract transfer of resources, “tasks” represent a more concrete exchange of labor and value, while a unit of work does not require further subdivision or delegation. Tasks have three roles associated with them.
-Manager – responsible for defining and coordinating the delivery of the task.
-Worker – Responsible for performing the task.
-Assessor – Responsible for evaluating the successful completion of the task.
The manager (who is initially the creator of the task) is responsible for selecting the evaluators and workers and setting other metadata for the task.
-Expenses of the manager, workers, and assessors.
-Specification hash: the address of the IPF specification, which is used by the worker to direct the work and by the assessor to assess whether the task was completed satisfactorily
In order to create a task, the manager must have administrative privileges. Future variants of the “Task” extension may enforce minimum reputation requirements and/or lock-in, making task creation implausible.
Of course, determining what each role should be paid for does not provide funding – this must be done through colony’s funding mechanism. Payments do not always have to be in the same currency; a mission’s payment can consist of any number of currencies. If payment for a task is denominated in colony’s tokens, then when the task is completed, the recipient will also earn a reputation, as long as their work is well received.
If no workers are assigned to a task, the manager has the right to cancel the task altogether. Any funds that have been assigned to a task through a funding proposal can be reassigned to the task domain.
Assigning a worker or evaluator requires the mutual consent of the manager and the assignee. Once assigned, changes involving workers or evaluators (e.g., changing the assignment summary or deadline, canceling the assignment, or changing the allocation or payment) require mutual consent (i.e., multisig approval) or can be triggered through a motion process. Once the assignment is completed, the worker must submit a “final submission” by the deadline, which includes some evidence that the work has been completed.
Once the due date has passed or the worker has submitted their comments, the evaluator can rate the work. Regardless of whether the rating is positive, the job enters a status where a motion to change the final status of the job can be filed or disputed. Once the request period has passed, it is eligible for payment.
As mentioned earlier, the performance of the user who completes the job is determined after the job is submitted. At this point, the evaluator rates the work submitted by the worker and the worker rates the manager’s ability to coordinate the completion of the task on a scale of one to three. For the evaluator, a rating of one point is considered a rejection of the job, and a rating of two or three is considered an acceptance of the job. The rating received determines the change in reputation the user will experience.
1 point: The user is unable to complete the job. Reputation penalty is equal to 1x payment.
2 points: The user completes the task satisfactorily. Reputation gain is equal to 1x payment.
3 points: The user completes the task with excellence. Reputation gain is equal to 1.5 times the payout.
The worker gains reputation in both the domain (and parent domain) and the skill of the task, while the manager gains reputation only in the domain, not in the skill, because they do not actually complete the task. While coordinating the delivery of a task may require some knowledge, this is not always the case; we believe that skill reputation should only show the ability to perform the task. Upon completion of the task, the assessor also receives a domain reputation (an implicit rating of “2”). The evaluator does not have an explicit rating, but as with all other expenditures, a motion can be filed before the expenditure can be claimed; the motion may result in a reduction in payment or an explicit reputation penalty.
Assignments are based on expenditures, and the execution of an assignment as an extended contract utilizes both arbitration and management authority, the latter to dictate expenditures and the former to enforce rates.
When the assignment is completed, the claim deferral for the base expense is set to allow for motions to be filed. Depending on the ratings the recipient receives, their payoutModifiers are set to either improve reputation (for excellent reviews) or reduce the payments they can request (for unsatisfactory reviews). In addition, if the review is unsatisfactory, a reputation penalty will be applied.
3.2 Funding Queue
Section 2.1 describes the funding permission, which is used to transfer funds between funding tanks. This permission is robust – for day-to-day operations, it is best to mediate the allocation of funds through more specialized mechanisms. One such mechanism is the funding queue, which uses time as a driver to enable collaborative, asynchronous, and trustless decision making without voting.
The basic idea behind the funding queue is that tokens are allocated continuously over time, rather than all at once on a pass/fail basis, with user input controlling the speed and direction of allocation. To use an analogy, we can have water flowing down a mountain, and the shape of the mountain determines the direction and speed of the flow. Using a money queue, the user can determine this shape. Whereas in a voting-based system, unpopular proposals fail completely, with a funding queue, unpopular proposals just take a long time to complete, while popular proposals are completed quickly.
Any member of colony can make a proposal for funding. The proposer must own 0.1% of the reputation of the domain that is the most recent common ancestor of the source and target pot, and hold a significant amount of colony tokens. This portion of the reputation is used to help discourage abuse of funding proposals and to provide a mechanism by which creators can be penalized for bad behavior.
The funding queue contains a series of funding proposals, each of which has the following attributes.
-creator-creator of the proposal.
-from-funding source-Funding source.
-To-The destination of the funding pot funds.
-TokenType-Token address (0x0 for Ether).
-CurrentState-The status of the proposal (i.e. not active, active, completed, cancelled).
-TotalPaid-The amount transferred so far.
-TotalRequested-Total amount of requests.
-LastUpdated-The last time the proposal was updated.
-Rate-The funding rate, which is a function of the support reputation.
We distinguish between two types of funding proposals: Basic Funding Proposals (BFP) for normal use and Priority Funding Proposals (PFP) for insufficient BFP or special circumstances. A basic funding proposal can start funding the target company directly, while a priority funding proposal must be explicitly voted on prior to starting to direct funding. In addition, for the Basic Funding Proposal, the target pot must be a direct descendant of the source in the hierarchy, while the Priority Funding Proposal has no such restrictions. Priority funding proposals should be used when funds need to be directed to a location that is not a direct descendant of the source, when the funding rate needs to be high (including immediate disbursement) or when multiple funding proposals must occur simultaneously (e.g., in the case of payroll).
3.2.1 Detailed Properties
The purpose of the From, To and TokenType funding proposals is to move TokenType tokens from one pot to another. token type can be Ether or any ERC20-compatible token. The “From” field must be the pot associated with the domain or expense in the colony, while the “To” field can be any pot. If funds are to be transferred “downstream” from a domain to one of its subdomains, a basic funding proposal is usually sufficient.
The current status of a funding proposal is inactive, active, completed, or cancelled. Only active funding proposals can raise funds. A basic funding proposal starts in active status, while a preferred funding proposal starts in inactive status (i.e., it must be activated by a vote). A funding proposal remains active until it is completed (when its total disbursement reaches the requested total) or until it is cancelled.
The creator of a funding proposal can cancel it at any time (by setting CurrentState to cancelled). This is similar to the creator of a task, which can be cancelled if the task has not yet been assigned to a staff member. Note that if an expenditure is cancelled, the next time it is pinged, the funding proposal with the funding pot targeted (To) for that expenditure will be automatically cancelled and no funds will be reallocated. However, funds that have been transferred are not automatically returned; it may take a PFP to return the funds “upstream”. the total amount of funds that TotalPaid and TotalRequested funding proposals wish to reallocate is called their TotalRequested amount. Due to the mechanism by which funding proposals accumulate funds over time, a funding proposal will typically receive some, but not all, of the total amount requested. The total number of tokens accumulated to date is stored in its TotalPaid amount. The creator of a funding proposal can edit the TotalRequested property of the funding proposal at any time, but doing so will reset the proposal’s reputation support in the funding queue to zero. The intent here is that if the requirements for the recipient pot change (e.g., the scope of the domain increases), changes to the funding may be implemented quickly with the consent of the rest of the colony.
Rates and last update
When a funding solution is eligible to accumulate funds, it will do so at a specific rate, denominated in “tokens per second”. Because nothing happens on the blockchain without user interaction, the funding system uses a lazy form of evaluation. To request funding for a proposal to expire, the user can “ping” the proposal, where the user manually requests a prorated allocation of funds. pinging multiplies the time since the last update by the rate to determine how many tokens the proposal will accumulate in the meantime if the funding stream continues. This amount is added to TotalPaid, the funds are transferred, and the current time is recorded as LastUpdated.
3.2.2 Basic funding proposals (BFP)
A Basic Funding Proposal (BFP) is a funding proposal that goes from the funding pot of a field to the funding pot of its subfield. It starts in active status and is therefore immediately eligible for funding. The creator can cancel it at any time.
Ordering of BFPs
When created, a basic funding proposal is placed at the back of the queue. The user can give the proposal “support” based on its reputation in the source domain at the time of support.
The higher the reputation of the proposal, the higher it will be ranked. Each transaction that adds support to a proposal (or otherwise updates the support level) inserts the proposal in the correct place in the queue. Only proposals at the front of the queue will accrue funding.
There is no cost to support a proposal (other than the cost of gas) and no direct benefit to the user; it does not put their earned reputation at risk, nor does it represent any symbol – it simply helps the proposal get funded in a more timely manner and indirectly benefits colony by helping it work better for them to benefit.
BFP’s funding ratio
The more a reputation supports a proposal, the faster it is funded. The ratio scales linearly and under the restriction that if 100% of the reputation in the source domain supports the underlying funding proposal, that funding proposal will be funded at a rate of 50% of the weekly domain holdings (TokenType).
The goal is a stable and predictable resource allocation, guided jointly by the (reputation-weighted) priority of the domains.
When a user supports a proposal, both the user and their reputation at that time are recorded.
As a result, users are able to update their backups at a later date. However, we note the case where the update is not automatic, and even if a user loses reputation due to bad behavior, their support level remains the same until it is explicitly updated. Anyone can make this update – imagine a user who has lost a lot of reputation due to bad behavior and other users who want to do this to prevent the funding proposals supported by that user from continuing to accumulate funds.
We emphasize that users can back proposals with their own reputation when backing them, because the reputation of a backed proposal does not change as the user’s reputation changes. If, due to a quirk in this system, the reputation recorded as supporting a funding proposal ends up being more than colony 100% of that reputation total, then funding does not happen faster than 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 funding. Obviously, the following steps need to be performed.
- Calculate the time for the funding proposal to be fully funded.
- TotalPaid is set to TotalRequested.
- Remove the BFP from the queue.
- The next BFP in the queue is raised to the top of the queue, and its last updated time is set to the time calculated in 1.
Three days after the BFP is fully funded (and thus completed), the creator’s shares are released. Prior to this, the stake can be reduced through a license to arbitrate.
3.2.3 Priority funding proposals (PFP)
A Priority Funding Proposal (PFP) is a funding proposal that can request the reallocation of funds from either pot to any other at any rate. the PFP starts with an inactive status and can only be activated by an explicit vote. The vote is based on the reputation of the domain of the most recent common ancestor of the two jars between which the money is being transferred. We believe that PFP will be used to.
-Recover money from sub-domains.
-Recover money from cancelled missions.
-Fund missions across domains.
-Allocate funds designated for individual salaries.
-Make large, one-time payments.
Unlike the Basic Funding Proposal, the Priority Funding Proposal is not lined up – all active PFPs are eligible to receive funds at any time. Note that since the amount of funds transferred is ultimately a function of available funds, too many large PFPs can interfere with each other (and with the major BFPs) by significantly reducing the amount of funds available in the funding pot.
3.3 Budget box (Budget box)
As an alternative to fund queuing, colony can choose to use the budget box to allocate funds among sub-domains (or among multiple recipients of expenditures). In contrast to the funding queue (where projects receive funds sequentially), the budget box allows projects to receive funds in parallel from a number of fixed budgets on a pro-rata basis.
3.4 Motions and Controversies
The most successful organizations are those that are able to make decisions, divide labor, and deploy resources effectively and efficiently. Often, these decisions are made through a management hierarchy. But untrustworthy colony is considered low trust, decentralized and anonymous – hierarchy is not appropriate.
In most DAO frameworks, the mechanism for collective decision making is usually voting, whereas colony is designed for the day-to-day operations of the organization. In colony, it is completely impractical to vote on every decision. The focus should be on “getting things done,” not on “getting permission. Therefore, colony is designed with tolerance at its core. Mission creation does not require explicit approval, nor does it require basic funding proposals or any number of administrative actions throughout colony.
The campaign system provides a self-regulating mechanism that allows users to keep colony running in harmony through a balanced set of incentives. It is designed to resolve disagreements and punish bad behavior and fraud. The motion system allows colony members to signal their disapproval and may force votes against users who misbehave.
When members of a group feel that something is wrong, they can file a motion. By doing so, they fundamentally propose that either a) a variable, or more than one variable, in colony should be changed to another value, or b) a user, or more than one user, should receive a reputation penalty. Thus, we call the proponent of the motion the “change” side and the opponent the “keep” side.
The user making the motion must also pledge colony’s internal tokens. Essentially, they are inviting the rest of colony to disagree with them. In the spirit of avoiding unnecessary votes, the motion will automatically pass unless someone sides with the “reserve” side, thereby elevating the motion to a controversy.
We say that whenever a motion is supported on both the “change” and “reservation” sides, a controversy has arisen. Once a dispute has been raised, it must be resolved by a vote.
3.4.1 Filing a motion
The user conducting the motion submits the following data.
-The data that should be changed or that the user will be penalized.
-Reputations that should be voted on this issue (up to one per domain and skill hierarchy).
-Proof that these reputations should be allowed to make relevant changes.
The first item identifies the subject of the motion and what the appellant believes the state should be. The second and third points relate to the appeal. colony’s basic principle is that you cannot appeal a decision to higher management, you can only appeal to a larger reputation group.
For example, suppose the motion involves a task in the “front end” domain. The appellant has the option to have all of the “development” reputations vote – we say that the decision is “appealed to the development domain”. In this example, the third point is to prove that the domain “frontend” is indeed a subdomain of “development”. The highest domain that any decision can be appealed to is the root domain, and all domain credentials are entitled to vote.
Whenever an appeal occurs, we need to make sure that the reputation we are appealing to is the parent of the reputation associated with the variable being changed. This can be done effectively because metadata is placed on the reputation (domain) at creation time, which includes at least a pointer to the direct parent. When a user does an action, instead of specifying the domain they are interested in directly, they provide the steps needed to reach it from the domain associated with the variable to be changed. This ensures that the domain they are accessing is the direct parent of the domain associated with the variable.
3.4.2 Costs and rewards
Cost of making a motion
To make a motion, users must have a sufficient reputation and must also hold a certain number of colony tokens. The reputation they need to make a motion depends on the domain they are attracted to; the higher the decision, the higher the reputation requirement (and potential loss). In order to be able to create a motion, a user must have 0.1% reputation in the domain and must hold 0.1% of the corresponding portion of tokens. Thus, if a motion involves 13% of the total colony reputation, then the motion requires 0.013% (0.1% of 13%) of the reputation and the required shares are 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 placing only 10% of the required tokens, which requires them to have a correspondingly smaller reputation. In this case, the campaign will not be “live” unless other users hold tokens and place them above the 0.1% threshold. When a specific campaign is created, the amount of tokens that need to be wagered for that campaign is recorded. Users can only hold tokens in proportion to their reputation. For example, if they want to hold 40% of the required tokens, they must have at least 40% of the reputation, which will be needed to create the campaign thoroughly.
Cost of opposing a motion
Once there are enough tokens on a motion, it is activated and unless there is any further action within three days, the proposed change will happen (when the motion is “pinged”).
However, if a user objects to the proposed “change”, they may use tokens to support the “hold” end. If the other side gets enough support, a dispute will arise.
If the “change” side does not get enough support within three days, the motion will fail and be rejected. If the “change” side has enough tokens after three days and the “keep” side does not, the change is assumed to be acceptable.
If both parties hold the required number of tokens within the specified period, the dispute is voted on. The weight of a user’s vote is the sum of their reputations in terms of the skills chosen by the user who originally made the motion.
The duration of the vote depends on the percentage of reputation eligible to vote as a percentage of colony reputation. If a larger score is eligible, the longer the poll is open. The minimum duration is two days and the maximum duration is seven days. This is a trade-off between allowing disagreements between small groups to be resolved quickly and allowing for full debate when more people participate.
Vote to use a submission and disclosure program. This scheme is desirable because the poll is confidential for the duration of the vote, preventing users from being influenced by what they believe to be the majority opinion. To vote, the user submits a hash, keccak256 (secret, optionId), where optionId indicates the option the user voted for. Once the poll is closed and the vote enters the display phase, the user can submit (secret, optionId) and the contract computes keccak256 (secret, optionId) to verify that it was originally submitted by them.
As the secret is revealed, it cannot be sensitive. It must also change with each vote, so that observers cannot be sure what people voted for after the first vote is announced. While there are many reasonable options for generating secure secrets, we recommend using the result field (hash) of a private-key signed poll because it can easily be replicated by the client at a later date without the need for local storage.
To counter voter apathy, 10% of the pledge tokens are set aside to pay voters when they vote: if a voter has 1% of the reputation available to them to vote on the decision, they will receive 1% of this voter. When they announce the results of their vote, they receive this bonus regardless of the direction of their vote or the final outcome of their decision. This “payment regardless of opinion” is designed to prevent us from becoming victims of the Cairns beauty contest, in which, by being rewarded for being “right,”
Voters are incentivized to vote for what they believe the majority will vote for, rather than their independent beliefs. After the vote closes, any tokens awarded to users who abstained or were not shown in the “show” window will be sent to the root domain funding pot.
Once the vote has been in the disclosure phase for 48 hours, transactions can be made to finalize the vote. Any subsequent vote display will have no effect on the decision being made, but will only be used to unlock the user’s tokens (in the case of a token-weighted or mixed vote).
Consequences of the vote If the “change” side wins the vote, then the problematic change is made, but only if the reputation of the vote for this outcome is higher than the previous vote on the same variable. If the “keep” side wins, the variable remains unchanged. In either case, note the fraction of the total reputation voted for the winning side in the colony.
At the end of the vote, the loser of the bet will receive 0-90% of the bet, and they lose the percentage of reputation required for the bet to be replenished. The exact number of tokens they recover (and therefore the reputation they lose) is based on.
-A fraction of the reputation of the vote in colony.
-how close the final vote was.
At the end of the vote, if the vote is very close, then the losing party will recoup nearly 90% of their shares. If the vote is unbalanced such that the vote weight (w) of the winning party reaches an overwhelming threshold of the total vote weight (L), then they will receive 0% of the bet tokens. l varies according to the fraction of the total reputation in the voting community (R).
Thus, for a small group holding a small surplus in the colony to be allowed to vote, it would have to be close to a unanimous decision in order to impose a severe penalty on the losing side. For the entire colony vote, the overwhelming threshold L is reduced to 67% of the vote, meaning that the overall reputation of the colony is distributed in this decision in a 2-to-1 ratio.
Between the slippery slope loss and the very weak loss, the losing party suffers a linear change in tokens and reputation loss above a minimum of 0.1 (∆).
So the total loss (0.1+∆) varies between 0.1 and 1.
What happens to the lost tokens?
Any tokens lost above the initial 10% will be split between colony and those on the winning side of the bet, in proportion to the amount they bet. Half of the reputation loss over the initial 10% goes to those on the winning side of the bet, and half is destroyed (the idea that colony as a whole owns the reputation makes no sense, unlike the idea that colony as a whole owns the tokens).
The motivation here is efficiency – it is designed to discourage spurious motions and disputes. The one vote no shows that the decision was not an easy one, and that forcing a vote may have been the smart thing to do.
Therefore, the opposition parties should not be punished harshly. On the other hand, if the vote ends in a landslide, it shows that the losing party went against the general consensus. We encourage communication within colony. Members should learn as much as possible about the views of their fellow members before making motions.
To reduce the number of repeated motions and disputes on the same variable, record the score of the total reputation of the colony that voted for the winning side after each vote. This is the threshold that must be exceeded in any future vote in order to change the variable again.
We reiterate that even if it is decided to maintain the current value of the variable, that value will be updated after each vote.
This requirement is the main driver of the appeals process. If a decision is made in a domain with a low turnout, it is possible to overturn the decision by holding another vote in the same domain (with a more energetic “get out of the voting chain” campaign). However, if the majority of the domain’s reputation is involved in the vote, then the only way to gain the support of a larger reputation body (necessary to reverse the decision) is to appeal to a higher domain or a larger skill body.
There is one exception to this rule: to ensure that variables can always be changed when necessary, the threshold for changing a variable is ignored if the movement is requested to the root domain of the group. Whenever a vote is taken in the root domain, the variable can be changed without regard to the previous vote on that variable.
3.4.3 Voting Types
Depending on the context and potential consequences of a vote, colony supports three types of voting. The type of voting for a given lawsuit is predetermined based on that lawsuit, not the appellant’s choice.
The majority of a colony’s votes will be due to task-related motions. In these cases, the weight of a user’s vote is proportional to the reputation of each user in the domain and skill in which the vote is cast. When such a vote is initiated, the current reputation status is stored with the vote. This allows the current reputation status to be “frozen” in the context of the vote and prevents unwanted behavior that might be encouraged (e.g., delaying task submission until close to the time of the vote so that earned reputation does not decay as much as before).
When displaying their vote, users also provide a Merkle proof that their associated reputation is included in the reputation status saved at the start of the poll. They certify that the total number of votes for the option they voted for will increase appropriately.
Token Weighted Voting
While Colony encourages the use of reputation as the primary sibyl resistance mechanism, in some cases, tokens are more appropriate. Specifically, if reputation is a stand-in for “labor” and tokens are a stand-in for “capital,” then token-weighted voting is appropriate whenever a decision must be made by capital rather than labor. Whenever an “investor” or “shareholder” of a traditional company makes a decision, a symbolic weighted vote may be appropriate.
Unlike reputation, we cannot “freeze” token distribution at the start of a vote. While this is effectively possible with MiniMe tokens, we envision that token-weighted (or hybrid) voting will remain routine enough within colony that we do not want to burden users with the natural gas costs of deploying new contracts each time.
When conducting token-weighted voting, steps must be taken to ensure that tokens cannot be used for multiple votes. In the case of a “DAO”, once a user votes, their token is locked until the vote is completed. This introduces a special incentive to delay voting until as late as possible to avoid unnecessary locking of tokens. Our locking scheme avoids this skewed incentive by locking tokens only during the reveal period.
Instead, once the poll enters the reveal phase, any user who voted in the poll will find themselves unable to see the tokens sent to them, or unable to send tokens themselves-their token balance is locked. In order to unlock their token balance, users simply show their votes for any poll that enters the display phase – something they can do at any time. Once their tokens are unlocked, any tokens they have nominally received since the tokens were locked are added to their balance. This global lock prevents situations where, for example, a user will display their vote and then send the tokens to a colluding user who will then display their vote using the enhanced token balance.
Locking of constant gas can be achieved by storing all submitted votes confidentially in a sorted linked list indexed by closeTime. If the first key in this linked list is earlier than when the user sent or received the funds, then they will find their tokens locked. Showing the poll will remove the key (or close it at the same time if the user has not submitted another poll).
This will unlock the token as long as the next key in the list is future timestamped. A more detailed description of our implementation can be found on the Colony blog.
Instead of searching for the correct position to insert a new item, the structure can also be inserted in constant gas if the client provides the correct insertion position, which can be efficiently checked on the chain.
Hybrid voting would allow both reputation holders and token holders to vote on decisions. We envision that such voting will be used when the action being voted on could have a significant impact on both reputation holders and token holders. This would include changing the supply of colonial tokens outside of the parameters already agreed upon or when deciding whether to perform an arbitrary transaction.
In order for a proposal to successfully pass a mixed ballot, a majority of both reputation and token holders voting must agree that changes should be implemented.
3.5.1 Token Management
While root users can make tokens at will, in many cases it is desirable to mediate this ability by extending the contract. Here we describe such an extension.
Token generation and initial provisioning
When deploying an extension, TokenSupplyCeiling and TokenIssuanceRate are set.
The former is the total number of colony tokens that will be created, and the latter is the rate that the root domain can allocate to sub-domains or sub-domains. The number of tokens available for the root domain can be updated at any time by a transaction from any user (i.e., the public function will determine the number of pro-rated tokens generated since the last distribution).
Increasing token supply
It is recommended that new tokens not be generated without broad consensus – especially if the tokens have financial value. Therefore, such decisions require a high quorum vote and involve both token holders and reputation holders.
Changing the Token Issuance Rate (TIR)
Token Supply Ceiling (TSC) represents the total number of tokens granted to colony by token holders to conduct business: fund domains and expenses, and incentivize employees and contributors.
Token Issuance Rate controls the rate at which colony receives new tokens. If the rate is “too high”, tokens will accumulate in the root domain’s pool (or other pools lower in the hierarchy). If the issuance rate is too low, it indicates that the activity of the group is considerable and the issuance rate has become a bottleneck. In this case, it may be necessary to increase the issuance rate without necessarily increasing the maximum supply.
Increasing or decreasing the Token Issuance Rate by up to 10% can be done by the Reputation Holder alone and can only be taken up to once every 4 weeks. Larger changes in the Issuance Rate also require the consent of the existing Token Holder.
3.5.2 Compensation methods
Using expenses, a variety of compensation methods can be implemented. In addition to “assignments”, we can also envision some additional compensation methods.
Tasks imply that the colony-worker relationship is primarily transactional. In many cases, it is desirable to express the longer-term relationship through salary.
Salary can be expressed simply as a recipient, an amount, a period and a final claim. At any time, the recipient can ping the payroll contract, at which point the contract will create an expense paid to the recipient with funds equal to the amount prorated since the last payroll payment. If the recipient is willing to pay for gasoline, they can claim (a small portion of) their salary daily, or choose to claim weekly, monthly, or at whatever pace suits them. It is the responsibility of Hong Kong to ensure that sufficient funds are available in the areas where salaries are paid.
This extension requires funding and administrative privileges to manipulate tokens and expenses on behalf of the recipient.
Regular or automatic assignments
For some types of work, the tasks are unique and must be individually scoped and subjectively evaluated. However, we can imagine situations where work can be done by many people and/or automatically evaluated by a computer (e.g. rewarding users who participate in a referral program). In these cases, it would be appropriate to include a task variant that evaluates the job logic and allows anyone to submit jobs.
This extension requires funding and administrative privileges to manipulate tokens and expenses on behalf of the recipient.
3.5.3 Granting reputation for work not captured by a task
This prevents permanent “reputation aristocracy” while allowing reputation to remain relevant even when the value of colony tokens changes significantly.
Reputation is granted when a user receives payment for a colony’s internal tokens – most often payment from expenses, but sometimes payment from motion resolution, and in the case of metacolony, payment from the reputation mining process. In the case of consensus, we can use the spending mechanism to reward the user with additional reputation.
Consider a scenario where the founders or important early contributors to the colony leave little to no reputation when the colony starts to become profitable; perhaps the development of the product took a long time, or perhaps the reputation decline rate is sub-optimally high for a specific group of people. Or maybe the founders did a lot of intangible work to get colony off the ground in the first place and therefore were never properly compensated in the chain. To get around the limitations of the reputation system and reintegrate the founders (and make them eligible for rewards), colony could create an expense dedicated to rewarding them for their deserved reputation. In order to be eligible to pay tokens (and thus earn reputation), the user in question would have to return the same amount of tokens to colony. again, a good front-end could make this reputation reward simple and intuitive.
Another important situation involves absences due to maternity/maternity leave or illness – the reputation system should not implicitly discriminate against these users. While a “moratorium” on reputation decline is not a viable option, various mechanisms for providing reputation “for free” can be used to ensure that these users maintain their reputation during unavoidable absences.
The important point is that any restrictions imposed by the system could be weakened if consensus is reached. The system should not prevent consensus, but should provide a mechanism for conflict resolution in times of disagreement.
3.5.4 Motions by non-members
Having a reputation is a prerequisite for filing a motion or raising an objection. Thus, if an outsider is hired by a colony to perform a task, they will not be able to make a motion defending their work on their own. However, a good colony front-end may allow them to create a template for a motion, effectively calling on colony members to support it, and submit the motion to the colony network chain on their behalf.
This is similar to a member placing only 10% of the required amount and waiting for further support from their peers, the difference being that without any third party support, the motion will never be processed on the chain.
The Colony Network is a collection of contracts on the Ether blockchain. The core of the network is the Colony Network contract. This contract is primarily responsible for managing the reputation mining process, as well as the general management of the network: deploying new colony, setting fees associated with using the network, and releasing new versions of the colony contract. These actions will be mediated by a special group, the metacolony.
4.1 Revenue model
The colony network must be self-sustaining. In particular, the metacolony (which controls the colony network) maintains the contracts that underpin the network and develops new features for the network, which requires payment for its development. In the long run, the development and maintenance of the network (including the reputation system) requires the network to fund itself.
4.1.1 Network Fees
We propose to levy fees for expenses and reward expenses. When a user requests a payment, some small part will be paid to the network. The fee is sent to the metacolony (if the payment is in Ether or other whitelisted ‘cryptocurrency’ tokens) or to the colony network contract (if it is any other ERC20-compatible token)
This idea of fees is a bit unusual for such a decentralized system. One of the attractions of ethereum systems is that they are not rent-seeking and are free to use, except for the cost of gas. However, the network fee is key to ensuring the game-theoretic security of the colony network reputation mining and governance process, and it provides potential value to the CLNY held by meta-colony members. Importantly, this fee is not paid to any centrally controlled entity, but to the metacolony. since anyone can contribute to the metacolony, anyone can claim a share of these fees in proportion to their contribution. We believe that the benefits of being part of a secure, well-maintained network will be attractive enough that paying a small fee for its existence will be acceptable.
The existence of this fee means that we must consider a number of considerations that would otherwise be irrelevant. Primarily, we need to develop “back pack” contracts as much as possible, so that when expenses are determined, for example, they are used to cover expenses but not to send fees.
4.1.2 Token Auction
Since network fees can be denominated in any ERC20 token, a mechanism is needed to liquidate arbitrary token packs: a token auction. The collected tokens are auctioned by the colony network contract, the auction is denominated in colony network tokens, and the proceeds are burned. These auctions – one for each type of token – are regularly conducted once a month.
We believe that this mechanism will benefit both the group network token holders (whose tokens gain value through explicit use outside of reputation mining) and the meta-colony itself (by reducing the supply of group network tokens, thus making any future minting more valuable).
It also provides an immediate price discovery mechanism for intra-colony tokens, which are unlikely to be traded on third-party exchanges until very late in the life of colony.
By auctioning the collected tokens, we also prevent metacolony from collecting a large number of different tokens that would have to be managed, which would prove tedious and annoying.
4.2 Meta-colony and CLNY
Meta-colony is a special group that dominates the colony network. The tokens in metacolony are called CLNY and will initially be generated during the distribution of the colony network.
4.2.1 Roles of CLNY holders and metacolony
CLNY holders have two main roles. The first is to participate in the reputation mining process. The second is the management of the colony network itself. There will be permitted functions on the network contract that allow setting the basic parameters of the network, and these parameters can only be called by the meta-colony. For these permitted functions to be invoked by the meta-colony, a vote open to all CLNY and reputation holders must be conducted. the management of the colony network also includes the provision of updates to the colony contract to the colony. the CLNY holders are not necessarily responsible for the development of these updates, but are required to vote to deploy them. As such, they are at least responsible for ensuring that they or their service providers perform due diligence to avoid introducing security weaknesses or other malpractice. In return for the responsibility of developing and maintaining the colony network, meta-colony is the beneficiary of the network fees.
Reputation in metacolony can be earned by spending CLNY tokens, just like in any other colony. Reputation in metacolony can also be earned by participating in the reputation mining process, which is unique to metacolony.
4.2.2 Giving decision making power to metacolony
The colony network token holder is responsible for reputation mining from the beginning, but decisions regarding the underlying properties of the network will initially be made by a multi-signature contract controlled by the colony team. As the network grows and proves to be effective, control of these decisions will be ceded to meta-colony.
Phase 1: colony team multi-signature control
Initially, the functionality of the network contract will be root-privileged so that only transactions from multisig contracts under Colony team control are allowed to change these properties of the network.
Phase 2: Colony team multisig approval required
Later, the extension contract will be created and root privileges will be granted. The contract will allow the meta-colony (as a whole, through the governance mechanism provided to all colony) to propose changes to the colony network contract. The intermediate contract will have the functionality that all changes must be explicitly allowed by an account under the control of the colony team. In other words, the metacolony will be able to propose changes, but the team must sign off on those changes.
Phase 3: colony team retains veto power over multiple signatures
The next phase will be a second extension contract that operates similarly to the first, but after a timeout (no interaction from the colony team account), anyone can forward changes to the colony network contract. it is the colony team’s responsibility to block the changes if necessary. Therefore, at this stage, metacolony will be able to make changes autonomously, but the colony team retains veto power. The proposal to move to this contract must come from the metacolony itself.
Phase 4: Metacolony takes full control of the network
Finally, the dedicated extension contract will be removed and replaced with a generic voting extension, and the meta-colony will have direct control over the colony network contract, with no privileged control by the colony team other than any CLNY-provided privileged control and held reputation.
5 Reputation Mining
The reputation system is a core component of any decentralized colony. By carefully balancing rewards and penalties, our goal is to align each user’s rewards with the group and the group network. Because reputation can only be earned between accounts and not transferred between accounts, the system fosters a more elitist form of decision making than can be achieved by simply weighting votes. The continuous decline of reputation ensures that the influence conveyed by reputation is effective
recently acquired and up-to-date. As such, it prevents reputation aristocratization and allows control to shift over time from one set of contributors to another.
Due to the combined complexity of reputation scores across multiple colony, domains and skills, reputation scores cannot be stored or calculated on the chain. Instead, all calculations will be performed off-chain, and the results will be reported to the blockchain by participating CLNY holders – a process similar to the proof-of-stake blockchain consensus protocol. We call this reputation mining.
The reputation calculations for which miners submit their results are determined by the activity that occurs in the colony and can be derived with complete certainty from the ethereum blockchain. Game-theoretically, the protection of the system is similar to TrueBit’s off-chain computation, since computations cannot be performed on-chain, correct submissions can never be proven correct, and incorrect computations can always be proven wrong.
Decentralized Capital Allocation via Budget Boxes
The mechanism is based on a new component called the budget box, which implements a simple, general and powerful governance algorithm where the budget box aggregates and processes pairs of preference sets. Our approach involves converting our set of pairwise preferences into a Markov transfer matrix M and using this matrix to find the eigenvector v corresponding to the probability distribution of the project, which we can interpret as a budget or ranking. Intuitively, we can consider the final probability as the likelihood of the “most important thing” based on the observed preferences.
Our voting information is converted into an integrable, non-periodic, iterative Markov matrix guaranteed to have a unique principal eigenvector that can be interpreted as a probability distribution of items, or as a ranking or budget allocation. There are many ways to find the eigenvectors; we will use power iteration, a simple algorithm to bring the v’s closer together.
Intuitively, each iteration will first ask “which items are the most popular?”
and then “For each item, which item is more popular?” Over time, the probability mass converges to the relatively more popular items, as the popular items accumulate more probabilities, which are then “sent” to items that are more popular than they are.
The limit of K items per box does not limit a mechanism to K items in total, as multiple budget boxes can be combined to accommodate larger sets of items. One way to synthesize them is to assemble the boxes into a scaffold; another way is to combine them into a recursive hierarchy of “abstract to concrete” (think public services) → Education → The composition of the budget boxes reduces cognitive complexity and computational complexity. For 100 items, there are 4950 possible pairs; compare this with 10-45 = 450 pairs, and the same 100 pairs are divided into 10 groups of 10 pairs each. These 450 pairs are a subset of the original 4950 pairs, but not at random. If we assume that the 100 items can be sorted by quality, and that only comparisons between items of similar quality can provide useful information, then subdividing the item set into subsets of items of similar quality avoids making 4500 low-value comparisons: a 10-fold increase in cognitive efficiency.
- Leagues and tracks (leagues and lanes)
To maximize the use of voters’ limited attentional resources, we divide the items into two categories: one for items in leagues (each league is basically a thin package of budget boxes) and the other for one of several tracks in the pool. All projects start in the pool; projects with sufficient support are promoted to the league, and projects in the league are then compared and ranked in pairs; higher-ranked projects advance to higher leagues and are eligible for larger awards.
3、Scoring track (scoring lanes)
Items in the league can be rewarded through the colony task mechanism. On the other hand, the pool is for projects that wish to enter the league; projects in the pool do not receive rewards.
Thus, the processing mechanism for items in the pool is simpler than in the high-risk, high-concern leagues, providing only a crude filter. The pool is divided into L “tracks”, each of which can hold up to 256 items. Projects enter a track by wagering a fixed number of CLNY tokens. Once in the track, projects are only approved for voting; projects receive a score equal to the reputation-weighted sum of their approvals.
At the end of the voting, we rank each track, and projects are ranked based on their overall reputation for support. The lockout requirement is intended as an anti-spam mechanism. To further prevent low-quality project submissions (which would distract voters), projects in the pool that score below the median of 0.2 are burned. To prevent projects from withdrawing their shares in anticipation of being burned, we will only allow projects to leave during the first third of the voting period.
- Moving between leagues
Our mechanism is much like a sports league, where the lowest ranked will be relegated to a lower league at the end of the season, while the higher ranked will be promoted to a higher league. In our example, a “season” is a voting cycle. At the end of the voting period, all programs are rated, appropriately rewarded, and placed in the next league. Reallocation is determined by the parameter Z and the “wash factor” C, which determines how many programs move between the two cycles. Since the leagues are arranged in a binary tree, it is possible to index each node and traverse the tree. When moving from one league to another, the worst (after sorting by score) 2C programs in the league are swapped with the best C+C programs in the league’s next level, and promotion and relegation occur alternately.
From the track to the league, items that finish at the bottom of the bottom league will be removed from the system (refunded their stakes). They can be freely re-entered into the pool by posting a new bet. The newly vacated spots are filled by the top programs in the pool. The goal is to have no more than half of the pool in the league at the same time, so that each track can support the most leagues. When there are multiple tracks, they are assigned to a blade league.
Conversely, we use leaf leagues(l) to denote the leagues associated with a track. Our goal is to replace the bottom 2C programs in all leaf leagues with the top 2C |leagues(l)| programs in the pool. Therefore, for each track, we perform a balanced replacement of the quality of the candidate projects, which should be implemented in a staggered exchange in a rotating manner, so that the strongest candidates are equally distributed as they enter the league.
- Determine the allocation
Once the projects have been voted on and the votes have been processed, their final budget allocations are determined before they are moved.
Only programs in the league receive a budget allocation, determined by v a damping factor d, which allows for a balanced allocation across all programs in the league. Related to this, we have to decide how to allocate the available budget in the league.
This allocation is controlled by the parameter Q ∈ [0, 1], which steers us between two extremes: at Q = 1, we have a uniform allocation across all leagues, and at Q = 0, the allocation is exponentially decreasing. Knowing Q, we can determine the total budget available to the coalition.
- Scaling mechanism
The mechanism can be scaled up to accommodate any number of projects. Note that the capacity of the mechanism is driven by three parameters: Z determines the number of leagues, K determines the size of the league, and C determines the degree of movement of the league; together they determine the size of the pool, which we require to be able to accommodate twice the number of programs entering the league in any given period.
As the colony network matures and the number of programs participating in the mechanism increases, the mechanism can be expanded by adding Z; each increment will double the league size and create new tracks as needed. Note that as tracks are added, existing candidate tracks are not redistributed, thus creating an “arbitrage opportunity” that allows projects to bet on less competitive tracks; this naturally leads to an even distribution of project quality among lanes.
To make this mechanism resistant to corruption, bribery, and complicity, we first turn to the colony reputation system. By reputation-weighted voting, those with the most influence also benefit the most from the development of the colony network, and in the case of reputation-weighted voting, those with the most influence also benefit the most from the development of the colony network, and are therefore the least willing to accept immediate payments (bribes) in exchange for worse long-term prospects. Moreover, because reputations stem from work done for Meta Colony, those with greater influence ostensibly have a better understanding of the ecosystem and are better able to determine the relative value of projects.
To encourage participation, we set aside a portion of B as constituent compensation, with each constituent’s compensation being a function of relative reputation. Making compensation proportional to reputation serves the dual purpose of counteracting sibyll, but also encourages the most influential people to do their best to make informed decisions (increasing their long-term compensation) and further reducing the relative incentive to accept bribes in exchange for preferential treatment. If BR is the portion of the budget set aside for voter compensation, determine each voter compensation in the following manner:
Another consideration is the breakdown of the voting process. Should “voting units” include votes for each pair and each item? Or should reputation holders contribute smaller units as their motives allow?
Fortunately, the “coalition” organization of projects leads to a natural division of work. Voting in a coalition or lane constitutes a voting “unit”. The requirements for voting per unit should be set in advance.
As mentioned above, the mechanism as a whole is controlled by a number of hyperparameters: K, which determines the size of the coalition; Z, which determines their number; C, which determines the degree of movement between two periods; B, which determines the total budget; and d and Q, which affect the distribution of budgets within and between coalitions, respectively.
Unlike two-by-two voting, which captures individual preferences, these hyperparameters capture political preferences because they define the behavior of the system as a whole: the size of payments, the number of programs eligible to compete, the degree of permissible inequality in payments to popular and unpopular programs, and the rate at which allocations to particular programs grow or decline.
All of these parameters, except for a fixed value of K, can be updated by reputation-weighted voting in the meta Colony. Our expectation is that Z and B start out small and increase in size as the network matures and the number of projects increases. We expect that d, Q, and C will be updated more infrequently to adjust the behavior of the mechanism; we expect each to start with a lower value of the mechanism so that spending becomes more meaningful in higher level leagues, and higher level leagues, where “losing” projects will still earn more than “winning” projects in lower level leagues. “projects, and the interleague movement is slow enough that the project has a meaningful time horizon for revenue.
It is intentional that winning programs will accumulate reputation and influence in the metacolony over time. Since these projects both support and depend on the colony network, it is appropriate that they both participate in the governance and share in the rewards of the network.
In our brief, we present some possible attack vectors and failure scenarios, and claim to have developed defenses.
We will present them one by one.
- Spam. Minimal bets make spam expensive.
- Scammers. Low initial payments make scams uneconomical.
- Bribery. Reputation-weighted voting adjusts long-term incentives.
- Self-voting. Solution: European visual rules.
- Collusion. Non-linear voting interactions, random wandering.
- voter apathy. Participation experience, voter compensation.
- cognitive bias. Nonlinear voting interactions.
- Random voting. Solution: Reputation-weighted voting and compensation.
- Sybil attack. Solution: Reputation-weighted voting and compensation.
It is important to note that no mechanism is completely resistant to attack or failure; every mechanism, even proof-of-work, works on the condition that some reality prevails. The mechanism we describe assumes that a reasonably diverse set of participating reputation holders want to benefit from the long-term success of the Colony network. The goal of this mechanism is not to provide an infallible framework for decision making, but rather to solve a set of specific problems without introducing a large number of new ones.
We believe that the use of pairwise preferences to solve collective ranking and budgeting problems is an important tool in the decentralized governance toolbox.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/colony-v2-a-dao-infrastructure-that-effectively-reduces-market-transaction-costs/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.