DAOrayaki DAO研究奖金池：

资助地址: DAOrayaki.eth

投票进展：DAO Committee 5/7

通过赏金总量：200 USDC

研究种类：DAO, Colony, Domains and permission, Transaction Cost, Reputation Mining, Market Suppliers, Colony V2，Transaction Cost Economics (TCE) theory, Collaboration

贡献者：黑白QB, DAOctor@Daorayaki

上线时间：2017年上线，2021年2月15日软上线

代币：CLNY（ERC-20）

人才高度分散，机会高度集中。很多人都想创业，尽管创业比以往任何时候都容易，但进入门槛仍然很大。因此，这些人可能投入商业项目的热情、才华和精力，往往被引导到在线社区、免费开源软件项目和其他爱好中。

什么是Colony？

Colony基于以太坊平台之上构建。它具有按贡献拥有所有权、功绩影响、公平回报的特点。Colony的公平奖励系统在colony赚钱时起作用，并且通过事先商定的智能合约协议自动将钱分享给colony成员和其他人。公平的奖励是根据会员持有的代币和声誉的比例来分配的。

Colony做了什么？

Colony是一个分布式组织的社会协作平台。用户可以在线启动项目，并建立一支员工队伍来帮助实现这些项目。因为它将劳动力的激励机制与生产力结合起来，所以世界上任何地方的人都有可能从事一个项目，而不需要分级管理。

该平台通过按每个用户贡献的价值比例分配权限权益，激励用户竞争成为最有技能和生产力的人。该平台自动化了项目管理过程，汇集了成员在建议任务、做出决策、将任务分配给最佳候选人以及提供工作反馈方面的集体智慧。平台的每一个方面都采用了博弈机制和行为设计，以确保令人信服的体验，鼓励重复参与。

Colony目前在xDai上运行，支持以下功能：

1.将社区组织成具有加入门槛的部门或团队。

2.管理代币库，并将预算应用于不同的团队和计划。

3.支持各种不同付款方式。

4.根据组织的具体情况，定制成员权益分配权限，比如通过参与治理获得的影响力等。

5.通过代币销售、捐赠或收入等方式筹集资金。

6.提供多种决策机制以适应不同的用例，并在其出现分歧时进行仲裁争议。

7.DAO可以与其在同一链上的其他合约进行任意交易，如果您的DAO需要管理另一个协议或与DeFi进行交互， Colony可以帮你实现。

总的来说，权力下放是Colony的治理哲学，我们认为投票不可取，所以力求在可能的情况下避免投票。鉴于任何组织都是不同的，所以Colony采用了模块化设计，这意味着组织能够插入扩展程序，可以根据需要进行操作，为其组织提供他们所需的工具。

Colony V1和V2版的区别

由于完全的数据去中心化造成的系统处理速度极慢、系统公共基础建设未完成、社区参与度不足等原因。Colony于2021年初开始逐步转向Colony V2。已由以太坊主网迁移到了xDAI网络

改变如下：

权限（Permissions）

Colony 的访问控制框架。访问权限以以太坊地址为单位，拥有权限的以太坊地址可以访问某些特权功能（类似于底层系统调用）。权限共分六种，从高到低排序如下：恢复权限、Root 权限、仲裁权限、架构权限、资金权限和管理权限。每种权限代表一个功能的语义包。可以在域层次结构的不同级别上授予权限，从而实现复杂授权系统的创建。此外，由于可以向任何地址授予权限，因此使得独立智能合约的开发成为了可能，进而实现将独立智能合约「插入」Colony 以扩展其功能。

扩展功能（Extensions）

赋予任意以太坊地址访问特权功能的权限就意味着可以非常灵活地开发和试验基于这些功能的任意机制和接口，那么基于以上权限设计的构思，Colony 自然而然就衍生出了扩展功能这一想法。例如，围绕「资金」权限可以建立一个专门的预算机制，允许各地址在不同域之间转移代币。通过开发可在底层功能与各机制之间进行调节的扩展功能，各 Colony 可以更有效地探索组织的设计空间，或者尝试使用更直接的管理控制以及无需许可的分布式决策机制。

质押管理（Stake Management）

许多扩展功能可能会要求用户在采取操作之前质押代币，例如一个关于投票的扩展功能可以实现用户通过质押代币来发起任意投票。如果其他用户认为该投票属于恶意行为（或者把投票当作垃圾邮件），那么投票发起人可能（理所应当）会失去他们质押的代币。考虑到扩展功能的合约是独立的，那么用户就不得不追踪对许多不同合约做出的质押，而这会给用户带来相当大的负担。此外，还要确保扩展功能的合约持有这些质押代币的安全性，这就给扩展功能的开发带来了极大的负担。为解决这些问题，Colony 为扩展功能（或管理员）开发了一个通用接口，代表用户管理质押，而无需实际持有资金

信誉挖矿（Reputation Mining）

虽然信誉挖矿过程的设计基本未做更改，但 Colony 团队已经做出了很多实现选择，与原始白皮书中给出的选择有很大不同。最重要的是，其中包括将信誉树的数据结构从常规的 Merkle 树切换到效率更高的 Merkle-Patricia 树。

Colony特点

交易成本包括明确需求、寻找供应商、接收和比较报价、商定合同条款、管理交货、开具发票和会计、质量控制、争议解决等等。DAO没有其它选择，只能通过市场机制来协调供应

一个有效的DAO框架必须降低市场供应机制的交易成本。但不幸的是，除Colony之外，所有DAO的问题都在于它们增加了交易成本，他们的复杂决策程序与要求代币持有者对组织做出的每个决策进行投票的策略是荒谬且完全不可扩展的。

鉴于此，Colony决定通过使用多种方法的组合来解决这些问题，我们允许DAO通过创建多个团队和子团队来进行扩展，并通过不要求每个决定都进行象征性投票。取而代之的是通过使用与DAO贡献价值成正比的影响力来量化个人专长，从而赋予个人行政权力。

此外，在Colony，投票是万不得已的手段。我们的治理通过“惰性共识”起作用，一个提议中，只要没有人反对，提案就会在安全延迟后自动通过。换句话说，如果你看到一条同意的建议，那么你什么也不做。如果发现不同意的内容，你就可以提出异议并强制进行表决。

创始团队：

杰克·杜·罗斯（Jack du Rose）

Colony首席执行官，毕业于英国西部大学。Collectively Intelligent Ltd前首席执行官，Outlier Ventures的导师。

科林·藤（Collin Vine）

Colony联合创始人，Zirtual.com前联合创始人。他最感兴趣的是未来的工作，包括城市、经济和组织是如何以及将如何受到技术的影响。

阿历克斯·雷（Alex Rae）

Colony联合创始人，拥有结合了实用性和实用主义的，由丰富的科学实践经验而磨练出的创造力。

全面解读Colony

1、背景

公司理论

公司的存在是为了协调商品和服务的生产。交易成本经济学（TCE）理论是罗纳德·科斯（Ronald Coase）的“公司理论”（theory of the Firm）的推广，该理论假设公司成立、雇佣员工和投资资本，因为存在一个门槛，在这个门槛下，直接控制生产要素比通过市场机制协调生产更有效，一旦交易成本入账。这些交易成本有三种类型：

•搜索和信息：与查找信息以提供决策、发现和评估供应商相关的成本。

•谈判：这些是与供应商达成协议相关的成本。讨价还价的成本可以很低（如买咖啡），也可以很高（如买公司）。

•监控和执行：确保遵守协议条款的成本（例如，按照约定的质量按时生产小部件）。由于偶然性、疏忽或恶，人们往往会偏离约定的条款，解决纠纷可能需要高昂的执行成本（如法律费用）。

TCE理论认为，由于信息的不完全性和有限理性，企业协调生产的效率高于市场机制。有了完美的信息，公司就没有必要了，因为市场力量会提供必要的机制来激励和协调生产——每个人都会知道自己和他人贡献的确切价值。

由于传统市场并非如此，这些知识和信任障碍可以通过尽职调查和合同加以克服，并需要法律制度在出现问题时提供追索权。这些过程是昂贵的，因此传统的公司经常发现，用命令和控制的等级制度取代自由市场的讨价还价，使他们更有效率和竞争力。

随着新技术提高了信息的多样性和流动性，新的组织正在出现，它们能够将市场的有效决策与传统企业的共享价值捕获相结合。共享经济平台（如Uber、Airbnb）、市场网络（如eBay、Amazon Marketplace）和加密货币（如比特币、以太坊）已经证明，如果产品定义足够明确，供应量足够大、可替代或多样化，通过使搜索和信息的发现变得容易，谈判变得简单，并由平台提供基本上免费的警务和执法，可以大大降低市场机制的交易成本。这使得这些新平台的效率比他们试图在公司的硬边界内协调同等供应的效率高出几个数量级。

信心和信任

公司能够通过将劳动组织成一个管理层级，来协调复杂的大规模生产。等级制度中的资历(理想情况下)代表了公司对员工的信心程度，在公司的柏拉图理想中，信心纯粹是能力的功能。公司对员工越有信心，他们的能力就越强，因此他们的责任、影响力和薪酬也就越大。

然而，在互联网上，人们很难对其他人有信心。到目前为止，我们一直依赖平台运营商来协调在线交易各方之间的关系(通常是通过各种评级和声誉系统)，在某些情况下(如支付处理)，来承担这些交易的风险。在区块链上就更难了，因为你只知道对方控制着公钥。很难想象一个传统的组织或层级可能存在于这种假名的、敌对的环境中。区块链没有地理边界，不能区分谁或什么控制公钥。

正如理查德·根达尔·布朗(Richard Gendal Brown)对彼得·施泰纳(Peter Steiner)的经典meme进行了一番改编:“在区块链上，没人知道你是一台冰箱。”因此，互联网组织必须假定最小的公分母:每个成员都是理性的利己主义者，完全专注于个人效用和利润的最大化，并给予相应的激励。这触及了colony的核心:一项旨在促进理想的公司层级模型应该具有相同的精英化的分工和权力划分的协议，除了自下而上之外，而且不容易出错。分散的、自组织的公司，决策权来自于公平评估的价值贡献。

因此，工作是我们的起点。colony成员会因为他们为colony创造的价值而获得补偿，其形式是ETH、任何erc20兼容的代币或声誉(一种不可替代的、时间衰减的衡量过去累计贡献的方法)。活跃的colony可能在任何给定的时间进行各种类型的工作;为了简化工作(及其预算)的管理，colony可以分为域。域（Domain）是你如何构建你的colony。你可以把他们看作是团队、部门、圈子，或者是在你的环境中有意义的东西。这些使得将相关任务分组并将其与其他领域中其他无关工作分开变得容易，并使其能够结合上下文适当的做出决策逻辑（其中一个域可以由管理员控制，另一个域由声誉加权投票控制）。

当colony成员以colony的内部代币获得报酬时，他们也会因所使用的技能以及创造价值的领域而获得声誉。声誉是用来量化成员对colony的历史贡献，并确保他们得到公平的回报。通过在一项技能（如Javascript）和一个领域（如BigCo客户端项目）中赢得声誉，接受者在与这些技能和领域相关的决策中获得了成比例的影响力

声誉在不同的帐户之间是不可以转让的，并随着时间的推移慢慢衰败。这种衰退确保了一个成员的任何声誉都是最近被认为对colony有利的行为的结果（因此是当前成员判断的函数）。由于涉及的计算过于复杂，无法在以太坊区块链上进行，因此会员声誉的更新是在链外计算的，链上报告机制由经济学和博弈论来保证。

一个colony内的许多决定都可以通过非正式的协商一致作出。成员们应该核实他们的同事的行为，但希望他们少干预。在这种情况下，干预意味着“提出动议”。在colony内，通过投票进行决策是不常见的，因为它速度慢，协调成本高；在争议解决（希望是罕见的）情况下合理的使用。争议解决制度允许将许多种类的决定交由colony部分或所有成员根据情况进行表决。根据选民的背景相关声誉，选票是按精英制度加权的。

colony可以是自愿的、非营利的或营利的。创收的colony可选择将其收入的一部分支付给其成员。当colony支付奖励时，成员获得的金额是依照综合代币和声誉持有量的函数；这确保那些贡献最大的人获得最大的利益。会员通过在colony的整个生命周期中为其贡献（从而保持高水平的声誉）而不是坐拥早期积累的代币来最大化回报。

我们希望人们将Colony用于尽可能多的不同工作流程，即使是那些不能立即显示为能够利用Colony协议的工作流程。

2、Colony的结构

Colony的存在使其成员之间能够进行协作，并将集体努力引向共同目标。因此，促进有效分工、管理奖励和分配资源是colony协议的一些最重要的职能

2.1域（domain）和权限

Colony的基本结构围绕域（domain）和帐户可能拥有的权限展开。这两个概念共同定义了群体的结构和安全性，并为创建多种类型的群体提供了一个灵活的框架。

2.1.1域

与任何组织一样，如果没有结构，一个庞大的群体将很快变得难以驾驭，因为参与者和交互的数量非常庞大——域解决了这个问题。

域类似于共享文件系统中的文件夹，只是它可以包含子域、资金和支出，而不是包含文件和文件夹。这种简单的模块化使得组织的结构具有很大的灵活性。域可以用来表示团队、部门、项目、部落、圈子等等。

最终是由单个群体决定它们希望如何使用域——有些群体可能只将它们用于粗分类，而另一些群体可能使用它们只将最相似的支出精确地分组在一起，甚至是其他群体认为是单一支出的多个支出。一些人可能使用域来表示长期存在的组织部门，而另一些人可能使用域来表示具有开始和结束日期的项目。

我们的目标是提供一个一般的框架，colony可以使用他们认为合适的任何方式，并仅在必要时进行规定。

除此之外，这种活动的划分为整个群落提供了一个重要的好处，因为它使声誉具有上下文关系。当仲裁发生时，它发生在colony域层次结构的特定级别上。这意味着可以将具有相关背景知识的人纳入他们的意见，并且当仲裁发生时，整个colony不需要参与这个过程。

2.1.2权限（Permissions）

colony的访问控制是围绕权限的概念组织的。有六种不同的权限(大致按影响顺序排列):恢复、根、仲裁、架构、资金和管理，每种权限解锁一组语义相关的功能。

除了恢复和根权限外，所有权限都是特定于域的(很像Unix文件系统中的权限是特定于目录的)，其规则是父域中持有的权限在所有子域中继承。换句话说，在域中拥有权限就会使你在该域的整个子树中拥有权限。要实现这种继承，授权函数需要以下参数的域证明

•permissionDomainId—帐户拥有权限的(父)域。

•childSkillIndex -在permissionDomainId的子数组中domainId的索引。

•domainId—正在执行操作的(子)域。

这些参数可以在链上的固定时间内进行评估，以确定帐户是否被授权调用特权函数。

权限由以太坊账户持有。这意味着可以将权限授予人工管理员，或分配给实现更复杂行为(如投票机制)的合约。这些类型的合约被称为扩展合约。使用扩展来灵活地“插入”各种决策机制是Colony协议中的一个关键概念。

值得注意的是，拥有所讨论的权限的帐户列表具有完全权限;在协议级别上不存在其他限制。在某些情况下，这些都是非常强大的功能(比如任意施加声誉惩罚)，需要对控制它的人或事物有绝对的信心。因此，我们预计在许多情况下，扩展合约将用于为底层权限提供不同程度的审核。

恢复（Recovery）

恢复权限允许帐户访问colony的紧急“恢复”功能，该功能允许对colony的数据进行任意状态更改。

根（Root）

根权限允许帐户访问colony中的高级管理功能，例如设置colony范围的参数、升级colony和创建新的内部代币。此权限还使帐户能够在整个colony(包括根域)中分配权限。

仲裁（Arbitration）

仲裁许可赋予帐户进行特定领域状态更改的能力，这意味着作为解决动议的一种手段。此权限还允许帐户发出声誉惩罚(但不允许声誉增加)。

架构（Architecture）

架构权限使帐户能够在集群中创建新域，并在这些新域中分配权限。与root不同，具有此权限的帐户不能在其持有该权限的域内编辑权限，只能在子域内使用。

基金（Funding）

基金许可使账户能够在资金罐之间移动代币。在实践中，这意味着该许可负责在域间分配资金和资金支出。

管理（Administration）

管理许可赋予帐户创建和管理(但不是基金)支出的能力，这是colony的基本激励单位

广义上说，许可被设计为“权力分立”:不同的许可必须协同工作，以实现一个colony的功能。例如，行政部门可以产生支出，但实际上只有资金可以提供资源，而仲裁可以解决出现的动议。复杂的扩展可能需要多个权限才能正常工作(例如“任务”，它需要仲裁和管理)

其目的是，由于权限被分组到功能的语义包中，因此有可能开发专门的机制来调解对底层功能的访问(即专门的资助机制和专门的纠纷解决机制，而不是用于处理所有可能决策的通用“投票”机制)。

colony的长期愿景是建立不需要信息的组织;在这样的组织中，成员可以安全地协作和管理共享资源，而不需要彼此了解或信任。早期的群体可能会发现，更强调人类审核员是有用的，而更成熟的群体可能会发现有理由将越来越多的决策下放到无信任功能的扩展上。我们将把大量使用这些扩展的colony称为不可靠的colony。

2.2、资金和支出（Funding and expenditures）

所有代币和货币都由colony合约管理;它负责所有的簿记和拨款。前者通过资金罐进行管理，后者通过支出进行管理。

2.2.1资金罐（Funding pots）

colony中的每个领域和每项支出都有一个相关的资金罐。资金罐可以被认为是特定于特定领域或支出的钱包，用于在colony内移动资金。对于每个资金罐，colony合约可以将其持有的任何数量的Ether或erc20兼容代币关联起来。根据具体情况，资金罐中的资金可能被称为支付、赏金、预算、工资或营运成本。除了资金罐，还有一个特殊的奖励罐，积累代币作为奖励分配给成员。

只有持有基金许可的账户才能移动代币;规则是他们可以在子树中的任意两个罐子之间移动代币。预计在许多情况下，这种许可将授予给实施专门决策机制的扩展合同。

2.2.2支出（Expenditures）

Colony的基本支付方式是“支出”。支出用于转移从colony到任何以太坊账户的资金。支出有几个属性：

•所有者（产生支出的账户地址）。

•状态（活动、取消或最终确定）。

•一个或多个收件人。

•以一个或多个代币计价的每个收件人的支付。

•可选的，每个接收者的技能。

•可选地，每个收件人支付修改器。

•可选的，每个接收者的索赔延迟

所有者负责设置支出的属性。收款者只是以太坊帐户。虽然预计收款者将是个人，但没有什么可以阻止这些账户是多人控制下的合同。

一旦支出最终确定，所有财产都将被锁定（但需要仲裁），并且可以要求支付（并授予声誉）。在最终确定之前，所有人有权完全取消支出。任何已经分配给支出的资金都可以重新分配到创建支出的域中。

当然，为每个接受者定义支出并不提供资金——这必须通过colony的资金机制来完成。支出不一定都在同一个代币中，支出可以由任意数量的代币组成。

支出是一个抽象的原语，可以支持多种类型的工作流，因此包含可选属性以支持更复杂的行为。例如，payoutModifier和claimDelay可用于实施评级和审查系统，其中好的或坏的审查会导致接收者的全面声誉增加（或支出减少），而claimDelay设置为允许在基金退出colony之前决定任何相关动议。

一旦某个账户接收到代币，它们就在接收者的控制之下——没有办法收回资金。基金必须在系统的某个地方越过“密码的卢比孔河”(根据区块链的性质)，在这里这样做是有意义的。

2.3内部代币（Internal tokens）

每个colony都有自己的ERC20兼容“内部代币”。这些代币，当作为支出获得时，也会为接收者产生声誉（从而在colony内分配控制权）。除此之外，这些代币代表什么，由colony决定。例如，它们可能具有财务价值，也可能纯粹是象征性的。

此外，colony可以“携带他们自己的代币”，并指定现有的ERC20兼容代币作为声誉承载。尽管这在某些情况下可能是有利的，但值得注意的是，这削弱了支持无信任colony博弈论安全性的激励一致性，因为代币的价值与colony的绩效脱节。请注意，一旦创建了一个colony，内部代币就不能更改，所以请明智地选择。在colony创建新代币的情况下，该colony控制代币的供应。

具体来说，根权限持有者可以随意造币。在某些情况下，这可能看起来像是创始人单方面管理代币供应，而在其他情况下，colony可能通过延期合同管理造币过程。

一个常见的问题是，为什么只有内部代币（而不是所有代币）具有声誉。让单一代币承担声誉的原因是，它避免了棘手的汇率问题，例如，为了赢得更多声誉，鼓励人们接受更多价值较低的代币。

2.3.1代币用例

最终，内部代币被用于分配声誉，从而包括所有权和决策权。因为拥有更多声望的用户既可以对群体活动施加更大的影响，也可以要求获得更大份额的奖励，声望功能可以调整群体成员之间的激励机制。在这里，我们给出了内部代币不同用例的几个例子，展示了群体可以采用各种方案来分配所有权和影响力以及现金薪酬。

colony拥有自己的代币的主要好处之一是，它可以在获得任何收入或外部资金之前为工作提供奖励。一个新的colony可能会提供代币支付，希望通过这些代币支付获得的声誉(以及colony未来获得的收入)最终会带来经济回报。通过在筹款之前允许“支出”，新colony启动阶段的财政负担就会减轻。一旦一个colony有利可图，代币支付可能是例外而不是常态。

我们可以想象在一个colony中，所有的支出都是通过Ether支付的，但也包括一些colony自己的代币，这些代币等于预期的工作小时数。colony的成员将负责分配“正确的”代币和以太支出。

这种额外的责任还可以确保用户完成相同工作量后获得相同的声望，而不是依赖于他们收取的费用。

或者，我们可以设想一个寻求可预测薪酬(即薪水)与基于绩效的激励之间平衡的群体。这样的colony可以用以太币或DAI等代币支付工资，并将其内部代币用于基于业绩的奖金(即达到季度okr)。这种方法使声誉(和决策权)成为成就的功能，而不会让colony的成员觉得他们支付房租的能力取决于他们实现季度目标的能力。

2.3.2 Colony的Token合约

Colony开发了一个定制的Token合同，带有一些额外的功能:

•mint -让代币合约所有者引入新的代币进入流通。

•burn -让任何人永久地从流通中删除代币。

此外，Colony的代币契约引入了“锁定”的思想——代币在单向布尔标志被翻转之前是不可转移的。这对于想要更多地控制如何以及何时清算和交换代币的colony是有用的。

虽然colony可以自由选择任何erc20兼容的代币，但该合约是colony网络代币的基础，是新colony的默认代币合约。

2.4收入及奖励（Revenue and rewards）

colony可以出售商品和服务，以换取以太或任何erc20兼容的代币，这些收入可以发送到colony的地址。每当一个colony收到这样的报酬时，我们就说该colony获得了收入。收入与colony的营运资本不同:后者是colony在各个领域中持有的所有代币的总和，而前者被隐式定义为colony尚未计入任何现有罐的代币持有。

有一种期望是，colony收到的任何Ether或其他代币的一部分将支付给其成员。在这里，“成员”是指在colony中同时持有代币和声誉的账户。当一个群体将一部分收入分配给它的成员时，我们就说这个群体正在支付奖励。

2.4.1处理收入

当colony接收到代币转移时，收入就会累积。为了进行处理，任何用户都可以进行特殊的claimColonyFunds交易，表明他们希望用哪种代币处理累计收入。

然后该交易计算自上次此类交易以来累计的代币计价收入，并将部分收入转移到colony的奖励罐中。

剩下的部分作为营运资金提供给colony。百分比分割可以通过root权限通过setRewardInverse函数进行配置。

2.4.2从奖励罐领取奖励

奖励在奖励罐中累积。为了触发对用户的支付（即，使奖励可申请），根用户进行一个特殊的startNextRewardPayout事务（每60天不超过一次），启动一个流程，通过该流程，所有成员都可以根据奖励罐的持有量申请支付。

此奖励支付交易包括应支付的特定货币（每个代币的奖励支付单独处理）。一旦流程开始，所有用户的代币都将被锁定，直到他们申请支付。锁定是必要的，因为每个账户的代币余额都会计入等式的奖励公式中。锁定是通过增加代币的totalLockCount来完成的。

我们的TokenLocking契约包含一个锁定机制，确保用户在拥有（代币加权）投票权时不能移动代币；我们在这里使用相同的机制来确保用户不能在支付得到colony成员的批准之后，但在用户申请他们的奖励之前移动代币。colony为每个用户都有一个计数器，每当他们要求支付时，计数器就会递增；他们也可以放弃他们的索赔支付将增加这个计数器。

奖励只适用于同时持有代币和声誉的账户，每个账户可申请的金额取决于代币余额和声誉。因此，我们需要有一个类似的行为来“锁定”支付用户的声誉。当支付被激活时，声誉树的当前状态记录在支付本身中。用户根据其在该状态下的声誉而不是最近的状态进行支付，以确保所有用户获得适当的支付，并避免利用系统（否则可能会通过将奖励收集延迟到完成支出之后，从而提高其声誉）。

2.4.3奖励公式

colony（C）的每个用户（ui）有权索赔的金额（pi）是其colony代币持有量（ti）和其在colony的总声誉（ri）的函数：

这是用户代币持有量和声誉的（标准化）几何平均值。我们注意到，这不太可能支付为支付而预留的所有代币——唯一的方法是，如果每个人在colony的声誉比例与他们在colony的代币比例相同。然而，几何平均是公平地捕捉两个不同范围变量影响的自然方法，并确保大型代币持有人必须获得大量声誉才能从支付中获得最大收益。群体中的总声誉和用户置换在索赔时都是可在链上证明的，通过Merkle证明声誉roothash包含用户索赔的一些值；用户的colony代币余额和发出的代币总数对于查找来说微不足道。

在一段足够长的时间（60天）之后，所有无人认领的代币可以由用户代表colony收回，并且支付结束。任何在该点之前尚未申请支付的用户仍将锁定其代币，并且他们将保持锁定，直到他们发布放弃其支付申请的交易（实际上，他们已经被动地这样做了，没有及时申请）。无人认领的代币返回奖励罐并成为下一个奖励周期的一部分。

2.5信誉体系

声誉是一个与每个用户相关联的数字，它试图捕捉该用户在一段时间内对colony所做贡献的价值。声誉被用来衡量用户在与他们所展示的专业知识相关的决策中的影响力，并在支付奖励时确定欠colony成员的金额。因为声誉是通过对用户行为的直接或间接的同行评估来授予用户的，所以我们认为，影响力和回报可以被视为（大致）按功绩分配。colony的目标是，声誉系统将使一个紧急和动态的决策层次，其中所有正确的人都在正确的地方。

colony的目标是广泛实行精英管理。因此，在一个不可信任的群体中，大多数决策都是由相关的声誉来加权的。与代币不同的是，声誉不能在账户之间转移，因为它代表了同行对账户活动的评价。因此，必须通过在colony内的直接行动来赢得声誉。赢得的声誉最终将因不作为、错误或不当行为而丧失。

2.5.1声誉类型

域中的声誉

在这个层次结构中，用户在所有存在的域中都有声誉——即使声誉为零。当一个用户在一个域中获得或失去声誉时，所有父域中的声誉都发生相同的变化。在用户失去声誉的情况下，他们也会在所有子域失去声誉，但在这种情况下，子域失去的声誉与原始域失去的声誉相同。如果声誉更新将导致用户的声誉小于零，则将其声誉设置为零。

有一个例子可以说明这一点。假设一个colony有“发展”域包含一个“后端”域和“前端”域。任何时候，colony的一个成员为后端领域完成的工作赢得声誉，这将增加他们的后端声誉，他们的开发声誉和他们在colony根域中的声誉。

在开发域获得的声誉只会增加用户的开发和根域声誉分数。

后来，用户在“开发”领域的行为很糟糕，他们在该领域的2000个声誉中损失了100个。它们在父域中也会失去100个声誉，在“开发”域的每个子域中会失去5%(100/2000)的声誉。(在这个例子中，包括前端和后端域)

2.5.2声誉的盈亏

在colony获得声誉有三种方式：第一种（也是目前为止最常见的）是通过支出获得。二是通过仲裁程序。第三个是创建一个colony和相关的引导过程。

声誉损失广泛地发生在仲裁的结果中，延期合约使实施涉及声誉惩罚（如任务和争议）的机制成为可能。此外，用户赢得的所有声誉都会随着时间的推移而不断衰退。

通过支出改变声誉

每当支出接收者收到以colony的内部代币计价的支出时，接收者也会收到一定数量的声誉，以该接收者的支出来衡量。如果值为1，则声誉相当于代币支付，但可以是2倍的倍数。

声誉是在支出的领域（以及所有父领域）中获得的，并在与该接收者相关的任何技能中平均分配。

由于仲裁而引起的声誉变化

仲裁许可持有人有能力在域和技能两个方面任意施加声誉惩罚（但不是增加）。虽然这似乎是仲裁许可持有人获得的一项重要权力，但回顾一下，在许多情况下，这种许可将分配给延期合约，延期合约将通过各种机制，如动议制度，来调解这种能力。

自举/自助（Bootstrapping）声誉

由于无信任群体的决策过程是基于信誉加权投票的，因此我们提出了一个新群体的自举问题。当一个不可信任的colony是新的，还没有人完成任何工作，因此没有人会赢得任何声誉。因此，由于没有人能够投票，因此不能提出任何动议，也不能解决任何争端。然后，一旦支付了第一笔支出，该用户就对相同领域或技能的决策拥有专政权，直到另一个用户获得类似类型的声誉。

为了防止这种情况，当创建colony时，创建者可以选择在根域中为其分配初始信誉的帐户，以允许colony自我引导。分配给每个用户的信誉将等于收到的代币数，即，如果一个成员收到10个代币，他们在根域中也会收到10个信誉。鉴于声誉会随着时间的推移而衰退，这种最初的自举不会对colony的长期运作产生影响。这是唯一一次在没有相关支出的情况下建立声誉。获得声誉的用户可能是colony的创始人及其同事，而这个初始声誉应该被视为团队中现有信任的代表。

我们注意到，当在一个colony中创建一个新域时，不需要相同的方法。我们不希望在这里创造新的声誉，因为这会使colony其他地方已经赢得的声誉贬值。当子域包含的信誉低于其父域信誉的10%时，可以通过在父域中使用信誉来解决此引导问题。低于此阈值的域不能在其下创建域。

声誉衰退

所有的名声都会随着时间的推移而衰退。每90天，4用户在每个领域或技能中的声誉就会衰减2倍。这种衰减每1小时发生一次，而不是每90天一次的阶跃变化，以确保在任何特定时间都有最小的动机来赢得声誉。这种频繁的、网络范围内的更新是信誉挖矿协议存在的主要原因，它允许这种近乎连续的衰减在没有气体限制的情况下进行链外计算，然后在链上实现。

衰变有多种用途。它确保声誉得分代表最近对colony的贡献，激励成员继续为colony做出贡献。它进一步确保了代币价值的大幅升值（以及相应的每项支出支付的代币减少）不会永久性地扭曲声誉的分布，而是有助于消除这种随时间波动的影响。

有人可能想知道，为什么我们选择了削弱声誉，而不是通过通货膨胀来推行声誉稀释的策略。从某种意义上说，它们是等价的：以恒定的速度赢得的腐朽声誉与以日益膨胀的估值赢得声誉是一样的。

然而，从数学上讲，衰减是一种更为简洁的方法，因此通货膨胀的用例是，它在链上的计算更为可行。在colony的情况下，声誉不能在链上计算，因为声誉更新会影响无限数量的声誉节点（由于域树的无限大小）。由于声誉不能在链上计算，我们选择在我们的链外声誉挖矿过程中衰减声誉。

2.6管理权益（stake）

在不可信的系统中，权益是一个关键概念，它是一种确保参与者“共担风险”的方式，可以激励他们做出良好的行为。由于Colony希望启用一个实现各种加密经济机制的扩展生态系统，一个用于管理利害关系的共享系统通过节省用户需要向许多不同的合约发送和检索代币来提高可用性和安全性。在colony，所有的权益都以该colony的内部代币计价。

2.6.1存储代币

所有权益都存储在网络范围内的TokenLocking合约中。单例合约的优点是，在用户是共享同一内部代币的多个colony的成员的情况下，一笔存款就足以支付所有colony的费用。

任何对股权的删减都是来自colony的函数调用的结果，是colony特定仲裁逻辑的结果。

2.6.2批准和义务

通过一系列的批准和义务来管理股权。用户批准一个帐户，然后强制他们达到他们批准的最大金额。如果承担的义务超过代币锁定合约中的存款，交易将失败。一旦一项义务被提出，如果取款导致余额少于他们的义务，用户将不能取款代币。在任何时候，经批准的扩展都可以解除用户的权限，释放代币以供取款。在实践中，我们期望相同的基础存款将被重复地强制和解除抵押，而不需要用户移动任何额外的代币。

当一项义务有效时，任何仲裁许可持有人都可以将stake削减到该义务的金额。我们重申，这是一种强的能力，在大多数情况下，应该通过适当的扩展来进行调解。

出于安全考虑，批准按域以及批准地址（即批准（批准，域，金额））键入。否则，恶意行为体可以使用colony中的任何仲裁许可持有人来削减stake，而不是使用预期域继承路径中的仲裁许可持有人。然而，由于TokenLocking不知道特定colony的域结构，TokenLocking中的义务是所有colony和域特定义务的集合。

总的来说，这种设计允许将仲裁广义化，并将其与任何特定扩展的实施分离开来：扩展名指定了权益（并界定义务期限），而在这一期间，单独的仲裁程序可以削减该利害关系。

2.7可升级性和安全性

2.7.1可升级性

我们预见到群体网络将不断发展。提供一个升级路径对于允许人们使用Colony而不阻止他们自己使用添加到网络中的新功能是很重要的。我们打算允许colony和代币通过使用以太路由器名称下提供的模式进行升级。除了提供实现的功能的合约之外，此实现还使用两个合约。第一个附加合约是EtherRouter合约，它通过delegatecall将事务传递给实现该功能的合约。第二个附加合约是解析器合约，其中定义了实现所需行为的合约的帐户。每当EtherRouter协定接收到事务时，它都会在解析器中查找实现该功能的协定（如果有的话），然后delegatecalls该协定。为了升级，使用新功能部署新合约，然后必须更改解析器合约指向的合约以指向这些新合约。为了避免合约部分实现新旧功能的情况，每次升级都会部署一个新的解析器实例，然后一个事务可以将EtherRouter指向新的解析器。从colony的角度来看，升级就是简单地将一个地址（解析器）换成另一个地址。

升级底层colony合约的选择总是落在colony身上，而不是落在colony网络上。虽然网络可以控制哪些升级可用，但他们无法强制任何colony升级基础合约。colony本身必须决定要升级到新版本。

2.7.2安全

虽然我们渴望无bug的合约，但是bug是不可避免的，因此采用“防御编程”的心态将限制在已部署合约中可能发现的任何漏洞的影响。

最终的回退被称为“恢复模式”。在这种状态下，白名单帐户（具有恢复权限的帐户）能够访问允许直接编辑合约状态的特殊功能—实际上，这将对应于访问允许设置变量的功能，以及能够升级合约。在多个白名单账户的同意下，一旦合约恢复到安全状态，合约就可以退出恢复模式。从恢复模式中删除需要多个白名单帐户的批准。这样可以确保单个白名单帐户在单个事务中不能进入恢复模式，进行恶意编辑，然后在白名单上的其他方有机会作出反应之前退出恢复模式。

可以想象，一旦网络和合约足够成熟，colony将能够在未来停用恢复模式功能。

一般情况下，由于以下原因，合约可能进入恢复模式：

•来自白名单账户的交易，表明合约应进入恢复模式。

•在colony不真实的情况下应始终正确的事情-例如，在支出后，检查承诺支出但尚未支付的资金金额仍然小于colony的余额。如果没有，则中止事务并将合约置于恢复模式。

•一个定性触发因素表明可能有问题-可能在短时间内支付了太多代币。

每当编辑变量时，必须重置来自白名单帐户的任何退出恢复模式的批准。同意退出恢复模式的白名单帐户会记录协议发生的时间戳，变量的任何更改也会更新指示上次编辑的时间戳。当试图离开恢复模式时，只有在最后一次编辑之后达成的协议才被计算为达到阈值。

第一个恢复权限持有者在colony创建时设置，并且是colony的创建者。可以通过根权限添加其他恢复权限持有者。

2.8任意交易

当然，有可能一个colony想要从事一些我们没有预见到的行为，这些行为可以在colony网络控制之外的合约中实施（例如，当colony作为一个整体负责管理合约时，改变合约中的参数）。为此，我们希望有一种机制，通过这种机制，colony可以在区块链上创建任意交易，与合约和代币进行交互，而无需网络明确支持它们。由于它们功能强大，因此这种交易应该很少发生，需要root用户授权。

3、扩展功能

colony的愿景是建立一个分散的、不可信任的组织，在这个组织中，决策是由声誉驱动的，而不是由主持人的子集驱动的。然而，在核心群体合约的层次上，访问是由权限而不是信誉来介导的。

决定让“权限”Colony的核心访问控制逻辑具有双重动机。首先，它可以启动一个由管理员控制的colony（适用于拥有大量现有信任的小型团队），并随着组织的成熟，向更分散、更不信任的运作方式过渡。第二，基于权限的方法可以尝试各种各样的机制，而不需要不断地部署新的colony合约。

就像操作系统设计中内核空间和用户空间的区别一样，权限可以被认为是提供了所需的系统调用，从而使最终用户应用程序（扩展）能够安全地操作系统的底层资源。正如这个模型已经证明非常成功地使各种各样的软件应用程序能够安全地共享计算资源一样，我们也认为colony和扩展模型将在这里取得成功。

3.1任务

与代表资源抽象转移的支出不同，“任务”代表了劳动力与价值的更具体的交换，而一项工作单元则不需要进一步的细分或委派。任务具有与之关联的三个角色：

•经理-负责定义和协调任务的交付。

•工人-负责执行任务。

•评估员-负责评估工作是否圆满完成。

经理（最初是任务的创建者）负责选择评估者和工作者，并为任务设置其他元数据：

•到期日。

•经理、工人和评估员的支出。

•规范哈希：IPF规范的地址，工人用于指导工作，评估人员用于评估任务是否圆满完成

为了创建任务，管理器必须具有管理权限。“任务”扩展的未来变体可能会强制实施最低信誉要求和/或锁定，从而使任务创建变得不可信。

当然，确定每个角色的报酬应该是什么并不能提供资金——这必须通过colony的资金机制来完成。支付不一定都是同一种货币，任务的支付可以由任意数量的货币组成。如果任务的支付是以colony的代币计价的，那么当任务完成时，接收者也将赢得声誉，只要他们的工作受到好评。

如果没有工人被分配到某项任务，经理有权完全取消该任务。任何已经通过资金提案分配给任务的资金都可以重新分配给任务域。

指派工人或评估人员需要经理和受让人的共同同意。一旦分配，涉及工人或评估人员的变更（如更改任务摘要或截止日期、取消任务或更改分配或付款）需要双方同意（即multisig批准），或者可以通过动议流程触发。任务分配完成后，工人必须在截止日期前提交“最终提交”，其中包括一些工作已完成的证据。

一旦到期日已经过了或工人已经提交了他们的意见，评估员可以对工作进行评分。无论评分是否为正，任务都会进入一种状态，在这种状态下，可以提出更改任务最终状态的动议，也可以引发争议。一旦申请期过去，就有资格申请支付。

如前所述，完成工作的用户的性能是在提交工作之后确定的。在这一点上，评估者对工人提交的工作进行评分，工人对经理协调完成任务的能力进行评分，评分标准为1到3分。对于评价者来说，一分的评分视为拒绝工作，二分或三分的评分视为接受工作。收到的评级决定了用户将经历的信誉变化：

1分：用户无法完成任务。声誉惩罚等于1倍的支付。

2分：用户完成任务满意。声誉增益等于1倍支付。

3分：用户出色完成任务。声誉收益等于1.5倍的支出。

工作者在域（和父域）和任务的技能中都获得声誉，而经理只在域中获得声誉，而不是在技能中获得声誉，因为他们实际上没有完成任务。虽然协调任务的交付可能需要一些知识，但情况并非总是如此；我们认为，技能声誉应该只表现出执行任务的能力。完成任务后，评估者还可以获得域声誉（隐式评分为“2”）。评估人员没有明确的评级，但与所有其他支出一样，可以在支出可索赔之前提出动议；动议的结果可能是减少支付或明确的名誉惩罚。

任务是建立在支出的基础上的，而将任务作为一个扩展合约来执行则利用了仲裁和管理权限，后者用来支配支出，前者用来执行费率。

当任务完成时，基本支出的索赔延迟被设置为允许提出动议。根据收受者收到的评级，他们的payoutModifiers设置为提高声誉（对于优秀的评审）或减少他们可以申请的付款（对于不满意的评审）。此外，如果审查不令人满意，将受到声誉惩罚。

3.2资金队列

第2.1节描述了供资许可，用于在供资罐之间转移资金。这种许可是强大的——对于日常运作，最好通过更专门的机制来调解资金的分配。其中一种机制是资金队列，它利用时间作为驱动因素，实现无需投票的协作、异步和无信任决策。

资金队列背后的基本思想是，代币是随着时间的推移不断分配的，而不是以通过/失败的方式一次全部分配，用户输入控制分配的速度和方向。打个比方，我们可以把水从山上流下来，山的形状决定了水流的方向和速度。使用资金队列，用户可以确定此形状。而在基于投票的系统中，不受欢迎的提案完全失败，在资金排队的情况下，不受欢迎的提案只是需要很长时间才能完成，而受欢迎的提案很快就完成了。

