Bounties are a great way to incentivize contributions to projects, but they impart significant cognitive overhead and coordination cost on the issuer of the bounty. For Decentralized Autonomous Organizations to provide a fairer, more open and inclusive Future of Work, we’ll need more flexible ways to coordinate and contribute.
Designing a protocol for organizations is a different sort of game than designing organizations themselves. Organizations come in all shapes and sizes, and often are held together by just a shared set of values, or perhaps by a finely-crafted business plan.
Organization protocols however, involve deeper thinking, and more generic planning. We’ve got to think about the rules that are able to capture the complete organizational possibility space, so that a wide variety of structures and arrangements can work within the same framework.
Colony is meant to be as general as possible; allowing the widest variety of use cases able to run on top of the same smart contract backbone, perhaps with the aid of UI/UX or other front-end abstractions built with help from the up-coming ColonyJS library.
The task method in the Colony Protocol has enough flexibility to be used in many possible ways, from one-off jobs with a single deliverable to long-term salaries with equity bonuses.
This leads us to an important point worth stressing about Colony:
Colony is a governance protocol. Bounties are just a stepping stone.
In Colony, the task is a functional component, not a use case. Tasks are used to mediate work generally, but can be used in arbitrary ways to achieve novel relationships within a decentralized organization. It’s really up to each colony’s members to decide how to arrange tasks that result in the relationships they want to have.
To illustrate this point, let’s look at a real-world colony example that uses the task element in different ways to create 3 unique organizational use cases. It’s worth noting that in these examples, we’ll explicitly highlight the use of the task element, but in practice this complexity would be hidden behind a snazzy front end.
Managing a plumbus factory with Colony
Everyone knows how plumbuses are made, but how do the workers organize themselves?
A plumbus factory run on Colony would have a native token (the Plumbus Token, or PT), and would be wholly owned and controlled by its workforce.
Members of the plumbus-factory colony make decisions and manage collective resources using the colony reputation system. This means that all decisions/disputes are made/resolved by members of the colony who have both PT and some amount of reputation.
Making a plumbus is not a simple process: you’ve got a fair amount of raw material inputs to acquire (dinglebops, schleem, fleeb juice), as well as several types of labor that may have different requirements of granularity or skill — all this work needs to be coordinated in order to make a regular ol’ plumbus.
Using reputation, domains, skills and the other elements described in the Colony whitepaper, here are some different patterns using the task element that the plumbus-factory colony might employ:
Tasks as bounties
During the plumbus assembly process, a Schlamy must show up to rub and spit on the dinglebop. In operational terms, this is generally freelance work, paid on a per-rub/spit basis.
Modeling a freelancer relationship in Colony is straightforward, as a single dinglebop rub/spit is an isolated task with a clear output:
In the example above, the bounty for the task is denominated in flerbos, as opposed to the native token of the plumbus-factory colony, PT. Taking a bounty in cold, hard flerbos means that the worker completes the task and they get a payment.
No native tokens transacted, no reputation awarded.
This is still great! It allows for maximum flexibility, and because the transaction is on the Ethereum blockchain, it’s trustless, secure, and instantaneous, which is a wicked improvement from traditional freelance work! Hooray for bounties using Ethereum!
But Colony can do more, and in fact the real use-cases begin to make sense only when reputation, domains, and tokens are included:
Tasks as Salaried work with Reputation
Blamphs, who do most of skilled labor, benefit from a long-term arrangement and a traditional salary. To model this using the task element, we would simply set the work specification as a salary:
Cutting away the fleeb is one of the most important parts of plumbus production, because of the several hizzards in the way. For this reason, Blamphs care about their reputation.
Reputational gains are mediated by the colony’s native token. When a task has a bounty denominated in PT, the worker paid by the task gains reputation equivalent to the number of tokens attached to the bounty.
In this case, the plumbus token is used by the Blamphs to keep track of seniority among all workers, who also receive a stable wage per contract. The longer a worker remains a fleeb-cutter, the more tokens that worker will accumulate. When a worker receives tokens for a completed contract, they also receive an equivalent amount of reputation.
Because reputation is the driver of action in a colony, this tasking arrangement entails that experience is what counts for influence in the Blamph domain. In day-to-day operations, the senior Blamphs will be able to direct shared funds faster, and in the event of a dispute or reputation-weighted vote, they will have more voting power. In other words, Blamphs earn the authority to set their own work. They don’t need a manager to do it for them, and the cognitive overhead and transaction cost of coordinating this work is dramatically reduced.
It’s important to note that if a Blamph wishes to maintain their standing in the plumbus-factory colony, they must complete work regularly, because reputation decays over time.
Complex tasks: Krombobulous Lin the headhunterKrombopulous Lin is an intergalactic headhunter (Oh boy, here I go recruiting again!).Her role within the plumbus-factory colony is to recruit new workers, and her value comes from being able to consistently deliver high quality workers to the firm. As such, Krombopulous Lin is offered a complicated arrangement of tasks with the plumbus-factory colony, in a domain created exclusively for her:
Let’s break this down.
Tasks 1–6 are structured as normal bounties. If Krombopulous Lin brings in workers who complete their own contracts, she gets a direct reward in flerbos. She’s totally fine to bring in a few workers, take her bounty, and move on to other headhunting.
But the plumbus-factory wants to incentivize K. Lin to do high-quality work, and to actually become invested in the plumbus-factory colony. The “meta-tasks” numbered 7–9 don’t award K. Lin any more money, but instead will give her reputation and tokens.
Because K. Lin exists in her own domain, her reputation isn’t really valuable for creating tasks, but her tokens and reputation together entitle her to a share of the colony rewards pot, as well as a say in colony-wide decisions.
Task 10 is an extra task created to mirror something like a working budget. By choosing to accept the challenge of delivering all 6 workers, K. Lin is committing herself to a significant amount of work, and she might need some flerbos up-front to get the job done.
Or, she could just spend them on AN ENTIRE AFTERNOON AT BLIPS ‘N CHITZ
Colony makes it easy for people all over the world to build organisations together, online.
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.
Griffin is a writer with a particular interest in Ethereum’s applications and promise for the developing world.
He has lived in Yangon, Myanmar for the last 5 years, and enjoys harrowing motorcycle journeys with a side of photography.
