Commons Swarm

Commons Swarm Working Group Manifesto

Working group lead: Griff

The Commons Swarm Working Group Manifesto is a live document, as the working group evolves (e.g. people join the working group, roadmap gets updated) this document should be updated to reflect these changes. This is important so that there is an updated single source of truth for onboarding new members to this group.

Griff is expected to keep the document up to date.


What goals would you like to achieve with this working group?

  1. To launch a test Gardens to allow the community to play with and better inform the final specification.

  2. To have a complete technical specification similar to this that defines the details around how the Gardens Template was deployed for all test deployments.

  3. Work with the tech team to deploy the TE Commons according to the feedback from the TEC Community from the TEC Tests. This

  4. To take the Specification and turn it into a technical playbook and reference manual for TE Commons Token Holders to easily understand how everything works.

  5. Work with other working groups to facilitate useful information sharing and avoid redundancy

  6. Make all the technical decisions required to get a healthy TE Commons off the ground!

The Tech Spec document is not necessarily telling 1hive what to deploy at each stage, but more communicating to those that inquire the most up to date information about what has been deployed.

The eventual TEC deployment will have had several rounds of informed feedback on it’s initial parameters and there will be a vote on at least 4 sets of parameters before the launch. After launch most of the parameters will be able to be changed by the TEC token holders after the Hatch if needed.

How will this working group benefit the TEC community according to its near term mission?

This group is foundational to the project. It defines the technical protocols we will use to govern and coordinate our public goods focused economy! While driving forward simultaneously, the comms wg relies on the tech spec to understand what to communicate and the soft gov wg relies on the tech spec to know what social protocols need to be in place to use the tech effectively. This in many eyes is the core work to be done to progress the near term mission, as it will define and document the design of the TE Commons Token Economy!

Success vs. Failure

What would be considered a success vs. failure?


  • Launch TE Commons Version 1.0 in December (with the exact scope yet to be defined) and everyone in the Commons feels comfortable engaging with the tech spec to understand how everything works under the hood.

  • New projects can use our tech spec to easily understand how the Gardens Template can be used to create a successful community economy and start using it to make their own Commons!


  • Too much focus on tech making the documentation not easy to read or accessible to many of the members, or the tech spec doesn’t match the final deployment, or the spec slows down the deployment, just for documentation, it should speed up deployment, not slow it down.


Please break down the goals into a roadmap with clear milestones

  1. ✅ Submit the Manifesto to the community

  2. Deploy a Gardens DAO on xDAI

    1. Take note of the parameters that are used… but just make best guesses for launch so we can get a taste of how it works

  3. Do a test Hatch with all participants of this group (make sure everyone gets tokens)

    1. Take note of the different parameters that are used, and if they can be better

  4. Start the bonding curve, have people from other working groups buy in

    1. Take note of the different parameters that are used,and if they can be better

  5. Vote on conviction voting with test tokens, find out the right parameters

    1. Take note of the different parameters that are used,and if they can be better

  6. Build designs for the Commons garden UI

  7. Develop a frontend to convert tokens using the bonding curve

  8. Propose the revised set of parameters to the rest of the community

  9. Deploy a test to xDAI that includes the Cultural Build Hatch and updated parameters

    1. Make how to guides and test all the parameters one more time for the Hatch, Bonding Curve and CV

  10. Integrate changes and deploy one more test deployment to test everything works as expected, and then deploy the real deal!

What is the deadline?

Late November!

The spec should document what we are launching before the launch so it can be passed to the technical participants so that they are informed about what we are doing and feel comfortable about joining.

Working Style

Define where sync is happening

telegram/discord/google docs/ calls

This document, that you are currently reading is the onboarding doc for the working group: Tech Spec Working Group Manifesto

Weekly sync calls happen with the entire TE Commons project on Thursday at 8pm Berlin time on jitsi:

  • We will schedule working calls as needed, no formal schedule

  • What is the pace of the work?

We work hard as we go, scheduling working sessions as need

  • What’s the format / framework / “language” used for articulating the specs? Is there some template or earlier work / best practices to follow? Where?

Documentation will likely start as google docs and then likely evolve into a set of medium posts… as determined by the Comms team.


Who are the members and what are their roles inside of the TEC? What is their availability

  • Sem - SME - 1Hive Dev / Commons Stack Dev

    • Gardens is my main project until December.

    • Timezone: Central European Time.

  • Rodrigo - SME - 1Hive Dev (mostly frontend work)

    • I am going to have bandwidth as far as 1hive other stuffs are not on fire ,

    • Timezone: UTC-3

  • Paulo - Contributor - Junior dev (Sort of a Full Stack profile. I have experience using Aragon framework and Aragon Connect )

    • 12 hours a week

    • Timezone: Berlin Time

  • Angela - Community Steward - TE requirements, application cases, launch Version 1.0

    • Timezone: Berlin time

  • Craig, Community Steward, Likely utility but more focused attention as needed

    • Min 4 hrs/wk, likely many more, PDT

  • Griff - Community Steward - This is my most important project… that said… i have too many projects! Probably 15 hours a week

    • I am very easy to reach async on telegram @griffgreen

    • Generally available from after 9pm Berlin time

  • Viviane, Contributor - FullStack Dev, I have some experience using the Aragon framework

    • Min 4 hours a week, but probably more :)

    • Timezone: São Paulo GMT-3

  • Santi, Contributor, Industrial and IT consulting

    • Min 4 hrs/wk, likely more, CET

  • Shawn, Contributor, Software Engineering, Data Science, Token Engineering, Documentation

    • PST: GMT-7 (Vancouver Canada)

    • Available for guidance and consulting in weekly community calls and work sessions

    • Additional 2 hours per week for coding, code reviews, documentation production, or github PM style work

    • Happy to lead teaching or explorative workshops, particularly in programming and data science

    • I have access to a team of engineers which can be mobilized for development

Last updated