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.
Goals
- Encourage team autonomy and flexibility
- Minimize bureaucracy
- Decentralise accountability
- Limit the quantity and complexity of proposals and decisions at the treasury level
- Limit budget pre-allocation to allow for better treasury management
Overview
I’ll split the main ideas behind this into two categories:
- Allowance streams — An funding primitive that allows for on-going, flexible budgets that change over time
- 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.
Requirements
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.
Examples
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.
Risks
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.
