Today we are proud to publish the first major revision of our technical whitepaper.

Colony is an ambitious piece of software, and its architecture and design choices have evolved in the more than two years since we published our original paper. By returning and revising our core technical spec, we hope to make it easier for interested parties to understand the current thinking and principles shaping the Colony Network and to make sense of the various components, their design, and their interactions. Further, by maintaining this as a public document, we make it easier for the professional community to evaluate our designs and judge their efficacy for themselves.

For those new to our whitepaper, feel free to dive in. For those already familiar and are curious what has changed, here are some highlights:

  • Permissions, our access-control framework. A permission is held by an Ethereum address and gives that address access to certain privileged functionality (analogous to low-level system calls). There are six permissions, roughly in order of decreasing power: Recovery, Root, Arbitration, Architecture, Funding, and Administration, each representing a semantic bundle of functionality. Permissions can be granted at different levels of the domain hierarchy, allowing for the creation of complex systems of authorization. Further, as permissions can be granted to any address, it is possible to develop stand-alone smart contracts which “plug in” to the colony to extend its behavior, which brings us to…
  • Extensions. The idea of extensions flow naturally from that of permissions, as the ability to give arbitrary addresses access to privileged functions means that it becomes possible to very flexibly develop and experiment with arbitrary mechanisms and interfaces built on those functions. For instance: a specialized budgeting mechanism, built on top of the “funding” permission. By developing extensions which mediate lower-level functionality with mechanisms, colonies can more effectively explore the organizational design space, alternatively experimenting with more direct admin control and more permissionless, distributed decision-making mechanisms.
  • Stake management. It is reasonable to expect that some extensions will require users to stake tokens before taking actions, such as a voting extension which allows users to initiate arbitrary polls by putting down a stake. If other users feel that the poll was made in bad faith (perhaps as spam), the initiator may (rightfully) lose their stake. Given that extension contracts are independent of the colony itself, having to keep track of stakes made to many different contracts could create a significant UX burden for users. Further, ensuring that extension contracts can hold funds securely makes the technical burden of developing extensions much higher. To address this, we developed a common interface for extensions (or admins) to manage stakes on behalf of users, without them having to receive and hold funds directly.
  • Reputation mining. While the design of the reputation mining process is largely unchanged, a number of implementation choices have been made which differ from those given in the original whitepaper. Most significantly, this includes the switch from a regular Merkle tree to a more efficient Merkle-Patricia tree as the data structure for the reputation tree.
  • The whitepaper’s overall organization has been changed, with sections being relocated to fit into a broad five-part thematic structure: introduction, the colony, extensions, the colony network, and reputation mining.
  • In addition, a large-but-not-embarassing number of errata have been found and fixed.

We hope you enjoy reading it as much as we did writing it!

Colony is a platform for community collaboration—do work, make decisions, and manage money, together.


Join the conversation on Discord, follow us on Twitter, sign up for (occasional and awesome) email updates, or if you’re feeling old-skool, drop us an email.