colony的任何成员都可以提出资助建议。提议者必须拥有域的0.1%的声誉，该域是源和目标pot的最近的共同祖先，并持有相当数量的colony代币。这部分权益被用来帮助阻止对资金提案的滥发，并提供一种机制，使创造者可以因不良行为受到惩罚。

资金队列包含一系列资金提案，每个提案具有以下属性：

•创建者creator–创建提案的人。

•资金来源from-资金来源。

•To–资助pot基金的去向。

•TokenType–代币地址（0x0表示以太）。

•CurrentState–提案的状态（即未激活、激活、完成、取消）。

•TotalPaid–迄今为止转移的金额。

•TotalRequested–请求的总金额。

•LastUpdated–上次更新提案的时间。

•利率rate–资金利率，是支持声誉的函数。

我们区分了两种类型的资助提案：用于正常使用的基本资助方案（BFP）和用于基本资助方案不足或特殊情况的优先资助方案（PFP）。基本资金提案可以直接开始为目标公司提供资金，而优先资金提案必须在开始指导资金之前进行明确表决。此外，对于基本融资方案，目标罐必须是层次结构中来源的直接后代，而优先资助方案没有此类限制。当资金需要定向到不是来源的直系后代的地方，当资金率需要很高（包括立即支付）或当多个资金建议必须同时发生（例如在支付工资的情况下）时，应使用优先供资建议。

3.2.1详细属性

From、To和TokenType融资提案的目的是将TokenType的代币从一个pot移动到另一个pot。代币类型可以是以太或任何与ERC20兼容的代币。“发件人”字段必须是与colony中的域或支出相关联的资金罐，而“收件人”字段可以是任何资金罐。如果资金要从一个域“下游”转移到它的一个子域，一个基本的资金提案通常就足够了。

当前状态资金提案的状态为非活动、活动、完成或取消。只有积极的筹资提案才可以募集资金。一个基本的筹资提案在活动状态下开始，而一个优先的筹资提案在非活动状态下开始（即必须通过投票激活）。筹资提案在完成（当其支付总额达到请求总额时）或取消之前一直处于活动状态。

资金提案的创建者可以随时取消该提案（将CurrentState设置为cancelled）。这类似于任务的创建者，如果任务尚未分配给工作人员，则可以取消该任务。请注意，如果取消某项支出，则下次ping时，以该支出的资金罐为目标（To）的资金提案将自动取消，并且不会重新分配任何资金。然而，已经转移的资金不自动返回；它可能需要一个PFP将资金返回“上游”。TotalPaid和TotalRequested资金提案希望重新分配的资金总数称为其TotalRequested金额。由于供资提案随时间累积资金的机制，一项供资提案通常会收到部分但不是全部所要求的总额。迄今累计的代币总数存储在其TotalPaid金额中。资金提案的创建者可以随时编辑资金提案的TotalRequested属性，但这样做会将提案在资金队列中的信誉支持重置为零。此处的目的是，如果对接收者pot的要求发生变化（例如，域的范围增加），在colony其他人同意的情况下，可能很快实现对资金的变更。

费率和上次更新

当一个融资方案有资格累积资金时，它会以特定的利率进行累积，以“每秒代币”计价。因为没有用户交互，区块链上什么都不会发生，所以资金系统使用一种懒惰的评估形式。要申请提案到期的资金，用户可以“ping”提案，即用户手动请求按比例分配资金。ping时，将上次更新后的时间乘以比率，以确定如果资金流持续，提案在此期间将累积多少代币。此金额被添加到TotalPaid，资金被转移，当前时间被记录为LastUpdated。

3.2.2基本资助提案 （Basic funding proposals）

基本资助提案（BFP）是从某个领域的资金罐到其子领域的资金罐的资金提案。它开始于活跃状态，因此立即有资格获得资助。创建者可以随时取消它。

BFP的订购

创建时，一个基本的资金提案会放在队列的后面。用户可以根据其在支持时在源域中的声誉来给予建议“支持”。

信誉度越高的提案，其排名就越高。为建议添加支持（或以其他方式更新支持级别）的每个事务都会将建议插入队列中的正确位置。只有排在队伍前面的提案才能累积资金。

支持一项提案不需要任何费用（除天然气费用外），用户也不会获得任何直接利益；它并不代表他们将自己赢得的声誉置于危险之中，也不代表任何象征——它只是帮助提案更及时地获得资金，并通过帮助colony更好地运作间接地使他们受益。

BFP的资金比率

声誉越支持一项提案，它获得资金的速度就越快。该比率呈线性扩展，并且在该限制下，如果源域中100%的声誉支持基本的融资提议，则该融资提议将以每周域持有量（TokenType）的50%的比率获得融资。

目标是稳定和可预测的资源分配，由域的（声誉加权）优先级共同指导。

当用户支持一个提议时，用户和他们当时的声誉都会被记录下来。

因此，用户能够在稍后的日期更新其备份。然而，我们注意到这样的情况，更新不是自动的，即使用户由于不良行为而失去声誉，他们的支持在显式更新之前，级别保持不变。任何人都可以进行此更新-想象一下一个用户由于不良行为而失去了很多声誉，而其他用户却想这样做阻止该用户支持的资金提案继续累积资金。

我们强调，用户可以在支持提案时用自己的信誉来支持提案，因为支持提案的信誉不会随着用户信誉的改变而改变。如果由于这个系统中的一个怪癖，记录为支持一项资助计划的声誉最终超过colony该声誉总额的100%，那么资助发生的速度并不比100%快。

完成BFP

如果更新发现某个提案已获得全额资金（即TotalPaid=TotalRequested），则会将其从此队列中删除，以允许下一个最受欢迎的资金提案累积资金。显然，需要执行以下步骤：

1.计算资助提案获得全额资助的时间。

2.TotalPaid设置为TotalRequested。

3.从队列中删除BFP。

4.队列中的下一个BFP被提升到队列的顶部，其上次更新的时间被设置为在1中计算的时间。

在BFP被完全资助（从而完成）三天后，创造者的股份被释放。在此之前，可以通过仲裁许可来削减股权。

3.2.3优先供资方案（Priority funding proposals）

优先筹资建议（PFP）是一项筹资建议，可以要求以任何速率将资金从任何一个罐重新分配给任何其他任何一个。PFP从非活动状态开始，只能通过显式投票激活。投票是基于这两个罐子最近共同祖先的领域的声誉，而这两个罐子之间的钱正在转移。我们认为PFP将用于：

•从子域回收资金。

•从取消的任务中回收资金。

•跨域资助任务。

•拨出指定为个人薪金的资金。

•一次性支付大额款项。

与基本筹资提案不同，优先筹资提案没有排成一队——所有活跃的PFP都有资格随时获得资金。注意，由于转移的资金数额最终是可用资金的一个函数，太多的大型PFP可以通过大幅减少资金罐中可用资金的数量相互干扰（以及主要的BFP）。

3.3预算箱（Budget box）

作为资金排队的替代方法，colony可以选择使用预算箱在子域之间分配资金（或者在支出的多个接收者之间分配资金）。与资金排队（项目按顺序获得资金）相比，预算箱允许项目按比例从一些固定预算中并行获得资金。

3.4动议和争议

最成功的组织是那些能够有效和高效地做出决策、分工和部署资源的组织。通常，这些决策都是通过管理层次结构来制定的。但是不可信任的colony被认为是低信任的、分散的和匿名的——等级制度是不合适的。

在大多数DAO框架中，集体决策的机制通常是投票，而Colony是为组织的日常运作而设计的。在colony，对每一项决定都投票是完全不切实际的。重点应该放在“完成任务”上，而不是“申请许可”。因此，colony的设计以宽容为核心。任务创建不需要明确的批准，也不需要基本的资金提案或整个colony的任何数量的行政行动。

运动系统提供了一个自我调节机制，通过一套平衡的激励机制，让用户保持colony的和谐运行。它的目的是解决分歧，惩罚不良行为和欺诈行为。动议系统允许colony成员发出不赞成的信号，并可能迫使投票反对那些行为不当的用户。

当一个群体的成员感到有什么不对劲时，他们可以提出动议。通过这样做，他们从根本上提出，要么a）一个变量，或一个以上的变量，在colony应改变为另一个值，或b）一个用户，或一个以上的用户，应收到声誉惩罚。因此，我们称该动议的支持者为“改变”一方，反对者为“保留”一方。

提出动议的用户还必须质押colony的内部代币。本质上，他们是在邀请colony的其他人与他们意见相左。本着避免不必要投票的精神，除非有人站在“保留”一边，从而将动议上升为争议，否则动议将自动通过。

我们说，只要一项动议在“改变”和“保留”两个方面都得到支持，就已经发生了争议。争议一经提出，必须通过表决解决。

3.4.1提出动议

进行运动的用户提交以下数据：

•应更改的数据，或用户将受到处罚。

•应就此问题投票的声誉（每个域和技能层次结构最多一个）。

•证明应允许这些声誉进行相关变更。

第一项确定了动议的主题，以及上诉人认为国家应该是什么。第二点和第三点涉及上诉。colony的基本原则是：你不能向更高的管理层申诉决定，你只能向更大的声誉集团申诉。

例如，假设动议涉及“前端”域中的任务。上诉人可以选择让所有的“开发”声誉投票-我们说，该决定是“上诉到开发领域”。在这个例子中，第三点是证明域“frontend”确实是“development”的子域。任何决定都可以上诉到的最高域是根域，所有域信誉都有权投票。

每当上诉发生时，我们需要确保我们上诉的声誉是与被更改的变量相关联的声誉的父级。这是可以有效地做到的，因为元数据在创建时放置在声誉（域）上，其中至少包括指向直接父级的指针。当一个用户做一个动作时，他们不是直接指定他们所感兴趣的域，而是提供从与要更改的变量相关联的域到达该域所需的步骤。这样可以确保它们所访问的域是与变量关联的域的直接父级。

3.4.2成本和报酬

提出动议的费用

要提出动议，用户必须拥有足够的声誉，还必须持有一定数量的colony代币。他们提出动议所需的声誉取决于他们所吸引的域；决策越高，声誉要求（和潜在损失）就越高。为了能够创建一个动议，用户必须在域中拥有0.1%的信誉，并且必须持有相应部分代币的0.1%。因此，如果一项动议涉及总colony声誉的13%，那么该动议需要0.013%（13%的0.1%）的声誉，所需的股份是所有colony代币的0.013%。

如果初始用户没有所需数量的代币或声誉，他们仍然可以创建这样一个提议，只需下注所需代币的10%，这要求他们拥有相应较少的声誉。在这种情况下，除非其他用户持有代币，并将其超过0.1%的阈值，否则该运动将不会是“实时”的。在创建特定运动时，将记录需要为该运动下注的代币量。用户只能根据自己的声誉按比例持有代币。例如，如果他们想持有40%的所需代币，他们必须拥有至少40%的声誉，这将需要创建运动彻底。

反对动议的代价

一旦在一个运动上有足够的标记，它就会被激活，并且除非在三天内有任何进一步的动作，建议的更改就会发生（当运动被户“ping”时）。

但是，如果有用户反对建议的“更改”，他们可能会使用代币来支持“保留”端。如果对方得到足够的支持，就会产生纠纷。

如果“变革”一方在三天内没有获得足够的支持，动议将失败并被否决。如果“变更”方在三天后有足够的代币，而“保留”方没有，则假定该变更是可接受的。

争议表决

如果双方都在规定的期限内持有所需数量的代币，那么争端就要进行表决。用户投票的权重是他们在最初提出动议的用户所选择的技能方面的声誉之和。

投票的持续时间取决于有资格投票的声誉占colony声誉的比例。如果一个较大的分数是合格的，投票的开放时间越长。最短持续时间为两天，最长持续时间为七天。这是一种权衡，既要允许小团体之间的分歧迅速得到解决，又要允许更多人参与时进行充分的辩论。

投票使用提交和披露计划。此方案是可取的，因为投票在投票期间是保密的，防止用户受到他们认为是多数意见的影响。要进行投票，用户提交一个哈希，即keccak256（secret，optionId），其中optionId表示用户投票的选项。一旦投票结束，投票进入显示阶段，用户可以提交（secret，optionId），合约计算keccak256（secret，optionId）来验证它是他们最初提交的。

随着秘密的揭露，它不可能是敏感的。它还必须随着每一次投票而改变，这样观察员就不能确定人们在公布第一次投票后投的是什么票。虽然有许多合理的方案可用于生成安全机密，但我们建议使用私钥签名的轮询的结果字段（散列），因为它很容易由客户端在稍后的日期复制，而不需要本地存储。

为了对抗选民的冷漠，10%的质押代币被预留出来支付选民投票时：如果选民拥有1％的声誉可让其对决定进行投票，则他们将获得此选民的1％。当他们公布自己的投票结果时，不管他们投票的方向或最终的决定结果如何，他们都会得到这笔奖金。这种“不分意见的支付”是为了避免我们成为凯恩斯选美比赛的受害者，在这场比赛中，由于获得了“正确”的奖励，

选民被激励去投票给他们相信大多数人会投票给他们的东西，而不是他们独立的信仰。投票结束后，将向弃权或未在“显示”窗口中显示的用户授予的任何代币发送到根域资金罐。

一旦投票进入披露阶段48小时，可进行交易以最终确定投票。任何随后的投票显示都不会对正在做出的决定产生影响，但仅用于解锁用户的代币（如果是代币加权投票或混合投票）。

投票的后果如果“改变”一方赢得了投票，那么就做出了有问题的改变，但前提是投票支持这一结果的声誉高于之前在同一变量上的投票。如果“keep”方获胜，则变量不变。在任何一种情况下，都会注意到在colony中投票给获胜一方的总声誉的分数。

在投票结束时，输掉赌注的人会得到0-90%的赌注，他们失去了赌注所需的名誉的补充百分比。他们收回的代币的确切数量（因此他们失去的声誉）基于：

•在colony投票的声誉的一小部分。

•最终投票结果有多接近。

在投票结束时，如果得票率非常接近，那么输的一方将收回近90%的股份。如果投票是不平衡的，以至于得票方的投票权重（w）达到总投票权重的压倒性阈值（L），那么他们将收到0%的赌注代币。L根据投票群体中总声誉的分数而变化（R）：

因此，对于一个在colony持有少量剩余的小群体被允许投票，就必须接近一致决定，才能对失败的一方进行严厉的惩罚。对于整个colony的投票，压倒性的临界值L降低到67%的选票，也就是说，colony的整体声誉在这个决策中是2比1的比例分配。

在滑坡损失和非常微弱损失之间，损失方遭受的代币和声誉损失超过了0.1的最小值(∆) 线性变化：

所以总损失（0.1+∆) 在0.1和1之间变化。

失去的代币怎么办？

任何损失超过最初10%的代币将由colony和那些赌赢一方的人分成，与他们赌的金额成比例。超过最初10%的声誉损失的一半给了那些赌赢一方的人，一半被摧毁（colony作为一个整体拥有声誉没有意义，不同于colony作为一个整体拥有代币的想法）。

这里的动机是效率——它旨在阻止虚假的动议和争端。一票否决表明这一决定并非简单的决定，强迫投票可能是明智之举。

因此，反对党不应受到严厉的惩罚。另一方面，如果投票以压倒性优势结束，则表明败诉的一方违背了普遍共识。我们鼓励colony内部的交流。在提出动议之前，各成员应尽可能了解其同僚的意见。

重复动作

为了减少对同一变量的重复动议和争议的次数，在每次投票后记录投给获胜一方的colony总声誉的分数。这是未来任何投票中必须超过的阈值，以便再次更改变量。

我们重申，即使决定维持变量的当前值，该值也会在每次投票后更新。

这一要求是上诉程序的主要推动力。如果一个决定是在一个投票率低的领域做出的，那么就有可能通过在同一个领域举行另一次投票来推翻这个决定（同时进行一场更有活力的“走出投票链”运动）。然而，如果该域名的大部分声誉参与了投票，那么获得更大声誉主体（撤销决定所必需的）支持的唯一方法就是向更高的域名或更大的技能主体上诉。

这个规则有一个例外：为了确保变量总是可以在必要时更改，如果运动被请求到群体的根域，那么更改变量的阈值将被忽略。无论何时在根域中进行投票，都可以更改变量，而不必考虑先前对该变量的投票。

3.4.3投票类型

根据投票的背景和潜在后果，colony支持三种投票方式。某一诉讼的表决权类型是根据该诉讼预先确定的，而不是上诉人的选择。

声誉加权投票

一个colony的大多数投票将是由于与任务有关的动议。在这些情况下，用户投票的权重与每个用户在投票所在的域和技能中的声誉成正比。当这样的投票开始时，当前声誉状态将与投票一起存储。这允许当前声誉状态在投票的上下文中被“冻结”，并防止可能被鼓励的不必要的行为（例如，将任务的提交推迟到接近投票的时间，以便赢得的声誉不会像以前那样衰减）。

当显示他们的投票时，用户还提供一个Merkle证明，证明他们的相关声誉包含在投票开始时保存的声誉状态中。他们证明他们投票支持的选项的总票数将适当增加。

代币加权投票

虽然Colony鼓励使用声誉作为主要的sibyl抵抗机制，但在某些情况下，代币更合适。具体来说，如果声誉是“劳工”的替身，而代币是“资本”的替身，那么无论何时必须由资本而非劳工做出决定，代币加权投票都是合适的。每当传统公司的“投资者”或“股东”做出决定时，象征性的加权投票可能是合适的。

与声誉不同，我们无法在投票开始时“冻结”代币分发。虽然这在MiniMe代币上是有效可行的，但我们设想代币加权（或混合）投票在colony内仍然足够常规，我们不希望每次都给用户带来部署新合约的天然气成本负担。

在进行代币加权投票时，必须采取措施确保代币不能用于多次投票。在“DAO”的情况下，一旦用户投票，他们的代币就会被锁定，直到投票完成。这引入了特殊的激励机制，将投票推迟到尽可能晚的时候，以避免不必要地锁定代币。我们的锁定方案通过仅在揭示期间锁定代币来避免这种倾斜激励。

相反，一旦投票进入显示阶段，任何在投票中投票的用户都会发现自己无法看到发送给他们的代币，或者自己无法发送代币-他们的代币余额已被锁定。为了解锁他们的代币余额，用户只需显示他们对任何进入显示阶段的投票的投票-这是他们可以在任何时候做的事情。一旦他们的代币被解锁，他们自代币被锁定以来名义上收到的任何代币都会添加到他们的余额中。这种全局锁可以防止出现这样的情况，例如，一个用户将显示他们的投票，然后将代币发送给合谋用户，然后合谋用户将使用增强的代币余额显示他们的投票。

通过将所有提交的投票机密存储在一个按closeTime索引的排序链接列表中，可以实现对恒定gas的锁定。如果此链接列表中的第一个密钥早于用户发送或接收资金时的时间，那么他们会发现其代币已锁定。显示投票将删除密钥（如果用户没有提交其他投票，则同时关闭）。

这将解锁代币，只要列表中的下一个密钥是将来的时间戳。我们实现的更详细的描述可以在Colony博客上找到。

如果客户端提供正确的插入位置，则也可以在恒定gas中插入该结构，而不是搜索正确的位置以插入新项目，而可以在链上高效地检查插入位置。

混合投票

混合投票将允许声誉持有人和代币持有人对决定进行投票。我们设想，当正在表决的行动可能对声誉持有人和代币持有人产生重大影响时，将使用这种投票。这将包括在已经商定的参数之外或决定是否执行任意事务时更改殖民代币的供应。

为了使提案成功通过混合投票，大多数投票的声誉和代币持有者都必须同意应实施更改。

3.5其他

3.5.1代币管理

虽然root用户可以随意造币，但在许多情况下，希望通过扩展合约来调解这种能力。这里我们描述这样一个扩展。

代币生成和初始供应

部署扩展时，会设置TokenSupplyCeiling和TokenIssuanceRate。

前者是将要创建的colony代币的总数，后者是根域可以分配给子域或子域的速率。根域可用的代币数量可以通过来自任何用户的事务随时更新（即，公共函数将确定自上次分发以来生成的按比例分配的代币数量）。

增加代币供应

建议在没有广泛共识的情况下不要产生新的代币——特别是如果代币具有财务价值的话。因此，此类决策需要高法定投票数并涉及代币持有人和声誉持有人。

更改代币发行率（Token Issuance Rate）

代币供应上限（Token Supply Ceiling）代表代币持有人授予colony的代币总数，以开展业务：资助域名和支出，并激励员工和贡献者。

Token Issuance Rate控制colony接收新代币的速度。如果费率“过高”，代币将累积在根域的资金池（或层次结构中较低的其他资金池）中。如果发行率太低，则表明该群体的活动量相当可观，发行率已成为一个瓶颈。在这种情况下，可能需要在不一定增加最大供应量的情况下提高发行率。

提高或降低Token Issuance Rate达10%可由声誉持有人单独完成，且每4周最多只能采取一次。发行利率的较大变化还需要现有代币持有人的同意。

3.5.2补偿方式

