Standardize Process for Builder Fund Awards

PROPOSAL SUMMARY

Merit:

The Builder Fund can be viewed as a "granting body" or "sponsor" of activities that fit within a specific scope. Attentive stewardship of this fund is synergistic with the long term success of the bZx protocol. I propose that the bZxDAO immediately moves to standardize the process by which proposals are collected and awards are granted from the Builder Fund.

By creating a process for soliciting work and awarding funding out of the Builder Fund, the DAO will ensure responsible stewardship over this treasury that fosters the long term success of bZx products. This process should be aimed at taking as much work off of the Executive as possible while streamlining the process for both the DAO and potential awardees.

Motivation:

  • Decentralization Theatre- if we do not put into place some guidelines and expectations for how the bZxDAO functionally is governed, it will devolve into another DAO of decentralization theatre. I do not want to see this - the bZxDAO community must take governance seriously and actively participate. By proposing frameworks for how the bZxDAO is actually governed, we are hardening the protocol against accusations of faux decentralization. This is important from a marketing perspective and a regulatory perspective
  • Treasury Stewardship is Risk Management- bZxDAO only gets one builder fund. If this is to be a long lasting protocol this fund must be managed responsibly. One aspect of this stewardship is the actual administration of funds in a coherent way that limits exposure of the DAO funds to tail risks. There should always be a strategic reserve on hand for emergent issues that may require paid consultation or auditing.
  • Agile Response to Protofire- Renat gave a fantastic proposal at the third bZxDAO community call. The bZxDAO community should demonstrate it’s excitement and commitment to this potential partnership by going out of our way to expedite the formalization of a deal with Protofire. The first step towards doing this is committing to some standards for document collection and decision making hierarchy.

Broader Impact:

Standardization of the materials required to make a request for a grant from the Builder Fund will reduce the Governance Fatigue of the bZxDAO community and legislators significantly by ensuring that all of the information relevant to making a decision is in front of the reviewer on first review. Just as this makes the process more streamlined for the DAO, it makes the proposal process simpler for the proposer because guidelines leave less room for guesswork when crafting a pitch.

Some standards and criteria for the types of programs that the DAO is willing to fund will also cause proposers to self-select based on likely community enthusiasm before making a proposal, again reducing the strain placed on the governance participants.

An open and up-front framework for how funds are paid and on what schedule will ease any back and forth negotiation between the DAO and the proposer on terms of payment and contractual issues. This framework should be trustless and self-enforcing to whatever extent possible, in the spirit of DAO governance.


INTRODUCTION

In the context of the Builder Fund, the bZxDAO is acting as a granting body which seeks to sponsor R&D that is beneficial to the bZx ecosystem. Viewed through this lens we must realize that the only new ground being tread here is that the entire process is governed by a DAO rather than a centralized party. As much as we all despise centralized powers, there is no need for bZxDAO to start from scratch when it comes to the solicitation of competitive contracts and grants.

Procedurally, the solicitation and execution of such competitive contracts can be thought of as divisible into several phases;

  1. Solicitation
  2. Proposal
  3. Review/Selection
  4. Negotiation
  5. Execution
  6. Closeout

Here I will highlight aspects of traditional solicitation/proposal based contractual administration that can be up-cycled for the DAO’s benefit.

1) Solicitation

Proposals can be made under two categories - they are either submitted in response to a Request for Proposal, or submitted without solicitation where some third party comes to the sponsor to propose work.
  • Request For Proposal- Many times there is a specific scope of work that the sponsor needs to be accomplished. In these cases, the sponsor puts together a Request for Proposal which is a set of specifications for the work being solicited. This is publicly posted and disseminated to potentially interested parties, who then are able to submit proposals for selection to win that contract.

  • Unsolicited- Other times, a third party has an idea for work that they can do for you and approaches with an unsolicited proposal. These types of proposals require more scrutiny because the Scope of Work is not pre-defined, and there is a qualitative assessment on whether the work to be performed is aligned with the interests of the sponsor.

2) Proposal

Let me just acknowledge - everyone HATES paperwork. Nobody likes it. But there's a reason it's done. Essentially paperwork is the standardization of information collection for processes that require some qualitative assessment to be made. At the doctor's office you fill out your family history and provide your insurance information for very important reasons. The same goes for filling out a license application at the DMV, and so on. These are necessary evils to streamline processes that would otherwise be inaccessible lacking formal guidelines.

