DAO Payment Escrow with Aragon Court Arbitration

[spengrah]

DAO Payment Escrow with Aragon Court Arbitration

Proposal Information

Proposal description:
RaidGuild is a DAOified web3 freelancing cooperative. We currently use multi-sigs to manage funds for projects. This is great, but we like to build stuff so we’re creating an disputable escrow tool that minimizes risk for all parties involved. Clients deposit funds into the escrow contract, then funds are released as project milestones are reached. If there’s a dispute over milestone deliverables a dispute can be raised for an alternative dispute resolution (ADR) provider to block or unlock funds.

This grant proposal is to integrate arbitration services from Aragon Court into the escrow tool and to sufficiently build out the tool so it can be used by other DAOs or organizations that accept payment from clients.

We propose to research, design, and build an escrow service that uses Aragon Court for arbitration. The service will consist of a (set of) smart contract(s) accessible via a web3-enabled web application, and will be able to be used by any DAO or other type of organization that performs services for and accepts payments from clients. Our proposal has two stages, to be paid out sequentially.

Stage 1: Design & Research

Before we buidl, we seek to understand. The design/research stage of the project involves diving into the Aragon Court codebase to understand how to make the integration as smooth as possible. From there we’ll know how to integrate the services as well as communicate it’s value prop of the service to future LexLocker users.

The deliverable from this stage will be a detailed specification of what will build in Stage 2. This will describe how to best to integrate Aragon Court into our existing escrow service.

Stage 2: Buidl & Ship

In this stage, assuming no major technical blockers are discovered, we will implement the specification from Stage 1. This will make LexLocker and the RaidGuild escrow available to any Aragon DAO! This will allow DAOs and 3rd parties to optimistically engage with each other knowing that their deal is secured by the power of the Aragon Court. It will also help drive more demand to alternative dispute resolution services such as Aragon Court.

Proposal Rationale
This proposal will benefit the following constituents:

• DAOs that sell services, by enabling them to enter into more trusted relationships with clients
• ANT/ANJ holders & the Aragon ecosystem, by creating a new channel for demand for and adoption of Aragon Court

Expected duration or delivery date (if applicable):

• Design and research: 2-3 weeks.
• Buidl and ship: 4-6 weeks.

Team Information (For Funding Proposals)

The finest guilders in all the land!

• Spencer - A full stack raiding veteran with a body count of slayed demons to prove it (all the things).
• Saimano - A young warrior with experience creating shiny armor (front-ends) for dApps and DAOs.
• Ross - A rogue and a one man army. Ross can cast legal spells that vanquish even the deadliest demons.
• burrata - Burrrata likes DAOs.
• Dekan - A warrior wizard who eats balrogs for breakfast.
• Other Raid Guild members may also contribute as needed and you’ll be glad when they do.

Skills and previous experience in related or similar work:
We have deep experience writing smart contracts, building web3 applications, and designing/creating DAOs. We’re building this escrow contract to solve our own pain points. With your help we can make it available to more DAOs!

Funding Information (For Funding Proposals)

• Design and research: 200 ANT.
• Buidl and ship: 300 ANT.

Ethereum address where funds shall be transferred:
0x1eFB322082781d110027Da76BBEC399F4bF9b64a

More detailed description of how funds will be handled and used:
The team-members are co-signers of the above multisig address, and will collectively disburse funds to each team-member as reimbursement for time spent researching, designing, and building the proposed disputable escrow service.

[lkngtn]

Stoked on this proposal, Escrow would be super useful and would love to see an escrow workflow that could be escalated to Aragon Court and used by Aragon DAOs.

I would love to try and figure out how we could escrow a conviction funding proposal in this way, currently the conviction funding flow sends funds from an Aragon organizations vault/agent to a beneficiary address when a proposal is approved, could we just have the beneficiary address be a lexlocker escrow address?

[spengrah]

Thanks - we’re excited about this too!

To the question of using this with conviction funding: possibly - the current LexLocker architecture is a single contract with many escrows (“lockers”), so to deposit into an escrow you call a specific function. However, there is likely a way to configure things differently, which we can explore during our research phase and potentially build if it fits within the scope of the present proposal.

One of the nice things about LexLocker for grant-giving purposes is that supports milestones, which would allow a grant-giving org to recover funds for subsequent milestones if the recipient doesn’t deliver on the first.

[lkngtn]

@spengrah

To the question of using this with conviction funding: possibly - the current LexLocker architecture is a single contract with many escrows (“lockers”), so to deposit into an escrow you call a specific function. However, there is likely a way to configure things differently, which we can explore during our research phase and potentially build if it fits within the scope of the present proposal

Gotcha, could also explore with 1Hive the possibility of adding proposal extensions to conviction voting (not entirely sure how this looks yet), but it might be a repeatable pattern as there was a similar challenge when trying to allocate funds using conviction voting to a Colony budget which I’ve talked with @proofoftom and @Auryn about a bit.

@spengrah

One of the nice things about LexLocker for grant-giving purposes is that supports milestones, which would allow a grant-giving org to recover funds for subsequent milestones if the recipient doesn’t deliver on the first.

Yes exactly! Seems like it would make it much easier for people to support proposals if there is more assurance through milestones, and would also make it easier to support larger proposal amounts/sizes.

Will continue to support, and maybe when the research phase kicks off we can try and map out how we could potentially get this working with conviction funding so we could use it for a subsequent pilot round.

[willjgriff]

@spengrah

To the question of using this with conviction funding: possibly - the current LexLocker architecture is a single contract with many escrows (“lockers”), so to deposit into an escrow you call a specific function.

Tbh I think it would be useful if conviction voting was a forwarder to call arbitrary functions. I’m working on adapting the court for 1Hive and it would have been useful if conviction voting was a forwarder for depositing subscription payments to it. I’m going to look into it but would still be curious if the escrow could be architected without having to call a function, just as an educational exercise.

[spengrah]

@willjgriff

Tbh I think it would be useful if conviction voting was a forwarder to call arbitrary functions. I’m working on adapting the court for 1Hive and it would have been useful if conviction voting was a forwarder for depositing subscription payments to it. I’m going to look into it but would still be curious if the escrow could be architected without having to call a function, just as an educational exercise.

Yea, I think this is worth exploring for sure. Will see what it could look like during the research phase of this proposal, and then take it from there either in this proposal (if it fits) or as a follow-up project.

As a general comment, different use cases (e.g. grant-giving vs. service payment vs. something else) will likely require different functionality from an escrow service and there’s value in keeping scope small for security purposes. But there’s also value in a general-purpose escrow that can serve multiple use-cases because a single design can accrue a (money-weighted) lindy effect faster. So there’s definitely an optimal balance to strike there.

[spengrah]

@lkngtn

Gotcha, could also explore with 1Hive the possibility of adding proposal extensions to conviction voting

As I think about this more, I think its the better approach. My (still nascent, of course) reasoning is that generalizing execution of conviction voting makes more things possible than abstracting escrow creation/deposit as a transfer, which makes it a better option towards which to allocate resources.