利用支出，可以实施多种补偿方式。除了“任务”，我们还可以设想一些额外的补偿方式。

工资

任务意味着colony-worker关系主要是事务性的。在许多情况下，通过薪水来表现更长期的关系是可取的。

薪水可以简单地表示为接收者、金额、期间和最后索赔。在任何时候，接受者都可以ping工资合约，此时合约将创建一个向接受者支付的支出，资金相当于自上一次工资支付以来按比例分配的金额。如果接受者愿意支付汽油费，他们可以每天申请（一小部分）工资，或者选择每周、每月或以任何适合他们的节奏申请。香港有责任确保在支付薪金的领域内有足够的资金。

此扩展需要资金和管理权限来代表接收者操纵代币和支出。

定期或自动任务

而对于某些类型的工作，任务是独特的，必须单独确定范围并进行主观评估。然而，我们可以想象这样的情况：工作可以由许多人完成，和/或由计算机自动评估（例如奖励参与推荐计划的用户）。在这些情况下，包含评估工作逻辑的任务变体，并允许任何人提交工作，将是合适的。

此扩展需要资金和管理权限来代表接收者操纵代币和支出。

3.5.3授予未被任务捕获的工作的声誉

这防止了永久的“声誉贵族”，同时允许声誉保持相关，即使在colony代币的价值发生重大变化时。

当用户收到colony内部代币的付款时，就会授予声誉——最常见的是从支出中获得的付款，但有时是从动议解决中获得的付款，在元colony的情况下，是从声誉挖矿过程中获得的付款。在达成共识的情况下，我们可以使用支出机制来奖励用户额外的声誉。

考虑这样一个场景：当colony开始盈利时，创始人或colony的重要早期贡献者几乎没有留下任何声誉；也许产品的开发花费了很长时间，也许声誉衰退率对于特定的群体来说是次优的高。或者，创始人在一开始就做了很多无形的工作来让colony脱离地面，因此在链条上从来没有得到适当的补偿。为了绕过声誉体系的限制，重新整合创始人（并使他们有资格获得奖励），colony可以创造一项专门用于奖励他们应得声誉的支出。为了获得支付代币的资格（从而获得声誉），相关用户必须将相同数量的代币返还给colony。同样，一个好的前端可以使这种声誉奖励变得简单和直观。

另一个重要情况涉及因产假/产假或疾病而导致的缺勤-声誉系统不应隐式歧视这些用户。虽然“暂停”声誉衰退不是一个可行的选择，但可以使用各种“免费”提供声誉的机制来确保这些用户在不可避免的缺勤期间保持其声誉。

重要的一点是，如果达成共识，该体系施加的任何限制都可能被削弱。这一制度不应妨碍达成共识，而应为存在不同意见的时代提供解决冲突的机制。

3.5.4非成员的动议

有声望是提出动议或提出反对意见的先决条件。因此，如果一个外来者被一个colony雇用来执行一项任务，他们将不能独自提出为他们的工作辩护的动议。然而，一个好的colony前端可能允许他们为一个动议创建模板，有效地呼吁colony成员支持它，并代表他们将动议提交给colony网络链。

这类似于一个成员只下注所需金额的10%，并等待其同行的进一步支持，不同的是，没有任何第三方的支持，动议将永远不会在链上处理。

4、colony网络

Colony网络是以太坊区块链上合约的集合。网络的核心是Colony Network合约。本合约主要负责管理声誉挖矿流程，同时负责网络的一般管理：部署新colony、设置与使用网络相关的费用以及发布新版本的colony合约。这些行为将由一个特殊的群体，即元colony介导。

4.1收入模式

colony网络必须能够自我维持。特别是，元colony（控制着colony网络）维护着支撑网络的合约，并为网络开发新的功能，而网络的开发需要付费。从长远来看，网络（包括声誉系统）的发展和维护需要网络的资助它自己。

4.1.1网络费

我们建议对支出和奖励支出征收费用。当一个用户要求支付，一些小部分将支付给网络。费用被发送到元colony（如果付款是以太币或其他白名单上的‘货币’代币）或colony网络合约（如果是任何其他ERC20兼容代币）

这种收费的想法对于这样一个去中心化的系统来说有点不寻常。以太坊系统的一个吸引力是，除了gas成本，它们不寻租，而且可以免费使用。然而，网络费用是确保colony网络声誉挖矿和治理过程的博弈论安全的关键，它为元colony成员持有的CLNY提供了潜在价值。重要的是，这项费用不是支付给任何中央控制的实体，而是支付给元colony。由于任何人都可以为元colony捐款，任何人都可以要求按其捐款比例分摊这些费用。我们相信，作为一个安全的、维护良好的网络的一部分的好处将是足够有吸引力的，为它的存在支付一点费用将是可以接受的。

这项费用的存在意味着我们必须考虑一些否则将无关紧要的考虑。主要是，我们需要尽可能地制定“背驮”合约，以便在支出确定时，例如，用于支付支出支出，但不发送费用。

4.1.2代币拍卖

由于网络费用可以在任何ERC20代币中计价，因此需要一种机制来清算任意的代币包：代币拍卖。收集的代币由colony网络合约拍卖，拍卖以colony网络代币计价，所得收益被烧毁。这些拍卖——每种类型的代币都会定期进行一次每月拍卖。

我们认为，这种机制将有利于群体网络代币持有者（其代币通过在声誉挖矿之外的明确使用而获得价值）和元殖民本身（通过减少群体网络代币的供应，从而使任何未来的造币更有价值）。

它还为colony内部代币提供了一种即时的价格发现机制，在colony的生命周期很晚之前，这种代币不太可能在第三方交易所交易。

通过拍卖收集的代币，我们还防止元殖民收集大量的不同代币，而这些代币必须管理，这将证明是繁琐和烦人的。

4.2元colony与CLNY

元colony是一个特殊的群体，它支配着colony网络。元colony中的代币称为CLNY，最初将在colony网络分发期间生成。

4.2.1 CLNY持有人的角色和元colony

CLNY持有人有两个主要角色。首先是参与声誉挖矿过程。第二是对colony网络本身的管理。网络合约上会有允许的函数，允许设置网络的基本参数，这些参数只能由元colony调用。对于元colony调用的这些许可功能，必须进行对所有CLNY和声誉持有人开放的投票。colony网络的管理还包括向colony提供colony合约的更新。CLNY持有者不一定要对这些更新的开发负责，但是需要投票来部署它们。因此，他们至少有责任确保自己或服务提供商进行尽职调查，以避免引入安全弱点或其他不良行为。作为对colony网络发展和维护责任的回报，元colony是网络费用的受益者。

在元colony的声誉可以通过支出获得CLNY代币，就像在任何其他colony一样。元colony中的声誉也可以通过参与声誉挖矿过程来获得，这是元colony所特有的。

4.2.2将决策权交给元colony

colony网络代币持有人从一开始就负责声誉挖矿，但有关网络底层属性的决定最初将由colony团队控制的多重签名合约作出。随着网络的发展和被证明是有效的，对这些决策的控制将让给元colony。

第1阶段：colony团队多签控制

最初，网络合约的功能将被根权限化，以便只允许来自Colony团队控制下的multisig合约的事务更改网络的这些属性。

第2阶段：需要Colony team multisig批准

稍后，将建立扩展合约并授予root权限。该合约将允许元colony（作为一个整体，通过提供给所有colony的治理机制）提议对colony网络合约进行修改。中间合约将具有这样的功能，即所有的变更都必须由colony团队控制下的账户明确允许。换言之，元colony将能够提出更改，但团队必须签署这些更改。

第三阶段：colony团队对多签保留否决权

下一阶段将是第二个扩展合约，其操作与第一个类似，但在超时后（没有来自colony团队帐户的交互），任何人都可以将更改转发到colony网络合约。colony团队的职责是在必要时阻止变更。因此，在这个阶段，元colony将能够自主地做出改变，但colony团队保留否决权。向这份合约转移的提议必须来自元colony本身。

第四阶段：元colony完全控制网络

最后，专用扩展合约将被删除并替换为通用投票扩展，元colony将直接控制colony网络合约，除任何CLNY提供的特权控制和持有的声誉外，colony团队没有特权控制。

5 声誉挖矿

声誉系统是任何分散colony的核心组成部分。通过仔细平衡奖惩，我们的目标是让每个用户的奖励与群体和群体网络保持一致。由于声誉只能在账户之间获得，而不能在账户之间转移，因此该系统培养了一种比单纯的加权投票所能实现的更为精英化的决策形式。声誉的持续衰退保证了声誉所传递的影响是有效的

最近获得的和最新的。因此，它防止了声誉贵族化，并允许随着时间的推移，控制权从一组贡献者转移到另一组贡献者。

由于跨多个colony、域和技能的声誉分数的综合复杂性，声誉分数无法在链上存储或计算。相反，所有计算都将在链外进行，其结果将由参与的CLNY持有人向区块链报告——这一过程类似于股权证明区块链共识协议。我们称之为声誉挖矿。

矿工提交其结果的声誉计算由colony中发生的活动决定，并且可以完全确定地从以太坊区块链派生。博弈理论上，系统的保护类似于TrueBit的链外计算，因为计算不能在链上进行，正确的提交永远不能被证明是正确的，错误的计算总是可以被证明是错误的。

附录

通过预算箱分散资本分配

该机制的基础是一个称为预算箱的新组件，它实现了一个简单、通用和强大的治理算法，预算箱聚合并处理成对偏好集。我们的方法涉及将我们的成对偏好集转换成马尔可夫转移矩阵M，并使用该矩阵来找到对应于项目概率分布的特征向量v，我们可以将其解释为预算或排名。直观地说，我们可以根据观察到的偏好，把最终的概率看作是“最重要的事情”的可能性。

我们的投票信息转换成一个不可约的、非周期的、遍历的马尔可夫矩阵，保证具有唯一的主特征向量，可解释为项目的概率分布，或者作为一个排名或预算的分配。寻找特征向量的方法有很多;我们将使用幂迭代，一个简单的算法将v的向靠拢。

直觉上，每次迭代都会首先问“哪些项目最受欢迎？”

然后“对于每一个项目，哪一个项目更受欢迎？”随着时间的推移，概率质量会收敛到相对更受欢迎的项目，因为受欢迎的项目积累了更多的概率，然后它们会“发送给”比它们更受欢迎的项目。

1、可扩展性 （scalability）

每个框K个项目的限制并不限制一个机制总的来说是K个项目，因为可以组合多个预算框来容纳更大的项目集。合成的一种方法是将盒子组装成一个支架；另一种方法是将它们组合成“抽象到具体”（想想公共服务）的递归层次结构→ 教育→ 预算框的组成降低了认知复杂性和计算复杂性。对于100个项目，有4950个可能的对；将其与10·45=450对进行比较，同样的100对被分成10组，每组10对。这450对是原来4950对的子集，但不是随机的。如果我们假设这100个项目可以按质量排序，并且只有质量相似的项目之间的比较才能提供有用的信息，那么将项目集细分为质量相似的项目子集，就可以避免进行4500次低值比较：认知效率提高了10倍。

2、联赛和赛道（leagues and lanes）

为了最大限度地利用选民有限的注意力资源，我们将项目分为两类：一类是联赛中的项目（每个联赛基本上都是预算箱的一个薄包装），另一类是池中几个赛道中的一个。所有项目都是从池开始；获得足够支持的项目将被提升到联赛中，然后以成对的方式对联赛中的项目进行比较和排序；排名较高的项目可以晋升到更高的联赛，并有资格获得更大的奖励。

3、得分的赛道 （scoring lanes）

联赛中的项目可以通过colony任务机制获得奖励。另一方面，池中是希望进入联赛的项目;池中的项目不接受奖励。

因此，与高风险、高关注度的联赛相比，池中项目的处理机制更简单，只提供一个粗糙的过滤器。泳池被划分为L“赛道”，每个车道可以容纳多达256个项目。项目通过下注一些固定数量的CLNY代币进入一个赛道。一旦进入赛道，项目只会得到批准投票;项目得到的分数等于其批准的声誉加权总和。

在投票结束时，我们对每个赛道进行排序，项目的排名是基于它们的整体支持声誉。锁定要求旨在作为一种反垃圾邮件机制。为了进一步防止低质量的项目提交(这会分散选民的注意力)，池里得分低于中位数0.2的项目将被烧掉。为了防止项目因预期被烧毁而撤出他们的股份，我们只允许项目在投票期第一个三分之一时段内离开。

4、在联赛间移动

我们的机制很像体育联赛，在赛季结束时排名最低的将降级到较低的联赛，而排名较高的将升到较高的联赛。在我们的例子中，一个“季节”是一个投票周期。在投票期结束时，对所有项目进行评分，适当给予奖励，并将项目划分到下一阶段的联赛。重新分配由参数Z和“洗选因子”C决定，它决定了有多少项目在两个周期之间移动。由于联盟被安排在一个二叉树中，它可以通过索引每个节点并遍历树。从一个联赛移到另一个联赛,联赛中最差的（按分数排序后）2C个项目与这个联赛的下级联赛中最好的C+C个项目互换，升级降级是交替发生的。

从赛道到联赛，在底层联赛中排名垫底的项目将从系统中删除（退还其赌注）。可以通过发布新的赌注自由地重新进入池中。新腾出的位置由池里的顶级项目来填补。我们的目标是让不超过一半的池子同时进入联赛，这样每条赛道可以支持最多的联赛。当有多个赛道时，它们会被分配到一个叶片联赛中。

反过来说，我们用leagues(l)表示与一个赛道相关的联赛。我们的目标是将所有叶子联盟中最底层的2C项目替换为池子里最顶层的2C个|leagues(l)|项目。因此，对于每条赛道，我们都要对候选项目的质量进行平衡的替换，实施时应以轮流的方式进行交错交换，这样最强的候选项目就会在它们进入联赛时平均分配。

5、确定分配

一旦对项目进行了投票并对投票进行了处理，在它们在移动之前，它们的最终预算分配就已经确定。

只有联盟中的项目才能得到预算分配，由v决定。一个阻尼系数d，它允许在联赛中的所有项目进行均衡分配。与此相关的是，我们必须决定如何在联赛中分配可用的预算。

此分配由参数Q∈ [0，1]控制，这将我们在两个极端之间引导：在Q=1时，我们在所有联盟中都有一个统一的分配，在Q=0时，分配是指数递减的。知道Q，我们就可以确定联盟可用的总预算。

6、扩大机制

该机制可以扩展，以适应任意数量的项目。请注意，机制的容量由三个参数驱动：Z决定了联赛的数量，K决定了联赛的大小，C决定了联赛的运动程度；他们共同决定了池的规模，我们要求池能够容纳两倍于任何时期进入联赛的项目数量。

随着colony网络的成熟和参与该机制的项目数量的增加，可以通过增加Z来扩展该机制；每一个增量都将使联赛规模增加一倍，并根据需要创建新的赛道。注意，随着赛道的增加，现有的候选赛道不会被重新分配，因而创造了一种“套利机会”，使项目可以将自己押在竞争不那么激烈的赛道上；这自然会引导车道间项目质量的均匀分布。

7、投票

为了使这一机制能够抵御腐败、贿赂和共谋，我们首先求助于colony声誉体系。通过声誉加权投票，那些影响力最大的人也能从colony网络的发展中获得最多的利益，在信誉加权投票的情况下，那些最有影响力的人也能从colony网络的发展中获得最大的利益，因此他们最不愿意接受即时支付(贿赂)以换取更糟糕的长期前景。此外，由于声誉源于为Meta Colony所做的工作，那些具有更大影响力的人表面上对生态系统有更好的了解，并能更好地确定项目的相对价值.

为了鼓励参与，我们将B留出一部分作为选民补偿，每个选民的补偿是相对声望的函数。使报酬与声誉成正比既能达到抵制sibyll的双重目的，又能鼓励最有影响力的人尽最大努力做出明智的决定(增加他们的长期报酬)，并进一步减少接受贿赂以换取优惠待遇的相对动机。如果BR是预算中预留给选民补偿的部分，则按以下方式确定每一选民补偿:

另一个考虑是表决过程的细分。“投票单位”是否应该包含对每一对和每一个项目的投票?或者声誉持有者应该在动机允许的情况下贡献更小的单位?

幸运的是，项目的“联盟”组织导致了工作的自然划分。在一个联盟或一个车道上投票构成了一个投票“单位”。每单位投票的要求应该提前设定。

8、结论

如上所述，该机制作为一个整体是由一些超参数控制的:K，它决定联盟的大小;Z，它决定了它们的数量;C，它决定了两个时期之间的运动程度;B，它决定了总预算;d和Q分别影响联盟内部和联盟之间的预算分配。

与捕获个人偏好的两两投票不同，这些超参数捕获政治偏好，因为它们定义了系统作为一个整体的行为:支付的规模，有资格竞争的项目数量，支付给受欢迎项目和不受欢迎项目的允许不平等程度，以及特定项目的分配增长或下降的速度。

除固定的K值外，所有这些参数都可以通过元 Colony中的声誉加权投票来更新。我们的期望是，Z和B开始时规模较小，随着网络的成熟和项目数量的增加而增加。我们预计d, Q和C将会更不频繁地更新以调整机制的行为;我们希望每个值较低的启动机制,这样支出成为更高级别的联赛的意义更大,更高级别的联赛,“失去”项目仍将赚的比在低级别联赛“获胜”项目,和联盟之间运动足够缓慢,项目有一个有意义的时间地平线的收入。

这是有意的，获胜的项目将积累声誉和影响在元colony随着时间的推移。由于这些项目既支持又依赖于colony网络，因此它们既能参与治理，又能分享网络的回报是合适的。

在我们的简介中，我们介绍了一些可能的攻击向量以及失败的场景，并声称已经开发了防御系统。

我们将逐一介绍：

1.垃圾邮件。最小的赌注使垃圾邮件昂贵。

2.骗子。低初始支付使诈骗不经济。

3.贿赂。声誉加权投票调整长期激励。

4.自我投票。解决方案：欧洲视觉规则。

5.串通。非线性投票互动，随机游走。

6.选民冷漠。参与经验，选民补偿。

7.认知偏差。非线性投票相互作用。

8.随机投票。解决方案：声誉加权投票和补偿。

9.西比尔袭击。解决方案：声誉加权投票和补偿。

必须注意的是，任何机制都不能完全抵抗攻击或失败；每一种机制，甚至是工作证明，都是以某种现实为条件发挥作用的。我们所描述的机制假设一组合理多样的参与声誉持有人希望从Colony网络的长期成功中获益。这一机制的目标不是为决策提供一个万无一失的框架，而是在不引入大量新问题的情况下解决一系列具体问题。

我们认为，利用成对偏好来解决集体排名和预算问题是去中心化治理工具箱中的一个重要工具。

联系方式：

主页：https://colony.io/

博客：https://blog.colony.io/

LinkedIn：https://ph.linkedin.com/company/colony-io

Twitter：https://twitter.com/joincolony

Github：https://github.com/JoinColony

Discord：https://discord.com/invite/Qjupxvg

Colony: A DAO framework that effectively reduces the transaction costs of market suppliers

Category: (Domains and permission, Transaction Cost, Reputation Mining, Market Suppliers, Colony V2，Transaction Cost Economics (TCE) theory, Collaboration)

Contributor：黑白QB, DAOctor@Daorayaki

Launch date:

Online time: Colony in 2017; Colony V2 soft launched in February 15, 2021

Token: CLNY (ERC-20)

Currency value (unknown)

Market value (unknown)

The Focus Problem

Talent is highly distributed, yet opportunity is highly centralised. Many people would like to start or work on startups, and though starting up is easier than ever, there are still significant barriers to entry. Consequently, the passion, talent, and energy these people might otherwise commit to commercial projects are often channeled into online communities, free open source software projects and other hobbies.

What is Colony？

Colony is built on open source smart contracts using the Ethereum network. It features ownership according to contribution, influence according to merit, and fair reward. The fair reward system on Colony works when a Colony member makes money, and the money is automatically shared through prior agreed upon smart contract agreements to the Colony member and others. Fair rewards are distributed based on the proportion of tokens and reputation Colony members hold.

What does Colony do？

Colony is a social collaboration platform for distributed organisations. Users can start projects online and build a workforce to help make them a reality.

Because it aligns the incentives of the workforce around being productive, it is possible for people anywhere in the world to work on a project without the need for hierarchical management.

The platform incentivises users to compete to be the most skilled and productive workers by distributing cryptoequity in proportion to the value of each user’s contribution.

The platform automates the project management process, aggregating the collective intelligence of the workforce in suggesting tasks, making decisions, assigning tasks to the best candidates and providing feedback on people’s work.

Every aspect of the platform employs game mechanics and behavioural design to ensure a compelling experience which encourages repeat engagement.

Colony currently runs on xDai and supports the following features.

1. Organize communities into departments or teams with a threshold for joining.

2. Manage token pools and apply budgets to different teams and programs.

3. Support a variety of different payment methods.

4. Customize member entitlement distribution permissions, such as influence gained through participation in governance, based on the organization's specifics.

5. Raise funds through token sales, donations, or revenue.

6. Provide multiple decision-making mechanisms to accommodate different use cases and arbitrate disputes when they arise.

7. DAOs can make arbitrary transactions with other contracts on the same chain as them, and if your DAO needs to manage another protocol or interact with Defi, Colony can help you do it.

Overall, decentralization is Colony's philosophy of governance, and we believe that voting is undesirable, so we strive to avoid it when possible. Given that any organization is different, Colony has a modular design, which means that organizations can plug-in extensions that can be manipulated as needed to provide their organization with the tools they need.

What is the difference between Colony V1 and V2?

Due to the complete data decentralization, the system processing speed is prolonged, the system public infrastructure is not completed, and the community participation is insufficient. The Colony began to shift to Colony V2 in early 2021 gradually. It has been migrated from the main Ethernet network to the xDAI network.

The changes are as follows:

Permissions

Colony's access control framework. The access authority is based on the Ethereum address, and the authorized Ethereum address can access certain privileged functions (similar to the underlying system call). There are six permissions, sorted from high to low: restore permissions, root permissions, arbitration permissions, structure permissions, funding permissions, and manage permissions. Each permission represents a semantic package of functions. Permissions can be granted at different levels of the domain hierarchy, thus enabling complex authorization systems. In addition, since permissions can be granted to any address, it is possible to develop independent, smart contracts and "plug" independent, smart contracts into Colony to expand its functions.

Extensions.

Granting any Ethereum address access to privileged functions means that it can be very flexible in developing and testing arbitrary mechanisms and interfaces based on these functions. Based on the above concept of permission design, Colony naturally derives the idea of extending functions. For example, a unique budget mechanism can be established around the "funds" authority, allowing addresses to transfer tokens between different domains. By developing extended functions that can be adjusted between the underlying functions and various mechanisms, each Colony can more effectively explore the design space of the organization or try to use more direct management control and a distributed decision-making mechanism that does not require permission.

Stake Management.

Many extended functions may require users to pledge tokens before taking action. For example, an extended function on voting can enable users to initiate arbitrary voting by pledged tokens. If other users believe that the vote is malicious (or treat the vote as spam), then the voter may (as expected) lose their pledged tokens. Considering that the contract for the expansion function is independent, the user has to track the pledges made to many different contracts, bringing a considerable burden to the user. In addition, it is necessary to ensure the security of the extended function contract holding these pledge tokens, which brings a significant burden to the development of the extended function. The colony has developed a standard interface for extended functions (or administrators) to manage pledges on behalf of users without actually holding funds to solve these problems.

Reputation Mining.

Although the design of the reputation mining process has not changed, the Colony team has made many implementation choices, which are very different from the choices given in the original white paper. Most importantly, it includes switching the data structure of the reputation tree from the conventional Merkle tree to the more efficient Merkle-Patricia tree.

What are the characteristics of Colony?

Transaction costs include specifying requirements, finding suppliers, receiving and comparing offers, agreeing on contract terms, managing delivery, invoicing and accounting, quality control, dispute resolution. DAOs have no other option but to coordinate supply through market mechanisms.

A practical DAO framework must reduce the transaction costs of market-based supply mechanisms. Nevertheless, unfortunately, the problem with all DAOs except Colony is that they increase transaction costs. Their complex decision-making process with a strategy of requiring token holders to vote on every decision made by the organization is absurd and completely unscalable.

With this in mind, Colony decided to address these issues using a combination of approaches where we allow DAOs to scale by creating multiple teams and sub-teams and not requiring a token vote on every decision. Instead, individual expertise is quantified by using influence proportional to the value of the DAO's contribution, thereby empowering individuals administratively.

Moreover, at Colony, voting is the last resort. Our governance works through "inert consensus," where a proposal automatically passes after a safe delay as long as there are no objections. In other words, if you see a proposal that you agree with, you do nothing. If you find something you disagree with, you can object and force a vote.

Founder Team：

Jack du Rose

CEO at Colony, Graduated from University of the West of England. Former CEO of Collectively Intelligent Ltd, Mentor of Outlier Ventures.

Collin Vine

Co-founder of Colony, former co-founder of Zirtual.com. He’s most interested in the future of work, inclusive of how cities, economies, and organizations are and will be influenced by technology.

Alex Rae

Co-founder of Colony.Alex has a mind as sharp as the finely honed blades of Hattori Hanzo. He combines practicality and pragmatism with a creativity tempered by deep experience of scientific best practices.

Detailed introduction:

1、Background

Theory of the firm

Companies exist to coordinate the production of goods and services. Transaction Cost Economics (TCE) theory, popularised by Ronald Coase’s Theory of the Firm, postulates that companies form, employ people, and invest in capital because there is a threshold at which it is more efficient to control the factors of production directly than to coordinate production via the market mechanism, once transaction costs are accounted for. These transaction costs come in three flavours:

• Search & information: Costs associated with finding information to inform decisions, and discovering and evaluating suppliers.

• Bargaining: These are costs associated with reaching an agreement with a supplier. Bargaining costs can be very low (e.g. buying a coffee), or very high (e.g. buying a company).

• Monitoring & enforcement: The costs of ensuring adherence to the terms of an agreement (e.g. that widgets are manufactured on time and to the agreed quality). People often deviate from the agreed terms due to chance, negligence, or malice, and potentially high enforcement costs (e.g. legal fees) are required to resolve disputes.

TCE theory states that firms are more efficient than the market mechanism at coordinating production due to imperfect information and bounded rationality. Given perfect information, companies would not be necessary, as market forces would provide the necessary mechanisms to incentivise and coordinate production — everyone would know the exact value of their and other’s contributions.

As this is not the case in traditional markets, these knowledge and trust barriers are overcome by due diligence and contracts, and require a legal system to provide recourse when things go wrong. These processes are expensive, and so traditional firms often find that replacing free-market bargaining with command-and-control hierarchy makes them more efficient and competitive.

As new technologies have improved the diversity and flow of information, new organizations are emerging which are able to merge the efficient decision-making of a market with the shared valuecapture of a traditional firm. Gig economy platforms (e.g. Uber, Airbnb), market networks (e.g. eBay, Amazon Marketplace), and cryptocurrencies (e.g. Bitcoin, Ethereum) have demonstrated that if the product is sufficiently well defined, and the supply sufficiently large, fungible, or diverse, then it

is possible to dramatically reduce the transaction costs of the market mechanism by making search and information discovery easy, bargaining straightforward, and having policing and enforcement provided essentially for free by the platform. This has enabled these new platforms to be orders of magnitude more efficient than had they attempted to coordinate equivalent supply within the hard boundaries of a firm.

Confidence and trust

The firm is able to coordinate complex production at scale by organising labour into a management hierarchy. Seniority within the hierarchy (ideally) represents the amount of confidence the company has in the employee, and in the Platonic ideal of a firm, confidence is a pure function of competence.

The more confident the company is in their employee, the higher their competence, and thus the greater their responsibility, influence, and compensation. Across the internet however, it’s hard to have confidence in other people. Up to now we’ve relied on platform operators to mediate relationships between parties in online transactions (often via various rating and reputation systems), and in some cases (such as payment processing), to underwrite the risk of those transactions. On the blockchain it’s even harder, as all you know about a counterparty is that they control a public key. It is difficult to imagine how a traditional organization or hierarchy could exist in this pseudonymous, adversarial environment. A blockchain has no geographical boundaries and cannot differentiate between who or what controls public keys.

As Richard Gendal Brown put it in his twist on Peter Steiner’s classic meme:‘On the blockchain, nobody knows you’re a fridge.’ Internet Organizations must thus assume the lowest common denominator: that every member is rationally self interested and focussed entirely on maximising personal utility and profit, and given incentives accordingly. This gets to the heart of Colony: a protocol seeking to facilitate the same kind of meritocratic division of labour and authority that the idealised model of the corporate hierarchy should, except from the bottom up, and less prone to error. Decentralised, self-organising companies, where decision-making power derives from a fairly-assessed contribution of value.

Work therefore, is where we start. A colony member is compensated for the value they create for the colony, in the form of ETH, any ERC20-compatible token, or Reputation, a non-fungible, time-decaying measure of aggregate past contributions. Active colonies are likely to have a variety of types of work ongoing at any given time; in order to ease the management of work (and their budgets), colonies can be divided into Domains. Domains are how you structure your colony. You can think of them as teams, departments, circles, or what ever makes sense in your context. These make it easy to group related tasks together and separate them from other unrelated work in other domains, and make it possible to incorporate contextually appropriate decision-making logic (in which one domain may be controlled by an administrator, while another is controlled by reputation-weighted voting).

When a colony member gets paid in the colony’s internal token, they also receive Reputation for the Skills they used, and in the Domain in which the value was created. Reputation is used to quantify the historical contributions of members to a colony, and to make sure they are fairly rewarded. By earning Reputation in a Skill (e.g. Javascript) and a Domain (e.g. BigCo Client Project), the recipient earns proportional influence in decisions pertaining to those skills and domains.

Reputation is not transferable between accounts, and slowly decays over time. This decay ensures that any reputation a member has is as a result of recent behaviour deemed beneficial to the colony (and thus a function of the judgment of the current membership). As the calculations involved are too complex to carry out on the Ethereum blockchain, updates to a member’s reputation are calculated off-chain, with an on-chain reporting mechanism secured by economics and game theory.

Many decisions within a colony can be made by informal consensus. Members are expected to verify their colleagues conduct, but hopefully will only rarely need to intervene. Intervention in this context means ‘making a motion’ . Decision via vote is infrequent within Colony because it is slow and carries a high coordination cost; costs which are justified in the (hopefully rare) case of dispute resolution. The dispute resolution system allows for many kinds of decisions to be put to a contextually-relevant vote of some or all members of the colony. Ballots are weighted meritocratically, according to voters’ contextually-relevant reputation.

Colonies may be voluntary, non-profit, or for profit. A revenue-generating colony may elect to pay out a portion of its revenue to its members. When the colony pays out rewards, the amount a member receives is a function of their combined token and reputation holdings; this ensures those who have contributed the most gain the greatest benefit. Members maximise rewards by contributing to a colony over its whole lifetime (thus maintaining high levels of reputation) rather than sitting on early accumulations of tokens.

We want people to use Colony for as many different workflows as possible, even those that are not immediately apparent as being able to leverage the Colony protocol.

1. Structure of a Colony

Colonies exist to enable collaboration between their members, and direct collective efforts towards common goals. Facilitating effective division of labour, management of incentives, and allocation of resources are therefore some of the most important functions of the Colony protocol.

2.1 Domains and permissions

The essential structure of the colony revolves around domains and the permissions that accounts may have in them. These two concepts jointly define the structure and security of a colony and provide a flexible framework for creating colonies of many kinds.

2.1.1 Domains

Like any organization, without structure, a large colony would quickly become difficult to navigate due to the sheer number of participants and interactions taking place - domains solve this problem.

A domain is like a folder in a shared filesystem, except instead of containing files and folders, it can contain subdomains, funding, and expenditures. This simple modularity enables great flexibility as to how an organisation may be structured. Domains could be used to represent teams, departments, projects, tribes, circles, and so forth.

It is ultimately up to individual colonies to decide how they wish to use domains—some might only use them for coarse categorisations, whereas others may use them to precisely group only the most similar expenditures together, or even multiple expenditures that other colonies would consider a single expenditure. Some might use domains to represent long-lived organizational departments, while others might use them more ephemerally, to represent projects with start and end dates.

We aim to provide a general framework that colonies may use however they see fit, and to be prescriptive only where necessary.

Among other things, this compartmentalisation of activity provides an essential benefit to the colony as a whole by making reputation contextual. When arbitration occurs, it occurs at a specific level in the colony’s domain hierarchy. This means that people with relevant contextual knowledge can be included for their opinion, and that when arbitration occurs, the whole colony is not required to participate in the process.

2.1.2 Permissions

Access control in a colony is organized around the concepts of permissions. There are six different permissions (roughly in order of influence): recovery, root, arbitration, architecture, funding, and administration, each unlocking a bundle of semantically-related functionality.

With the exception of the recovery and root permissions, all permissions are domain-specific (much like permissions in a Unix file system are directory-specific), with the rule that permissions held in a parent domain are inherited in all child domains. Put another way, have a permission in a domain gives you that permission in the entire subtree rooted in that domain. To implement this inheritance, permissioned functions require a domain proof of the following arguments:

• permissionDomainId - The (parent) domain in which the account holds the permission.

• childSkillIndex - The index of domainId in permissionDomainId’s children array.

• domainId - The (child) domain in which the action is being taken.

These arguments can be evaluated on-chain in constant time to determine whether the account is authorized to call the privileged function.

Permissions are held by Ethereum accounts. This means that permissions may be given to human administrators, or assigned to contracts which implement more complex behavior (such as voting mechanisms). These types of contracts are known as extensions. The use of extensions to flexibly ‘plug-in’ various decision-making mechanisms is a key concept in the Colony protocol.

It is worth noting that the list of accounts that have the permission in question have the full permission; no additional restrictions exist at the protocol level. In some cases, these are extremely powerful capabilities (such as emitting arbitrary reputation penalties) and require absolute confidence in whomever or whatever controls it. We anticipate therefore that in many cases, extension contracts will be used to offer varying degree of moderation to the underlying permissions.

Recovery

The recovery permission gives accounts access to the colony’s emergency ‘recovery’ functionality, which allows for arbitrary state-changes to the colony’s data.

Root

The root permission gives accounts access to high-level administrative functions in the colony, such as setting colony-wide parameters, upgrading the colony, and minting new internal tokens. This permission also gives accounts the ability to assign permissions throughout the colony (including in the root domain).

Arbitration

The arbitration permission gives accounts the ability to make domain-specific state changes, meant as a means of resolving motions. This permission also enables accounts to emit reputation penalties (but not reputation increases).

Architecture

The architecture permission gives accounts the ability to create new domains in a colony, as well as assign permissions in those new domains. Unlike root, accounts with this permission cannot edit permissions in the domain in which they hold the permission, only in subdomains.

Funding

The funding permission gives accounts the ability to move tokens between funding pots. In practice, this means that this permission is responsible for allocating money amongst domains and for funding expenditures.

Administration

The administration permission gives accounts the ability to create and manage (but not fund) expenditures, the basic incentive unit in a colony.

Broadly, permissions are designed as a ‘separation of powers’: different permissions must work in concert to carry out the functioning of a colony. For example, administration can create an expenditure, but only funding can actually provide the resources, while arbitration resolves motions as they arise. Complex extensions may require multiple permissions in order to function properly (such as ‘tasks’, which requires both arbitration and administration).

The intention is that, since permissions are grouped into semantic bundles of functionality, it will be possible to develop specialized mechanisms for mediating access to the underlying functionality (i.e. specialized funding mechanisms and specialized dispute-resolution mechanisms, as opposed to a general-purpose ‘voting’ mechanism meant to handle all possible decisions).

Colony’s long-term vision is of trustless organizations; organizations in which members can safely collaborate and manage shared resources, without needing to know or trust each other. Early colonies may find that a larger emphasis on human moderators to be useful, while more mature colonies may find reasons to devolve increasingly more decision-making to extensions implementing trustless functionality. We will refer to colonies which make substantial use of these extensions as trustless colonies.

2.2 Funding and expenditures

All tokens and currencies are administered by the colony contract; it is responsible for all the bookkeeping and allocations. The former are managed via funding pots, the latter via expenditures.

2.2.1 Funding pots

Each domain and each expenditure in a colony has an associated funding pot. A funding pot can be thought of as a wallet specific to a particular domain or expenditure, and are used to move funds around within a colony. To each funding pot, the colony contract may associate any number of Ether or ERC20-compatible tokens it holds. Depending on context, the funds in a funding pot may be referred to as the payout, bounty, budget, salary or working capital. In addition to the funding pots, there is a special rewards pot which accumulates tokens to be distributed to members as rewards .

Only accounts holding the funding permission may move tokens; the rule is that they may move tokens between any two pots in the subtree rooted in the domain in which they hold the permission. It is the expectation that this permission will in many cases be given to an extension contract implementing a specialized decision-making mechanism.

2.2.2 Expenditures

The basic payment primitive of a colony is the ‘expenditure’. Expenditures are used to transfer funds out of a colony to any Ethereum account. An expenditure has several properties:

• An owner (the account address which created the expenditure).

• A status (active, cancelled, or finalized).

• One or more recipients.

• payouts for each recipient, denominated in one or more tokens.

• Optionally, a per-recipient skill.

• Optionally, a per-recipient payout Modifier.

• Optionally, a per-recipient claimDelay

The owner is responsible for setting the properties of the expenditure. The recipients are simply Ethereum accounts. While it is anticipated that recipients will be individuals, there is nothing to prevent these accounts being contracts under the control of multiple people.

Once the expenditure is finalized, all properties become locked (but subject to arbitration) and payouts can be claimed (and reputation awarded). Prior to finalization, the owner has the ability to cancel the expenditure entirely. Any funds that have already been assigned to the expenditure can be reassigned to the domain that the expenditure was created in.

Defining the payouts for each recipient, of course, does not provide the funds — this must be done through the funding mechanisms in Colony. Payouts do not have to all be in the same token, and an expenditure’s payouts can be made up of an arbitrary number of tokens.

The expenditure is meant to be an abstract primitive which can support many types of workflows, and so contains optional attributes to support more complex behavior. For instance, the payoutModifier and claimDelay can be used to implement a rating and review system, where good or bad reviews lead to an across-the-board reputation increase (or payout decrease) for a recipient, while the claimDelay is set to allow for any relevant motions to be decided before funds can exit the colony.

Once the tokens have been received by an account, they are under the control of the recipient-there is no way to reclaim the funds. The funds have to cross the ‘Cryptographic Rubicon’ somewhere in the system (by the nature of the blockchain), and it makes sense to do so here.

2.3 Internal tokens

Every colony has its own ERC20-compatible ‘internal token’. These are the tokens that, when earned as an expenditure payout, also generate reputation for the receiver (and thus distribute control within the colony). What these tokens represent apart from this is up to the colony to decide. For example, they may have financial value, or they may be purely symbolic.

In addition, colonies may ‘bring their own token’ and designate an existing ERC20-compatible token as reputation-bearing. While this may be advantageous in some contexts, it’s worth noting that this weakens the incentive alignment underpinning the game theoretic security of trustless colonies, in that the value of the token is divorced from the performance of the colony. Note that the internal token cannot be changed once a colony has been created, so choose wisely. In cases where a colony creates a new token, that colony is in control of the supply of the token.

Specifically, root permission holders can mint tokens at-will. In some cases, this may look like a founder managing the token supply unilaterally, while in other cases colonies may manage the minting process via an extension contract.

A common question is why only internal tokens (as opposed to all tokens) are reputation-bearing. The reason for having a single token be reputation-bearing is that it avoids tricky exchange-rate problems, such as incentives to receive more of a less valuable token to earn more reputation.

2.3.1 Token use-cases

Ultimately, internal tokens are used to distribute reputation, and thus both ownership and decisionmaking power. Since users with more reputation can both exercise more influence over the activity of the colony, as well as claim a greater share of the rewards, reputation functions to align incentives among the members of colony. Here we give a few examples of different use-cases for internal tokens, demonstrating the variety of schemes colonies may adopt for distributing ownership and influence alongside cash compensation.

Tokens as early rewards One of the chief benefits of a colony having its own token is that it can offer rewards for work before it has any revenue or external funding to draw on. A new colony may offer token payouts for expenditures with the hope that the reputation earned by these token payments (and the future revenue earned by the colony) will eventually lead to financial rewards. By allowing ‘spending’ before fund-raising, the financial burden during the start-up phase of a new colony is eased. Once a colony is profitable, payment in tokens may be the exception rather than the norm.

Tokens representing hours worked We could imagine a colony in which all expenditures are paid in Ether, but include a number of the colony’s own tokens as well, equal to the expected number of hours worked. The members of the colony would be responsible for assigning ‘correct’ token and Ether payouts to expenditures.

This extra responsibility would also ensure users doing the same amount of work received the same reputation gain, rather than the reputation gain being dependent on the rates they charged.

Tokens as performance-based bonuses Alternatively, we could imagine a colony which seeks to balance predictable compensation (i.e. salaries) with performance-based incentives. Such a colony could pay out salaries in a token such as Ether or DAI, and reserve their internal token for performance-based bonuses (i.e. for hitting quarterly OKRs). Such an approach makes reputation (and decision-making power) a function of achievement, without making members of the colony feel as though their ability to pay rent depends on their ability to hit quarterly goals.

2.3.2 Colony’s Token contract

Colony has developed a customized Token contract, with some additional functionality:

• mint — lets the token contract owner introduce new tokens into circulation.

• burn — lets anyone permanently remove tokens from circulation.

In addition, Colony’s Token contract introduces the idea of ‘locking’ — tokens being nontransferrable until a one-way boolean flag is flipped. This is useful for colonies which want more control over how and when their tokens can be liquidated and exchanged.

This contract underlies the Colony Network Token and is the default token contract for new colonies, although colonies are free to choose any ERC20-compatible token.

2.4 Revenue and rewards

A colony may sell goods and services in exchange for Ether or any ERC20-compatible tokens, and this revenue may be sent to the colony’s address. Whenever a colony receives such payments, we say that the colony has earned revenue. Revenue is distinct from a colony’s working capital: the latter is the sum of all tokens held by the colony in various domains, while the former is implicitly defined as the colony’s token holdings not yet accounted for in any of the existing pots.

There is an expectation that some fraction of any Ether or other tokens received by the colony are paid out to their members. ‘Members’, in this context, means accounts holding both tokens and reputation in the colony. Whenever a colony distributes a portion of revenue to its members, we say that the colony is paying out rewards.

2.4.1 Processing revenue

Revenue accumulates as the colony receives transfers of tokens. In order to be processed, any user can make a special claimColonyFunds transaction, indicating for which token they wish to process accumulated revenue.

The transaction then calculates the amount of token-denominated revenue that has accumulated since the last such transaction, and transfers some proportion to the colony’s rewards pot. The remainder is then made available to the colony as working capital. The percentage split is configurable by the root permission via the setRewardInverse function.

2.4.2 Claiming rewards from the rewards pot

Rewards accumulate in the rewards pot. To trigger a payout to users (i.e. to make rewards claimable), a root user makes a special startNextRewardPayout transaction (no more than once every 60 days), initiating a process by which all members may claim a payout based on the reward pot's holdings.

This reward payout transaction includes the specific currency that should be paid (reward payouts for each token are handled separately). Once the process begins, all users' tokens are locked until they claim their payout. Locking is necessary because the token balance of each account factors into the rewards formula of equation. Locking is done by incrementing the token's totalLockCount.

Our TokenLocking contract contains a locking mechanism ensuring that a user cannot move tokens while they have (token-weighted) votes to reveal; we use the same mechanism here to ensure that a user cannot move tokens after a payout is approved by the members of the colony but before the user has claimed their rewards. The colony has a counter for each user that is incremented whenever they claim a payout; they can also waive their claim to a payout that will increment this counter.

Rewards are only available to accounts that hold both tokens and reputation, and the amount claimable by each account depends on both token balance and reputation. Therefore we need to have a similar behaviour to ‘lock’ the reputation of the users for the payout. When a payout is activated, the current state of the reputation tree is recorded in the payout itself. Users are paid out according to their reputation in this state, rather than the most recent state, to ensure all users get an appropriate payout and to avoid exploiting the system (which might otherwise be possible via e.g. delaying reward collection until after completing an expenditure, increasing their reputation).

2.4.3 The rewards formula

The amount that each user (ui) of a colony (C) is entitled to claim (pi) is a function of their colony token holdings (ti) and their total reputation in the colony (ri):

This is a (normalised) geometric average of the user’s token holdings and reputation. We note that this is very unlikely to payout all the tokens set aside for a payout — the only way it would do so is if everyone had the same proportion of reputation in the colony as they did proportion of tokens in the colony. However, the geometric average is the natural way to fairly capture the influence of two variables with different ranges, and ensures that large token holders must earn large amounts of reputation to get the most from the payouts. The total reputation and user eputation in the colony are all provable on-chain at claim time via a Merkle proof that the ReputationRootHash contains some values claimed by the user; the user’s balance of colony tokens and the total number of tokens issued is trivial to lookup.

After some sufficiently long period of time (60 days), all unclaimed tokens can be reclaimed on behalf of the colony by a user, and the payout closed. Any users that have not claimed their payout by that point will still have their tokens locked, and they will remain locked until they issue a transaction waiving their claim to the payout (indeed, they already passively did this by not claiming it in a timely fashion). Unclaimed tokens are returned to the rewards pot and become part of the next reward cycle.

2.5 The reputation system

Reputation is a number associated with each user which attempts to capture the value of that user’s contributions to the colony over time. Reputation is used to weight a user’s influence in decisions related to the expertise they have demonstrated, and to determine amounts owed to a colony’s members when rewards are disbursed. Because reputation is awarded to users by either direct or indirect peer assessment of their actions, we argue that influence and rewards can be seen as being (roughly) distributed by merit. Colony’s aim is that the reputation system will enable an emergent and dynamic decision-making hierarchy in which all of the right people are in the right places.

Colony aims to be broadly meritocratic. Consequently, the majority of decisions in a trustless colony are weighted by the relevant reputation. Unlike tokens, reputation cannot be transferred between accounts, as it represents an appraisal of the account’s activities by their peers. Reputation must therefore be earned by direct action within the colony. Reputation that is earned will eventually be lost through inactivity, error, or misbehaviour.

2.5.1 Types of reputation

Reputation by domain

Reputation in this hierarchy, and a user has a reputation in all domains that exist — even if that reputation is zero. When a user earns or loses reputation in a domain, the reputation in all parent domains changes by the same amount. In the case of a user losing reputation, they also lose reputation in all child domains, but in this case the child domains lose the same fraction of reputation that was lost in the original domain. If a reputation update would result in a user’s reputation being less than zero, their reputation is set to zero instead.

An example makes this clearer. Suppose a colony has a ‘development’ domain which contains a ‘backend’ domain and a ‘frontend’ domain. Any time a member of the colony earns reputation for work completed in the backend domain, it will increase their backend reputation, their development reputation and their reputation in the all-encompassing root domain of the colony.

Reputation earned in the development domain will only increase the development and root domain reputation scores of the user.Later, the user behaves badly in the ‘development’ domain, and they lose 100 reputation out of the 2000 they have in that domain. They also lose 100 reputation in the parent domains, and 5%(100/2000) of their reputation in each of the child domains of the ‘development’ domain (which in this example, includes both frontend and backend domains).

2.5.2 Earning and losing reputation

There are three ways to receive reputation in a colony.The first (and by far the most common) is through receiving a payout via an expenditure. The second is through the arbitration process. The third is upon the creation of a colony and the associated bootstrapping process.

Reputation losses broadly occur as the result of arbitration, and extension contracts makes it possible to implement mechanisms which involve reputation penalties (such as tasks and disputes). In addition, all reputation earned by users is subject to a continual decay over time.

Reputation change via expenditures

Whenever an expenditure recipient receives a payout denominated in the colony’s internal token, the recipient also receives some amount of reputation, scaled by that recipient’s payoutScalar. A value of 1 gives reputation equivalent to the token payout, but a multiple of up to 2x is possible.

The reputation is earned in the domain (and all parent domains) of the expenditure, and divided equally among any skills associated with that recipient.

Reputation change as a result of arbitration

Arbitration permission holders have the ability to emit arbitrary reputation penalties (but not increases) in both domains and skills. While this might seem to be a significant power available to arbitration permission holders, recall that this permission will in many cases be assigned to extension contracts, which will mediate this ability via various mechanisms, such as the motions system.

Bootstrapping reputation

Since a trustless colony’s decision making procedure rests on reputation weighted voting, we are presented with a bootstrapping problem for new colonies. When a trustless colony is new, no-one has yet completed any work in it and so nobody will have earned any reputation. Consequently, no motions can be made and no disputes can be resolved as no-one is able to vote. Then, once the first expenditure is paid out, that user has a dictatorship over decisions in the same domains or skills until another user earns similar types of reputation.

To prevent this, when a colony is created, the creator can choose accounts to have initial reputation assigned to them in the root domain to allow the colony to bootstrap itself. The reputation assigned to each user will be equal to the number of tokens received, i.e. if a member receives ten tokens, they also receive ten reputation in the root domain. Given that reputation decays over time, this initial bootstrapping will not have an impact on the long-term operation of the colony. This is the only time that reputation can be created without an associated expenditure being paid out. Users receiving reputation are presumably the colony founder and their colleagues, and this starting reputation should be seen as a representation of the existing trust which exists within the team.

We note that the same is not required when a new domain is created in a colony. We do not wish to allow the creation of new reputation here, as this would devalue reputation already earned elsewhere in the colony. This bootstrapping issue is resolved by instead using reputation within the parent domain, when a child domain contains less than 10% of the reputation of its parent domain. A domain below this threshold cannot have domains created under it.

Reputation decay

All reputation decays over time. Every 90 days,4 a user’s reputation in every domain or skill decays by a factor of 2. This decay occurs every 1 hour, rather than being a step change every 90 days to ensure there are minimal incentives to earn reputation at any particular time. This frequent, network-wide update is the primary reason for the existence of the reputation mining protocol, which allows this near-continuous decay to be calculated off-chain without gas limits, and then realised on-chain.

The decay serves multiple purposes. It ensures that reputation scores represent recent contributions to a colony incentivising members to continually contribute to the colony. It further ensures that wild appreciations in token value (and the corresponding decrease in tokens paid per expenditure) do not permanently distort the distribution of reputation but instead serves to smooth out the effects of such fluctuations over time.

One might wonder why we have chosen to decay reputation, rather than pursue a strategy of reputation dilution via inflation. In one sense, they are equivalent: decaying reputation that is earned at a constant rate is the same as earning reputation at increasingly inflated valuations.

Mathematically, however, decay is the cleaner approach, and so the use-case for inflation is that it is more feasibly calculated on-chain. In the case of Colony, reputation cannot be calculated on chain, since reputation updates effect an unbounded number of reputation nodes (due to the unbounded size of the domain tree). Since reputation cannot be calculated on chain, we choose to decay reputation in our off-chain reputation mining process.

2.6 Managing stakes

Staking is a key concept in trustless systems, as a way to ensure that participants have ‘skin in the game’ and can be incentivized towards good behavior. As Colony wishes to enable an ecosystem of extensions implementing various cryptoeconomic mechanisms, a shared system for managing stakes improves usability and security by saving users from needing to send and retrieve tokens to and from many different contracts. In colonies, all stakes are denominated in that colony’s internal token.

2.6.1 Storing Tokens

All stakes are stored in the network-wide TokenLocking contract. A singleton contract has the advantage that in scenarios where a user is a member of multiple colonies sharing the same internal token, a single deposit suffices for all colonies.

Any slashing of stakes occurs as a result of a function call coming from the colony and is a result of colony-specific arbitration logic.

2.6.2 Approvals and Obligations

Stakes are managed via a sequence of approvals and obligations. Users approve an account to then obligate them up to the maximum amount of their approval. If an obligation is made in excess of the deposits held in the TokenLocking contract, the transaction will fail. Once an obligation is made, a user cannot withdraw tokens if the withdrawal would result in a balance less than their obligations. At any time, the approved extension can deobligate the user, freeing the tokens for withdrawal. In practice, we expect that the same underlying deposit will be obligated and deobligated repeatedly without the user needing to move any additional tokens.

While an obligation is active, any arbitration permission holder can slash the stake up to the amount of the obligation. We reiterate that this is a powerful ability and in most cases should be mediated by an appropriate extension.

For reasons of security, approvals are keyed by domain, as well as by address of approvee (i.e. approve(approvee, domain, amount)). Otherwise, a malicious actor could use any arbitration permission holder in the colony to slash a stake, rather than arbitration permission holders in the intended domain inheritance path. However, because TokenLocking does not know about the domain structure of specific colonies, the obligations in TokenLocking are aggregates of all colonyand domain-specific obligations.

Overall, this design allows arbitration to be generalized and separated from the implementation of any particular extension: extensions obligate a stake (and define the period of obligation), while during that period separate arbitration processes can slash that stake.

2.7 Upgradability and security

2.7.1 Upgradability

We foresee the Colony Network being continuously developed. roviding an upgrade path is important to allow people to use Colony without preventing themselves from using new features as they are added to the network. We intend to allow colonies and tokens to be upgraded by using the pattern made available under the name EtherRouter . This implementation uses two contracts in addition to the contract(s) providing the functionality implemented. The first additional contract is the EtherRouter contract, which passes on transactions — via delegatecall — to the contract that implements that function. The second additional contract is the Resolver contract, where the accounts of the contracts that implement the desired behaviour are defined. Whenever a transaction is received by the EtherRouter contract, it looks up the contract that implements that function (if any) in the Resolver, and then delegatecalls that contract. In order to upgrade, new contracts are deployed with new functionality, and then contracts that the Resolver contract points to must be changed to point to these new contracts. In order to avoid a situation where the contract partially implements both old and new functionality, a new instance of Resolver will be deployed for each upgrade, and then a single transaction can point EtherRouter at the new Resolver. From the perspective of the colony, an upgrade is then simply swapping out one address (the Resolver) for another.

The choice of upgrading the underlying Colony contract will always fall to the colony, and never the Colony Network. While the network is in control of what upgrades are available, they are not able to force any colony to upgrade the underlying contracts. The colony itself must decide that it wants to upgrade to a new version.

2.7.2 Security

While we aspire to bug-free contracts, bugs are inevitable, and so the adoption of a ‘defensive programming’ mentality will limit the impact of any vulnerabilities that may be discovered in the deployed contracts.

The ultimate fallback is known as ‘recovery mode’. In this state, whitelisted accounts (those with the recovery permission) are able to access special functions that allow the state of the contract to be directly edited — in practise, this will correspond to access to the functions to allow setting of variables, as well as being able to upgrade the contract. With the agreement of multiple whitelisted accounts, the contract will then be able to be taken out of recovery mode once the contract has been returned to a safe state. Removal from recovery mode requires the approval of multiple whitelisted accounts. This ensures that a single whitelisted account cannot, in a single transaction, enter recovery mode, make a malicious edit, and then exit recovery mode before the other parties on the whitelist have had a chance to react.

It is conceivable that colonies will be able to deactivate the recovery mode feature in the future, once the network and contracts have matured sufficiently.

In general, the contract may enter recovery mode due to:

• A transaction from a whitelisted account signalling that the contract should enter recovery mode.

• Something that should always be true of the colony not being true — for example, after an expenditure payout checking that the amount of funds promised to expenditures and not yet paid out is still less than the balance of the colony. If not, then abort the transaction and put the contract into recovery mode.

• A qualitative trigger suggesting something may be amiss — perhaps too many tokens have been paid out in a short amount of time.

Any approvals from whitelisted accounts to leave recovery mode must be reset whenever a variable is edited. A whitelisted account agreeing to leave recovery mode records the timestamp at which the agreement occurred, and any change of variables also update a timestamp indicating the last edit. When attempting to leave recovery mode, only agreements made after the last edit are counted towards meeting the threshold.

The first recovery permission holder is set at colony creation and is the creator of the colony. Additional recovery permission holders can be added by the root permission

2.8 Arbitrary transactions

Of course, it is possible that a colony will want to engage in some behaviour that we haven’t foreseen, that could be implemented in a contract outside the control of the Colony Network (such as changing a parameter in a contract when the colony as a whole is responsible for governing that contract). To that end, we wish to have a mechanism by which a colony can create an arbitrary transaction on the blockchain to interact with contracts and tokens without requiring the network to explicitly support them. As they are powerful, such transactions should be rare occurrences requiring root authorization.

3、Extending Functionality

The vision of Colony is the creation of decentralized, trustless organizations, in which decisions are driven by reputation, not a subset of moderators. Yet, at the level of the core Colony contracts, access is mediated by permissions, not reputation.

The decision to make ‘permissions’ Colony’s core access-control logic is doubly motivated. First, it makes it possible to launch a Colony which is admin-controlled (appropriate for small teams with substantial existing trust) and to transition to a more decentralized, trustless style of operating as the organization matures. Second, the permissions-based approach makes it possible to experiment with a wide variety of mechanisms without needing to continually deploy new Colony contracts.

Much like the distinction between kernel space and user space in the design of operating systems, permissions can be thought of as providing the system calls needed to give end-user applications (extensions) the ability to securely manipulate the underlying resources of the system. Just as this model has proven very successful in enabling a wide variety of software applications to safely share computing resources, so do we think that the colony-and-extensions model will be successful here.

3.1 Tasks

Unlike an expenditure, which represents an abstract transfer of resources, the ‘task’ represents a more concrete exchange of labor for value, and a unit of work requiring no further subdivision or delegation. A task has three roles associated with it:

• Manager -responsible for defining and coordinating the delivery of the task.

• Worker-responsible for executing the task.

• Evaluator-responsible for assessing whether the work has been completed satisfactorily.

The manager (initially the creator of the task) is responsible for selecting the evaluator and worker and setting additional metadata for the task:

• A dueDate.

• payouts for each of the manager, worker and evaluator.

• A specificationHash: the address of a specification on IPFS, used by the worker to guide the work, and the evaluator for assessing the satisfactory completion of the task.

In order to create a task, the manager must have the administration permission. Future variations of the ‘tasks’ extension may instead impose minimum reputation requirements and/or staking, making task creation trustless.

Defining what the payouts for each role should be, of course, does not provide the funds -this must be done through the funding mechanisms in Colony. Payouts do not have to all be in the same currency, and a task’s payout can be made up of an arbitrary number of currencies. If a payout for the task is denominated in the colony’s token, the recipient will also earn reputation when the task is completed as long as their work was well received.

If no worker has been assigned to a task, the manager has the ability to cancel the task entirely. Any funds that have already been assigned to the task via funding proposals may be reassigned to the domain of the task.

Assigning either the worker or the evaluator requires the mutual agreement of the manager and the assignee. Once assigned, changes which involve either the worker or evaluator (such as changing the task brief or due date, cancelling the task, or changing assignments or payouts) require mutual consent (i.e. multisig approval), or can be triggered via the motions process.

After the task has been assigned, the worker has until the due date to make a ‘final submission’, which includes some evidence that the work has been completed.

Once the due date has passed or the worker has made their submission, the evaluator may rate the work. Regardless of whether the rating is positive or not, the task enters a state in which motions to the change final state of the task can be raised and disputes can be initiated . Once the motions period has elapsed, payouts are eligible to be claimed.

As mentioned, the performance of the user who has completed the work is determined after the work is submitted. At this point, the evaluator grades the work submitted by the worker, and the worker rates the manager’s ability to coordinate delivery of the task, on a scale of one to three points. In the case of the evaluator, a rating of one point counts as them rejecting the work and a rating of two or three points counts as accepting the work. The rating received determines the reputation change the user will experience:

1 point: User was unable to complete the task. Reputation penalty equal to 1x payout.

2 points: User completed the task acceptably. Reputation gain equal to 1x payout.

3 points: User completed the task superbly. Reputation gain equal to 1.5x payout.

The worker receives reputation both in the domain (and parent domains) and the skill(s) of the task, while the manager receives only in the domains, not in the skill(s) as they have not actually done the task. While it is likely some knowledge is required to coordinate delivery of the task, this is not always the case; we believe that skill reputation should exclusively demonstrate ability to perform tasks.

Upon completion of a task, the evaluator also earns domain reputation (with an implicit rating of "2"). There is no explicit rating of the evaluator, but as with all other payouts a motion can be made before a payout is claimable; the outcome of the motion may be a reduction of payout or an explicit reputation penalty.

Tasks are built on expenditures, and implementing tasks as an extension contract makes use of the arbitration and administration permissions – the latter to manipulate the expenditure and the former to implement consequences of the rate-and-reveal flow.

When the task is finalized, the underlying expenditure’s claimDelays are set to allow for motions to be made. Based on the rating recipients receive, their payoutModifiers are set to give a reputation boost (for an excellent review) or reduce the payout they can claim (for an unsatisfactory review). Also in the case of an unsatisfactory review, a reputation penalty is emitted.

3.2 Funding queues

Section 2.1 describes the funding permission, which is used to transfer funds in between funding pots. This permission is powerful — for daily operations, it is better to mediate the allocation of funds via a more specialized mechanism. One such mechanism is the funding queue, which leverages time as a driving factor to enable collaborative, asynchronous, and trustless decision-making, without voting.

The essential idea behind the funding queue is that tokens are continuously allocated over time, rather than all at once in a pass/fail fashion, with user inputs controlling the speed and direction of the allocation. As an analogy, one can think of water running down a mountain, where the shape of the mountain determines the direction and speed of the flow. With funding queues, users determine this shape. Whereas with voting-based systems, unpopular proposals fail entirely, with a funding queue, unpopular proposals simply take a very long time to be fulfilled, while popular proposals are fulfilled quickly.

Any member of the colony may create a funding proposal. The proposer must have 0.1% of the reputation of the domain that is the most recent common ancestor of the source and target pots, and stake an equivalent amount of the colony’s tokens. This stake is used to help discourage spamming of funding proposals and provide a mechanism whereby the creator can be punished for bad behaviour.

A funding queue contains of a series of funding proposals, each with the following attributes:

• Creator – The person that created the proposal.

• From – Funding pot funds are coming from.

• To – Funding pot funds are going to.

• TokenType – The token address (0x0 for Ether).

• CurrentState – The state of the proposal (i.e. inactive, active, completed, cancelled).

• TotalPaid – Amount transferred thus far.

• TotalRequested – The total amount requested.

• LastUpdated – The time when the proposal was last updated.

• Rate – Rate of funding, a function of the backing reputation.

We distinguish between two types of funding proposals: Basic Funding Proposals (BFP) intended for normal use, and Priority Funding Proposals (PFP) intended to be used when a basic proposal is inadequate, or for unusual circumstances. The basic funding proposal may start funding the target straight away, whereas a priority funding proposal must be explicitly voted on before it starts directing funds.

Furthermore, for a basic funding proposal the target pot must be a direct descendant of the source in the hierarchy whereas a priority funding proposal has no such restrictions. Priority funding proposals should be used when funds need to be directed somewhere that is not a direct descendant of the source, when the funding rate needs to be very high (including immediate payment), or when multiple funding proposals must occur in parallel (e.g. in the case of paying of salaries).

3.2.1 Attributes in detail

From, To and TokenType The purpose of a funding proposal is to move tokens of TokenType from pot From to pot To. The TokenType may be Ether or any ERC20-compatible token. The From field must be a funding pot associated with a domain or an expenditure in the colony, while the To field may be any funding pot. If the funds are to move ‘downstream’ from a domain to one of its children, a basic funding proposal is often sufficient.

CurrentState The state of a funding proposal is either inactive, active, completed or cancelled. Only an active funding proposal is in line to channel funds. A basic funding proposal begins in active state while a priority one begins inactive (i.e. it must be activated by a vote). A funding proposal is active until it is either completed (when its TotalPaid reaches TotalRequested) or cancelled.

The creator of a funding proposal may cancel it (setting CurrentState to cancelled) at any time. This is analogous to the creator of a task being able to cancel the task if it has not yet been assigned a worker. Note that if an expenditure is cancelled, funding proposals that have that expenditure’s funding pot as their target (To) are automatically cancelled when they are next pinged, and no funds are reallocated.

However, the funds that had already been transferred are not automatically returned; it may require a PFP to return the funds ‘upstream’. TotalPaid and TotalRequested The total number of funds that a funding proposal wishes to reallocate is called its TotalRequested amount. Due to the mechanism by which funding proposals accrue funds over time, it is common that a funding proposal will have received a part but not all of its TotalRequested amount. The total number of tokens accrued to date are stored in its TotalPaid amount. The creator of a funding proposal may edit the TotalRequested property of a funding proposal at any time, but doing so resets the reputational support that the proposal has in the funding queue to zero. The intention here is for changes to funding to be potentially quick to achieve with the agreement of others in the colony if the requirements for the recipient pot change (e.g. the scope of a domain increases).

Rate and LastUpdated

When a funding proposal is eligible to accrue funds, it does so at a specific Rate, denominated in ‘tokens per second’. Since nothing happens on the blockchain without user interaction, the funding system uses a form of lazy evaluation. To claim funds that the proposal is due, a user may ‘ping’ the proposal — i.e. the user manually requests a pro-rated distribution of funds. When pinged, the time since LastUpdated is multiplied by the Rate to determine how many tokens the proposal would have accrued in the interim if funding flow were continuous. This amount is added to TotalPaid, the funds are transferred, and the current time is recorded as LastUpdated.

3.2.2 Basic funding proposals

A basic funding proposal (BFP) is a funding proposal from some domain’s funding pot to one of its children’s. It starts out in the active state and is thus immediately eligible for funding. It may be cancelled at any time by the Creator.

Ordering of BFPs

When created, a basic funding proposal gets placed at the back of the queue. Users can give a proposal ‘backing’ weighted by their reputation in the source domain at the time of backing.

The more reputation backs a proposal, the higher up the queue it is placed. Every transaction that adds backing to a proposal (or otherwise updates the backing level) inserts the proposal in the correct place in the queue. Only the proposal at the front of the queue accrues funds.

There are no costs to backing a proposal (other than gas costs) and the users obtain no direct benefits; it does not represent them putting their earned reputation at risk, nor any tokens - it merely helps the proposal achieve funding in a more timely fashion, and benefits them indirectly by helping the colony run better.

The rate of funding for BFPs

The more reputation backs a proposal, the faster it is funded. The rate scales linearly, and at the limit, if 100% of the reputation in the source domain backs a basic funding proposal, then that funding proposal will be funded at a rate of 50% of the domain’s holdings (of TokenType) per week.

The goal is a steady and predictable allocation of resources directed collectively by the domain’s (reputation weighted) priorities. When a user backs a proposal, both the user and their reputation at the time are recorded.

Consequently, the user is able to update their backing at a later date. However, we note that such an update is not automatic and even if a user loses reputation due to bad behaviour, their backing level remains unchanged until explicitly updated. Anyone is allowed to make this update – imagine a scenario where a user lost a lot of reputation due to bad behaviour, and other users wanted to stop a funding proposal backed by that user from continuing to accrue funding.

We emphasised that a user could back a proposal with their reputation at the time of backing because the reputation backing a proposal will not change when that user’s reputation does so. If by a quirk in this system, the reputation recorded as backing a funding proposal ends up higher than 100% of the total of that reputation in the colony, then the funding occurs no quicker than it would at 100%.

Completing a BFP

If an update finds that a proposal is fully funded (i.e. TotalPaid = TotalRequested), it is removed from this queue to allow the next-most-popular funding proposal to accrue funds. Explicitly, the following steps need to happen:

1. The time at which the funding proposal was fully funded is calculated.

2. TotalPaid is set to TotalRequested.

3. The BFP is removed from the queue.

4. The next BFP in the queue is promoted to the top of the queue, and its

LastUpdated time is set as the time calculated in 1.

Three days after the BFP has been fully funded (and thus complete) the creator’s stake is released. Until that time, the stake can be slashed by the arbitration permission.

3.2.3 Priority funding proposals

A priority funding proposal (PFP) is a funding proposal that can request funds to be reallocated from any pot to any other at any rate. PFPs begin in the inactive state and can only become active via an explicit vote. The vote is based on reputation in the domain that is the most recent common ancestor of the two pots that money is being transferred between. We imagine PFPs will be used to:

• reclaim funds from child domains.

• reclaim funds from cancelled tasks.

• fund tasks across domains.

• set aside funds designated as a person’s salary.

• make large, one-off payments.

Unlike Basic Funding Proposals, Priority Funding Proposals are not ordered in a queue -all active PFPs are eligible to receive funding at any time. Note that, since the amount of funds transferred is ultimately a function of the funds available, too many large PFPs can interfere with each other (and the leading BFP) by substantially reducing the amount of funds available in the funding pot.

3.3 Budget box

As an alternative to funding queues, colonies may instead choose to use a Budget Box to allocate funding between subdomains (or to divide funds among multiple recipients of an expenditure). Compared to funding queues, in which items are funded serially, Budget Boxes allow items to be funded in parallel, proportionally out of some fixed budget.

3.4 Motions and disputes

The most successful organisations are those which are able to effectively and efficiently make decisions, divide labour, and deploy resources. Often, these many decisions are structured via management hierarchies. But trustless colonies are intended to be low trust, decentralised, and pseudonymous - a hierarchy is not suitable.

In most DAO frameworks, the mechanism of collective-decision making is usually voting, but Colony is designed for day-to-day operation of an organisation. In a colony, voting on every decision is wholly impractical. The emphasis should be on ‘getting stuff done’ and not about ‘applying for permission’. Therefore, Colony is designed to be permissive. Task creation does not require explicit approval, nor do basic funding proposals or any number of administrative actions throughout a colony.

The Motions System provides a self-regulating mechanism which, via a balanced set of incentives, lets users keep their colony running harmoniously. It is there to resolve disagreements and to punish bad behaviour and fraud. The motions system allows colony members to signal disapproval of and potentially force a vote against users who have acted inappropriately.

When a member of a colony feels that something is amiss, they may make a motion. By doing so, they are fundamentally proposing that either a) a variable, or more than one variable, in the colony should be changed to another value, or b) a user, or more than one user, should receive a reputation penalty. For this reason we call supporters of the motion the ‘change’ side and opponents the ‘keep’ side.

The user making the motion must also put up a stake of the colony’s internal token. In essence, they are inviting the rest of the colony to disagree with them. In the spirit of avoiding unnecessary voting, the motion will pass automatically unless someone else stakes on the ‘keep’ side and thereby elevates the motion to a dispute.

We say that a dispute has been made whenever a motion has found support on both the ‘change’ side as well as the ‘keep’ side. Once raised, disputes must be resolved by voting.

3.4.1 Making motions

The user making a motion submits the following data:

• The data that should be changed, or users to receive penalties.

• The reputation(s) that should vote on this issue (a maximum of one from each of the domain and skill hierarchies).

• Proof that these reputations should be allowed to make the change in question.

The first item identifies the subject of the motion, and what the appellant believes the state should be. The second and third points concern appeals. The basic rule in Colony is: you cannot appeal a decision to higher management, you can only appeal to larger sets of reputation.

For example, suppose that the motion concerns a task in the ‘frontend’ domain. The appellant could choose to have all ‘development’ reputation vote on it -we say the decision was ‘appealed to the development domain’. In this example, the third point would be a proof that the domain ‘frontend’ was indeed a subdomain of ‘development’. The highest domain any decision can be appealed to is the root domain, where all domain reputation is entitled to vote.

Whenever an appeal occurs, we need to ensure that the reputation we are appealing to is a parent of the reputation associated with the variable being changed. This is possible to do efficiently because of metadata that is placed on the reputations (for domains) when they are created, which includes pointers to at least the direct parent. When a user makes a motion, instead of directly specifying the domain they are appealing to, they provide the steps needed to get there from the domain associated with the variable that is to be changed. This ensures that the domain they appeal to is a direct parent of that associated with the variable.

3.4.2 Costs and rewards

Cost of making a motion

To make a motion, a user must possess enough reputation and must also stake some number of the colony’s tokens. The reputation they need to be able to make the motion depends on the domain they are appealing to; the ‘higher up’ the decision goes, the higher the reputation requirement (and potential loss). To be able to create a motion, the user must have 0.1% of the reputation in the domain and must stake 0.1% of the corresponding fraction of tokens. Thus, if a motion involves 13% of total colony reputation, then the motion requires 0.013% (0.1% of 13%) of reputation and the required stake is 0.013% of all colony tokens.

If the initial user does not have the required number of tokens or reputation, they can still create such a proposal by staking as little as 10% of the tokens required, which requires them to have a correspondingly smaller amount of reputation. In this case the motion will not be ‘live’ until other users stake tokens, and take it over the 0.1% threshold. The amount of tokens required to be staked for a particular motion is recorded at the time when it is created. Users can only stake tokens in proportion to the reputation they have. For example, if they wanted to stake 40% of the tokens required, they must have at least 40% of the reputation that would be required to create the motion outright.

Cost of opposing a motion

Once enough tokens have been staked on a motion it becomes active and, barring any further actions for three days, the suggested change will take place (when the motion is ‘pinged’ by a user).

However, if there are users who oppose the suggested ‘change’, they may stake tokens in support of the ‘keep’ side. If the keep side receives sufficient support, a dispute is created.

If the ‘change’ side does not garner enough support in three days, the motion fails and is rejected. If, three days after the ‘change’ side had enough tokens staked and the ‘keep’ side does not, then it is assumed that the change is acceptable.

Voting on disputes

If both sides stake the required number of tokens within the time limit, then the dispute goes to a vote. The weight of a user’s vote is the sum of their reputations in the skills chosen by the user who originally made the motion.

The duration of the poll is determined by the amount of reputation eligible to vote as a fraction of reputation in the colony. If a larger fraction is eligible, the longer the poll is open for. The minimum duration is two days and the maximum is seven. This is a trade-off between allowing disagreements between small groups to be resolved quickly, but to also allow adequate debate to occur when more people are involved.

Voting takes place using a commit-and-reveal-scheme. This scheme is desirable because votes are kept secret during the voting period, preventing users from being influenced by what they perceive to be the majority opinion.To make a vote, the user submits a hash that is keccak256(secret, optionId), where optionId indicates the option that the user is voting for. Once voting has closed, the poll enters the reveal phase, where a user can submit (secret, optionId) and the contract calculates keccak256(secret, optionId) to verify it is what they originally submitted.

As the secret is revealed it cannot be sensitive. It must also change with each vote so that observers cannot establish what people are voting for after they have revealed their first vote. While there are many reasonable schemes for generating secure secrets, we suggest a (hash) of the consequence field of the poll signed with their private key, as it is easily reproducible by a client at a later date with no local storage required.

To combat voter apathy, 10% of the staked tokens are set aside to pay voters when they vote: if a voter has 1% of the reputation allowed to vote on a decision, they receive 1% of this pot that is set aside. They receive this payout when they reveal their vote, regardless of the direction they voted in or the eventual result of the decision. This ‘payout regardless of opinion’ is to avoid us falling victim to the Keynesian beauty contest, in which due to receiving a reward for being “correct”,

voters are incentivised to vote for what they believe most other people will vote for, rather than what they independently believe. Any tokens that would have been awarded to users who abstained from voting, or are not revealed in the reveal window, are sent to the root domain funding pot once the poll closes.

Once a vote has been in the reveal phase for 48 hours, a transaction may be made to finalise the vote. Any subsequent reveals of votes do not contribute to the decision being made, but serve only to unlock the user’s tokens if it was a token-weighted or hybrid vote.

Consequences of the vote If the ‘change’ side wins the vote then the change in question is made, but only if the reputation that voted for this outcome is more than previous votes on the same variable. If the ‘keep’ side wins, then the variable is not changed. In either case, the fraction of total reputation in the colony that voted for the winning side is noted.

At the conclusion of the poll, losing stakers receive 0-90% of their staked tokens back and they lose the complementary percentage of the reputation that was required to stake. The exact amount of tokens they receive back (and therefore reputation they lose) is based on:

• The fraction of the reputation in the colony that voted.

• How close the vote ultimately was.

At the end of a vote, if the vote was very close, then the losing side receives nearly 90% of their stake back. If the vote is lopsided enough that the winning side’s vote weight (w) reaches a landslide threshold (L) of the total vote weight, then they receive 0% of their staked tokens back. L varies based on the fraction of total reputation in the colony that voted (R):

So for a small vote with little reputation in the colony being allowed to vote, the decision has to be close to unanimous for the losing side to be punished harshly. For a vote of the whole colony, the landslide threshold L reduces to 67% of the votes - i.e. the reputation of the colony overall was split 2-to-1 on the decision.

Between these extremes of a landslide loss and a very slim loss, the loss of tokens and reputation suffered by the losing side beyond the 0.1 minimum (∆) varies linearly:

and so the total loss (0.1 + ∆) varies between 0.1 and 1.

What happens to the tokens lost?

Any tokens lost beyond the initial 10% are split between the colony and those who staked on the winning side, proportional to the amount they staked. Half of the reputation lost beyond the initial 10% is given to those who staked on the winning side, and half is destroyed (the colony as a whole having reputation has no meaning, unlike the idea of the colony as a whole owning tokens).

The motivation here is efficiency — it aims to discourage spurious motions and disputes. A close vote is a sign that the decision was not a simple one and forcing a vote may have been wise.

Therefore, the opposition should not be harshly punished. On the other hand, if a vote ends in a landslide, it is a sign that the losing side was going up against a general consensus. We encourage communication within the colony. Members should be aware of the opinions of their peers whenever possible before motions are made.

Repeated motions

In order to reduce the number of repeated motions and disputes over the same variable, the fraction of total reputation in the colony that voted for the winning side is recorded after every vote. This is the threshold that must be exceeded in any future vote in order to change the variable again.

We reiterate that this value is updated after every vote on the variable, even if the decision was to maintain the current value of the variable.

This requirement is the primary driver of the appeals process. If a decision was made in a domain, with low voter turnout, then it may be possible to reverse the decision by holding another vote in the same domain (along with a more vigorous off-chain get-out-the-vote campaign). However, if a large fraction of the domain’s reputation participated in a vote, then the only way to gain the support of a larger body of reputation (necessary to reverse the decision) would be to appeal the motion to a higher domain, or to a larger body of skills.

There is one exception to this rule: to ensure that a variable can always be changed if necessary, this threshold for changing the variable is ignored if the motion was appealed to the root domain of the colony. Anytime a vote is held in the root domain, regardless of prior votes on the variable, the variable can be changed.

3.4.3 Types of vote

Depending on the context and potential consequences of the vote, Colony supports three types of voting. The type of vote a particular action merits is predetermined based on the action, and is not a choice of the appellant.

Reputation-weighted voting

Most votes in a colony will be due to motions related to tasks. In these cases, the weights of the users’ votes is proportional to the reputation that each user has in the domain and skill that the vote is taking place in. When such a vote starts, the current reputation state is stored alongside the vote. This allows the current reputation state to be ‘frozen’ for the context of the vote, and prevents unwanted behaviours that might otherwise be encouraged (for example, delaying submission of a task until closer to voting so that the reputation earned has not decayed as much).

When revealing their vote, the user also supplies a Merkle proof of their relevant reputation contained within the reputation state that was saved at the start of the vote. The total vote for the option they demonstrated they voted for is then incremented appropriately.

Token-weighted voting

While Colony encourages the use of reputation as the primary sibyl-resistance mechanism, there are situations where tokens are more appropriate. Specifically, if reputation is a stand-in for ‘labour’, and tokens are a stand-in for ‘capital’, then token-weighted votings are appropriate whenever a decision must be made by capital, rather than by labour. Whenever a decision would be made by ‘investors’ or ‘shareholders’ in a conventional firm, a token-weighted vote may be appropriate.

Unlike with reputation, we do not have the ability to ‘freeze’ the token distribution when a vote starts. While this is effectively possible with something like the MiniMe token, we envision token-weighted (or hybrid) votes will still be regular enough within a Colony that we do not wish to burden users with the gas costs of deploying a new contract every time.

When conducting a token-weighted vote, steps must be taken to ensure that tokens cannot be used to vote multiple times. In the case of ‘The DAO’, once a user had voted their tokens were locked until the vote completed. This introduced peculiar incentives to delay voting until as late as possible to avoid locking tokens unnecessarily. Our locking scheme avoids such skewed incentives by locking tokens only during the reveal period.

Instead, once a vote enters the reveal phase, any user who has voted on that poll will find themselves unable to see tokens sent to them, or be able to send tokens themselves — their token balance has become locked. To unlock their token balance, users only have to reveal the vote they cast for any polls that have entered the reveal phase — something they can do at any time. Once their tokens are unlocked, any tokens they have notionally received since their tokens became locked are added to their balance. This global lock prevents a scenario, for example, where one user would reveal their vote and then send tokens to a colluding user, who would then reveal their vote using theaugmented token balance.

It is possible to achieve this locking in constant gas by storing all submitted secrets for votes in a sorted linked list indexed by closeTime. If the first key in this linked list is earlier than now when a user sends or would receive funds, then they find their tokens locked. Revealing a vote causes the key to be deleted (if the user has no other votes submitted for polls that closed at the same time).

This will unlock the tokens so long as the next key in the list is a timestamp in the future. A more detailed description of our implementation can be found on the Colony blog.

Insertion into this structure can also be done in constant gas if the client supplies the correct insertion location, which can be checked efficiently on-chain, rather than searching for the correct location to insert new items.

Hybrid voting

A hybrid vote would allow both reputation holders and token holders to vote on a decision. We envision such a vote being used when the action being voted on would potentially have a sizeable impact on both reputation holders and token holders.

This would include altering the supply of the colony tokens beyond the parameters already agreed or when deciding whether to execute an arbitrary transaction.

In order for a proposal to successfully pass through a hybrid vote a majority of both reputation and token holders who vote must agree that the change should be enacted.

3.5 Miscellaneous

3.5.1 Token management

While root users can mint tokens at-will, in many cases it will be desirable to mediate this ability via an extension contract. Here we describe such an extension.

Token generation and initial supply

When the extension is deployed, the TokenSupplyCeiling and the TokenIssuanceRate are set.

The former is the total number of colony tokens that will be created and the latter is the rate at which they become available to the root domain to assign to subdomains or expenditures. The number of tokens available to the root domain can be updated at any time by a transaction from any user (i.e. a public function will determine the pro-rated amount of tokens to generate since the last distribution).

Increasing the TokenSupplyCeiling

It is advised that new tokens not be generated without widespread consensus — especially if tokens have a financial value. Consequently, such decisions require a vote with high quorum and majority requirements involving both the token holders and reputation holders.

Changing the TokenIssuanceRate

The TokenSupplyCeiling represents the total number of tokens that the token holders have granted to the colony in order to conduct business: to fund domains and expenditures, and to incentivize workers and contributors.

The TokenIssuanceRate controls how rapidly the colony receives the new tokens. If the rate is ‘too high’, tokens will accumulate in the funding pot of the root domain (or other funding pots lower in the hierarchy). If the rate is too low, this signals that the colony has a healthy amount of activity and that the issuance rate has become a bottleneck. In such situations it may be desirable to increase the rate of issuance without necessarily increasing the maximum supply.

Increasing and decreasing the TokenIssuanceRate by up to 10% can be done by the reputation holders alone and this action can be taken no more than once every 4 weeks. Larger changes to the issuance rate should additionally require the agreement of existing token holders.

3.5.2 Compensation Modalities

Using expenditures, it is possible to implement many types of compensation modalities. In addition to the ‘task’, we can conceive of a number of additional modalities of compensation.

