You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can install a Payments / Escrow app along with the Conviction Voting app, and when a proposal is approved, transfer the money to the escrow before before it is sent to the beneficiary. I'm going to use the Escrow app and Payments app indistinctly until we decide which name fits better the app.
When a proposal is created, it is associated with an escrowed payment in the Escrow app. A reviewer address and an arbitrator address are probably already in place since those can be Aragon permissions (REVIEW_ESCROW_ROLE and ARBITRATE_ESCROW_ROLE) over the Escrow app. So DAOs can define fixed reviewers and arbitrators for all proposals, or set up granular permissions adding custom reviewers and arbitrators per each proposal.
When a proposal has been approved, the money is transferred to the escrow payment contract (payments don't go to the escrow app directly, but to an independent contract), and the funds are released by the reviewer to the beneficiary when they consider the task is complete.
The arbitrary can be the Aragon Court, the same community via voting, or event a single entity. Beneficiary can raise a dispute to the arbitrator in case the reviewer do not release the funds appropriately, and anyone can raise a dispute to the arbitrator in case the reviewer collides with the beneficiary to release the funds before the task has been completed. Reviewer can decide to return all or part of the funds to the DAO if the task is not been completed appropriately.
The text was updated successfully, but these errors were encountered:
There are sooooo many alternatives outside of the Aragon UI to consider....
It is much better IMO to use an external escrow so that you can have interoperability for funding proposals.
Imagine CV where external donors can donate directly to a proposal to lower the amount of conviction required because donating directly would change the Asking amount of the proposal
For Example: maybe a proposal asks for Y which makes the conviction X but then someone donates to the proposal so now the proposal is only asking for Y-D and the Conviction required is now less than X
I also prefer Conviction to be displayed as a DAI amount (using the Conviction and the trigger function you can derive a $ amount) but thats a side note....
here is a list of projects that could be interfaced with:
We will wrap multiple StandardBounties contracts inside an Aragon app (similar to what TokenManager does with a MinimeToken), so we can integrate the app inside our systems, and obtain compatibility with many bounties platforms (such as gitcoin!).
We can install a Payments / Escrow app along with the Conviction Voting app, and when a proposal is approved, transfer the money to the escrow before before it is sent to the beneficiary. I'm going to use the Escrow app and Payments app indistinctly until we decide which name fits better the app.
When a proposal is created, it is associated with an escrowed payment in the Escrow app. A reviewer address and an arbitrator address are probably already in place since those can be Aragon permissions (
REVIEW_ESCROW_ROLE
andARBITRATE_ESCROW_ROLE
) over the Escrow app. So DAOs can define fixed reviewers and arbitrators for all proposals, or set up granular permissions adding custom reviewers and arbitrators per each proposal.When a proposal has been approved, the money is transferred to the escrow payment contract (payments don't go to the escrow app directly, but to an independent contract), and the funds are released by the reviewer to the beneficiary when they consider the task is complete.
The arbitrary can be the Aragon Court, the same community via voting, or event a single entity. Beneficiary can raise a dispute to the arbitrator in case the reviewer do not release the funds appropriately, and anyone can raise a dispute to the arbitrator in case the reviewer collides with the beneficiary to release the funds before the task has been completed. Reviewer can decide to return all or part of the funds to the DAO if the task is not been completed appropriately.
The text was updated successfully, but these errors were encountered: