Financial Proposal: Aragon Court deployment on Arbitrum

Proposal Information

Proposal summary:

Deploy Aragon Court to Arbitrum to facilitate more adoption and cross-chain usage without unbearable associated gas costs.

Previous work on the proposal area:

Early discussions and suggestions are here. After meeting with the technical committee, we think Arbitrum is a better choice for canonic deployment as it will also house some future Aragon development that will use Court.

Proposal description:

As most community members know, Aragon has strived to deploy its products to more cost-efficient blockchain networks to facilitate more adoption. Since Aragon is building products on Arbitrum which will use Aragon Court, it seems to be a natural chain of choice for L2 deployment.

Deployment of Aragon Court (Aragon Protocol) on Arbitrum is essential because it would allow Guardians to rule on cases without experiencing unbearable gas fees. However - while a lot of dApps are cross-chain nowadays - these deployments are independent of each other. So technically, they’re autonomous deployments under a single frontend. Our take is that for Aragon Court, a simple cross-chain deployment is not enough because most DAOs are still on the Ethereum network. The ideal solution would be a MetaDapp, where you can dispute an Ethereum case on Arbitrum. It will significantly reduce the associated gas costs for Guardians, allowing them to resolve Ethereum cases filed to the Arbitrum deployment of Aragon Court. The final goal is to make any case on any Solidity compatible chain disputable in Aragon Court deployment on Arbitrum.

How can it be achieved? Stage one is a standard deployment to the new network - Arbitrum. Then we need to onboard Guardians to that new deployment. We think that the best way to do it is staking rewards in ANT paid on Arbitrum for Guardians with staked ANT tokens on Ethereum. In such a way, we’ll be able to onboard experienced Guardians who were already using Aragon Court.

The next stage would be implementing a holistic resolution registry synced between all networks where Aragon Court resolutions are needed. However, we’ll need to use deterministic dispute UID, which will be unique for all networks. The simplest UID would be the hash of chain id and current dispute id in integer form: keccak256(abi.encodePacked(chainId, SEPARATOR, disputeId)). An even better solution would be to include a secondary UID, so it’s possible to identify the case in a network-agnostic way. For the Greet Escrow solution, UID can look like keccak256(abi.encodePacked(cid, milestoneIndex)). This UID should be included in dispute on-chain events of Aragon Court and can be passed either as dispute-related metadata or as a separate function argument for dispute initiation.

Finally, to publish results for his case, any user can post a resolution to the optimistic Resolution Registry by deterministic id with some collateral (150 DAI) and proof on Arbitrum. Thus, an Oracle network will be able to challenge it in scope of 7 days before it’s finalized in the registry. After successful finalization the user can withdraw his collateral. Greet can develop the open-source code for such Oracles, which we release as a Docker container.

Based on this we’d like to discuss with the Aragon community the following proposal;

Milestone 1

  1. Deploy Aragon Protocol (Court) smart contracts to Arbitrum;

  2. Deploy ANT token to Arbitrum;

  3. Implement a staking program for guardians who keep ANT locked on Ethereum with rewards on Arbitrum.

The implementation of the staking program depends on the outcome of an independent vote for this staking program by the Aragon community. If it is not a successful vote, we only do step 1 and 2.

Milestone 2

  1. Develop and deploy Aragon Protocol resolution registry smart contract to Ethereum, Polygon and BSC;

  2. Implement the resolution registry in Greet Escrow as a new dispute resolver smart contract;

  3. Develop docker image for Oracle network validators to challenge optimistic confirmation of Aragon Court resolutions for the generic and Greet use cases.

Proposal Rationale:

With the current gas fees on the Ethereum blockchain, the cost of running a dispute would start from 2000 DAI in total expenses, which makes it hard to justify for small to medium cases. Furthermore, the guardian chunk of those fees barely covers the gas costs associated with their voting process. Therefore, if we wish Court, Govern, and future products to succeed, we must allocate the main chunk of fees to guardians, not the blockchain infrastructure.

