BASED Budgeting - Bottom-up Approach for Strategic, Effective & Decentralized Budgeting
We present Based Budgeting, a bottom-up, strategic, modular approach to Treasury budgeting that focuses on progressively building voter support to grow the ecosystem more effectively than uncoordinated approaches.
This research has been made possible through a Web3 Foundation Decentralized Futures grant for OpenGov.Watch.
tl;dr
Bad Governance weakens the ecosystem by being ineffective (directionless) and inefficient (wasteful). It creates corruption, wastes time and resources, and creates uncertainty in the market.
Good Governance strengthens the ecosystem by effectively and efficiently organizing the DAO. It creates consensus around shared goals and coordinates professional teams to achieve them, which creates confidence in the market.
Based Budgeting is an approach that has good governance as ambition. Its primary goal is to promote ecosystem success through the application of Web3 principles of self-organization. Based Budgeting is bottom-up, strategic, modular, and progressively builds consensus.
Our approach builds on 3 values:
- Effectiveness: focus on ecosystem success through the shared objectives
- Efficiency: professional operationalization through self-organized teams with skin in the game
- Confidence: Strong and sustainable voter support through the progressive building of consensus
Introduction
Polkadot is the biggest DAO in the world. Polkadot is not a single chain or tech stack or protocol or community. It is rather a rich Web3 ecosystem with many moving parts. Its decentralized governance system OpenGov allows everyone to participate in the steering of the DAO.
OpenGov’s role is to help the Polkadot ecosystem grow.
To get the job done, OpenGov is equipped with a Treasury. OpenGov continuously negotiates which projects to fund on a case-by-case basis in a very time-consuming process. Right now, no deliberate planning and consensus-building is going into the development of the budget at the macro level.
So far, OpenGov has not developed a proactive spending strategy or budget. It just reactively spends money on the opportunities that present themselves.
This is understandable when we consider that OpenGov is just a year old. We can compare this behavior to a young kid who is getting pocket money for the first time, walks down the street, and spends the money on the sweets and toys it discovers in the first store. Most grown-ups behave differently: They spend time thinking about all the basic needs they need to meet (rent, water, heat, food, clothing, internet) before they move on to all the nice things they want to have. Translating this to DAO budgeting: The basic needs of Polkadot are the things it needs to provide to be a fully functioning Web3 ecosystem (easy-to-use tech stack, rich feature set, good UX, targeted marketing, efficient deal flow, etc)
To help the Polkadot grow, OpenGov needs to fund all the essential functions necessary to make it a competitive Web3 ecosystem.
When funding projects, we can consider how effectively and efficiently the funds are spent. Effective spending means we achieve our goals (tick all the boxes to be competitive). Efficient spending means that it happens with as little as possible waste of time, effort, and money. Effectiveness should be considered before efficiency because if we optimize for the wrong goals, we still miss the target. We now argue that having no spending strategy carries a huge risk of creating an ineffective system: As long as there is no holistic debate about what projects OpenGov is funding, there can never be certain that we are creating a fully functioning Web3 ecosystem.
Strategic budgeting will massively improve the effect the Treasury can have on the growth of the ecosystem.
We believe that reactively making spending decisions case by case is not fit to meet the challenges of growing one of the most important Web3 ecosystems in existence. Instead, we want to see a strategic and thoughtful approach to Treasury spending. Because of the decentralized nature of the network, this can only work if we employ a bottom-up approach that seeks broad consensus and gets supported by a large voter base over an extended time.
Based Budgeting enables strategic budgeting by providing principles and processes to
- agree on shared objectives,
- recruit self-organized teams that work to meet the objectives,
- helping them to define projects and resources needed
- allow voters to influence the process and progressively commit to it
Why should OpenGov stakeholders adopt Based Budgeting? Because Based Budgeting is more convincing to stakeholders than the reactive, ineffective, inefficient, and chaotic process we have seen so far.
Four Principles of Based Budgeting
Based Budgeting is built on four principles:
- bottom-up
- strategic
- modular
- progressively building consensus
By combining these four principles, Based Budgeting follows a bottom-up approach of integrating teams working on individual solutions into modules so that together they can achieve higher-level strategic objectives. To achieve voter support, each module individually improves its plans until it has built enough voter support to be accepted.
We will now look at the principles and flesh out how they lead to a budget.
Bottom-Up
In the absence of central authorities, all action in the system emerges out of the individual agents and how they participate. On the first layer, agents form teams. They identify relevant challenges and growth opportunities and address them by developing projects. Depending on their capabilities, these projects can range from small (hosting a single Hackathon in Austria) to medium (managing event production in a geographic region) to large (coordinating the global marketing efforts of Polkadot). To realize the projects, they develop an execution plan, estimate costs, and request funding.
This dynamic is already the case today. The question is how we can ensure that these teams work together effectively and efficiently and that we don’t miss essential functions.
Strategic
Polkadot can only be effective when it ensures all essential functions for ecosystem success are covered. We can only be certain that this is the case if we have a holistic strategy. However, it is typically assumed that strategies can be dictated top-down by a central authority.
Based Budgeting asserts that strategies can be achieved without relying on central authorities. Strategy can be formed bottom-up through individuals and teams contributing strategic components.
Here is how: Agents form their own opinions about what is the best overall strategy to move forward. As they communicate with others, they start agreeing (forming a consensus) on certain strategies. This forms the basis for them to coordinate their actions. Certain strategic objectives will gather widespread support. We can curate these objectives into a consensus strategy and validate it through signal voting on the wish-for-change track. A successfully validated consensus strategy can then be used to organize high-level planning and structuring of an executive organization.
Once there is an accepted consensus strategy, teams can form around the high-level objectives to get them solved. They lay out project plans and request budgets. These specific budgets then form the foundation of the overall budget.
Modular
How can we bridge the gap between a top-down consensus strategy and the reality of a bottom-up organization? By viewing the organization as a modular structure of teams, such as bounties, collectives, teams, community DAOs…
For example, the high-level objective of marketing Polkadot’s technology consists of several specific functions, such as PR, Advertising, Content Production, Social Media, etc. Several independent entities have to work together in a modular fashion to achieve the higher-level objective. By coordinating the work of teams working on related problems into a larger module, we can solve larger and larger problems until we arrive at the highest level defined by the strategy (software development, marketing, etc…)
A bottom-up budget can be built by letting the lowest levels determine what they need (and of course make sure that the requests are plausible) and then aggregating these budget requests. At each level, there might be negotiations to ensure that the whole module is acting reasonably. The higher up, the bigger is the responsibility of the coordinators to ensure proper budgeting.
Progressive Consensus
Planning the future only makes sense when there is a reasonable expectation that a significantly large portion of the voter base supports the plan. This is typically seen as the biggest challenge in creating large-scale governance coordination. Opinions and voter bases might change. No plan lasts forever. A too-hard consensus (e.g. fixed budget) is not realistic. A too-soft consensus (e.g. just a few good ideas) will not have a big impact. How can we properly budget a coordinated strategy without risking that it fails because a single component is not accepted by stakeholders?
Our solution to this is to progressively build consensus and voter support in iterations.
- In the first step, a very rough concept or competing concepts with broad objectives are presented to voters to seek general directional support.
- Then, the modules start developing individual project plans with budgets and present them for signal voting. If they get approved, implementation can begin. If not, another round of feedback is taken and the project plan is revisited.
- From time to time it may become necessary to revisit the general strategy or seek direction from stakeholders (e.g. split decisions). In this case, additional high-level signal voting might happen.
The goal is to develop specific agreements that carry broad support and are likely to persist over an extended time. A meatspace analogy is coalition agreements in multi-party political systems. When multiple parties agree to work together and form a coalition, they need a rough consensus on what they intend to achieve together despite competing interests. To this effect, they agree on their goals and intended legislation in the future. It is not legislation itself, but a declaration of intent that reduces uncertainty and allows the participating parties to begin the work.
Because Based Budgeting follows a bottom-up process, it is possible to wait for or eliminate individual modules from the planning if they don’t gather sufficient support yet. This can give voters confidence that the overall project can progress even if individual sub-projects stall. As such, this process carries all the advantages of bottom-up organizing and also integrates the benefits of top-down strategies without having to rely on centralized authorities.
Process
We will now describe the specific process that we suggest to implement.
Phase 1: Objectives
At the beginning of a Based Budget, there needs to be a common understanding of the goals and objectives. Objectives act as the crystallization point around which work is organized. A manifesto or strategy is suggested as a starting point for this process, as it is a good format to present supporting evidence for why these objectives should be considered. A manifesto allows people to rally around a common vision. A strategy allows people to develop a sophisticated mental model of the whole solution.
The goal of this phase is to build a coalition for common objectives. Voters need to be convinced, and a team of professional executors needs to be assembled and a rough coalition agreement needs to be developed.
Phase 2: Coalition Agreement
Based Budgeting builds on the premise of a coalition: A good plan, supported by a significant share of the stakeholders (measured by the number of AYE votes) and people to get the job done.
A coalition agreement is derived from the objectives and lays out in short form what the coalition wants to get done and how they plan to achieve it. This could be in the form of a rough structure and execution plan.
This is also a good point in time to present the already assembled team. Of course, the team can continually evolve and more members will join later, but this is a good opportunity to further convince voters of the coalition.
Once the coalition agreement is developed, it is brought to an on-chain on the wish-for-change track. If it passes with strong support this acts as the final GO signal for the coalition. Of course, the coalition may decide to start work early, either to build additional support or because it intends to perform the work anyway.
Phase 3: Forming departments and budgets
Once the coalition is agreed upon, departments can start to form. Departments are the highest-level structures in the coalition. They derive their objectives from the coalition agreement and from there develop a work agenda and projects.
For these projects, they will also define the necessary budgets to achieve their goals and report them to the community for open feedback.
Once the department is confident in its plan, it can submit a bounty creation proposal (or WFC) to OpenGov. This way, each department can progress at its own pace and doesn’t block the other ones.
After the bounty is accepted, the department becomes fully operational.
Phase 4: Operations and Continuous Controlling and Improvements
The teams operate according to their objectives and have the freedom to internally self-organize as needed. They publish monthly progress reports and quarterly budget reports. Auditing and Controlling happen through an external unit. OpenGov can influence the process by modifying objectives, budgets, and compliance rules.
Considerations
Similarity to Existing Practices
Readers might notice that many aspects of what is described here are already found as established practice. This is intentional. There is already an established structure in OpenGov, even if it is sometimes hard to see for the casual observer. The processes described here are designed to be minimally invasive on the existing structure and instead should only act to add additional benefits like increased coordination, better consideration of additional values, the possibility to achieve broad consensus for top-down suggestions, etc. without disturbing established best practices in the system.
Management of the Coalition
While the system builds on established practices, there still is an additional level of management and oversight introduced. The coalition has the goal to achieve certain objectives and this is also what it is elected for. It is up to future coalitions to define this process for themselves, but they should not be afraid to assert this management activity as a necessary function of the coalition. If voters disagree, we can assume they will be quick to signal this on-chain.
Positive Effects on Coordination
The assumed closer working relationship of departments within the coalition can serve to simplify coordination and synchronization. Since agents are recruited as part of a coalition, they are incentivized to coordinate and synchronize to ensure the continued support of voters and to avoid competing coalitions from taking over. Because they follow shared principles and processes to achieve shared goals, this simplifies the challenge of attributing responsibility and distributing work.
Modularity Breeds Flexibility
Viewing Based Budgeting under the modular lens allows us several insights:
- Modular entities can be reformed or swapped out. If entities do not perform as intended by OpenGov, they can be changed or replaced.
- The system can be incomplete. Even if the strategy suggests certain entities, it does not have to force them into existence if there is a lack of human resources or for any other reason.
- Modules can be added or removed from the strategy. Based Budgeting does not aspire to cover every aspect of OpenGov. It is open to other projects outside of its scope. It primarily focuses on effective ecosystem growth. OpenGov can fund any other initiatives next to it. If projects turn out to be no longer needed, they fall out of the scope of Based Budgeting. Research projects that develop traction might become part of the strategy and be integrated into the modular structure.
On the Openness of the System
Because the Based Budgeting is modular and does not assert authority over all aspects of OpenGov, it is very compatible with the existing system and does not require other OpenGov processes to stop.
There does not need to be a single unified Budgeting party. Different parties might compete to get their coalition accepted. We could even view the existing system as several small coalitions working on very specific objectives (e.g. all the bounties). In this sense, the Based Budgeting also gives a perspective of how these different coalitions might merge into larger coalitions.
Resilience
Bottom-up systems breed resilience. Since there is ample competition between teams at the basic level, we can deduce that only the more resilient approaches survive on a large enough timescale. Any higher-level approach must consider that if it is not built extra resilient, it will get toppled sooner or later. Based Budgeting is developed with the idea in mind that the system needs to remain resilient even if it aims to implement top-down ideas. Our main approach to this is modularity, which tries to encapsulate complexity on each level of abstraction, such that as many modules as possible might survive adverse circumstances.
Handling disagreements
If opinions about the further course of action within an entity diverge too much, this shall be brought to the attention of the next higher level for arbitration. If no agreement can be found, a signaling vote (or whatever is most suitable) can be brought to OpenGov.
Transparency
Each entity funded by OpenGov shall report a quarterly overview of how it uses funds and shall always provide a publicly accessible archive of its spending that keeps as much detail as possible.
The coalition leadership shall provide quarterly reporting on its overall activities.
Accountability
OpenGov workers who carry responsibility for funds over a certain amount shall be KYCed. Additional inputs can be found on the Accountability Checklists page on OpenGov.Watch.
An auditing unit established by OpenGov but independently of the coalition shall audit the spending of the coalition.
Integrating existing structures
Based on Budgeting would be wise to integrate existing projects and structures as much as possible. Because of its open nature, it allows existing projects to opt-in to this new approach to coordination.
Push Everything to Bounties
It is suggested that every individual proposal that hits OpenGov but can be handled by a specific bounty should be “pushed” to that bounty by suggesting to proposers to resubmit their proposal to the respective bounty. This minimizes the involvement of OpenGov stakeholders on individual proposals and frees them up to focus on directing the overall direction of OpenGov.
Denomination of the Budget in DOT and USD
We suggest to denominate the budget in USD, but limiting the budget in DOT. Why? The ideal cost of projects is based on certain costs or profit expectations in USD. This acts as the upper bound of what is spent. Limiting the budget to the amount of DOT that is available on the other hand creates the realistic limit of the money that the Treasury has available for spending. If there is not enough DOT to cover the USD demand, that is the limit.
We suggest that payments are made in either DOT or USD, but that proposers are explicitly invited to request in USD and that if they request in DOT no top-ups shall be provided in the future.
Results-Based Funding
Funding should happen as much as possible based on results (retroactively), not promises (proactively).
