Bounty Granter

Purpose

This project is about defining and controlling the disbursements of project grants, allocated by DAO funds.

The broad idea is to enable project initiators and sub-DAO/committees to propose dev projects; expressing the project deliverables and their completion conditions in contracts; having funds allocated once approved by the community, another DAO; reviewers validating the work done, which allows the grantees to unlock corresponding funds, potentially rated per the deliverables' evaluated completion level.

Instead of paying straight the whole amount of a proposed initiative once it is approved by a DAO community, we propose to have clear installment payments defined over time and/or rated per its completed achievements.

Like if we pay for replacing our house roof, this is costly and we want it done properly. So we usually agree on paying 30% of the agreed total billing amount at start, have eventually an intermediary payment, then the remaining amount is paid once finished & validated.

Solution

Establishing funding contracts for development projects, having their disbursements phased over different milestones or features completion, and optional acceptance criteria for rating the claimable payments.

Implemented Logic

1- The project funding contract is prepared by a committee and/or the project initiators, and submitted to DAO voting for the validation of its terms and conditions.

2- Upon validation, corresponding funds are allocated to a funding granter contract, controlled by the DAO. The project holders can start to develop, report on their achievements, request for reviews and claim for payments.

3- To evaluate and report the defined features' completion criteria, acknowledged reviewers are assigned to the project contract. They are responsible for reviewing and evaluating the features' achievements, based on artifacts & proofs provided by the project holders against the KPIs set in the project contract.

4- Once a feature completion is reviewed, it is acknowledged by the project holders and corresponding [rated] payments can be claimed.

5- In case of disputes about the evaluated completion level of a feature (impacting the rated payment amount), project holders can escalate and request for a community vote to settle.

6- In case a project is halted or is closed but has unspent funds, the latter are returned to the community funds

7- Yield farms are used for generating benefits out of stalled funds part of the treasury. Generated benefits are then distributed among the participating actors

8- A dedicated DAO governs the solution using proposals, votes and dev grants!

Technical foundations:

_ EVM compatible on-chain contracts: the L2 chains Optimism & Polygon are targeted to deploy the projects registry, factory & project contracts

_ Using āut as DAO management foundation: authentication, members ID, managing membership & roles

_ Oracles are used for evaluating project features' completion: * automated with Tellor for off-chain data requests * interactive with UMA Optimistic Oracle and its DVM (Data Verification Mechanism) support for managing disputes

_ Project grants dashboard for executors, reviewers, the assigned committee and community in general: A web UI is deployed on IPFS, as well as reference documents and AV media

_ AAVE will be integrated for yields farming of stalled treasury funds

_ ENS addresses for the payments' recipients & reviewers, to ease actors' transparency (readability & auditability)