Increase of active Aragon DAOs
Implementation of this proposal not only improves the related DAO tooling and utility of ANT token, as it will be easier, cheaper, and safer to work as Aragon Guardian. It also paves the road (with the adoption of deterministic ids in Govern which is not part of this proposal) to the launching of Govern-based Aragon DAOs in any Solidity-based chain without the need to deploy and onboard Aragon Court on those chains. The deployment of Aragon Protocol on Arbitrum will also be used in the upcoming new version of the Aragon DAO engine on this network, so it’s either a hard or soft requirement to make it possible to launch new DAOs on this engine. To summarize, we believe that this proposal both increases the utility of ANT tokens and paves the road to more cross-chain adoption, which should increase the number of Aragon DAOs.

Limitations of any benefits mentioned above:

Milestone 1 may require an independent security audit if so voted by the tech committee. Smart contracts for milestone 2 will require an independent security audit for sure, at least I would vote for that. At the delivery stage, challenging of collateralized resolutions will be permissioned. AN DAO can add and remove such oracles on Ethereum. BSC and Polygon registries will be managed by multisigs, owners will be nominated by AN DAO.

Expected duration or delivery date (if applicable):

Up to 3 weeks after it’s voted and funded for milestone 1, up to 6 weeks for milestone 2 on the same terms. It may be delayed based on arrangement, results, and execution of the independent audit.

Team Information

Names and/or usernames, preferred contact method, and/or relevant social links for team members (Twitter, Github, Aragon Forum, etc.):

Skills and previous experience in related or similar work:

The Greet Team already developed an advanced Contracts & Escrow solution integrating Aragon Court deployed to Ethereum in October. The first deal on Greet was the Aragon Association grant payment.

Funding Information

Milestone 1

Amount of ANT requested: 2000 / 3500 / 5000 ANT as voted by the AN DAO

Milestone 2

Amount of ANT requested: 4500 / 6000 / 7500 ANT as voted by the AN DAO

This funding doesn’t cover an independent audit, it should be arranged by the AN DAO tech committee and financed by AN DAO or Aragon Association.

Escrow where funds shall be transferred:

More detailed description of how funds will be handled and used:

The Greet DAO treasury will keep ANT, and fund development from its operational budget. Our expenses will be work compensation and gas fees for deployment and tests.


Thanks for the proposal @voronchuk .

Resolution registry and oracle network for syncing the results requires more research and separate proposal.

Would it be possible to bundle this within the same proposal so that the community can vote on a more complete working solution? Perhaps with 2 separate milestones.


Yeah, I can add how we see the scope of the second milestone, for a final solution. We are still not sure about the budget for it, as it has more moving parts (audit and onboarding of oracle network). Though we can make a separate vote for the budget of Milestone 2 at some later point if the general direction is approved by the Aragon community.


@joeycharlesworth I did my best to include the full scope in this proposal with suggested timeline and budget for both milestones. The audit which we can’t estimate at this moment, will be arranged by AN DAO tech committee and funded separately by AN DAO or AA. Oracle network for challenging optimistic resolutions will be controlled by AN DAO, we’ll provide the open-sourced code for verification and run one of the nodes if approved by community. AN DAO can later replace it with another solution, as it will be a governor for the resolution registry smart contract.


@voronchuk - I am speaking generally in my own stead; however, in my opinion, this is an excellent and well-crafted proposal. The introduction is well-written, comprehensive, and thorough. Even refined to milestones. This is truly exemplary.

cc @eaglelex @ronald_k


Thanks for your kind words :slight_smile:

1 Like

@voronchuk - can you please add a section detailing why you believe this proposal will increase the number of Active Aragon DAOs?

This is a requirement of the AN DAO Charter for finance proposals. “Description of why the author believes it will help to increase the number of Active Aragon DAOs” - as per AN DAO Charter

1 Like

I have added this section under “Proposal rationale” block.

1 Like

Added 14 days vote on Voice: Aragon Voice - the ultimate solution for creating and managing proposals and voting in a decentralized, cost-effective, and secure manner


For those who may wonder about the security of the proposed design, we essentially follow the idea of an optimistic rollup. While the proposed challenging solution will be basic at the start, there is a clear path to make it fully trustless following the Arbitrum implementation: Arbitrum Rollup Protocol · Offchain Labs Dev Center

1 Like

@voronchuk can you clarify for me please why the big difference in price options 6500 ANT - 12500 ANT. This is an excellent proposal and I will certainly vote FOR but because of the grant range, I’m wondering if I’ve missed some important understanding of budget constraints/opportunities.

For bigger proposals that are harder to value, it’s a price discovery mechanism for a community how much they’d be willing to fund to make it happen. We generally follow the mechanics of our previous proposal and others.

The first bracket is the minimum we’d be willing to deliver, the second is the budget we want, the third is to make it a priority for us. In this case, a combined budget for both milestones is provided, to reduce the number of votes.

1 Like

Cool thank you.

Can I request including this quick explainer in future proposals, as super helpful for understanding the budget request. I will vote (not that there’s much weight behind it) for a priority budget

1 Like

Can you elaborate on this closer? Because doing this in an actual decentralized and trustless way isn’t such a small thing, definitely not a 1-2 man show, and probably also not smart to have our own solution instead of joining eg Optics in the development. :slight_smile:

Overall do I think that we probably better first should think about a general multi-chain/interoperability strategy of Aragon.

Also with the current product market fit Court has (6 disputes and all are trainings: Aragon Court Dashboard) is this from a strategy perspective not the most import thing to solve. I think this proposal does mostly help the third party product Greet instead of the Aragon Network itself.

1 Like
  1. With a current gas cost it will be hard to have a proper product-market fit as the product is just too expensive for the guardian usage compared to the rewards guardian gets.
  2. The idea is to have a usable in production Court deployment asap. The proposed solution makes it quite trivial to switch to any other oracle network when they provide all the functionality we need e.g. Optics or others. So it should be in tune with whatever general multi-chain/interoperability strategy Aragon decides.
  3. We think that 3rd party solutions like Greet would be the main source of dispute cases, compared to Govern / V2 usage. So while we agree that we need this in Greet, but it’s the Court guardians who need dispute cases, not Greet. Still, it’s important for Govern and V2 that guardians are kept engaged and regularly trained in Court usage, so that when those disputes occur they are ready to deal with them.
  4. This proposal includes permissioned challengers which AN DAO can vote for, Greet can run one of those. If in general multi-chain/interoperability strategy Aragon agrees with the optimistic challenging approach of Arbitrum we can go forward with that: Arbitrum Rollup Protocol · Offchain Labs Dev Center Otherwise it can be replaced with another solution according to this strategy which will suffice the needs by a vote of AN DAO who will be an operator of the resolution registry.

This solution is low risk, as AN DAO retains control over the ResolutionRegistry and can change oracles so it is in tune with future developments. ANT holders also retain control over Aragon Court on Arbitrum and increase the utility of their tokens.

  1. This is an assumption but I think definitely a pain point. But not how proper product resp human-centered development is done. First, we have to have multiple user research cycles, etc. to validate assumptions and to define the biggest pain points our (if there are any) customers do have.
  2. There is no rush required.
  3. The go-to market strategy is something a Court Squad/Guild should define.
  4. Has to get validated accordingly with an ANDAO community initiative and Tech Squad.

How risky this solution is from a strategy and tech perspective is not fully analyzed and increasing the utility of ANT is an argument but a way bigger topic and can’t be used here as a political argument.

This proposal is not well thought through and I recommend as an independent member of the ANDAO to vote against it. Priority one within the ANDAO is now to define first an overall strategy with clear goals for the network in the next X years. And to make it clear, it isn’t the case that I don’t see the importance of a well working, legally recognized, and cheap digital dispute resolution within the Aragon Network and in the broader Web3 space.

With all respect, could you elaborate on this please?

  1. This proposal has been in discussion stage since Sep 23 (2 months), but despite @voronchuk poking you several times you haven’t taken your time to review it before -after- the vote is published, and now you say you want veto the whole thing. That’s quite detrimental to the whole process.

  2. What do you mean by there is “no rush required” to make Court work after years of development? I assume you acknowledge Court as a product that is meant to have integrations with 3rd parties, not just as internal product for ANDAO? From Greet’s perspective we are in production with a functional product and absolutely need to go-to-market as soon as possible, but the product we integrated to, Court, a core dependency - does not scale; Fees are way too high, and Guardians are yet to get the necessary training. So we really have spent lots of time trying to resolve this for the benefit of both parties with this proposal.

    Even with ANDAO there are contributors like @mheuer that tries to use Greet for ANDAO proposals but face harsh fees (Metagovernance/Financial Proposal: A Git-Versioned AN DAO Charter). So maybe we could ask contributors like him if there is any rush or not.

  3. So you want to support a completely new go-to-market strategy that does not acknowledge current integrations & plans?

  1. I can’t veto without the whole tech committee. As said “I recommend as an independent member of ANDAO to vote against it”.
  2. I explained the point of lack of ANDAO strategy etc. so… one after the other before we send money around.
  3. What was the old go to market strategy? I don’t know about :slight_smile:

