# Gitcoin DAO Governance Process v1

*see v0 details here

This document is a suggested process for developing and advancing Gitcoin Community dynamics, governance flows and everything that comes with it. It is a living document intended to be owned, modified, and enforced by stewards as well as the overall community.

The post is intended to anchor and kickstart discussion around the different roles, flows and pathways so that we may ensure the effective and smooth operation of everything we do in this community. We’ll move this over to get ratified after five days of (hopefully) great additions and discussions.

*Please note that if you have support questions, our Discord here is the place to ask, comments not related to the proposal in this thread will be removed.

Join the Gitcoin Discord Server!

Governance Roles

There are three main roles in Gitcoin governance: stewards, delegates, and contributors.

Becoming a steward: Getting involved in a steward is easy, anyone who wants to be considered simply has to state their intent here and express why they think they’d be a good fit to build and govern for the public good. Any community member may pledge their intent to be a steward, but fellow community members will delegate voting power according to their own views.

Delegating your voting power: Anyone that wants to delegate GTC to a steward can visit the dashboard here and choose from the current list of interested parties. Delegation goes a long way in ensuring everyone’s views and thoughts are well represented. Delegations can be changed at any time.

Contributing to a workstream: Workstreams that have been successfully ratified, as defined below, will constantly be looking for new contributors, and over time just like in any DAO members who do well will be rewarded and given more stake in the future they’re helping to build.

Gitcoin Values / Code of Conduct

In addition to the general rules of engagement for forum participation listed here, we want to define an even clearer definition of the values and conduct expected of stewards, delegates and moderators, given the important role they have in the Gitcoin ecosystem.

Gitcoin’s core mission is to build and fund digital public goods, which naturally involves playing all kinds of positive-sum, multiplayer games. Doing that effectively requires us all to internalize and act upon shared values and common knowledge. We hope that the code below can act not just as a template for acting in the Gitcoin ecosystem, but eventually the broader Ethereum ecosystem as well.

Code of Conduct

Gitcoin is a community for open source development and supportive collaboration. It welcomes all opinions and perspectives, encouraging meaningful discussions as we build new cooperative models to further public goods together. Above all, our goal is to ensure that public goods get the support and attention they need.

The Code of Conduct is here to help guide the community on how we should work towards this goal while treating each other with respect and as peers.

Gitcoin as a community is only as strong as it is because of highly engaged contributors, delegates, and stewards alike. We must continue to foster a culture of collaboration and support. We value the participation of every member of the community and want all participants to have a meaningful and fulfilling experience. Accordingly, all members are expected to show respect and courtesy to others throughout their engagement in Gitcoin community activity.

What to Do (values to instill)

Respectfulness & Kindness

  • We are an inclusive community
  • We respect difference in opinions
  • The community is not JUST Gitcoin, but anyone who wants to participate

Discuss topics, not each other

  • Sometimes things can get heated but we disagree on topics not people

  • Discussions should be additive not reductive

  • Respect privacy

Build together and be transparent

  • Everything is open source anyway so building compassionate tech requires openness and honesty, not gatekeeping

  • This means accepting differences and acknowledging flaws

  • Work together, but don’t force or coerce others into anything

  • Redundancy is natural and should be respected vs vilified


  • Things don’t generally work long term on goodwill alone, active participation is required; as such, accountability is key in manifesting the DAO’s mission, if you agree to run a workstream or push forward a proposal you must be willing to be held accountable

  • Timeliness in delivering work, contributions, and goals set out is essential. Be considerate that you’re always working as part of a community


  • As a primary principle of web3, contributing work should be done in public as much as possible and communication should be forthcoming


  • An openness towards and willingness to work with others in achieving DAO mission goals is critical in establishing an environment of collaboration and co-creation

What not to Do (things to avoid)

  • 0 tolerance for hate speech

  • 0 tolerance for personal attacks or threats

  • 0 tolerance for sharing illegal or explicit material

  • No spam

If you see something do something

  • Everyone taking part in the Gitcoin community—stewards, delegates, moderators, contributors—is required to abide by the Code of Conduct. If you’d like to raise something you feel goes against the code, speak to a mod. All communication will be treated as confidential.

The code of conduct will be enforced by stewards who have chosen to take on moderator duties. If you would like to become a moderator, please reach out to myself, Scott, or Yalor on Discord.

See something missing? Suggest it below!

Governance Process:

Note: All meaningful governance discussion should take place on this forum to ensure the community has full transparency

The Gitcoin governance process is the act of proposing, discussing, and deciding initiatives for GitcoinDAO to take on around the mission of sustaining digital public goods. As currently scoped, workstreams provide a place for discussion and collaboration, leading to proposals which are then voted on by the community.