Salaries

Tasks imply colony-worker relationships are mostly transactional. In many cases, it is desirable to represent more long-term relationships via a salary.

A salary can be as simple as a recipient, amount, and period, and lastClaimed. At any point, the recipient can ping the salaries contract, at which point the contract will create an expenditure made out to the recipient, with funding equivalent to the pro-rated amount since the last salary payout. If the recipient is willing to pay the gas costs, they could conceivably claim (a fraction of) their salary daily, or choose to claim weekly, monthly, or at whatever cadence suits them. It would be the responsibility of the colony to ensure that adequate funding is available in the domain out of which salaries are to be paid.

This extension would need the funding and administration permissions to manipulate tokens and expenditures on behalf of the recipients.

Recurring or Automatic Tasks

While for certain kinds of work, tasks are unique and must be individually scoped out and subjectively evaluated. However, we can imagine situations where work can be done by many people and/or evaluated automatically by computer (such as rewarding users for participating in a referral program). In these cases, a variation of the task which contains logic for evaluating the work, and allows anyone to submit the work, would be appropriate.

This extension would need the funding and administration permissions to manipulate tokens and expenditures on behalf of the recipients.

3.5.3 Awarding reputation for work not captured by tasks

This prevents a permanent ‘reputation aristocracy’ and allows reputation to remain relevant even after major changes in the colony token’s value.

Reputation is awarded when a user receives payment of a colony’s internal token- most commonly as payout from an expenditure, but sometimes from motions resolution and, in the case of the Metacolony, from the reputation mining process. We can use the expenditure mechanism to award users extra reputation when there is consensus to do so.

Consider the scenario in which a founder, or an important early contributor to a colony has almost no reputation left by the time the colony starts earning revenue; perhaps the development of the product took a long time or perhaps the reputation decay rate was sub-optimally high for the particular colony. Or perhaps the founder was doing a lot of intangible work to get the colony off the ground in the first place and so was never compensated properly on-chain. To get around the limitations of the reputation system and to re-integrate the founder (and make them eligible to receive their rewards), the colony can create an expenditure that is solely designed to award the reputation they are due. To qualify for the payout of tokens (and thereby the reputation), the user in question would have to give the same number of tokens back to the colony. Again, a good frontend abstraction could make such reputation awards easy and intuitive.

Another important scenario concerns absences due to maternity/paternity or illness -the reputation system should not implicitly discriminate against these users. While ‘pausing’ reputation decay is not a viable option, various mechanisms of giving reputation ‘for free’ can be used to ensure that these users retain their reputation during periods of unavoidable absence.

The important point is that any limitations imposed by the system can be weakened if there is consensus to do so. The system should not stand in the way of consensus, it should just provide conflict resolution mechanisms for those times in which there is dissent.

3.5.4 Motions by non-members

Having reputation is a prerequisite for creating a motion or staking an opposition. Therefore, if an outsider is hired by a colony to perform a task, they will not, on their own, be able to make a motion in defense of their work. However, a good colony frontend may allow them to create the template for a motion, effectively calling for members of the colony to support it and submit the motion to the colony network on-chain on their behalf.

This is analogous to a member staking only 10% of the required amount and waiting for further support from their peers, with the difference being that without any third party support, the motion would never be processed on-chain.

4、The Colony Network

The Colony Network is a collection of contracts on the Ethereum blockchain. At the core of the network is the ColonyNetwork contract. This contract is primarily responsible for managing the reputation mining process, but also for general management of the network: deploying new colonies, setting the fees associated with using the network, and releasing new versions of the Colony contracts. These actions will be mediated by a special colony, the Metacolony.

4.1 Revenue model

The Colony Network must be able to sustain itself. In particular, the Metacolony (which controls the Colony Network) maintains the contracts that underpin the network and develops new functionality for the network — development of which needs to be paid for. Long term, the development and maintenance of the network (including the reputation system) needs to be financed by the network itself.

4.1.1 The network fee

We propose a fee levied on expenditure and reward payouts. When a user claims a payout, some small fraction will be paid to the network. The fees are sent to either the Metacolony (if the payment was in Ether or another whitelisted ‘currency’ token) or the Colony Network contract (if it is any other ERC20-compatible token).

This idea of a fee is a little unusual for such a decentralised system. One of the appeals of decentralised systems on Ethereum is that other than gas costs, they do not seek rent and are free to use. However, the network fee is key to ensuring the game theoretic security of the Colony Network’s reputation mining and governance processes, by providing underlying value to the CLNY held by Metacolony members. Importantly, this fee is not payable to any centrally controlled entity, but rather to the Metacolony. As anybody may contribute to the Metacolony, anyone may claim a share of these fees proportional to their contribution. We believe that the benefit of being part of a secure, well maintained network will be appealing enough that a small fee to pay for its existence will be acceptable.

The presence of this fee means we have to make some considerations which would otherwise be irrelevant. Primarily, we will need to make ‘piggyback’ contracts as hard as possible to make that might e.g. be used to pay out an expenditure payout when a expenditure was finalized, but without sending the fee.

4.1.2 The token auction

As the network fee may be denominated in any ERC20 token, there is a need for a mechanism to liquidate arbitrary bundles of tokens: the token auction. The tokens collected are auctioned off by the Colony Network Contract, with the auctions denominated in Colony Network Tokens, the proceeds of which are burnt. These auctions-one for each type of token collected-occur on a regular basis of once a month.

We believe such a mechanism will be beneficial for the Colony Network Token holders (whose tokens gain value by having an explicit use beyond reputation mining) and the Metacolony itself (by reducing the supply of Colony Network Tokens and thus making any future minting more valuable).

It also provides an immediate mechanism of price discovery for a colony’s internal tokens, which are unlikely to be traded on third-party exchanges until much later in the lifetime of the colony.

By auctioning off the collected tokens, we also prevent the Metacolony collecting a large number of different tokens that it has to manage, which would prove cumbersome and annoying.

4.2 The Metacolony and CLNY

The Metacolony is a special colony which governs the Colony Network. Tokens in the Metacolony are known as CLNY and will be initially generated during the Colony Network distribution period.

4.2.1 Role of CLNY holders and the Metacolony

CLNY holders have two primary roles. The first is to participate in the reputation mining process. The second is management of the Colony Network itself. There will be permissioned functions on the Network Contract to allow fundamental parameters of the network to be set, which can only be called by the Metacolony. For these permissioned functions to be called by the Metacolony, a vote open to all CLNY and reputation holders must be conducted. Management of the Colony Network also includes making updates to Colony contracts available to colonies. CLNY holders are not necessarily responsible for the development of these updates, but are required to vote to deploy them. They are therefore responsible for at least ensuring due diligence is done, either by themselves or by service providers, to avoid introducing security weaknesses or other undesirable behaviour. In return for the responsibility of the development and maintenance of the Colony Network, the Metacolony is the beneficiary of the network fee.

Reputation in the Metacolony can be acquired by earning CLNY tokens by via expenditure payouts just as in any other colony. Reputation in the Metacolony can also be earned by participating in the reputation mining process, which is unique to the Metacolony.

4.2.2 Handing off decision-making power to the Metacolony

Colony Network Token holders are responsible for reputation mining from the start, but decisions about the underlying properties of the network will initially be made by a multisignature contract controlled by the Colony team. As the network develops and is proved to be effective, control over these decisions will cede to the Metacolony.

Stage 1: Colony team multisig in control

Initially, the Network Contract’s functions will be root-permissioned to only allow transactions from the multisig contract under the control of the Colony team to change these properties of the network.

Stage 2: Colony team multisig approval required

At a later date, an extension contract will be set up and given the root permission. This contract will allow the Metacolony (as a whole, via the governance mechanisms provided to all colonies) to propose changes to be made to the Colony Network Contract. The intermediate contract will have functionality such that all changes will have to be explicitly allowed by the account under the control of the Colony team. In other words, the Metacolony will be able to propose changes, but the team must sign them off.

Stage 3: Colony team multisig retains veto

The next stage will be a second extension contract operating similarly to the first, but after a timeout — with no interaction from the Colony team’s account — the change will be able to be forwarded to the Colony Network Contract by anyone. The Colony team’s role will be to block changes if necessary. Thus at this stage the Metacolony will be able to make changes autonomously, but the Colony team retains a veto. The proposal to move to this contract will have to come from the Metacolony itself.

Stage 4: Metacolony fully controls the network

Finally, the specialized extension contract will be removed and replaced with a generic voting extension, and the Metacolony will have direct control over the Colony Network Contract with no privileged control available to the Colony team other than that provided by any CLNY and reputation held.

1. Reputation Mining

The reputation system is a core component of any decentralised colony. By carefully balancing the rewards and penalties we aim to keep every users’ incentives aligned with the colony and the colony network. Since reputation can only be earned and not transferred between accounts, the system fosters a more meritocratic form of decision making than pure token-weighted voting can hope to achieve. The continuous decay of reputation ensures that the influence conveyed by reputation is

recently earned and up-to-date. As such, it prevents a reputation aristocracy and allows for a fluid passing of control from one set of contributors to another over time.

Due to the combined complexity of reputation scores across multiple colonies, domains, and skills, reputation scores cannot be stored or calculated on-chain. Instead, the calculations will all take place off-chain, the results of which will be reported to the blockchain by participating CLNY holders -in a process resembling a proof-of-stake blockchain consensus protocol. We call this procedure Reputation Mining.

The reputation calculation whose result the miners are submitting is determined by the activities that have taken place in the colonies and can be fully deterministically derived from the Ethereum blockchain. Game-theoretically the system is protected similarly to the off-chain calculations of TrueBit in that, while the calculation cannot be done on-chain and a correct submission can never be proved true, an incorrect calculation can always be proved to be wrong.

Appendix

Decentralized Capital Allocation via Budgeting Boxes

The cornerstone of this mechanism is a novel component called a Budgeting Box, implementing a simple, general, and powerful governance algorithm, budgeting boxes aggregate and process sets of pairwise preferences. Our approach involves converting our set of pairwise preferences into a Markov transition matrix M, and using this matrix to find an eigenvector v corresponding to a probability distribution over the items, which we may alternatively interpret as a budget or ranking. Intuitively, we can think of the final probability as the likelihood of that item being “the most important thing”, based on the observed preferences.

Our voting information converted into an irreducible, aperiodic, ergodic Markov matrix guaranteed to possess a unique principal eigenvector interpretable as a probability distribution over the items, or alternatively as either a ranking or allocation of a budget. A number of methods exist for finding eigenvectors; we will use power iteration, a straightforward algorithm returning v to a precision of E.

Intuitively, every iteration first asks “which items are the most popular?”

and then “for every item, which items are even more popular?” Over time, probability mass converges to the items which have been relatively preferred, as popular items accumulate more probability, which they then “send forward” to items more popular than they.

1、Scalability

A limit of K items per box does not restrict a mechanism to K items overall, as multiple budgeting boxes can be composed to accommodate larger sets of items. One approach to the composition is to assemble boxes into a tournament bracket); another approach is to compose them into a recursive hierarchy of “abstract to concrete” (think public services → education → primary schools).The composition of budgeting boxes reduces cognitive complexity in tandem with computational complexity. For 100 items, there are 4,950 possible pairs; compare this to 10 · 45 = 450 pairs when this same 100 is divided into 10 groups of 10. These 450 pairs are a subset of the original 4,950 –but not a random one. If we posit that these 100 items can be ordered by quality, and that only comparisons between items of similar quality provide useful information, then subdividing the set of items into subsets of items of similar quality allows us to avoid making 4,500 low-value comparisons: a 10x improvement in cognitive efficiency.

2、Leagues and Lanes

To make the best use of the limited attentional resources of the voters, we divide the set of items into two categories: those in the leagues (each league being essentially a thin wrapper around a budgeting box), and the remainder in one of several lanes of the pool. All items begin in the pool; items which receive sufficient of support will be promoted to the leagues Items in the leagues are then compared against each other in a pairwise fashion and ranked; items which rank highly may be promoted to higher leagues and become eligible for larger rewards.

3、Scoring the Lanes

Projects in the leagues receive rewards, paid out via the Colony task mechanism. The pool, on the other hand, serves as a reservoir of projects hoping to get into the leagues; projects in the pool do not receive rewards.

Consequently, in comparison to the high-stakes, high-attention leagues, the mechanism for processing projects in the pool is simpler, providing only a coarse filter. The pool is divided into L “lanes”, each of which can hold up to 256 projects. Projects enter a lane by staking some fixed amount of CLNY tokens. Once in a lane, projects receive votes of approval only; projects receive scores equal to the reputation-weighted sum of their approvals.

At the end of the voting period, we have an ordering of each pool lane in which projects are ranked based on their total backing reputation. The staking requirement is intended as an anti-spam mechanism. As a further protection against low-quality submissions (which drain voter attention), projects in the pool with a score less than 0.2 of the median will have their stakes burnt. To prevent projects from withdrawing their stake in anticipation of being burnt, we allow projects to leave the pool only during the first third of the voting period.

4.、Moving Between Leagues

Our mechanism functions much like a sports league, in which those that rank at the bottom at the end of the season are relegated to a lower league, while those that rank highly will move to a higher one. A “season” in our case is one voting period. At the end of a voting period, all the projects are scored, rewards are paid out where appropriate, and the projects are assigned a league for the following period.

The reassignment is governed by the parameters Z and a “shuffling factor”C, which determines how many projects move between periods. As the leagues are arranged in a binary tree, it is possible to index every node and traverse the tree.

Moving from one League to another，The bottom (after sorting by score) 2C projects in league g are swapped with the top C + C projects from league J, where the demotion from g to J happens in alternating fashion.

Moving from the Lanes to the Leagues, Projects that rank at the bottom of the bottom-tier leagues are expunged from the system (with their stake returned). They are free to reenter the pool by posting a new stake. The newly vacated spots are filled by the top projects in the pool lanes. We aim to have no more than half of the pool enter the leagues at any one time, thus each lane can support a maximum of leagues and so. When there are multiple lanes, they are assigned to leagues in a roundrobin fashion for a leaf league.

Conversely, we denote the leagues associated with a lane by leagues(l). The goal is to replace the bottom 2C projects in all the leaf leagues with the top 2C |leagues(l)| projects in the pool lanes. So for each lane we replace on of candidate quality balanced amongst the leagues, the implementation should interleave the swap in a round-robin fashion such that the strongest candidates are distributed evenly amongst the leagues which they enter.

5、Determining Allocation

Once projects have been voted on and the votes processed, but before they are moved between leagues, their final budget allocations are determined.

Only projects in the leagues receive an allocation, governed by v. A damping factor d which allows for evening out the distribution over all projects in the league.

Relatedly, we must decide how to distribute the available budget across the leagues.

This allocation is governed by a parameter Q ∈ [0, 1], which guides us between two extremes: at Q = 1 we have a uniform allocation over all leagues, and at Q = 0 an exponentially diminishing allocation. Knowing Q we have the total budget available to league.

1. Expanding the Mechanism

In that the mechanism can be expanded to accommodate an arbitrarily large number of projects. Note that the mechanism’s capacity is driven by three parameters:

Z, which determines the number of leagues, K, which determines their size, and C, which determines the degree of movement; jointly they determine the size of the pool, which we require to be able to hold twice the number of projects which can enter the leagues in any period.

As the Colony Network matures and the number of projects looking to participate in this mechanism grows, the mechanism can be expanded by incrementing Z; every increment will double the size of the leagues and create new lanes as necessary. Note that as lanes are added, existing candidates are not redistributed, creating a type of “arbitrage opportunity” where projects can stake themselves into lanes where competition is less intense; this will naturally lead to an even distribution of project quality amongst the lanes.

7、Voting Process

In order to make this mechanism Sybil-, bribery-, and collusion-resistant,

we first appeal to the Colony reputation system. With reputation-weighted voting, those with the most influence also have the most to gain from the growth of the Colony Network, and are thus the least incentivized to accept immediate payouts (bribes) in exchange for worse long-term prospects. Further, as reputation derives from work done for the Meta Colony, those with more influence ostensibly have better knowledge of the ecosystem and can make better determinations about the relative value of projects.

In order to encourage participation, we will set aside a portion of B for voter compensation, with per-voter compensation a function of relative reputation. Making compensation proportional to reputation serves the dual purpose of Sibyl-resistance and encouraging those with the most influence to expend the most effort in making judicious decisions (to increase their long-term rewards) and further decrease the relative incentive to accept bribes in exchange for favorable treatment. If BR is the portion of the budget set aside for voter compensation, then the per-voter compensation be is determined as follows:

Voting Subdivision，Another consideration is the subdivision of the voting process. Should a “unit of voting” involve voting on every pair and project? Or should reputation holders be able to contribute smaller units, as motivation permits?

Fortunately, the “pool and leagues” organization of projects leads to a natural compartmentalization of work. Voting on one league or one lane constitutes one “unit” of voting. The per-unit voting requirement should be set in advance.

8、Conclusion

As described above, the mechanism as a whole is governed by a number of hyperparameters: K, which determines the size of the leagues; Z, which determines their number; C, which determines the degree of movement between periods; B, which determines the total budget; and d and Q, which affect the distribution of budget within and between the leagues, respectively.

Unlike the pairwise votes, which capture personal preference, these hyperparameters capture political preference, as they define the behavior of the system as a whole: the size of the payouts, the number of projects eligible to compete, the permissible level of inequality in the payouts going to the popular versus unpopular projects, and the speed with which the allocation a specific projects can rise or fall.

All of these parameters, except for the fixed K, can be updated via reputation-weighted voting in the Meta Colony. Our expectation is that Z and B will begin small and be increased over time as the network matures and the number of projects increases. We anticipate that d, Q, and C will be updated less frequently to fine-tune the behavior of the mechanism; we expect to launch the mechanism with low values of each, such that payouts become meaningfully larger in higher leagues, that “losing” projects in higher leagues will still earn more than “winning” projects in lower leagues, and that movement between leagues is slow enough that projects have a meaningful time horizon of income.

It is intentional that winning projects will accumulate reputation and influence in the Meta Colony over time. As these projects both support and depend on the Colony Network, it is appropriate that they are able to both participate in the governance and share in the rewards of the network.

In our introduction, we introduced a number of possible attack vectors

and failure scenarios, and claimed to have developed defenses against them.

We will take them point by point:

1. Spam. Soln: minimum stake makes spamming expensive.

2. Scammers. Soln: low initial payouts makes scamming uneconomic.

3. Bribes. Soln: reputation-weighted voting aligning long-term incentives.

4. Self-voting. Soln: eurovision rule.

5. Collusion. Soln: nonlinear vote interactions, random walks.

6. Voter apathy. Soln: engaging experience, voter compensation.

7. Cognitive biases. Soln: nonlinear vote interactions.

8. Random voting. Soln: reputation-weighted voting and compensation.

9. Sybil attacks. Soln: reputation-weighted voting and compensation.

It is important to note that no mechanism can ever be fully resistant to attack or failure; every mechanism, even proof-of-work, functions conditional on some reality. The mechanism we describe assumes a reasonably diverse set of engaged reputation holders looking to benefit from the long-term success of the Colony Network. The goal of this mechanism is not to provide a fool-proof framework for decision-making, but rather to solve a specific set of problems without introducing a large set of new ones.

We believe that the use of pairwise preferences to solve collective ranking and budgeting problems represents an important tool in the decentralized governance toolkit.

Contact Information:

Home page: https://colony.io/

Recruitment: https://angel.co/company/colony

Blog: https://blog.colony.io/

LinkedIn:https://ph.linkedin.com/company/colony-io

Twitter:https://twitter.com/joincolony

Github:https://github.com/JoinColony

Discord:https://discord.com/invite/Qjupxvg

Address: 5th Floor, Genesis Building,Genesis Close, PO Box 446,Grand Cayman,, Grand Cayman KY11106, KY

欢迎提交你的DAO研究到邮箱：daorayaki@dorafactory.org，瓜分10000USDC赏金池！欢迎访问DAOrayaki官网（daorayaki.org）

详情请参考：

Dora Factory支持去中心化DAO研究组织DAOrayaki

历史文章：

Synthetix：去中心化治理结构

DAOMaker: 代币化的创业孵化器和募资平台

SourceCred：基于贡献的计算信用工具

二次方融资（Quadratic Funding）的攻击与防守

道德作为通证工程共享（Token Engineering Commons）的使命与动机

DAO 联盟|Open DeFi DAO 治理结构

策展市场|一种构建联合关注网络的机制

Farming机制是否代表着代币分配的进步？

全方位解读PANVALA：去中心化的以太坊资助平台

Social token与DAO思潮下微观经济体的崛起

什么是社区贡献机会（CCO）？

万字解读| Upshot One 对等预测协议

如何DAO化|基于社区贡献机会（CCO）机制的去中心化治理

罗宾·汉森经典论文（四）|Futarchy：工程设计25个问题

罗宾·汉森经典论文（三）|Futarchy：工程设计25个问题

罗宾·汉森经典论文（二）|Futarchy：我们应该价值投票、对赌信仰吗？