I think somehow there has to be acceptance of having diverge opinions and even better if elected members of committee X do not always agree. It proves the integrity of the individuals.

The point is we’d like your input while proposal was in discussion stage as we are time sensitive and we would have been happy to make any adjustments based on this input. Also that you acknowledge that a network typically has integration partners that depends on its products. It sounds like you don’t care about partners like us since you say it’s no rush and suggest to start from scratch and completely re-define the go-to-market. It should be obvious that at least part of this strategy was to support the escrow usecase, as if not - why facilitate an integration with Greet.

What’s your suggested way forward then? Let’s be constructive and make this work for both parties. For us the only objectives are that we have a Court that is possible to use for Guardians (low enough fees), that they receive the necessary training for escrow usecases, and that this is achieved within a short timeframe as we took this initiative already 2 months ago and we depend on it now to get traction. I’m sure also that ANT holders that are staked in Court also would appreciate if we found a solution here.

Can you elaborate on this closer? Because doing this in an actual decentralized and trustless way isn’t such a small thing, definitely not a 1-2 man show, and probably also not smart to have our own solution instead of joining eg Optics in the development. :slight_smile:

There is always a seduction for a lawyer to veto things where they see any potential risk. Morally it is the easiest approach, as if smth goes wrong, one can always say, “I was against this” and do not do any more work to resolve the challenge. Finding a solution is what differentiates a “good” from a “bad” lawyer. We do not wish the tech committee to become “bad” lawyers in this sense. The proper approach would be to prove that the suggested solution is insecure or propose a better alternative given the requirements, including the time constraints.

Create dispute operation includes the number of options and metadata createDispute(2, metadata). Currently, court UX supports only two option disputes, so metadata generates all its content. Taking this, to prove the validity of resolved case on Arbitrum, we need to validate that metadata is the same as would be on Ethereum.

In a proposed solution, a metadata validator will be the task for the challenger, which will do the following operations:

  • Monitor ResolutionRegistry for events on Ethereum
  • As soon as a NewResolution event is submitted, it will fetch the dispute metadata and resolution from submitted proof on Arbitrum.
  • It will compare resolution from proof with proposed resolution in ResolutionRegistry, seize the collateral and invalidate the proposal if it is different.
  • It will generate metadata by deterministic dispute uid based on the relevant Ethereum smart contract. In the case of Greet, it will be the following: bytes memory metadata = enforceableSettlement.generatePayload(_termsCid, _feePayer, _index, _multiMilestone); Seize the collateral and invalidate the proposal if metadata is different in a provided Arbitrum proof.

This code will be open-source and usable as a docker container, runnable by any party approved by AN DAO. Greet can be one of those parties. This solution has a clear path to decentralization by following the escalation game similar to Arbitrum: Arbitrum Rollup Protocol · Offchain Labs Dev Center

We are open to any other solution that will achieve metadata validation with an existing working solution.

What should be in mind for existing “easy to plug” solutions like Connext, which I generally like a lot? For simplicity, we would put the challenges of dispute initiation, like paying fees with different tokens on different networks, out of context. Our primary concern is secure bridging the results from Arbitrum to Ethereum. For Connext, the general flow would look smth like that: ResolverContract (Arbitrum) → TransactionManager (Arbitrum) → TxService (Mainnet) → ResolutionRegistry (Mainnet). TransactionManager is a permissionless contract, so anyone can forge the input and achieve the same results: Forger (Arbitrum) → TransactionManager (Arbitrum) → TxService (Mainnet) → ResolutionRegistry (Mainnet). We do not see a clear way how ResolutionRegistry can verify that TxService provided proper resolution without using a trusted signer, which can validate it. If using a trusted signer for any reason is acceptable, there are easier ways to resolve the whole task without Connext.