Escrow w/ Aragon Court Arbitration

Phase 1: Research & Design

Budget: 200 ANT
Time: 2-3 weeks
Deliverable: A design doc / spec, including answers to the following questions.

How can Aragon Court be added as an arbitration provider / dispute resolver in the LexGuildLocker contract on kovan and on mainnet?
How can the escrow service (contract, front-end, and private back-end) be productized for use by any DAO?
How can variable sized milestones be supported?
Can we enable Aragon Conviction Voting to send to an escrow?

Note: answers to these questions must be executable within the Phase 2 budget and alloted time.

Which DAOs are currently sending invoices and could benefit from this escrow system? Who is our ideal "customer"?
Do other DAOs use a loot/spoils system to return a percentage of funds to their communal treasure chest?
Would this system be valuable for web3 freelancers too?
Ideally the client would only need to bookmark one link to access their invoice details. How difficult would it be to embed project ID into the escrow URL?
How long does it take for a dispute to be resolved?
How might we notify clients/providers when a dispute has been resolved?

pass the Aragon Court address as the resolver in registerLocker
Add an option (dropdown?) to the UI for leads to select the desired provider, e.g. Aragon Court or LexDAO
https://github.com/aragon/aragon-court/blob/master/docs/4-entry-points/1-aragon-court.md
TODO: What information does Aragon Court need to have to properly arbitrate?

how do we package up the airtable portion of the app?

Option 1: forgo displaying the transaction metadata altogether. This removes the need for airtable, but it sacrifices on the UX quite a bit.
Option 2: find a way to wrap an airtable and proxy server so it's easily deployable by others
Option 3: find a web3-compatible database replacement for airtable
1. fetch the list of users who should have access to a single piece of metadata
  - authorizing DAO members – from different types of DAOs! – to view the data will be a challenge
2. find a web3/ distributed storage mechanisms that support ACLs
  - maybe textile buckets or threads?
Option 4: find a non-database approach to transaction metadata privacy
does the UI (i.e., theme?) need to be customizable?
Option 5: Keep metadata, but allow it to be public.
- This fits @dan13ram's research suggesting that option 3 and 4 won't fit within the current scope
- Store metadata in JSON format in IPFS, include the IPFS hash in the details field, to be parsed by the subgraph.
- Allow users to choose their own privacy model:
  1. "unlisted" (no metadata)
  2. generically named escrows (w/ metadata)
  3. insert metadata into a document only accessible by the provider and client, and include only that URL in the JSON metadata

convert milestones parameter to a schedule of payments, i.e. milestones = uint256[]

Option 1: refactor to create a new contract for each locker, and allow direct erc20 tranfers to that locker. A separate public function can be called that checks if the deposit is sufficient, and then sets locker.confirmed = 1
Option 2: Aragon to extend Conviction Funding to be able to execute arbitrary functions upon approval of the proposal.

should confirmLocker return the locker index?
- no need; just get the index from the event
convert milestones parameter to a schedule of payments, i.e. milestones = uint256[]
consider a different approach to checking sums that doesn't lead to rounding difficulties on the front end
consider refactoring to a factory that creates a new contract for each locker