DAO budgeting - allowance streams

Budgeting process has been coming up a lot recently in different contexts, and especially so with the current focus on the transition to the DAO and the org design workstreams.

This post presents an idea for a budgeting mechanism that could be used as a way to fund teams within the DAO.


  1. Encourage team autonomy and flexibility
  2. Minimize bureaucracy
  3. Decentralise accountability
  4. Limit the quantity and complexity of proposals and decisions at the treasury level
  5. Limit budget pre-allocation to allow for better treasury management


I’ll split the main ideas behind this into two categories:

  1. Allowance streams — An funding primitive that allows for on-going, flexible budgets that change over time
  2. Stream management — A governance mechanism for the creation, review and closure of allowance streams.

Allowance streams

The core primitive for budgeting under this model is an allowance stream.

In a regular stream (as in, drips) funds are streamed at a fixed rate and the recipient can collect available funds at any point.

In an allowance stream, instead of streaming funds, we stream allowance (a cap on maximum spend). The main difference here is that we don’t pre-allocate, so any unspent allowance stays in the funding pool. This is important for a couple of reasons that I’ll discuss in this post.

One of the core attributes of allowance streams is that they are elastic, allowing them to change over time without intervention. Each stream has a set of configuration parameters:

  • Starting allowance — The allowance at stream creation time
  • Elasticity - Defines the maximum amount that a stream can grow or shrink each month
  • Cap - The maximum size a stream can grow to before it caps out and a review is required

Once an allowance stream is created, the recipient is granted the requested allowance using ERC20 approve, allowing them to spend tokens directly from the funding pool. In order for the allowance to be “streamed” it can be refreshed at any time to account for the time elapsed.

Unspent allowance does not carry over to the next period. Additionally, at the end of a spend period the stream allowance will grow or shrink based on its elasticity and how much was spent in the previous period.

The result of this approach is that teams can create a stream once and thereafter be funded in an on-going manner without further intervention unless (1) their funding requirement increases beyond their initial cap or (2) someone contests their spending. This addresses a number of the primary goals — encouraging team autonomy and flexibility, minimizing bureaucracy, and decetralized accountability.


Stream recipients must adhere to two requirements:

  • Public accounting - Periodically publishing accounting outlining their previous period’s spend (high-level, categorised spending). This reverses the normal process of receiving funding from up-front budget approval to retrospective accounting, which addresses a number of the primary goals:
    • Encourage team autonomy and flexibility — We want to trust teams to make their own budget decisions, and want to encourage flexibility and autonomy over those decisions. Budget pre-approval compromises that goal.
    • Decentralise accountability - Public accounting allows for spending to be reviewed, discussed and challenged by anyone. Discussion should be encouraged, and can help to decentralise accountability for spending decisions across the DAO.
    • Minimize bureaucracy — Retrospective accounting is much simpler for both parties and provides a more accurate picture with which to judge the value of a stream.
  • Just-in-time spending - Funds should only be spent from the funding pool as and when they are required. This allows for better treasury management and enables the stream elasticity mechanism to function.

Not adhering to either of these requirements should result in stream closure.


Stream creation

The growth team proposes an allowance stream to fund their team operations, starting at $50k / month, with an elasticity of 10%, and a cap of $100k. The proposal is passed, and the allowance stream is created. The growth team’s multi-sig can now spend money directly from the funding pool up to their allowance. If the team spends near or at their limit in any given period, the elasticity function (TBD) increases their allowance for the following month, up to the allowance cap.

Stream accountability

The growth team posts their retrospective monthly spend breakdown. DAO stakeholders challenge the growth team’s spending and propose a lower cap. Budget governance votes on this proposal and passes it, lowering the stream’s allowance cap.

Stream management

Budget streams would be managed through an on-chain governance process (TBD). Any DAO stakeholder can propose the creation, modification or closure of a budget stream, and a decision on this proposal would then be made by the budget governance process.

This governance mechanism would have to be designed around all the usual goals of a governance mechanism — resilience, inclusivity, etc — but as it is itself only granted approval through the treasury, the treasury can act as the ultimate layer of accountability and, if it ceases to function effectively, can reform or even dissolve the budget governance entirely through a regular treasury proposal. Because of this treasury oversight, a simple multi-sig (Gnosis safe), or managed multi-sig (such as Orca) with a number of key core contributors could suffice.

Funding pool

As stated, an allowance stream grants the recipient a spend allowance on a DAO-wide pool of funds, which I’ll call the funding pool. The funding pool can be topped up from the treasury periodically, using regular treasury proposals to grant it a spend (top-up) allowance on the treasury’s ERC20 tokens.

This addresses goals #4 and #5.

  • We limit the quantity and complexity of treasury proposals by keeping them high-level. A treasury proposal here could be summarised as a decision to the following question:

    Do we trust the budget system to allocate budget effectively within the DAO? If so, allow it to allocate X tokens from the treasury over the next 6 months.

  • Enable better treasury management practices by using withdrawal allowances to reduce budget pre-allocation, allowing the funding pool to withdraw money from the treasury only as required.


The worst case scenario would be one where the budget governance process turns hostile. As the budget governance process has no direct control over funds, only over the management of streams, they would have around 7 days — the amount of time it would take for a treasury proposal to pass — to create streams to direct funds out of the funding pool. This risk could be partially mitigated by setting upper limits on stream amounts, or it could be mitigated entirely by introducing a 7 day delay on stream creation, allowing time for the treasury to revoke access before any funds are moved.

1 Like

