Proposal: trustless contracts and escrow with Aragon Protocol for dispute resolution

Background

To facilitate adoption and usage of Aragon Protocol (AP) we are proposing a system for trustless contracts between Ethereum wallets with AP as a neutral arbiter in case of dispute. The long-term vision is that any user can transact with any other user using subjective agreements with an on-chain escrow system that supports any currencies (fiat or crypto), using AP as arbiter. We envision this system to change the way people and organizations transact, but only as long as it is so simple, cost-effective, secure and inclusive that users sensitive to heavy UX operations, fees, contract risks and legal risks are able to use the system without the system effectively excluding them.

A leveled field, the true democratization of trustless subjective contracts

To shed some light on how we wish to achieve a leveled field for all users long term, we assume that different networks (blockchains) will ultimately be different “countries". Those networks will represent different markets with different economies created by local and cross-chain dApps. Making dApps cross-chain will likely be a common way to scale their user base, similarly to how companies scale by launching in different countries to serve new markets. Deploying AP to different chains will expand its usage not only because it allows local dApps to use it, but it can also attract fully new customer groups which can’t use Ethereum deployment because of high fees or other reasons. Another competitive advantage of cross-chain AP deployment is that it will be easier for cross-chain dApp developers (or those who plan to scale to other networks) to integrate a cross-chain subjective oracle to streamline their workflow processes and support.

Similar to launching in other countries, language is a common barrier for an easy launch in a new network. The natural first choice for cross-chain launch should therefore be networks with Solidity language support: xDai, Matic, Ethermint based networks (e.g. Binance smart chain), Moonbeam/Plasm (to access Polkadot infrastructure) etc. Longer-term it should be possible to launch AP implementations in other networks to address their rich customer bases (e.g. Flow).

Assuming the need of launching in different networks is clear, there are two options: use ANT as a cross-chain staking token for AP or make a separate token for each AP deployment in each network.

The main advantages of using own token:

  • sovereignty;
  • increase usage of custom token which can potentially increase capitalization of that token

The main disadvantages of using custom token:

  • lower security because of lower market cap, buy-in risks (confirmed by ANJ launch feedback on Ethereum);
  • harder bootstrap for a completely new token;
  • the need to build a new community and brand for a new token;
  • the need to draft and support new Guardians, management of different tokens for cross-chain Guardians;
  • harder integration for cross-chain dApp developers if AP token is also used for utility

In case ANT is made a cross-chain token it will allow its usage not only in AP, but also in local DeFi economies. ANT investors will be able to move their holdings in different networks to stake in local AP implementations based on market supply and demand in those networks. Over time, the amount of ANT in each network will represent the market usage of that protocol in that network. We expect that smaller holders will move ANT to networks like Matic or Moonbeam to enjoy cheap workflows while whales will stake in Ethereum AP which will address larger cases where gas costs are negligible to potential gains.

Technically, ANT can be moved cross-chain using bridges (e.g. PoS bridge for Matic) or exchanges (e.g. USDT, USDC on Tron, Matic, OMG etc). It’s possible to add wrappers for local staking tokens in case direct staking of bridged ANT is not possible for any reason.

Increased usage of cross-chain ANT should increase demand, usage and value of ANT. We assume emission rights will be left on Ethereum and ANT circulating in other networks will be parked in peg smart contracts.

Deployment on networks like Matic can be also used as a test polygon for new models like branched courts and insurance coverage for dispute fees, which is also needed to achieve an inclusive and leveled field for all users and use cases. In case those models are working well, they can be extended to AP deployments in other networks. It can work similarly to Polkadot / Kusama for testing innovations.

We should also do more research if zk-rollup AP deployment can be potentially used as a long-term scaling solution for Moonbeam deployment similarly to Ethereum deployment.

We wish to emphasize that these scaling efforts should be done in a way where attack vectors are kept to a minimum at all times.

Support of more complex use cases

The contracts system can eventually be enhanced using open source libraries such as Open Law and concepts from Jur to be able to provide customizable templates supporting more diverse and complex use cases.

Requirements milestone 1 (“Contracts with simple escrow”)

While we believe these scaling & development efforts are necessary eventually to get true mainstream adoption, milestone one will be limited to relatively simple use of the contracts and escrow system on mainnet, covering use cases such as when DAOs need to enter into subjective agreements with third parties (e.g. when issuing grants to developers and development teams).

Technically, the contracts will in the first version consist of text in natural language and smart contracts. Text should be accessible and interpretable by AP Guardians and smart contracts will be deployable on Ethereum Mainnet for trustless management of contract escrow funds, with AP address used as a subjective oracle for dispute resolution.

The specific requirements can be summarized as the following:

  • Should be possible to make a contract in digital form between two Ethereum wallets expressed in plain text (Markdown);
  • Should be possible to download / view PDF artifact of signed contract on IPFS by unique hash;
  • Should allow trust-less transactions of ERC20 tokens on Ethereum Mainnet network using escrow smart contracts;
  • Should be possible to define several milestones with a separate escrow payments in scope of one contract;
  • Should have AP contract address on Ethereum Mainnet as arbiter of escrow smart contracts;
  • Should be possible for service provider to receive transfer from customer without AP interaction if there is no dispute;
  • Should be possible for service provider to initiate dispute in AP;
  • Should be possible for customer to initiate dispute in AP;
  • Should be possible for the opposite party that won a dispute to receive payment or refund;
  • Should open-source escrow smart contracts and source code for contract creation with exception to Greet integration code (see workflows).

Workflow milestone 1 (“Contracts with simple escrow”)

Alice - customer

Bob - service provider

  1. Bob onboards Alice for contract negotiation in Greet messenger (see the introduction of Greet in a separate forum post);

  2. Alice and Bob negotiate contract terms;

  3. Alice and Bob sign contract with their Ethereum wallets;

  4. Contract PDF artifact is generated and stored on IPFS with unique hash;

  5. IPFS URLs of signed contracts are accessible by both parties;

  6. Alice transfers contract amount to escrow contract with IPFS hash as metadata;

    1. No dispute

      • Alice confirms the delivery in smart contract;
      • Bob receives funds with transaction initiated by Alice;
    2. Refund by Alice (Bob is cooperating)

      • Alice asks Bob in Greet messenger for a refund;
      • Bob grants refund in smart contract;
      • Alice receives funds with transaction initiated by Bob;
    3. Refund by Alice (Bob is not cooperating, arbitrage won)

      • Alice initiates a dispute, paying the arbitrage fee;
      • Aragon Protocol (AP) rules in favor of Alice;
      • Alice executes AP decision and gets her funds back;
    4. Refund by Alice (Bob is not cooperating, arbitrage lost)

      • Alice initiates a dispute, paying the arbitrage fee;
      • Aragon Protocol (AP) rules in favor of Bob;
      • Bob executes AP decision and gets contract amount;
    5. Claim by Bob (Alice is not cooperating, arbitrage won)

      • Bob initiates a dispute, paying the arbitrage fee;
      • Aragon Protocol (AP) rules in favor of Bob;
      • Bob executes AP decision and gets contract amount;
    6. Claim by Bob (Alice is not cooperating, arbitrage lost)

      • Bob initiates a dispute, paying the arbitrage fee;
      • Aragon Protocol (AP) rules in favor of Alice;
      • Alice executes AP decision and gets refund.
2 Likes

Thanks for this detailed proposal @voronchuk. Adding escrow functionality to be used with AP and more generally to any Aragon DAO wishing to make a payment to a provider makes a lot of sense. I’m also interested to make this escrow feature available in the Aragon Network DAO launch.

What’s your estimated implementation timeline for Milestone 1?

“Should open-source escrow smart contracts and source code for contract creation with exception to Greet integration code (see workflows)” - Just want to double check here that there wouldn’t be any closed source code that would prevent us using this escrow tool with the Aragon Network DAO (without a requirement to also use Greet)

Overall, looks great! Once we have given the community a bit more time to review, I think we should open up this proposal to an ANT holder vote.

What do you think is a fair amount of funds to build this escrow feature / milestone 1?

@joeycharlesworth, thanks for taking a look at our proposal, we really appreciate any feedback and hope it can be voted by ANT holders soon!

What’s your estimated implementation timeline for Milestone 1?

We plan to deliver it in June 2021 or sooner.

Just want to double-check here that there wouldn’t be any closed source code that would prevent us using this escrow tool with the Aragon Network DAO (without a requirement to also use Greet)

Aragon can make a custom front-end to access contracts outside Greet (e.g. in Aragon Client), it will be permissionless, we’ll provide the relevant API docs. Contracts done in Greet will be possible to access as well, just without the related communication in messenger.

What do you think is a fair amount of funds to build this escrow feature/milestone 1?

We think 20k ANT would be a fair amount for this development as we don’t ask for any upfront payments and take all the risks.

1 Like

Hi everyone. I’m @voronchuk’s partner, so figured I’d also say hello. I’ve been active in the Discord forum and internal group chats for a while, but this is my first forum post.

Aside from being big ANJ/ANT holders ourselves and being very passionate about DAOs and governance in general, we wish to highlight (in a less technical way) for the community some of the benefits that all of us as token holders can reap with this initiative.

A contract and escrow system with AP/Aragon Court as arbiter, usable by any DAO or individual that wants to contractualize and transact in a trustless way, has the following benefits for ANJ/ANT holders:

  • increase mainstream adoption of products that uses AP/Aragon Court significantly
  • increase staking of ANT by jurors (eventually across many blockchain networks)
  • remove ANT from circulating supply, driving price upwards
  • help facilitate the release of AP so that ANJ holders can finally do the 0,044 ANJ/ANT lock-up

We believe this effort can kick-start quite a lot of activity and synergies across suites of products that will benefit all ANT/ANJ holders and be the start of something even more exciting. Hoping with this that we have the community’s support and that we together can bring this technology into significantly more hands over the next few years.

1 Like