This goes for a proposal to a funder as well. On both sides, the proposer and the funder, some guidelines are very beneficial. As a proposer you are seeking to make the strongest possible argument for your case, therefore guidelines are appreciated as they allow you to construct an argument which does not lack any critical information. As the funder you are seeking to limit the administrative burden created by the processes, so guidelines are appreciated as they go a long way toward making the information collection complete on first pass and limit any back and forth questions during this process.

It’s important for these proposals to come in with a uniform format to give consistency to the review process as well as keep the administrative burden as low as possible for the DAO.

3) Review/Selection

Review of these types of proposals has to be conducted by someone with expertise. Typically, a panel of experts. Selection can be purely subjective or you can base it on some type of scoring rubric.

4) Negotiation

In traditional negotiations it is simplest to begin a negotiation using a pre-prepared template agreement and then make adjustments to the agreement as needed. The sponsor will seek language that protects their interests and ensures the money is applied to the scope of work as agreed. The recipient will seek language that protects their interests and ensures that there are not issues with non-payment, inadequate funding, or unreasonable deadlines.

Payments could be incremental, or milestone based, or invoice based, etc. There could be pre-negotiated deadlines, or no deadlines but funding blocks don’t unlock delivery of the preceding milestone. There are many ways to negotiate payment structures that are advantageous to both parties under different conditions.

Often times there are stipulations requiring progress reports at certain increments through the project period. There are terms for how additional funds should be requested, alter the scope of work, change senior personnel, etc.

By coming to mutually agreeable terms up front for all awards from the builder fund, the DAO will be able to avoid any embarrassing public disagreements. At the same time, this offers assurance to the contracted workers that they are entering into an agreement that serves their needs - and has no unseen surprises.

Now, these days it is ENTIRELY possible to make these agreements self-enforcing deterministic smart contracts - but that does not change their need to be negotiated! The DAO should be able to draw inspiration from these standard practices while remaining nimble.

5) Execution

The team contracted to execute a scope of work should be largely autonomous. If thought to be beneficial the DAO could require periodic progress reports.

During the execution of a scope of work, the mechanisms of payment are really the main task from the perspective of the funder. You could make the administrative involvement a complete minimum by paying up front for the entire task, but you are gaining convenience at the cost of responsible stewardship over the builder fund treasury.

I think the best compromise for a DAO like bZxDAO would be to negotiate agreements into set deliverable milestones and pay on a deliverable basis, or do a standard X% up front and the remainder upon completion. Funds for each segment of the milestones can be released up-front, with the next block of funding released with the acceptance of the prior milestone.

For example, we could approve the Protofire proposal for Low Hanging Fruit. We would set a total $ value for the entire project, and consider each sub project it’s own deliverable which accounts for some % of the overall Scope of Work. As deliverables are completed by Protofire, they would unlock additional blocks of payment.

6) Closeout

The closeout of an agreement can be as simple as an exchange of emails, or as complicated as the initial negotiation. One concern is that with a milestone based payment system, the further into the Scope of Work the project progresses the lower % of the overall reward is left - meaning that if the original performer ceases work it can be difficult to contract a new person to finish the work. This can be addressed by leaving a % of the overall payment as a lump sum to be paid on closeout, which re-aligns the incentive towards completing an entire scope of work rather than portions.

PROPOSAL: UPCYCLING ASPECTS OF TRADITIONAL CONTRACTUAL MANAGEMENT FOR BZXDAO

1) Solicitation&Proposal

I propose that just as the Protofire team did, prospective applicants should deliver a pitch to the community at a community call. If the community signals general support, a formal proposal is solicited.

When it comes to solicitation and proposal, I think the bZxDAO should lean heavily on one of the many the very successful granting bodies that already exists and has public templates. For this I think the National Science Foundation has some very applicable formats for documents. Some suggested documents;

1a. Project Summary

  • Each proposal must contain a summary of the proposed project not more than one page in length. The Project Summary consists of an overview, a statement on the intellectual merit of the proposed activity, and a statement on the broader impacts of the proposed activity.
  • The overview includes a description of the activity that would result if the proposal were funded and a statement of objectives and methods to be employed. The statement on intellectual merit should describe the potential of the proposed activity to advance knowledge. The statement on broader impacts should describe the potential of the proposed activity to benefit society and contribute to the achievement of specific, desired societal outcomes.
  • The Project Summary should be written in the third person, informative to other persons working in the same or related fields, and, insofar as possible, understandable to a scientifically or technically literate lay reader. It should not be an abstract of the proposal.

1b. Project Description

  • The Project Description should provide a clear statement of the work to be undertaken and must include the objectives for the period of the proposed work and expected significance; the relationship of this work to the present state of the technology/bZx ecosystem.

  • The Project Description should outline the general plan of work, including the broad design of activities to be undertaken, and, where appropriate, provide a clear description of experimental methods and procedures. Proposers should address what they want to do, why they want to do it, how they plan to do it, how they will know if they succeed, and what benefits could accrue if the project is successful. The project activities may be based on previously established and/or innovative methods and approaches, but in either case must be well justified. These issues apply to both the technical aspects of the proposal and the way in which the project may make broader contributions.

  • The Project Description must contain, as a separate section within the narrative, a section labeled “Broader Impacts”. This section should provide a discussion of the broader impacts of the proposed activities. Broader impacts may be accomplished through the research itself, through the activities that are directly related to specific research projects, or through activities that are supported by, but are complementary to the project.

1c. Budget and Budget Justification

  • Each proposal must contain a budget for the support requested. The budget justification must be no more than three pages per proposal. The amounts for each budget line item requested must be documented and justified in the budget justification. For proposals that contain a subaward(s), each subaward must include a separate budget justification of no more than three pages.

  • The proposal may request funds under any of the categories listed so long as the item and amount are considered necessary, reasonable, allocable, and allowable under DAO policy (policies not yet discussed - subject for a future post).

  • The proposing organization may request that salary data on senior personnel not be released to persons outside the bZx team during the review process. In such cases, the item for personnel salaries in the proposal may appear as a single figure and the person-months represented by that amount omitted. If this option is exercised, personnel salaries and person-months must be itemized in a separate statement, and forwarded to the designated bZx representative. This statement must include all of the information requested on the proposal budget for each person involved.

2) Review/Selection

I propose that the review/selection be a joint venture between the Executive and Legislative branch, possibly with some signaling mechanism via token-polling from the broader community as well. Bringing in external expert opinions might be considered as well, or tapping into specific community members (Kain, etc) to serve on review panels could be considered.

The Project Summary and Project Description should be posted publicly for community involvement. After some period of time the Executive/Legislative branch should then conduct a formal review and consult with the proposer on any requested revisions to the scope or budget.

Selection should be based solely on perceived risk:reward for the DAO, against the amount of funds to be expended from the treasury.

3) Negotiation/Execution/Closeout

I propose that smart contract escrows be used for these types of agreements. The total agreed upon payment for a contract would be input into an Escrow, where blocks of funding can be released by the bZxDAO's Executive upon the completion of agreed-upon deliverables (be that as simple as a 50% up front and 50% upon completion, or as complex as a 20 milestone payment plan).

Any intractable dispute arising from this process should be arbitrated by an impartial third party external to the DAO (ex, Kleros). This is necessary for a trustless agreement between a DAO and a contractor because governance by the DAO participants is fundamentally biased towards the best outcomes for the DAO and therefore unfair resolutions for the contractor become more likely in the event of dispute.

To incentivize high quality participation from the best talent in the space, a trustless arbitration process by a third party is necessary. Absent a form of blockchain-native dispute resolution, a dispute could rise to the level of meatspace court rooms and become a stain on the reputation of all parties involved.

Close out would be a very simple procedure in which a final report is submitted which upon acceptance unlocks the very final block of funds.

4) Administrative Burden vs. Responsible Management of Treasury Funds

The overall goal of these proposed actions and guidelines is to limit the administrative burden to the DAO while maintaining practices that promote responsible management of DAO treasury funds.

I submit that the bZxDAO Executive should have the power to delegate these tasks as seen fit. Should the Executive feel it is a good use of their own time, they may carry out the majority of these administrative tasks themselves. Alternatively, the bZxDAO Executive should have the option of delegating these tasks to either the legislators or other community or team members. The bZxDAO Executive should have also have the power to use a small budget from either the Builder or Ecosystem funds to incentivize participation of an administrator.

Given this freedom, the bZxDAO is charged with the responsibility of balancing the administrative burden and responsible management of treasury funds. These duties will either be performed directly by the Executive, or they will be delegated to another DAO participant under the supervision of the Executive.

This freedom should be balanced by a Veto power held by the Legislators. The legislative branch should be granted rights to veto any contract before they are finalized, and make intervening recommendations if they determine the funds are being managed irresponsibly.

5) Conclusion/Final thoughts