Thanks for sharing this. I am keen to see processes like this be explored to enable a more permissionless style of contribution. It’s what I have been experimenting with as I onboard contributors and I am starting to feel a little like the gate keeper. So I am keen to see simpler ways for anyone to get funding approved to take on work they believe will be valuable to the community and for there to be a simple and effective accountability model.

I have also not had much visibility on budgets and reporting from other teams, which makes it harder to budget and feel responsible for the Growth teams. So I am keen to see a process that brings everyone’s efforts together.

How are teams approved for having this privilege?

Who do you think will end up taking responsibility for reviewing these reports? Who will have enough context to this well? This is the biggest challenge I’ve seen in DAOs trying to ownership of accountability over to the entire community. Those with high context don’t feel they are responsible to review and many with low context decide to be the most vocal.

How are teams approved for having this privilege?

This would be as light touch as possible, with the philosophy that by removing heavy, centralised decision-making you reduce gate-keeping and encourage more initiative and contributions.

One idea – sponsors and vetos:

Any core contributor can put in a proposal for a new stream, with the expectation that, before it is created, any proposal already has informal support from at least 3 other core contributors outside of the new stream being proposed. This support should be sought before the creation of the proposal. Along with the proposal there should be a post with an outline of the work that will be carried out and a justification of the allowance amount proposed. Once the proposal is created, it enters a fixed 7 day period, at the end of which it will be created if (1) at least 4 total core contributors signed in support (2) less than 2 core contributors vetoed it.

The variables (# support, # vetos, proposal duration) could be tweaked and could scale as a function of the # of core contributors.

This governance mechanism could be used for updating and removing streams too. Update would be identical. Removing streams would follow the same process except the terminology sounds different, e.g.:

Any core contributor can trigger a close proposal on an existing stream. If ≥2 core contributors support the closure (same # vetos above), it will be closed. If <2 core contributors support closure, and ≥4 core contributors reject closure (same as # support above), the stream remains open.

Vetos here (incl. closures) signal very strong disagreement and should only be used as such. Ordinarily, a disagreement shouldn’t be grounds for a veto.

Who do you think will end up taking responsibility for reviewing these reports? Who will have enough context to this well? This is the biggest challenge I’ve seen in DAOs trying to ownership of accountability over to the entire community. Those with high context don’t feel they are responsible to review and many with low context decide to be the most vocal.

I think it helps to break this down into more granular questions rather than seeing it as a monolithic review process.

  1. Is funding being spent effectively to achieve the team’s goals?
    • Recipient , Core contributors
    • We should trust that the teams themselves are best positioned to make decisions on how to allocate their budget in order to achieve their goals. They are the people with the best context and the people who best understand their domain of expertise.
    • The more difficult question is probably how to spot inexperience leading to inefficiency in spending, especially in cases where experience wasn’t demonstrated prior to the stream being created. I think there’s a good argument that open peer review would help to address this, but definitely open to other views or suggestions on that.
  2. Are the team’s goals in-line with the wider mission of the DAO?
    • Recipient , Core contributors
    • All core contributors should be aligned on what our wider mission is. This is an on-going process that is outside the scope of a budget mechanism and is being addressed elsewhere in other workstreams.
    • There’s a follow up question to this that touches on strategy. Even if all contributors agree on our wider mission, they might disagree on the best way to get there, and so disagree on the value of a stream. This budget mechanism proposal is an attempt to promote emergent strategy, which is to say, rather than creating a strategy by committee and enforcing it through gate-keeping, we let strategy emerge out of the distributed actions and proposals of contributors. The veto mechanism is a balance on this system to allow space for strong disagreements to be resolved.
  3. Is the DAO’s overall spend rate acceptable?
    • Core contributors
    • The DAO should collectively establish (and periodically review) an overall acceptable spend rate. This should be a collaborative decision involving any interested contributors. With that we can answer the Q of whether the current spend rate is acceptable: (1) If yes — every team should be able to receive the funding they need to achieve their goals. (2) If no — there should be an inclusive discussion amongst all contributors about what to prioritise for funding
  4. Is there an abuse of spending going on?
    • Core contributors
    • My assumption is that, by recipients posting periodic public accounts, spending abuses would quickly be spotted by other contributors, and would also be less likely to happen in the first place as they would be harder to hide.

There are two other groups that could be considered to take on responsibility to answer some of these questions:

  • Sponsors — The contributors that supported the original proposal.
  • Budget — Core contributor(s) nominated or volunteering to take responsibility for reviewing all streams

But my feeling is that these should only be employed if the system doesn’t work without them. The reason being that it risks introducing extra work that may not be necessary, and it risks siloing and centralising responsibility where it may be possible and advantageous to have it be distributed.

The general philosophy behind this proposal is that to really decentralise a DAO you need to create a culture where contributors care about things beyond a narrow role within their own team and feel empowered to take initiative. Centralised structures are self-reinforcing because they suppress this, and this is the exact thing that is required to dismantle them.

BTW I realised some unnecessary complexity and technical issues with the original allowance mechanism I posted here. I’ll post an updated one soon. Essentially I’m not sure having allowances change over time really adds much value and I think it would probably function fine and be a lot simpler with fixed allowance streams. Also the recurring part needs to be tweaked to support how these would actually be used in reality.


I do agree with a lot of these points. Particularly as it addresses some of the opportunities and challenges I’ve been seeing as I try onboard passionate, creative, and entrepreneurial contributors that have many opportunities to choose from.

As discussed in private convo - I think we need to spend more time presenting the challenges and opportunities in order to get the DAO aligned before getting further into solution design.

Ya that makes sense and I agree this needs to be framed with all the prior reasoning behind it. Some of it is embedded in the post, but some of it is omitted entirely. I’ll rework and update this based on that and other changes. Thanks! :+1: