We’ve moved all of our early blogs initially published here to our site so you can find everything in one place.

As we have for some time, we will no longer be publishing on Medium. Find our latest news, articles, and updates on the Colony Blog.

Between posts, be sure to join us on Discord or check out our latest on X.

See you there!

Thank you for following us and being a part of the Colony journey.

Goodbye Medium, find us at the Colony Blog was originally published in Colony on Medium, where people are continuing the conversation by highlighting and responding to this story.

Colony v2 will soft launch on Ethereum mainnet and xDai at 17:00 UTC (ish) on 15th February 2021.

Join us for the ride on Telegram or Discord!

What is Colony?

Colony is the most powerful, practical, flexible, and easy to use DAO framework, and we’re extremely excited to let people start playing with our sparkly new dapp.

This video shows where Colony is heading in the months following launch:

What does soft launch mean?

It means we’re ready to play… gently.

It’s an early beta, so there will be bugs, and assorted UX quirks. We’ll appreciate you helping us find them.

And while the Colony Network v5 smart contracts on which the app runs contain virtually all features detailed in the Colony whitepaper, the app doesn’t yet. So, using it means accepting its current limitations. (See below)

We also make no guarantees about Colony’s security or fitness for purpose; the Colony Network smart contracts are large, complex, and under active development, which makes audit impractical. While Colony has been developed with a defensive programming mentality, it would be imprudent to deposit your project’s entire treasury to your colony right away. We’re looking into some ways to attenuate this concern, but for now, exercise caution: you use Colony at your own risk.

Alright, so here’s what to expect, and what not to expect.

Launch features

Colonies
Create, join, and switch between colonies; just like Slack.

Tokens
Issue a new erc20 token, or bring your own; the choice is yours.

Receive funds
Receive and manage income in any erc20 compatible token.

Action Creator
All the actions your colony can take, accessible via one button.

Simple Payments
Send funds from a colony to an external account.

Teams
Structure your colony into teams to divide and conquer any project.

Budgets
Allocate teams their own budgets to control.

Permissions
Assign authority to members in each team to create expenditures, transfer funds, and more.

Reputation
Payment in a colony’s native token confers reputation in the team from which it was received. Reputation decays over time.

Events
A log of everything that happens in your colony, whether in the app, or directly via the contracts.

Recovery mode
Your colony’s panic button in case of emergency. Freeze the colony. Fix the problem. Restart your colony via multisig.

Coming Soon

After launch, updates will roll out thick and fast. Over the first month, aside from a bunch of minor improvements and bug fixes, you can expect to see:

Extension manager
Install and manage smart contract extensions that expand your colony’s capabilities.

Token Supplier (extension)
Control the supply of your colony’s token. We’re really imaginative with names.

Coin Machine (extension)
Sell tokens in fixed price batches, adjusting prices up or down between batches based on recent demand.

Early Access Program

While decentralised governance is Colony’s raison d’être, it is not available at launch.

If you wish to participate in the early access program, we don’t want you to be disappointed when you find you can’t do voting. It’s coming, real soon, but early users must be prepared to work around this limitation for a little while.

If you understand the limitation, and still want in, reach out here and tell us about your use case.

If you already have a colony on Ethereum, you’ll need to upgrade your Colony Network version to v5 to use it. That said, to avoid any nasty surprises, we urge you to be mindful of gas costs before signing transactions.

Fin

That’s it for now. In a post dropping in the next few days, we’ll outline what the dapp roadmap for the next six or so months looks like (and yes, it’ll include governance).

Colony makes it easy for people all over the world to build organisations together, online.

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

Originally published at https://blog.colony.io on February 9, 2021.

Colony v2 Launch on Ethereum mainnet and xDai was originally published in Colony on Medium, where people are continuing the conversation by highlighting and responding to this story.

In 2017 we published the first version of the Colony Whitepaper. In it, we outlined our vision of “Organizations, for the Internet”. That it is awesome is universally acknowledged.

Unfortunately, the same could not be said of our Dapp. There’s no point in being coy here: our Dapp suuuucked! It was about as pleasant a user experience as root canal surgery, and not as useful. Further, it barely made contact with the prodigious power of the Colony Network thrumming underneath.

It wasn’t the product we’d promised, and it left users confused and disappointed. There are some teachable moments in how things unfolded that way, but it’s a story for another day.

The important thing is this: we’re about to launch New Colony.

Which confusingly, is old Colony. Colony of the Whitepaper. Colony as advertised. Colony as it always should have been. And it is goooooood! 😎

Okay, so what exactly is Colony again?

Colony is the most powerful, practical, flexible, and easy to use DAO framework.

Powerful
Everything an organization needs to operate on-chain. Payments, Teams, Authority, Governance, Fundraising, Revenue sharing, Arbitration, the ability to interact with any other smart contract on Ethereum, and a whole lot more.

Practical
In a healthy organization, voting should be rare. That’s why Colony operates a more agile system of ‘lazy consensus’. It means organizations spend their time productively, not endlessly voting.

Flexible
Colony Core provides powerful primitives for finances, org structure, and authority. Extensions are plug-ins that build on those, shaping organizations according to their needs.

Easy
Colony makes DAOs easy. Unlike the complicated, clunky competition, Colony’s application seamlessly integrates powerful DAO functionality into a polished, logical, and easy to use experience.

Colony is the core of a suite of tools a Decentralized Organization needs to manage its operations. For Colony, as a team, that suite of tools looks something like this:

‌‌So, if your project needs a DAO, but the options you’ve tried so far are all just a little bit… meh, or you’re interested in doing work for DAOs, you’ll want to stay tuned.

In the next blog post we’ll unveil the launch release features.

After that, the 2021 roadmap.

And then, finally, our plans for the long awaited Colony token sale.

