Clarify access control strategy/roadmap for creating tasks?



Hi. There is something about the access control for creating tasks in a colony that I don’t understand. Can you clarify the current operation as well a the roadmap/plan for future extensions?

Right now it seems that anyone with an Ethereum address will be able to create a proposed task within a colony, correct? That seems like it would open up a colony to potentially crippling DDoS/Spam problems. If there are controls on creating tasks can you please explain how they work?

Personally, I think it will be essential to add access control related to task creation. I would suggest these types of layers:

  • Determining whether a colony is private (restricted to registered users) or public
  • At a minimum, allow an option for administrators to be able to approve potential tasks before they become visible to colony users
  • In the future, develop a more robust and flexible control structure that could allow for different ways for tasks to be approved (e.g. N-users voting, sufficient staking of backing tokens from existing users, administrator approval, etc)

Thank you for commenting on the current offering and plans in this area.


Hey @bmiller59, take a look at our Authority docs page, it explains how permissions work within a colony.

tl;dr, accounts must be added as an Admin to be able to create (and fund) tasks.


Thanks for the quick clarification. This is a very centralized strategy and seems counter to the decentralized intent of Colony. Shouldn’t there be decentralization within a colony as well?

Is there any plan to separate some the admin permissions into more roles for greater flexibility? It seems that a variety of the permissions assigned to the Founders role would be better allocated to the Admin role, and a new role created called “User” or “Member,” for example, so that a wider base of people could create tasks as well.



We are still working towards the model in our whitepaper that assigns influence and permissions via reputation scores. We still have some work to do to get there, though.

We have considered a role of “member” but don’t have plans to implement it yet. If we heard from more users that this was desired we could always build that in.

What use case do you have? In an ideal case, what roles would you want and what permissions would they have?

Another way we’ve thought about this is by allowing anyone (or ‘members’) to be able to suggest tasks that other users could upvote/downvote and admins could approve. Thoughts on that as a model?


I am hoping that Colony can be the foundation for a distributed alternative to things like Facebook Groups, but augmented with the ability to pay people and track reputation over time, etc.

I imagine a world in which it is as easy for a user to create a new colony as it is to create a new Facebook Group now.

Once, created, I imagine that the focus on organic growth and decentralization also applies WITHIN the colony as well.

Here is how it might work:

  • A user creates a new colony with a public description announcing its mission and goals. This person invites other to join them in that mission.
  • Other people see the colony description and request membership. They would submit their 3box profile (with necessary private details disclosed) and a statement of interest.
  • Approval of new members could happen one of two ways. An admin could approve them. Or, my preferred, decentralized way to approve them would be by some number N of existing users voting for them to be able to join and become a member.
  • Members would be able to stay active members unless their reputation dropped below a certain threshold set by admins.

So bottom line, I do think a member level of permission would be helpful to support colonies who also desire to operate themselves internally in a decentralized way.


Hey @bmiller59! As Collin mentioned above, permissions via reputation score is the intended direction, which is outlined in the whitepaper but not yet implemented in the current version of the colonyNetwork contracts. We are also considering the option to choose between assigned permissions (the current version) and permissions via reputation scores (the model outlined in the whitepaper).

I really like the idea of having a third “member” role included in the authority roles for a colony, which currently only has two roles (“founder” and “admin”) but I am still confused about what the permissions of a member would be in relation to the roles that already exist.

In your use case, what permissions would the “member” role have? How might the permissions of the “founder” and “admin” roles be different if a “member” role was added?

Also, feel free to add a description of your feature request for a “member” role to the #features category, which will help us better track the request and make it easier to find for others thinking about features.


Hey Ryan and Collin. Reputation score might be an acceptable solution, but there are many nuances to consider. The main one I have concerns about is fairness/openness to new members. I don’t want to unnecessary create hierarchies and gatekeepers in my colonies. Will new members be able to make new tasks, or will they need to wait months/years before being able to be heard/empowered? If you use a reputation system i think it will be important to let the administrators of different colonies “tune” the stringency with how the reputation is used to be more or less restrictive.

You asked about a “member” role and how it might fit in. Using the existing authority chart, the main change that I consider important is to allow “Create Task” to be possible by a member, not just an administrator.

The logic is that the rest of the admin role permissions can dramatically affect the structure and operation of a colony, but creating tasks is the “bread and butter” of the colony and should be much more accessible.

While you consider whether member is something you want to add, I am in parallel going to think about how to leverage an off-chain discussion platform, linked and validated by ethereum addresses tied to Colony, to create the openness in process and decision-making I desire without changing the existing Colony permissions. It may be possible with a supplemental smart contract or two…I am not sure yet but will keep you posted.


With the current implementation of the contracts, only the “founder” and “admin” roles can create tasks. Anyone can request to work on any task within any colony but they will not be assigned as the worker of the task until the manager of the task has approved their request. If anyone was able to create a new task, this would open up the possibility for anyone to spam the colony.

In the current implementation, your idea for a “member” role would allow delegated users to create tasks but they would not have permission to add a new domain or move funds between pots like the “admin”. I think this would be a nice feature request in relation to the current implementation we have using permissions and I think it would be another tier to consider when we implement the ability to set permissions via reputation scores.

Another option would be to build out a way for users to submit proposals for tasks without actually creating the tasks, in which the proposals would need to be approved by an “admin” before the transaction for creating a task is executed on the network. This would allow anyone to create task proposals while preventing bad actors from spamming colonies with new tasks. This is something you could build with the current implementation.

In the current implementation, the time it would take to gain permission to create a task would depend on how long it takes to be granted “admin” permissions, i.e. how long it takes to be trusted with “admin” permissions. As mentioned above, you could create a task proposal mechanism with the current implementation.

In the future implementation, the time it would take to gain permission to create a task would depend on how much reputation a user has earned through contributions and what the reputation threshold is for the equivalent of the current “admin” permissions. In the future implementation, it might also be possible to set the reputation threshold for individual actions such as creating a task.


This is a great idea! Colony is not trying to be the solution for everything but rather something you can easily integrate into existing workflows or alongside new workflows. Definitely keep us posted!