My intent with this proposal is to provide a starting point for the DAO to quickly approve a process by which a Scope of Work and Budget for Protofire or any other prospective Builders may be reviewed and accepted.

I want to collect community and team feedback on these issues, and once the discussion seems to be tapering off I will take community commentary into consideration and translate the results into a properly formatted BZIP for DAO approval.

10 Likes

Great effort. I’d suggest adding a walkthrough (e.g. given a scenario, like a Protofire project, what happens end-to-end) to give everyone a sense of how this would work under the proposed model.

Great effort. I’d suggest adding a walkthrough (e.g. given a scenario, like a Protofire project, what happens end-to-end) to give everyone a sense of how this would work under the proposed model.

Thanks. Let me write this up, I will post within ~24hrs

WALKTHROUGH

This is an example of how the work flow might look under such a model. From the start to finish of a project.

Proposal stage

1. Pitch

Proposer should post a very brief (~1 paragraph) summary of their intended work with a poll. If there is community interest, schedule time for a pitch to be delivered on a governance call (just as Protofire delivered).

2. Proposal submission

With rough community consensus, the proposer then knows that pursuing a detailed proposal is worth their effort. This is important because putting together a piece like this takes quite a bit of work, and if it is not going to get support the wasted effort is bad for the proposer and also creates Governance Fatigue for the DAO.

Proposer follows the format that the DAO has ratified to make a proposal. This format can follow the BZIP format but shall contain additional documents such as a budget/budget justiciation, Scope of Work (project description), and Proposal Summary.

Using a standardized format here again reduces Governance Fatigue and streamlines the process, as it will limit the amount of questions and necessary debate to approve a proposer.

3. Proposal review

The finalized proposal is posted for community debate on the governance forum. After a certain period, or when discussion wanes, a revision may be submitted to incorporate community suggestions/requests.

At this point, the bZx Executive shall conduct a review. They can approve or deny the contract, or request additional edits. This power is to be balanced by 2/3 Veto power of the Legislature.

Contract stage

1. Negotiation

The terms of the contract will need to be negotiated with the Subcontractor (formerly Proposer). Some general considerations (non-exhaustive!);
  • Start date, end date
  • Funding $ amount.
  • Payment terms- half up front half on completion? Milestone based?
  • Terms for early termination. What happens if for some reason it is found that the SoW is not possible to complete?
  • Other considerations on either side, such as nondisclosure/nondisparagement etc.

A representative of the Subcontractor and a representative of the DAO will draft an agreement. Since this will be a Smart Contract paid out by the DAO treasury, the DAO must approve this through the normal governance process.

2. Acceptance/Execution

Once the contractual terms are agreed upon, a smart contract is initialized with an escrow for the total payment in a manner consistent with the payment terms. In the 50/50 example where you pay half out front, a direct payment would be made out to the Subcontractor upon acceptance for half of the agreement.

The second half would then be locked in an Escrow (example) that is released upon the completion of the Scope of Work. In the provided example Escrow service, Kleros is used as a native Dispute Resolution Layer which could be triggered by the Subcontractor if they believe the DAO has inappropriately refused to pay out the remaining funds.

Use of a native Dispute Resolution service that is external to bZxDAO is a show of good faith which would likely never be invoked unless there is a very protracted dispute. In this sense, it protects both the Subcontractor and the reputation of the DAO;

  1. The willingness to allow disputes to go to an external service for adjudication represents an increase in trustlessness. Good for both parties.
  2. If there ever is a true dispute, the DAO cannot be accused of impropriety by anyone and the Subcontractor can expect a fair resolution. Scandal avoidance is key. Again, good for both parties.
  3. Given the past dispute over bug bounty payouts, this seems like a good place to regain some faith in general.

3. Performance/Closeout

Subcontractor, having now been funded, goes on and begins to conduct the work.

Periodically, to the extent that is contractually necessary (or beyond), reports on the progress will be made to the DAO. This could be forum posts, or quick check ins at governance calls.

If there are major changes to the proposed work for any reason, supplemental funding or approval to deviate from the Scope of Work may be granted by Governance.

Upon completion, a final formal report is written. Completion may have other terms, such as a passing audit from a mutually agreed upon audit provider. Once the DAO determines that the requirements have been met, the escrow is released to the subcontractor.

6 Likes

Yes, I’m down with this. I would love to see this in action with Protofire’s low hanging fruit.

Please let them know about this and we can start with an easy, quick and simple project in order to also test this walkthrough!

1 Like
1 Like