Join the community on Discord or Telegram to ensure you don’t miss the next announcement, and to register your interest in the beta.‌

‌Colony makes it easy for people all over the world to build organisations together, online.

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

(Re)Introducing Colony was originally published in Colony on Medium, where people are continuing the conversation by highlighting and responding to this story.

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!

Originally published at https://blog.colony.io on March 5, 2020.

Colony Whitepaper 2020 Update was originally published in Colony on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ve released a new feature on our docs sitefor developers!

Developers

Developers cruising around the docs might notice a new little button on the upper right hand corner that says “Login”. Login to what?

The developer dashboard is a cool new way for us to help and support you, dear devs ❤️

Once created and connected to GitHub and MetaMask, your developer account will allow you to connect to your network of choice (Goerli or Mainnet), view colonies, and check your token balances. You can choose specific colonies to “watch”, and maybe in the future, see some at-a-glance network statistics.

Developers

That’s not it, however. We’ve got some bootstrapping to do.

We’ve created the first ever community colony on mainnet, built by and especially for developers working with and contributing to our developer tools.

This will be our testing ground for rewarding community contributions that embiggen the overall cromulence of the Colony protocol.

The new developer dashboard integrates with the developer’s colony, and with its internal token, CDEV.

If you are interested and able, use your linked developer’s account to make contributions to Colony repositories, and to earn CDEV for your good works.

Check the contribute page for “Help Wanted” issues in Colony open source projects, and see your accumulated tokens and reputation in the developer’s colony.

For now the CDEV token is just a token of appreciation — a developer’s upvote, if you will. Meaning is collectively created, however.

Developers

The developer dashboard was created to compliment the docs and open-source tools (such as Purser), all of which are community-driven and supported. The developer’s colony is how we’ll be organizing this community.

It may be an upvote for now, but we regard CDEV (and more importantly, Reputation in the developer’s colony) in high esteem. Tokens today mean a stake in the future of Colony open-source tools, and clout in future decisions to be made about where we go from here.

If you’d like to contribute to Colony open-source projects, you can dive right in by opening an issue or pull request on Github. Alternatively, post to Discourse with suggestions or feature requests, use cases, etc.

“Developers, developers, developers, developers, developers, developers, developers, developers, developers, developers.”
- Steve Ballmer

Colony builds tools for organizing and incentivizing teams, communities, and contributors. Join the discussion on Discourse, follow us on Twitter, sign up for (occasional) email updates, or if you’re feeling old-skool, drop us an email.

Originally published at https://blog.colony.io on July 3, 2019.

A Colony for Developers was originally published in Colony on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mainnet release in… negative two weeks™

glider is ready for the prime-time. Mainnet time. Tell your friends.

Actually, things have been live and running smoothly for about two weeks now — now that we’ve confirmed everything is running as expected, it’s time to SHOW YOU WHAT WE GOT

The first release of Colony is glider, and it can be accessed at:

0x5346D0f80e2816FaD329F2c140c870ffc3c3E2Ef

Release notes: https://github.com/JoinColony/colonyNetwork/releases/tag/glider

Devs should read the docs before trying anything ambitious.

New chain, who dis?

Ahoy hoy! This is Colony. In a nutshell?

Organizations, for the Internet.

The Colony Network is an open source Ethereum based protocol providing a general purpose framework to create, operate, and monetize Digital Companies.

Digital Companies are to traditional organizations as digital currencies are to fiat currencies: Digital Currencies are internet-native cash, Digital Companies are internet-native organizations. The Colony Network provides a framework for the essential functions Digital Companies require, such as ownership, structure, authority, and human and financial resource management.

What we’re talking about here would fly well with the blockchain-cognoscenti as crypto-organizational primitives: ReputationⓇ, Domains, Permissions, and Incentives are codified structures to coordinate working relationships between people (and/or robots), inside the natively permissionless, psyeudonymous world of smart contracts and blockchains.

These could be the kind of relationships meant to solve the world’s big, ugly multi-party coordination dilemmas (#molochproblems), or they could be relationships forged by the simple need to fairly divvy up DAI amongst a fellowship of friends on an extended adventure. Maybe those end up being two sides of the same token. ¯\_(ツ)_/¯

In creating a colony, founders choose how to organize these structures according to whatever work the colony is doing. From platform cooperative to (virtual) thieves guild, a colony provides tools to coordinate work, manage budgets, and make decisions; from each according to her ability, to each according to her reputation-weighted token holdings.

Colony, by virtue of its upgrade pattern, is eternally backwards-compatible, meaning that any organization built with Colony will run indefinitely and unstoppably according to the will of its members. Not a platform, but infrastructure. For the future of the firm.

The first release of Colony is called glider after the smallest of the spaceships from Conway's Game of Life - (spaceships are little explorers of a Universal Turing Machine, not unlike colonies in the EVM).

glider implements the following features of the Colony Protocol as described in the whitepaper, and it will be continuously upgraded to implement new functionality:

Reputation Ⓡ- with ✨ exponential decay ✨ and a decentralized mining client.

Bring your own token- allowing any colony to use an ERC20 token as a means of accounting for reputation.

Domains- for the management of multiple token *funding pots*, with specialized reputation score according to domain and skill.

Modular Permissions- create granular control over ability to interact with a colony at the domain level.

Payments and Tasks- perform the secure transfer of funds (and reputation) as compensation for work done for the colony.

Rewards- distribute periodically a set amount of a colony’s revenue its contributors, proportional to their reputation-weighted contributions to the colony.

If you feel unsatisfied by this feature list and want a more full-bodied explanation, check out the Görli glider release post or the . Those inclined to do so should follow the whitepaper rabbit 🐇.

Importantly, there are aspects of glider that, in their current implementation, require some amount of "trust" in the sense that they are not yet under fully decentralized/distributed control.

The Metacolony is permissioned and controlled by the core contributors to the colonyNetwork repo, as are contract upgrades, maintenance, and reputation mining.

Colony builds tools for organizing and incentivizing teams, communities, and contributors. Join the discussion on Discourse, follow us on Twitter, sign up for (occasional) email updates, or if you’re feeling old-skool, drop us an email.

Domains are restricted to single-level within the root domain (nested domains are currently prohibited as a precaution).

Tasks are partially in a “trusty” state, insofar as there is no dispute resolution system implemented at this time to handle work disputes on chain. Payments can be seen as “trustful” Tasks without work ratings or reputation bonuses.

Bug Bounty scope

With the release of glider-rc.1 on the Goerli testnet, the bug bounty program changed in scope a little bit, and it will continue to run permanently. Bugs that affect the mainnet deployment should be reported (discreetly🙏) to security@colony.io -- they will be handsomely rewarded.

If a bug is found that affects only the develop branch, it can be reported as a Github issue, and discussed privately or publicly (if the finder believes it doesn't constitute a security risk for mainnet).

Originally published at https://blog.colony.io on June 24, 2019.

Glider has launched was originally published in Colony on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR — We deployed our mainnet release candidate, glider-rc.1, to the Görli testnet last week.

For bug hunters, this is now the only deployment eligible for bounties.

Glider is our first implementation on a long road toward the full Colony Protocol, so if you dive in straight after reading the whitepaper, you’re going to be a little confused. See below for what glider-rc.1 can do and what it can't (yet).

What’s with the name?

A proper introduction, of course, starts with names. Colony’s mainnet release is dubbed glider. What's a "glider"? Good question.

The first thing to get out of the way is why the name Colony is appropriate for what we’re building. Yes, it’s been pointed out that there is a not-so-great interpretation for “colony”. This is our official statement on the matter:

The name ‘Colony’ comes from complex adaptive systems theory.

From Wikipedia:

Complex adaptive systems are complex in that they are dynamic networks of interactions and their relationships are not aggregations of the individual static entities, i.e., the behavior of the ensemble is not predicted by the behavior of the components.

They are adaptive in that the individual and collective behavior mutate and self-organize corresponding to the change-initiating micro-event or collection of events.

Most examples of such systems found in the natural world use the word ‘colony’ to describe the larger thing that, in a nutshell, a whole greater than the sum of its parts.

Whether we’re talking about leafcutter ants or naked mole rats, colonies are able to allocate resources, coordinate effort, and in a rudimentary sense, make decisions that are built upon the collective action of each member organism, but in an important way, not made by any particular member. Furthermore, the super-organism itself is able to accomplish things that no single organism ever could, on impossibly large scales.

Now that we have cleared that up, why ‘ glider ‘?

We in the Ethereum community often like to believe that we’re breaking new ground, building entirely new systems the world has never conceived of before, but in reality a lot of what we do is a re-mix of ideas that have been thought about long before our hip peer-to-peer consensus protocols existed.

As a hat tip to those brilliant minds that first started dreaming about complex, self-organizing systems, at a time when even the computer was in many senses just theoretical, we decided upon a naming scheme for the colonyNetwork based upon a particularly compelling system: John Conway’s Game of Life.

glider is our first release, because it's the simplest and smallest of the elementary spaceships found in the Game of Life.

After glider has been deployed on mainnet, we'll be getting straight to work on improvements, and working towards the lightweight-spaceship.

Another fun parallel between the Game of Life and the EVM is that they are both Universal Turing machines.*

*yes, yes, there are many many people who have weighed in to say that the EVM is not, in fact, turing-complete.

If you feel like you need to point this out to us, it’s a sign that you are very smart, but have too much time on your hands. Why not put that brain to work finding some bugs in the glider release?

This is the first system we feel meets our exceptionally high standards for mainnet deployment. Still, we are going to be the first to point out that glider is not a full implementation of the comprehensive system described in our whitepaper.

So what does it do?

• The Reputation system
• Meta Colony and the CLNY Token
• Colony funding and rewards
• Single-level domains
• Payments and Tasks
• Work ratings
• Roles and domain-level permissions
• Contract upgradability and recovery
• ENS integration
• Extensions

On mainnet, you’ll be able to create a new colony, import or create your colony’s internal token, and get straight to work creating tasks, payments, and organizing them into (single level) domains.

Reputation, for glider, is passive- meaning that it records contributions faithfully, and is used to proportionally distribute rewards. But the question of "who has the authority to do X in Y domain?" is handled by our modular permissions and roles, rather than reputation. You can read more about the roles and modular permissions in our latest quarterly update, or in the docs.

Get into glider-rc.1

Ready to roll up your sleeves and build with colony? Fantastic. Here’s what you need to know:

We have chosen to deploy glider-rc.1 on the Görli testnet, primarily because it supports both parity and geth clients. Also, we have a soft spot for our friends at ETHBerlin, where Görli was born.

To connect to Görli, you’re going to need a few pieces of information:

ColonyNetwork address: 0x79073fc2117dD054FCEdaCad1E7018C9CbE3ec0B ColonyNetwork commit: 41b2e0b429c03d1011e1a96506dcbfe504391f2d ColonyToken commit: 59cf56f18c54c0bc749ddaa8b6d77ebfd0d0aaf4

For poking around with the contracts, this is really all you need. Use truffle, remix, or your preferred development framework to interact with the colonyNetwork or your colony.

At a minimum, you’ll need to compile and instantiate the interfaces you need (likely IColonyNetwork.sol and IColony.sol), as well as your token contract, and any dependencies.

Have a look at our get started section for more detailed instructions.

You want to do more, you say. Full-fledged dapp development on top of the colonyNetwork, you say. To shreds, you say…

Good news, everyone! The latest release works with the Glider deployment, which can be quickly set up using the colonyStarter, which contains boilerplates and examples for your project.

Hack the planet.

Colony builds tools for organizing and incentivizing teams, communities, and contributors. Join the discussion on Discourse, follow us on Twitter, sign up for (occasional) email updates, or if you’re feeling old-skool, drop us an email.

Originally published at https://blog.colony.io on May 24, 2019.

Introducing Glider was originally published in Colony on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Colony, we use the OKR method for setting quarterly goals and keeping our distributed team of 20 in sync and accountable. Below is our quarterly report on Q1 2019 and a look ahead at Q2 2019.

Recently we passed the important milestone of being about two weeks ™ away from being all squared away for main-net launch.

But first, a retrospective:

À tout à l’heure, Q1

Q1 was very much about refinement of our product and processes. We gave our smart contracts superpowers, created a new team, and made some big strides toward the release of our fully decentralized dapp.

Modularity FTW

From the beginning, we have known that there are many use cases for Colony, not all of which are DAOs, or even organisations in any recognizable sense. Yet, when we talk about Colony, we usually only talk about the use case detailed in the whitepaper: DAOs.

We have always intended Colony to be broadly inclusive and capable of supporting a wide variety of use cases. Our public communication has alluded to our broader mission, but we have been light on the details.

Internally, our product development processes have focused on the DAO use case. Our supposition has been that as this is the most ambitious manifestation of the Colony vision, support for other, simpler use cases would be a natural consequence of developing the more complicated thing.

If there is one thing we’ve learned through our customer discovery work, it’s that every organisation is different. They all have subtle nuances in how they want to work. It has become clear that we must be intentional and explicit in designing, building, and positioning Colony as an inclusive, coherent platform in which all types of users are treated as first class citizens. If we try to force people to adhere to a single, prescriptive organizational methodology, we will alienate them. Colony should be flexible and modular, allowing people to organize themselves in ways that make sense to them.

At the same time, there are very real practical and technical limitations about what is possible, or desirable. It is not in our interests to allow users to create colonies which won’t work well, or come at the cost of heightened security risk. Our job is to provide well thought out design choices for the most popular use cases, and sensible degrees of customisation where appropriate.

Whether you’re a musician who wants to harness the passion of your fanbase, a startup that wants to meritocratically split ownership between its founders, a thieves guild in a virtual world which needs to trustlessly manage the risk (or reward) of theft, or an Ethereum based project that wants to devolve binding on-chain governance to its token holders; Colony provides the tools you need to organize and incentivize your team, community, or contributors.

Colony should be lightweight enough for an app developer to incentivize freelance marketers to grow sales with a share of revenue, powerful enough for thousands of strangers around the world to collectively execute on an open source project, and flexible enough that the former can seamlessly evolve into the latter if that’s what makes sense.

With that in mind, two major improvements have been made to the colonyNetwork codebase. Together they create a new, more flexible, modular core upon which the future of the firm will be built.

Modular Payments

In earlier versions of the network, the only mechanism by which a colony’s funds could be transferred to a recipient address, was the method. The task is a richly featured mechanism for a colony to make payments to its members. It makes specific consideration of negotiating and compensating discrete units of work in low trust, pseudonymous contexts. Given the rich functionality contained within the task, we anticipated that clever frontend trickery would be make it possible to hide most of this workflow behind a shiny UI in simpler, or more trustful contexts.

We realized however, that in order to provide the flexibility we envisaged, it was necessary to be more intentional in our protocol design. The solution was to flip the script and build more powerful functionality out of simple modules, instead of abstracting simpler functionality from a more monolithic contract. Consequently, colonyNetwork now includes the all new slim and sylphlike payment method.

payment contains just the bare bones required to send funds from a colony to an external address. Features like the funds for a payment being escrowed, and release of the payment being subject to performance review, may be "plugged in" using smart contract extensions to create more sophisticated capabilities.

In the spirit of Reid Hoffman, we’re launching our dapp’s mainnet beta with just the bare bones payment plugged into an extension that bundles all its four required transactions into a single click. That requires a colony's members to fully trust the admins of the colony they're contributing to, but based on our customer discovery work, this minimal functionality appears to be sufficient to enable experimentation in a small subset of use cases.

Modular Permissions

The big tl;dr is that we are adding support for a number of permission classes at the domain level. Each permission class captures some related and complementary bundle of functionality. Here are the following permissions, each granted to an account for a particular domain in the Colony.

Funding 💰

• Able to move funds within arbitrary pots in the domain.

Administration 👔

• Able to manipulate payments (tasks) in their domain.
• Able to raise disputes.

Arbitration ⚖️

• Able to resolve disputes in their domain (i.e. change arbitrary state).
• Able to set the escrow period.

Architecture 🏗

• Able to create subdomains.
• Able to manage permissions in subdomains (but not the domain itself).

Root 🌳

• Modify Colony-wide parameters.
• Upgrade the Colony.
• Manage permissions in root domain.

This division was meant to strike a balance between flexibility and structure. By grouping sets of related functionality into “permission classes” we make permissions more intuitive and fun to approach. These few permission classes allow for a wide range of behaviors, using modules to provide mediating layers between users and the underlying permissions.

We envision that the contracts maintain a list of addresses that have the permission in question, and that every address in that list has the full permission; no additional restrictions exist at the protocol level. However, if that address refers to a contract, then that contract can define internal rules through which it takes those actions and thus mediate between the human and the colony.

For example, every Administrator has the ability to raise disputes, but there could be a contract that will only raise disputes on behalf of a user who supplies a stake and a reputation proof. If a permission is assigned to a “multi-sig” type contract, it would only take the actions if the majority requirements are met. If the permission is assigned to an ordinary account, the owner of the account can freely and without restriction take all the actions that require this permission.

Thus permissions may be held by contracts as well as accounts, and these contracts can implement arbitrary logic. For example, we expect to implement a RepFundingQueue.sol contract which performs reputation-weighted funding as described in the Colony Whitepaper Section 8.2. A Colony can give this account Funding permissions in the root domain and provide exactly the funding functionality described in the Whitepaper.

Alternatively, a Colony could implement a FundingMultisig.sol contract, assign a number of accounts to this multisig, and incorporate logic around periodic transfer limits. In this case, individual accounts could allocate up to X tokens per period unilaterally, and propose larger transfers conditional on some vote of the accounts.

Alternatively, a Colony could grant an individual user address full Funding permissions in a subdomain and allow this user autonomy with the funds allocated to that domain, conditional on funding being distributed via other mechanisms higher up the domain tree (perhaps using a BudgetBox).

In the case of the Administration permission, we could abstract the Payment creation behind a reputation/stake anti-spam mechanism as described in the Whitepaper. Alternatively, a Colony which preferred a concept of discrete “membership” could assign all members the Administration permission to enable them to manage payments with less friction.

The Architecture, Arbitration, and Root permissions are more powerful and we expect they will be assigned to a small number of trusted accounts, or to contracts which implement additional logic (such as a RepDispute.sol which implements the dispute functionality described in the WP Section 9). A Colony wishing to go "full rep" would assign these permissions to contracts implementing the appropriate decision-making mechanisms.

The idea here is that by dividing up permissions in this way, various roles will be able to “check and balance” each other. For example, accounts with the Administration permission can scope out and manage work, but will not be able to get anything done without support of an account with the Funding permission. Multiple permissions may be assigned to the same account. If I want to start a Colony and run things unilaterally, I can just give myself all the permissions. The Power is Yours (until you assign it to a reputation-weighted voting contract).

When you create your own colony, tell us (@DevRel) how you set up your domains/permissions!

“Look ma, no server!”

Okay, so we missed our first launch estimate. After re-grouping, drinking a few hundred strong cups of coffee/tea, we re-assessed exactly what needs to be done, and how long each issue will take.

After the last sprint meeting, the consensus from #dev is that things are now humming along with the dapp and the light is visible at the end of the tunnel.

“‘Things’? What ‘ things ‘? What have you all been doing? When can I try the dapp? WAI U NO MOON?” you might be wondering.

Here are some highlights from the dapp team:

OrbitDB gets some features

OrbitDB is our chosen solution to square a circular problem: We need to keep a store of a lot of different types of user data, and in order to qualify as being ‘fully decentralized’, that data has to exist and remain available on a distributed network.

OrbitDB allows us to have database-like records kept on IPFS, eliminating the need for any server-client architecture.

Our boy in Brazil, Thiago, has been crushing it with the colony fork of OrbitDB. So much so, that they’ve merged some of his work into their main (open source) repo. Yaaaaaay cross-team collaboration!

To learn more about OrbitDB check out their GitHub.

Wiring

Any changes made to the colonyNetwork have cascading effects upwards through the Colony stack. Any new methods or workflows need to be reflected in colonyJS, which affects how the buttons and components built into the dapp do their thing.

This work is largely referred to by the dapp team as “wiring”- it’s not particularly challenging in theory, but in practice wiring dapp components has been and will continue to be the big main push for the dapp team.

Now that all the final changes to the colonyNetwork have been merged, the total amount of wiring is finite and known, which means all it needs now is a little bit of elbow grease.

One fully decentralized dapp, comin’ right up.

User testing is a core part of our design process at Colony. It helps us make the correct product decisions and find usability issues before we even launch our product. This quarter we were able to test our user onboarding and find some crucial user experience improvements.

Now our onboarding has a heavier emphasis on creating your first colony, setting up an internal token, and funding your colony to start creating payments. We’ve also added an invite link to invite your community to start contributing to your project. We found that these improvements made it much quicker for users to set up their colony and start getting real work done.

Introducing DevRel

At Colony, we constantly work to improve and refine our organizational processes. It both helps inform what we’re building, and ensures our internal communications and project management remain lean and focused.

Q1 saw the emergence of a new domain by the name of #DevRel (or, “Developer Relations” for those of you not hip to the lingo of Silicon Valley) in the Collectively Intelligent Ltd. colony- Yes, this is a thing, and it’s pretty important to us, as well as many other startups in the Ethereum Ecosystem.

DevRel’s remit is to enable a good developer experience, and to foster and support a good developer community.

So, if you have questions about the docs, a project that you might be considering using colony to build, or just ran into an infuriating error message when trying to integrate colonyJS with your existing project, these are the people to talk to:

Auryn — @auryn_macmillan

As always, the best place for developers to hang out is build.colony.io, our Discourse instance. Come post your questions, project ideas, or feature requests!

We went to some events!

Paris (EthCC + ETHParis)

A few of the team made it out for Paris blockchain week, which was the marriage of a stimulating and engaging conference and a really cool hackathon.

@gichiba (Griffin) led a workshop (no video :/), and @kronosapiens (Daniel) gave a talk:

Oh, and if you’re into this sort of thing, there was also episode #3 of the Griff Riff — a recurring live-cast from all the Griffs in crypto: Griff Green, Austin Griffith, and me (Griffin).

RadicalXChange

Two of the Colony team members ventured outside of the blockchain space for a weekend to attend the inaugural RadicalxChange conference in Detroit, Michigan. @kronosapiens split sides and opened minds with his BudgetBox presentation, while @auryn_macmillan meandered around shaking hands and soaking up content. Both left the conference invigorated by the richness of diversity, ideas, and action plans geared towards creating a better world; faith in humanity at least partially restored.

Game on, Q2

Well, we’re ready. This is going to be the quarter for Colony.

Bug Bounty Redux

One of the more important pieces of prep for launch is the re-invigoration of our Bug Bounty Program.

The “staging” version of the colonyNetwork mainnet release will be on Rinkeby this week.

Any bugs found on this deployment will be rewarded handsomely — because any bug found within the next 2 weeks (TM) is a bug prevented from going to main-net.

The same rules still apply, but we implore you, solidity developers, spend a day attacking the Rinkeby deployment!

docs.colony.io/colonynetwork/bug-bounty-program-overview/

Dapp Testing

A handful of teams and projects is much easier to learn from than a vast sea of anonymous users.

Also, it’s exceptionally hard to get the normal user feedback tools like hotjar to run in a decentralized context.

So, we’ll be opening up Colony Contribute to the largest group of beta testers that we can reasonably learn from (read: only a hand-full of teams/projects who have promised to give us great feedback).

If you really, really want to be part of this group, send a message to Auryn. But be advised that there’s a good chance he’ll need to give you the cold shoulder; don’t take it personally.

Colony builds tools for organizing and incentivizing teams, communities, and contributors. Join the discussion on Discourse, follow us on Twitter, sign up for (occasional) email updates, or if you’re feeling old-skool, drop us an email.

Originally published at https://blog.colony.io on April 29, 2019.

Q2 2019 Update was originally published in Colony on Medium, where people are continuing the conversation by highlighting and responding to this story.

We just got back from ETHDenver, Colorado’s “full crypto” conference — and one of our favorite events ever to have attended in the Ethereum space.

There was a lot going on at ETHDenver, but a few broad trends really came out over the weekend.

UX improvement is critical for Ethereum

One of the most important areas of development for Ethereum right now has nothing to do with Ethereum 2.0, eWASM, or anything else on the bleeding edge of the tech side.

It was good ol’ fashioned user experience.

And boy, progress has been made. Here’s what makes me think that the next big leap in Ethereum adoption is going to come from the UX/Design domain:

Food trucks @ETHDenver led the way for real-world usability

This was the first conference I’ve attended where we ate our own dogfood — Well, we ate a wide variety of delicious food from around Colorado: tacos, sushi, pizza, gyros, and ice cream — but we paid for that food using crypto!

https://medium.com/gitcoin/burner-wallet-at-ethdenver-was-faa3851ea833

Each attendee was given a small (physical) token that instantiated a burner wallet filled with $40.00 worth of “Colorado Coin”. Using QR codes printed on the sides of the trucks, attendees were able to purchase what they wanted, or send their extra coin to other attendees.

One moment really illustrated how far we’ve come from a user onboarding perspective: I watched as a confused customer handed his phone over to the food truck operator, who showed him how to buy food using the burner wallet. Think about that for a second: The process was simple enough (and designed well enough), that a small business owner felt confident enough to walk a customer through the process of using crypto to buy a gyro.

I would be remiss not to give due credit to one Austin Griffith, who ran the Buffcoin show and made sure things ran super smooth over the course of the event. Well done, Austin!

User on-boarding for ‘non-crypto’ transactions

Another thread in the same category is the number of projects in the hackathon who focused on making a first transaction as simple as possible.

A newcomer to Ethereum won’t have Ether. They won’t want to take the time to understand what a private key is and what steps they need to take to secure it. They certainly aren’t going to even try to understand what ‘gas’ is and where that money goes.

Taylor from MyCrypto said it best in her presentation:

Users are expecting the same simplicity from web3 that they currently experience with web2.

Talk to PEOPLE.
Build for PEOPLE.
Talk to more PEOPLE.
React to how PEOPLE use your product.
Save PEOPLE from themselves.

For the first time at an event like this, I saw a number of projects integrating with services like Portis and Fortmatic (who put up bounties for integration, FYI), which allow users to pay for their first transactions using only a phone number and a credit card.

This might go against some of the stronger “decentralization maximalist” sentiments in the Ethereum community, but we have to be real: It’s these kinds of “trusty” integrations that are enabling mainstream adoption, and they need to be embraced by more projects if we want adoption to continue.

As we continue to develop our products, we need to remember many, many PEOPLE might see bugs when we (the core Ethereum fans) see features.

We at Colony have been thinking along these lines more and more, and that’s one of the reasons we’ve chosen to roll out a one-transaction payment method for developers integrating with our platform.

Even though it side-steps some of the game-theoretic security built into a task transaction workflow, making a direct payment with reputation gain without a multi-sig approval process is something that PEOPLE have asked for, and we are building for them!

Developer Experience matters

This is my main takeaway from ETHDenver: In many senses, the whole Ethereum community is still in the middle of a massive period of bootstrapping. We’re building (or #buidling) some things that enable us to build more things that enable us to build all the things.

EthDevTools

The project that illustrates this particularly well was built in the hackathon: EthDevTools.

https://kauri.io/article/03a1ce4d66aa47e2a935f7d65f936371/eth-dev-tools

The concept was simple enough: It’s the web3 analog to the Chrome dev tools. As a chrome extension, it will show transactions, contract ABIs, logs, and a GraphQL explorer.

When concluding the presentation, Billy Rennekamp (@okwme) said something that made me clap:

“This should have been around from the very beginning.”

So much in Ethereum development right now is “roll your own” that many projects end up building different implementations of the same functional tool, or similar (yet incompatible) approaches to the same problem (like debugging and ABI generation).

Projects like ETHdevtools may not be as sexy as token-curated registries or decentralized carbon offsetting, but they are going to have a huge positive impact on the lives of developers who are building those (sexy) things right now.

Open Source enables a better developer experience

At Colony, we do our best to, whenever possible, open-source the tools we build (from scratch) in order to save other developers from having to re-do our work:

We still need to improve on getting our tools out there faster, with better documentation and examples — but we are keeping our commitment to contributing and maintaining open-source tools and infrastructure for the broader Ethereum development community.

Speaking of those open-source tools, we are super proud of Ryan and Scott, who made major progress on a command line tool for generating javascript libraries on-the-fly — and won the Infura prize for their work!

The final thing I noticed at ETHDenver was the number and quality of projects that submitted along the impact track for the hackathon.

This was also the first Ethereum conference (to my knowledge) that officially partnered with UNESCO:

Key highlights at @EthereumDenver. @UNICEF share key initiatives + what’s coming: #boosttoken | #impacttrack | #collaboration with @Ethereum Foundation. Find out more via @Newsweek ➡️ https://t.co/Kzm3AtLBjJ.@hichrisfabian @mi_ayako @crlomazzo @ETHGlobal @EthereumFog pic.twitter.com/TNM9JKeOBn

- UNICEF Innovation (@UNICEFinnovate) February 20, 2019

The impact-focused hackathon projects are important. The people working on them are proving to the world that blockchain technology is not just a buzzword, but something of great potential for NGOs, non-profits, and larger impact initiatives, like the Sustainable Development Goals.

I anticipate we’ll continue to see more interest and involvement in the Ethereum ecosystem for projects that not only focus on cutting-edge technology, but on solving real-world problems.

Focus on impact was one of my personal favorite highlights from the Colony Hackathon last year, and we’re going to take that into consideration in planning this year’s hackathon model. (stay tuned).

This is too good not to re-post:

Originally published at https://blog.colony.io on February 23, 2019.

The Spirit of the Bufficorn was originally published in Colony on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Colony, we use the OKR method for setting quarterly goals and keeping our distributed team of 20 in sync and accountable. Below is our quarterly report on 2018 and a look ahead at Q1 2019.

Touché, Q4

These updates are written to provide a clear and honest reflection of the work that we do. Our update post has taken longer to write (it’s well into February) because this time ‘round, we’ve got a lot to reflect on.

Let’s start with the big, obvious thing: If you saw us at DevCon in Prague this year, you might have heard us say something along the lines of *”we’re working hard with a target to release before the end of the year.*

We didn’t hit that goal. So it goes*.

It’s ok to fail, but only if we learn something from it. And we’ve learned quite a few things from missing our aggressive release target.

*For avoidance of doubt: Colony has not pulled a Metroid Prime 4 — we’re not starting again from scratch or anything like that; bulding a dapp that is decentralized, distributed, and trustless end-to-end is just harder than we initially expected. The devops groundhog saw her shadow, and it’ll be at least 6 more weeks of development.

Learning #1: The off-chain world is more important than we previously estimated.

Dapps are hard. Really hard. One of the big challenges we took on with our dApp is “full” decentralization. That means no compromises. Everything in our stack, from UI components down to smart contracts must, in principle, function without relying on any component or service that’s hosted, owned, or otherwise ‘centralized’.

Not a lot of people realize what a big deal this is.

With smart contracts, in some senses we get decentralization for free. All the ‘consensus-relevant’ stuff runs on the EVM, which is as secure and decentralized as the blockchain it lives inside. Creating a secure, efficient system of smart contracts is certainly not a trivial task, but it’s only part of the whole.

There is an entire world of work to be done off the chain in the form of basic interfaces for blockchain interaction and integrations — Robust and secure smart contracts are necessary for the success of any Ethereum project, but they are not sufficient.

Ultimately, whatever benefits a smart contract brings a user will be mediated by that user’s ability to access and manipulate the smart contracts. Dapps are meant to bridge a smart contract and a human, but right now that divide is still large.

The Ethereum developer community has been at it for a while, and there are so many brilliant efforts toward what is largely a unified goal: Mainstream adoption and acceptance by real users. But there’s still a lot of work to be done to close that gap.

UX/UI, a distributed user database, multi-signature transaction workflows — there are a number of very fundamental interactions *off-chain* that are largely un-charted territory. If a user’s data is out there on the decentralized web (IPFS), how do we make sure it remains available and secure for that user? How do we onboard new users that might not have any Ether or be “hip to the blockchain”?

These are some of the major hurdles that we confronted last quarter, and it resulted in a lot of careful and deliberate designing, on both back and front ends. Because, as we said, this is all un-charted territory. No one has built a dapp to this standard before, and these things take time.

Learning #2: Secure the Network

Our network team might be mad at me for seemingly representing the dapp work as more important than the smart contracts. Quite the contrary!

We strive to set the bar for robust testing and best-practices when it comes to our deepest layer. The colonyNetwork contracts comprise over 6000 lines of well-tested solidity (395 tests, to be exact, with over 90% code coverage)

Shameles plug:
If you’re a solidity developer looking to hack on some advanced contracts, we are still accepting submissions! Secure the Network and make some $DAI in the process
</shamelessplug>

Last quarter we launched our Bug Bounty Program, and have to-date paid out $3600 in bounties to open-source contributors who submitted valid issues.

There were bugs alright, and we are continuing to optimize and improve the Colony Network with your help.

Learning #3: Research is important

Although it’s crucial sometimes to focus exclusively on the here and now challenges, we put a high value on theory and more forward-looking work. While we have made steady progress on the dapp, one of our big accomplishments last quarter was the creation of a new crypto-economic primitive! Eat your heart out, TCRs and Bonding Curves.

In London this winter, a few members of the Colony research team convened for a ‘research sprint’ to discuss possible mechanisms for perpetual self-improvement of the Meta-Colony.

https://blog.colony.io/introducing-budgetbox/

What resulted from that week was pretty nifty pattern we call BudgetBox

@joincolony Budgetbox is one of the most creative governance proposals I’ve seen. It replicates a sports championship, where instead of votes each proposal get many 1:1 comparisons and then they move up or down in their “league” depending on how they fare. https://t.co/12w7vAcHHl

- alex van de sande (@avsa) January 18, 2019

TL;DR — BudgetBox is a proposed mechanism for allocating a budget in a decentralized context. Instead of creating a ranking or other arbitrary method of deciding “this much money goes to this recipient”, budgetbox builds a budget directly from a large set of pairwise preferences (“I think this initiative is better than that one”).

We’ve gotten a lot of good feedback on the paper, and we welcome anyone who wants to discuss or experiment with our solidity implementation to reach out to krono@colony.io .

En Guarde, Q1

As we have said many times: dapps are hard. This quarter, we’re working on overcoming a few major challenges that need to be solved before the colony reference client meets our exceptionally high standards.

UX and onboarding

One major piece of work we’ve been fixated on is user onboarding and UX.

We want interacting with our smart contracts to be simple. Dead. Simple. That’s a huge ask considering that users will need to perform multiple transactions on-chain as they interact with Colony. So we came up with a concept we call the ‘gas station’ for grouped and multisig transactions.

The Colony gas station is a way of displaying all the need-to-know information about your dapp interactions that are bound for the blockchain in a human-readable context, and more importantly making the multi-signature transaction workflow smooth and simple. Rather than popping up and asking you to sign and broadcast transactions as they happen, the gas station saves all your interactions as unbroadcasted ‘pending’ transactions, ready to be signed and committed to the public record.

All transactions ready to be signed and sent to the blockchain are grouped together by category, so that they can be sent at once or queued for later. Instead of seeing a contract address, you’ll get a descriptive title of what you’re doing, how much the transaction will cost, and whether or not that transaction requires another’s signature to be finalized.

TL;DR: Colony’s gas station makes using Ethereum multi-sig transactions easier to understand, and reasonable for normal people.

ENS support

Colony is made for people (although robots are welcome, too). People have a hard time remembering phone numbers, let alone long strings of hexidecimal.

Well good news, everyone! Through the magic of ENS sub-domains, your Colony will, at launch, be able to claim a nice, friendly human-readable name *without* needing to go through all that commit/reveal hubbub associated with top-level domains.

When you create a colony with the dapp, you will have the option to register `mycoolcolony.joincolony.eth` — and it’ll just work. If you don’t want the .joincolony.eth TLD, you can also configure your own ENS domain to work with a newly created colony.

Pinion and OrbitDB

Every dapp needs to have some kinda database, because there’s a lot of important stuff that can’t be put on-chain. For example, profile pictures, comments associated with tasks, and other meta-data such as that is necessary for a good user experience, but totally impractical (and expensive) to put on chain. That would be crazy. Most dapps today are a kind of centralized/decentralized hybrid, where this meta-data is hosted on a server, but the *real* important “decentralized” center is, of course, on Ethereum.

That’s not good enough for us. Colony needs to be **truly decentralized**, meaning that even that meta-data should not depend on a central server or data store. It’s gotta live on a distributed network like IPFS. In the case of the Colony dapp, that system is built on top of (or forked from, to be more accurate) the OrbitDB project. This allows us to keep more complex data associated with a single Ethereum account on IPFS, as a structured database instead of an isolated file.

IPFS, however, by virtue of being a decentralized and distributed system, has some of its own quirks, which we needed to solve. For example, when some meta-data is put up on IPFS, it’ll only stay on a particular node for a finite time if it’s not requested by someone else on the network. When a user uploads a profile picture to the dapp, we want that picture to be *always* available, no matter how long the user waits.

Pinion solves this problem, by providing a ‘pinning service’, and making sure that at least one node on IPFS is up an serving the data that needs to be available, effectively ‘pinning’ it to the network, available for all users at all times. We’ll be open-sourcing pinion when we feel it’s polished enough for the prime-time.

Multi-signature transactions

You may have read Elena’s parameterized transaction reviews article, which was a deep dive into the solidity implementation of Colony’s multi-sig pattern.

The complete end-to-end lifecycle of a multi-sig transaction involves a lot of off-chain helper machinery, which brings the signed transaction from one user to another. The multi-sig transaction workflow touches almost every aspect of the Colony stack.

There’s a lot going on here — too much to fit into this post, but expect a full-blown technical post that dives into an end-to-end multisig transaction, and how it plays out, both on-chain and from the perspective of a user.

Integrate Colony into your App

Developer experience matters. One thing we’ve worked on already is making integrations with Colony as simple as possible for dapp developers and projects that want to use Colony for their governance layer.

The ColonyJS docs have been massively improved, and now detail exactly how to bring in all Colony methods to your application for simple integration.

We’ve added a new payments function to the colonyNetwork contracts. This is to enable a Colony to make payments without requiring the signature of the person getting paid. This might be useful for cases in which you want to create incentives or rewards that happen after the work has taken place.

Finally, the colonyStarter has also been revamped and improved. If you’re wondering how to integrate colony into a JS or react-based front end, you can see tons of examples within the colony-starter-basic and colony-starter-react packages. Just yarn and go!

Meet us in person!

ETHCC / ETHParis — Our own Daniel Kronovet will be giving a talk on budgetbox at EthCC, and more than a few team members will be attending both ETHCC and ETHParis. Magnifique!

Colony builds tools for organizing and incentivizing teams, projects, and communities. Join the discussion on Discourse, follow us on Twitter, sign up for (occasional) email updates, or if you’re feeling old-skool, drop us an email.

RadicalxChange — And right after Paris, a few (or maybe just one) Coloneer will be headed to Detroit to present BudgetBox.

Originally published at https://blog.colony.io on February 20, 2019.

Q1 2019 Update was originally published in Colony on Medium, where people are continuing the conversation by highlighting and responding to this story.