Proposals can vary broadly, they can be qualitative / procedural (e.g. “Should Gitcoin Grants allow VC backed projects?”) and have no funding requests attached, or make an explicit request for funding (e.g. “We would like to create a workstream focused on building a decentralized architecture for Gitcoin Grants”).


Workstreams are the atomic units of how stewards coordinate. A workstream is a group of people actively working on tasks that align with Gitcoin’s mission to sustain digital public goods. As such, ratifying workstreams sets boundaries on what is and isn’t in scope for Gitcoin DAO governance.

Anyone may start a workstream and gather momentum around it by posting on the forum. Until a formal proposal for a budget is made, this workstream is considered “informal.” A workstream can be as broad or narrow as its initiators like, but any workstream proposals must satisfy the following criteria or risk being removed by mods:

  • Have a clear objective the workstream is aiming to achieve that aligns with Gitcoin’s mission.
  • Name a directly responsible steward willing to take ownership for the objective and be accountable for meeting it.
  • Be distinguished from or explicitly state its improvements on existing workstreams.
  • Propose a clear budget and timeline for an initial target outcome of its activities.

Workstreams may have five potential states:

Stages Detail
Informal Workstream Informal workstream
Proposal Stage Workstream has made formal proposal to governance for budget.
Active Workstream Workstream budget and target has been ratified by governance.
Renewed Workstream has been renewed or is receiving continuous funding.
Archived Workstream is concluded, defunded, deprecated, no longer active.

To move into a subsequent level of formality, a workstream must satisfy a set of criteria defined below.

Workstream Stage Information Needed to Proceed
Workstream Initial Proposal To be posted on the forum when the workstream initial proposal is made.
Team Who is proposing this project? What are their qualifications?
Mandate What is the mandate of this Workstream? What will it try to accomplish? Does it have an initial goal?
Workstream Funding Proposal To be posted on forum & linked in Snapshot proposal when a funding proposal is made.
Initial Target What is the first project this workstream aims to deliver? How does this project enhance Gitcoin’s goals or align with its values?
Budget What budget is required for the workstream to succeed at this goal?
Timeline What is the plan and timeline for delivering on this work?
Directly Responsible Steward Individiual who is managing the project and directly responsible for its success or failure.
Formalized Team Who else is working on this project and what are their responsibilities?
Active Workstream To be posted on the forum as a responsibility of funded workstreams.
Make a weekly report on forum What has been accomplished this week?
Renewal To be posted on the forum before renewed funding request is made.
Success/Fail Did the initial target get successfully delivered? Did it meet expectations?
Renewal Targets What will the workstream be taking on next?
New budget requirements Are there any changes to the budget for funding this new tranche of work?
Team Updates Are any team members changing? Is there a new DRS?
Archival To be answered by workstream or governance when considering archiving a workstream.
Performance on Mandate Has the workstream accomplished or failed to achieve its mandate?
Necessity of Workstream Is there more ongoing work to be done under this specific mandate?
Eligible Leadership Are there people willing and capable of taking on the leadership role?

Examples of workstreams

Public Goods Funding: Helping rally the community to fund public goods, setting criteria for matching rounds, and finding ways to get Gitcoin involved in funding new digital public goods.

Sybil Defenders: Analyzing Gitcoin data and brainstorming long-term identity and mechanism design solutions for Sybil-Resistance.

Progressive Decentralization: Finding ways to modularize and simplify Gitcoin’s architecture for the community to use in perpetuity.

Public Goods Prototyping: Finding ways to use Gitcoin’s new architecture to build novel solutions to ecosystem problems.

If you have other ideas, please suggest a workstream, or just dive straight into discussions.

Workstream Funding

Workstreams are not funded by default. Each workstream must apply for funding and is free to define its own structure for paying contributors and leads.

Workstreams requesting a budget for a project by default are assumed to be requesting a budget from the DAO treasury, denominated in GTC. However, this path for funding is not the only one available to a workstream or projects therein, and does not preclude workstreams or projects initiated by workstreams from maintaining a Gitcoin Grant or leveraging other coordination tools.

It is recommended that workstreams pursue funding from the DAO treasury, and that projects find ways to interact with workstreams directly, treating other funding sources as supplemental, reactive funding from the community.


The following section applies to both the creation of workstreams, or any other general proposal therein that the community believes requires formal ratification (e.g. the anti-sybil workstream ratifying Gitcoin Grants round results with the broader community).

Proposal Approval Process

Once a proposal is ready to be formalized, its members should make a proposal in the Proposal Discussion section of the forum.

Any forum proposal must:

  • receive input from at least 5 stewards
  • be live for at least 5 days


  • follow the template & considerations above for forming a workstream
  • follow this template for a general proposal

Otherwise, it will not be considered a valid proposal and will be removed should an attempt to create a Snapshot vote be made.

Moving to Vote

Once a proposal has met the above criteria, a formal Snapshot vote can take place.

Off-chain voting or “soft voting” will take place on Snapshot, a simple voting interface that allows users to signal sentiment. Votes on Snapshot are weighted by the number of GTC delegated to the address used to vote.

On-chain voting or “hard voting” will be an additional final step to move GTC from the DAO or other key changes to DAO structure. Gitcoin will be using Tally to upload on-chain proposals.

In both cases voting power is directly proportional to the amount of GTC a user holds and the quorum requirements are the same - a minimum of 2.5mm GTC must participate in the vote unless the community ratifies otherwise.

IMPORTANT: Snapshot will be used for final decision making on any proposal that does not require moving funds from the treasury.

Edge Cases

Soft Quorum

From time to time, votes might narrowly miss hitting quorum. To facilitate better governance and avoid making participants repeat votes unnecessarily, a soft quorum rule is instituted. Soft quorum only applies to Snapshot voting given that we cannot execute on-chain votes if quorum isn’t met.

We define soft quorum as follows: If a proposal would have passed in any scenario where the number of outstanding votes required to hit quorum were distributed to other options, stewards must act as though the proposal hit quorum. This is true no matter how many options were available in the poll in question.


Suppose a proposal gets 1.5m votes in favor of Option A and 500k votes in favor of Option B. We add an additional 500k “shadow” votes to Option B to hit quorum (2.5m) and find that the vote is still strongly in favor of Option A. Soft quorum is hit and the proposal moves forward.

Conflicting Votes

From time to time there may be conflicting proposals, to avoid issues, the 5 day window above can also serve as time for anyone to list their preferred alternative option on the forum. Each proposal on an associate topic will have a [TOPIC] block placed in its title.

After that time, a vote will be put forward including all options available to move forward with. This will ensure that everyone has the ability to surface their preferences while keeping decision timelines reasonably short,

Future Updates

Remember, this is a living document and is only meant to act as a starting point for governance. Please comment now, as any updates once this is ratified will need to go through a Snapshot vote following the process described.


This post was flagged by the community and is temporarily hidden.

This is a fantastic start on covering many of the important topics when spinning up a workstream.

I would like to discuss how the initiator or creator of a workstream should propose compensation for themselves. It would be great to hear thoughts on how that could work and we could create examples to bring it to life.

To start the discussion, here is a possible approach and some problems…

Static Pay (mocks how it would work in a normal employment situation)

  • Lead proposing the workstream composes a budget
  • Budget includes proposed monthly/bi-weekly/weekly pay at a certain rate in USD
  • Depending on prior experience applicability:
    • Prior experience directly applies: Lead includes resume and pay range data for applicable skillsets
    • Prior experience partially applies: ?
    • Prior experience does not apply: ?
  • After establishing a track record delivering on the goals of the workstream in a timely manner and responsibly managing funds, the lead could propose an increase in pay
    • This could be done by the lead iniating a review of some sort by the DAO resulting in a scale that diretly relates to a realignment of compensation
    • It might be such that certain members of the workstream and DAO could initiate this process as well if they want to recognize great performance or identify lacking performance

In the case that a leads prior experience only partially applies or does not apply, there might have to be a probationary period or have pay locked pending frequent reviews over time. As time progresses, those reviews could become less frequent and finally cease.

I would love to hear thoughts on this approach then we could create an example with numbers, dates, etc. around it to better illustrate how it would work.


So I’d like to take some time clarifying this. Based on mentioning the 5 day window, the implication here is that the conflicting proposals would be present at the same time on the forum, and if that is the case this makes a lot of sense.

However, what about in the case of two proposals that have both managed to get to snapshot, asynchronously. An example being the recent AKITA debacle which had two separate, conflicting, snapshot votes within one week.

I understand the extenuating circumstances surrounding that instance, it would just also be good to try to account for this issue in the future.

Should there be a statute of limitations on repeated votes for a given issue?

Assuming there are two opposing snapshot conclusions, should there be a third vote to resolve their dispute?

I think it would be worth figuring out the official stance on this issue to prevent repeatedly creating votes until ones desired conclusion gets accepted.


hey Simona, thanks a lot for taking the time to write all this down. Let me make some comments.

When you say everything here what do you mean? Grant recipients? Things we build etc? Because this is actually not true and something that bothers me from the start about gitcoin and its mission statement changing away from opensource to defining “public good” software as something quite vague allowing pretty much anything to be called a public good.

I think this should be increased to 7 days and if not that then specify that 5 days should be Monday - Friday. Weekends should not count for this.

Additionally we should ping all stewards in discord (so there is an active notification) to come and comment on the proposals. Otherwise if none knows there is a proposal they won’t bother commenting.

I agree with this, but I think we should also add a clause in there for someone quitting their role, no questions asked. Sounds too harsh without such a clause.

Most of us have a lot of other responsibilities and having flexible roles would be paramount.

Perhaps this would be more regarding the actual role’s definition. More like a real-world contract. So what would you need to do and how many hours per day so that you know what you are signing up for and the workstream knows what to expect.

Personally I think I will just try to participate actively in governance as much as I can and try to help in workstreams if I can in some capacity.

But if it’s:

A: 750k B:750k C:750k for a total of 2.25m then no soft quorum is reached, right? Since nobody has a clear majority and can’t guess where the shadow votes would go?

I would also like a clarification on the exact situation that happened with Akita. That was two conflicting votes. The first got ratified but then not executed and then another one came up completely ignoring the results of the first.

I would like to see some clear rules so that this does not happen again.


Thanks for sharing this! Everything sounds really reasonable to me.

1 Like

Thanks a lot for your detailed proposal, I would like to know more role-specific actions like

  • what can delegators do?
  • what can stewards do?
  • how to involve in a workstream? (how to name this role?)

another suggestion is:
could we have a picture to illustrate the workstream lifecycle? e.g

  • preparation (get comments from at least 5 stewards)
  • make proposal on forum
  • if meet criterial, then goto snapshot
  • approve or reject
  • continuous update (outcome and budget etc)

Last but not least, thanks again for your efforts :wink:


Great input and thanks!

The Renewal/Archive is a key part, I really like it.

Proposal to * receive input from at least 5 stewards - maybe we can consider to add something like : 5 stewards (that come from at least 2 different organisations, not coming from the same family etc)

1 Like

I think this is great Philip, thx for starting this! Although I think it merits a topic on itself, which could be fleshed out the moment workstreams are defining how to pay their contributors. That will also help to make it more practical? Not sure if it really needs to be included in the overall governance process though.

Great proposal, thx for all the work on this simona!

I think this is pretty comprehensive and a great start to use as guidance for now, until some real-live situations require it to be adjusted.

A few thoughts:

Agree with @lefterisjp that this should be changed to ‘weekdays’ or ‘workdays’. I like the combo with also needing input by at least 5 people, and would definitely keep the requirement of both, so that nothing passes without some solid on-topic feedback that shows they have read the entire proposal. If not enough feedback, even if it’s just a simple ‘this all looks great’, the proposal remains open and has to wait.

Is there any link that can be added here to how you actually request funding or what the format is for this (maybe an example of one that has passed already if any)? Or is this just by making a proposal on the forum as well?

Just a little typo here

If you need help, don’t hesitate to add me.

Again, thx so much for creating this from scratch, this is epic!!

Great proposal, and I really like “Soft Quorum” idea.

I think we should add condition for “shadow” vote: original total votes must have minimum number (i.e. 1.5m votes) , or “shadow” vote must less than original total votes.

For example, original total votes is 1m, Option A: 900k votes, Option B: 50k votes, Option C: 50k votes, Option D: 0k votes. After we add 1.5m “shadow” vote (500K->Option B, 500K->Option C, 500K->Option D), vote is still strongly in favor of Option A. Soft quorum is hit and the proposal moves forward. But original total votes is too low(1m).

Hi people - this is my first post in the Gitcoin community. Hopefully fresh eyes will see some things the grizzled veterans have missed.

Overall I think this document is a great start. As a non-technical newcomer with a working knowledge of DAOs, I was able to parse it and figure out how the process works. There are a few areas where more detail would be helpful, and a few things that were missing and should be added. The document could also benefit from an edit for clarity and readability. I’d be happy to take a stab at that before the next version if people think that would help.

On to the comments:

This section explains the how, but not the what. It could use brief definitions or explainers for each of the roles, not just how to do them. This is one area that is probably clear to experienced community members, but a governance document should be usable by beginners too.

This section might benefit from adding a brief step-by-step roadmap to the governance process as a whole, with links to detailed discussion of each point later in the document. Something like:

  1. Create workstream
  2. Develop proposal
  3. Discuss proposal
  4. Vote on proposal
  5. Report on progress

An illustration might be even better

In either this section or the Proposal Approval Process section directly above, there should be an explanation of how the move to the Snapshot vote occurs. Who decides if the criteria in the Proposal Approval Process have been met, and how? Who triggers the vote, and how? Again this might make perfect sense to someone who has been around the community for a while, but to a newcomer this is a black box.

This section could also be expanded to explain how voting works - what tokens are eligible to vote (ie. can you vote tokens purchased after vote is called?), how delegation works ie. (how to delegate, who can be delegated to, changing delegation…), what thresholds are required for certain kinds of votes (ie. simple majority or supermajority?), etc.

Finally, this section should set out how off-chain results are implemented. Who is responsible for sending tokens from the treasury?

An explanation of what is meant by a conflicting proposal would be helpful here, along with some consideration of who gets to decide if a proposal is conflicting and how that decision is made.

1 Like

Is this handled automatically by Snapshot? If not, who is responsible for checking for soft quorum?