Aragon Flock proposal - PanAragon: Aragon for All

agp
#2

Welcome @mariapaulafn thanks for sharing the proposal! An admin note:

(i cant mention the rest due to the forum’s rules)

You should be able to tag more people now :slight_smile: feel free to dm me for help if the forum gives you any more trouble posting.

1 Like
#3

Thanks so much @light! tagging the rest of the teams as they would like to answer questions - if there’s some :slight_smile:
have a great eve!

#4

Hey PanAragon team,

First thanks a lot for your proposal and for your interest in the Flock program, your enthusiasm for Aragon is highly appreciated.

There are lots of things in your proposal, some are new and some are topics Flock teams already have come across or are addressing in their roadmap. In the Flock Program teams work together towards common objectives. Therefore, the two main things we’d like to highlight here:

  1. Flock proposals have to be thought according to current Flock teams and applicants. It is crucial to go through each item and check that they integrate seamlessly with other Flock teams’ roadmaps. This is especially true in a time of limited financial resources where we want to minimize overlaps between teams work.
  2. Teams financed through the Flock program are 100% dedicated to building on Aragon. A Flock team cannot work on external projects. This is a reference to a passage of your proposal: “Works on Aragon infrastructure and new apps that work both for Akropolis and as standalone apps that can be plugged into other Aragon DAOs.”

In addition to these 2 points, here is a list of things that may require further thinking:

  • Financial interoperability tools (chamas systems) vs. Aragon Network Court: if I’m not mistaken both could be used for similar use cases. For example the Aragon network court could be used to oversee financial contracts in the network.

  • Revenue generation and product market fit: Glad you’ve taken these seriously. They are recurrent topics among Flock teams lately and market-fit is in the roadmap of pretty much all the teams (both current Flocks or applicants). Coordination and cohesion around this is key. How do you plan to deploy the solution in Kenya concretely? I don’t want to dismiss Kenya as a target market, but I’m not 100% convinced its a relevant target for Aragon (yet!).

  • Cross-flock Collaboration: It would be interesting for you to get advice of other Flock teams to see if they can validate/infirm your propositions in the “Cross-Flock Collaboration” section of PanAragon’s proposal.

  • About I02 Identity solution: as you pointed out several Flock and Nest teams or proposals are working on Identity solutions (AragonID, BrightID, Autark, this Nest proposal). Financing another team on the topic has to be thought very carefully for treasury management concerns.

  • About I03 Mobile Client: would the app be a standalone app or a piece of the Aragon ecosystem? Do you have a PoC or something the community could have a look at?

  • I01 Scalability Solution: is potentially the initiative we are the most excited about and where overlap is lowest. This is especially true when looking at the possibility to extend it to become the Arachain.

To wrap up, I’d say that the proposal needs further discussions in regard of the Flock program. These can easily take more than a month, that’s why we recommend teams to apply as early as possible.

One alternative we can imagine here is for you to submit a Nest proposal adapting the items from the PanAragon proposal that have the best fit with current objectives. This is usually a great way to start contributing to Aragon and to get teams to know each other’s work.

1 Like
Our new Nest proposal + Bug/Feature we found when building :) (PanAragon stage 0)
#5

Totally. Hi there @stellarmagnet @osarrouy @cemfdagdelen would you mind reading the proposal? we would love to collaborate with you in the points we state but need feedback - thanks

1 Like
#6

Thanks for this, Louis - we have studied all proposals (even the rejected ones) before writing this- if you see any inconsistencies, let us know and we can fix it.

Sure, this makes perfect sense. Two questions: the Akropolis team is made of 12+ people. We only need 5 tops for PanAragon - the others are free to work in other projects right?
Also - does this apply to part-time contractors?

#7

Yes, this is a possibility - an essential question here: does Aragon want one single solution throughout all frameworks for dispute resolutions, or would you be interested in teams exploring alternatives? eg. the Level K proposal on Futarchy.

#8

PanAragon team – this is a very intriguing proposal with a lot of great ideas. Here is some high-level feedback:

  • I think you should explain what a Chama is in the proposal — the financial model worksheet is a bit confusing. Probably also include some background on mPesas system - does this initiative plan to create a currency to replace/compete with mPesas? There is mention of Aragon financial sustainability, but the spreadsheet doesn’t define what percentage of the profit would be distributed back to the Aragon Network (or at least I’m having a hard time deciphering that).
  • The proposal is very Chama-focused, but it seems like it can be made more generic so the tools can be used for organizations that do not classify as Chamas.
  • “Works on Aragon infrastructure and new apps that work both for Akropolis and as standalone apps that can be plugged into other Aragon DAOs.” --> The proposal never described what Akropolis is - I see it’s your organization name – is this the name of the app that will have an aragonOS backend?
  • The proposal covers a lot of ground, and it’s unclear if the goal is to accomplish this all within the 6 month timeframe. Considering this would be a new team to the Aragon Network, I think it would be more beneficial to trim the scope of the proposal.
  • Many teams that have been developing Aragon Apps as part of the Nest program have run into delays with shipping everything described in their/our original proposals.
    • Autark is 6+ months behind schedule from the original Nest proposal and have had to make sacrifices with features as well once digging into the framework.
    • Pando recently launched to Rinkeby 6 months behind schedule (have also had to make feature sacrifices, omit features, and pivot).
    • Level K - I haven’t seen a Rinkeby launch announcement? Hence that may also be about 2.5 months behind schedule (estimated for 3 months, but at 5.5 months now). Level K team - please clarify.
    • Protofire who took on completing the Payroll app underestimated their timeline, and Aragon One took on completing the work.
    • I don’t think the Wetonomy team were able to fully deliver on their proposal as well, and had their funding cut.

On a related note, check out this forum post I just created to understand some of the current limitations: Cross Application UX Initiative: Part 1

Feedback per initiative

I02-1 DAO Financial Interoperability

There is a lot described in this section and it’s a bit high level/vague. It may be better to go into details on how some of the functionality would be accomplished within the context of Aragon.

I02-2 DAO Documents storage & Law contracts

We are going to integrate blockchain-enabled legal agreements into the creation and operation of DAO (in collaboration with Ross Campbell of OpenLaw), as well as for cross-DAO interaction.

I think Ross’s work on interfacing legacy organizations with DAOs is very important and this is a great part of the proposal

We have already commenced working with Ross on DAO-to-DAO loan agreements, tailored constitution documents and co-investment agreements.

The intention of Aragon Court is to make progress on solving DAO-to-DAO agreements, especially the dispute aspect. Can you describe how you see the collaboration with Ross fitting into the court system?

I02-3 PanAragon Identity

  • Individual profiles. Allows individuals to create a user profile, match it with a human-readable identity (name ENS / mobile phone number/email address).

Indeed the Autark team will be making progress on identity in the next few weeks, and I am happy to see that collaboration was mentioned in this proposal (disclaimer: the contents of this proposal was not discussed with Autark beforehand).

I see you have a proof of concept for the Chamas Passport which is your solution – can you describe the technical approach? It looks like an interesting multi-contract system, but I can’t seem to personally wrap my head around it.

  • A single entry-point for interaction with all organizations in which the user is. A user profile is used for registering membership in an organization and allows you to create a single interface for managing all organizations (in the same way that Slack supports participation in different teams). A user in a single interface can view all the DAOs in which he is a member, manage the permissions and privileges that he has granted to various DAOs.

There are definitely some similarities with what we are trying to do at Autark with being able to see all of your DAOs in a single interface as the first step. Right now permission management across DAOs takes a few clicks and is limited to one DAO at a time (click on DAO Switcher, then click on Permissions app for the DAO), but I can see it being interesting to have an understanding of all your organization’s privileges in a single interface.

I03-1 Mobile client

This sounds much needed, I think Aragon One will be making progress in the Mobile client in the next year, although I am not sure how much a user-focused DAOshboard is in their priority.

1 Like
#9

Sorry for my delay, i was doing two forum posts in parallel!

1 Like
#10

Right - so we are building a generalized solution, Kenya is just an example, a very relatable one too, this is about emerging markets which are the first on crypto adoption. Adoption will happen in emerging markets or at an enterprise level. We have also been researching enterprise but thought it was too broad to include in this proposal, so we chose the Kenyan product market fit, but it is definitely not restrictive to it. See this very simple primer I posted yesterday on other organizations that could benefit from this.

#11

Aragon Court and Chama Ineroperability functionalities are different. (AFAIK) The purpose of the Aragon Court is Dispute Resolution and it works with standard financial transactions. The purpose of the Chama Interoperability tool is in providing new forms of financial cooperation for DAOS in addition to sender<>receiver interaction:

  • lending: collateralised / uncollateralised/cashflow-collateralised
  • savings
  • joint investments.

These forms of financial interactions are hard to implement using tje existing tools + Aragon Court. In our opinion, it is necessary to build additional framework to such kind of operations.

#12

Thanks a lot @stellarmagnet for the comprehensive feedback :slight_smile:

To your questions:

Good point, actually there is a slideshow on chamas in the proposal, we presented it as additional to keep it short. See it here.
NOTE: The financial model is planned for PanAragon and the monetisation of the whole Aragon ecosystem /ANT holders. Chamas or other coops are only the usecases to be able to earn revenue. The model is for the Aragon community.
Noting this to add to the proposal though!

As mentioned to @LouisGrx : " Right - so we are building a generalized solution, Kenya is just an example, a very relatable one too, this is about emerging markets which are the first on crypto adoption. Adoption will happen in emerging markets or at an enterprise level. We have also been researching enterprise but thought it was too broad to include in this proposal, so we chose the Kenyan product market fit, but it is definitely not restrictive to it. See this very simple primer I posted yesterday on other organizations that could benefit from this."
Will also add some copy on this.

We have worked on some infrastructure and new apps for Akropolis, that we can repurpose with the necessary time and funds, for Aragon - the names of the apps are TBD, we need to brainstorm :slight_smile: (fyi - the team working on PanAragon will focus solely on Aragon)

If you see the monetisation plan, it is not for chamas but for PanAragon, I think the misunderstanding is there. The financial model shows PanAragon will run for at least 4 years and what it will give to the Aragon ecosystem, not for chamas. We aim to build the proposal in 6 months, and if needed to do further work on scaling, apply again for a new grant.
We have researched Aragon for +3 months and we believe we can accomplish this - the team is formed and working together already so there are no onboarding delays, it is a realistic timeline for us.

We are already validators on Polkadot and exploring parachains. Aragon is exploring too. The Arachain has been mentioned to be possible to build in Polkadot, and through our tools (chama interoperability) and contributing to the Arachain research + implementation, we think we can accomplish this. We are advanced in our Polkadot research, and we believe this can only move the Arachain forward.
We are talking about building 2-layer solution for voting using Substrate, for instance. This implementation could be used as a basis for the Arachain. We can also help Aragon to migrate from Ethereum to Arachain.

Our mobile client is thought out to work on even the cheapest smartphones - this is really important for emerging markets. We hope we can also contribute to the Mobile Client of Aragon One.

Legal comments and Identity coming soon :slight_smile:

#13

As mentioned above: We are already validators on Polkadot and exploring parachains. Aragon is exploring too. The Arachain has been mentioned to be possible to build in Polkadot, and through our tools (chama interoperability) and contributing to the Arachain research + implementation, we think we can accomplish this. We are advanced in our Polkadot research, and we believe this can only move the Arachain forward.
We are talking about building an 2-layer solution for voting using Substrate, for instance. This implementation could be used as a basis for the Arachain. We can also help Aragon to migrate from Ethereum to Arachain :slight_smile:

#14

@LouisGrx @stellarmagnet many thanks for your feedback, we know it has been short notice for reasons outside of our control, so your responsiveness is much appreciated.

@mariapaulafn did a great job addressing your prior questions, so let me just pick up on the remaining ones. For convenience, I shall compile them below into a Q&A.

I02-3 PanAragon Identity

Indeed the Autark team will be making progress on identity in the next few weeks, and I am happy to see that collaboration was mentioned in this proposal (disclaimer: the contents of this proposal was not discussed with Autark beforehand).

I see you have a proof of concept for the Chamas Passport which is your solution – can you describe the technical approach? It looks like an interesting multi-contract system, but I can’t seem to personally wrap my head around it.

Currently, to the best of our knowledge there is no single interface where a user could see all DAOs she is a member of, manage their settings and permissioNs. Chama Passport serves to address that. So what is Chama Passport? It is an application built on AragonOS that functions as an SSO (Single Sing-On) whilst maintaining a dynamic ENS for each user, e.g. alex.chamapassport.eth. In that sense, it is like a decentralised Google SSO for AragonOS services, and for cross-blockchain services on AraChain in the future;)

What excites us is an ability to create a DAO on the fly from her ChamaPassport interface. What we therefore see here, is a more familiar and generalised UX, and ability to create and configure DAO-to-DAO interactions directly from a user’s ChamaPassport.

We started experimenting with AragonKit to this end, and the work is not over yet. However, the immediately apparent benefit of the solution is the ability to attract new users and developers to the ecosystem through familiar and easy UX.

I02-2 DAO Documents storage & Law contracts

I think Ross’s work on interfacing legacy organizations with DAOs is very important and this is a great part of the proposal.

The intention of Aragon Court is to make progress on solving DAO-to-DAO agreements, especially the dispute aspect. Can you describe how you see the collaboration with Ross fitting into the court system?

As @mariapaulafn has covered above, the main application area is creation of legally recognisable – in the “meatspace” – DAOs, e.g. LLC, LLPs, that can claim property rights to real assets, enter enforceable contracts, and protect its members from liability. Our intention is enable them exchange value freely between each other and external parties. Based on our analysis of AragonCourt so far, an additional framework is required to be built to allow for that.

So, what’s next? We are grateful for everybody making the time at such short notice, and we will reflect your feedback in a revised proposal which will be pushed to github tomorrow. Separately, I shall add my thoughts on monetisation scenarios illustrated by a summary financial model we provided, and how we see the model evolving over time.

Have a good evening, everybody!

2 Likes
#15

Hi María Paula,

Thanks for posting this proposal, we are not a flock team (yet :crossed_fingers:) but as you tagged us for a feedback here it is:

I01 Scalability solutions

As already stated by previous reviewers, this is critical to the Aragon ecosystem. Such a solution+ the edgeware lockdrop AGP proposal would be a good way to expand interoperability and diversify holdings while keeping our current development efforts and ETH reserves.

A nest proposal towards building a compatibility between Aragon and Polkadot parachains +laying the groundwork for Arachain would be a good opportunity to prove the team can deliver and start building relationships with teams (flock or nest) in the rest of the Aragon ecosystem.

I02-1 DAO Financial Interoperability

Interesting but as many as 4 different complex systems would require more details (a technical and economic paper and sketches)+planning.

I think corporate accounting standards are important but also tools for individuals such as taxes filing could be interesting altho the multitude of jurisdictions make this exercise difficult. Exporting a DAOs csv files to an existing tool would probably be much less of a headache and bounties around pulling data from an Aragon DAO API would be useful.

I am well aware of the work of Akropolis on pension systems and one medium term deliverable could be a bridge between current pension and health insurance systems and the payroll.

A long term goal of the digital jurisdiction would be to have easy bridges/tax treaties between the Aragon jurisdiction and nation states framework.

I02-2 DAO Documents storage & Law contracts

One of the objectives of Aragon Black and other prospective teams.

For the moment we are working on the IPFS pinning system that can be used across Aragon apps and that would be useful for this use case. We have also started discussing with open law’s team how to create a bridge between their syntax and API on one side and the aragon client on the other.

The notion of variable permissions for viewing documents in a DAO (private repositories) is part of the long term roadmap for the Pando App. I believe espresso is also working on storage solutions for DAOs and am also aware of some nest proposals in draft stage around this type of integration.

I03-1 Mobile client

This would be more a section of the eventual aragon mobile app than a standalone. Too early for the proposed timeframe but promising for the future.

Regarding the Chamas: while I agree the use case of disrupting so called “fintech providers” is a priority from a social and financial sustainability point of view in the medium to long term:

  • The technical features required for this are IMO already existing and planned, for example the Agent App could interact with any lending protocol on behalf of the DAO instead of redeveloping a financial protocol from scratch
  • Multi contract apps thus still need to be developed
  • Adoption of crypto in Kenya… mpesa is universally adopted because it runs on top of a centralized low-tech environment such as SMS

Where Akropolis dev talent could be deployed would be creating a general framework or library for building financially oriented DAOs using a combination of the agent app, that planning suite, voting, finance etc in a multi-contract app.

Hope this will be useful for calibrating the proposal :slight_smile:

3 Likes
#16

Hi @DanielS lovely to e meet and awesome feedback.
We are looking at it with the team and you have really great insights - much appreciated.

The Nest proposal is a great idea and we are taking it with serious consideration. Just waiting to see what happens with this one - but of course we’ll build one over night if we have to - last sprint!
We are skeptical about Edgeware yet, not because it’s a bad idea, but because there is certain lack of depth. Our full focus is Polka, but happy to help review this possibility.
We think we can help build the Arachain - and Edgeware will be helpful but not super necessary. Our team is already building on Polka as mentioned, so we’re more than ready.

100% for the more comprehensive information - this is what the team wanted I adviced to shrink down the proposal on fear to turn too long and tedious.
The deliverables make sense, we have a few things on PoC from our previous work so this should not be a problem.

This is one of the spots where we could see us collaborating with Pando, hence why I tagged you to get your input :slight_smile:

This makes sense too. For our mobile client, we would like to simplify functionalities as much as possible for adoption to be possible on emerging markets. If we want a real world userflow, we need to build for them. Maybe makes sense to develop a more complex one (with Aragon Core/Pando/Autark) and a “light one” for the emerging markets.

Again, thanks. And all the best for the AGP, your proposal is stellar.

1 Like
#17

NOTE: Please note that the description of the monetisation strategies below pertained to our original FLOCK proposal, which we intend to submit at the next AGP to allow the community more time for consideration. These points remain valid and we are happy to flesh them out over the course of the next few months. In the meantime, we have updated and are submitting a revised shorter proposed under the NEST route.

Our original grant proposal shared our ideas about how best to bridge Aragon ethos and mission that we share with the real-world use cases using our product-market-fit research to date. Due to short timeframe for consideration, we are submitting a shorter proposal for the NEST vertical, as recommended by the Aragon and intend to be applying for FLOCK vertical for the next AGP, as it has been recommended to us.

A core objective of our PanAragon proposal is to bring a dose of pragmatism to what we all agree is an important technological and societal mission. A long-term outlook requires long-term funding. We are here to propose how long-term funding can be addressed, what models have worked historically and what new approaches can be considered. Happy to flesh this out in more detail if there is sufficient interest on the part of the Aragon community and AA.

The post is broken down into these main parts:

  1. OSS monetisation strategies proven to work to date
  2. Monetisation strategies for decentralised networks
  3. Aragon ecosystem financial sustainability proposal

1. What OSS monetisation strategies have been proven to work to date?

Historically, OSS monetisation strategies have been limited to integration work. RedHat and Linux have built multi-billion dollar companies focussing on OSS integration with enterprise clients. RedHat (recently acquired by IBM) and Linux are good examples, with all of their revenues driven by integration, customisation and training fees.

2. Monetisation strategies for decentralised networks

Recently emerged and still emerging decentralised networks are still finding their feet, however two main monetisation strategies approaches stand as viable (a) network fees and (b) service provider fees:

(a) Network fees: let’s focus on DeFi projects as the most appropriate comparison group:

  • Veil charges a 1% fee per trade as well as a 1% settlement fee if you elect to use the Instant Settlement feature, despite the fact that it is open-source project.
  • IDEX charges 0.2% for the market taker and 0.1% for the market maker.
  • ETH2DAI: DEX integrated in MakerDAO ecosystem doesn’t charge any commission from users; they pay only gas fee for transaction mining.
  • bZx Protocol charges lenders a 10% fee. This fee flows form a decentralized insurance fund redeemable against BZRX tokens. It de-facto pegs the lowest value of the token to the amount of assets, that can be received by redeeming of one BZRX tokens. So, the team implied commission, that works for system stability but also drives the demand for a token with protocol adoption.

(b) Service provider fees:

  • Bancor was charging $150,000-300,000 for adding a new trading pair to their ecosystem. These funds were used for buying BNT tokens, which thereafter were used for liquidity provision to a contract. A commercial fee for integration of a new asset.
  • Product/dApp fees to developers building on Aragon Network

3. Aragon Network Monetisation proposals

A summary of fee models to ensure long-term financial sustainability of the Aragon Network ecosystem is below. These fees can be paid in ANT tokens or by other means, and used by Aragon Association to cover operating expenses, incl. protocol maintenance and development.

Considerable savings as a by-product from scalability solutions will define the exact fee levels. In our further posts, we can discuss pricing policy and rationale and comparison with other market precedents.

Fee model Commentary
Network fee For-profit user-owned organisations historically charge their members an acceptable fee level - this model has been validated.
Fee-sharing agreements PanAragon AFOs network, that will be monetized through fees. We can be a pioneering project for using such fee-sharing approach.
One-time integration fee The overall fee pool can be government by a smart contract and split between the Aragon Association and integrators in a pre-agreed proportion.
Recurring or pay-per-play product-based fees to developers The overall fee pool can be government by a smart contract and split between the Aragon Association and developers in a pre-agreed proportion. Finance- and community governance-oriented tools as well as domain-specific tools built on Aragon, e.g. crypto-fiat conversion, access to financial markets, identity and compliance services, legal services, etc.

NEST PROPOSAL (Alternative to FLOCK proposal)

Given the time restrictions for a full FLOCK proposal and the kind feedback that the Aragon community have taken the time to provide to us at short notice, we are adjusting our proposal to NEST. In this proposal, we remove the elements deemed non-essential and focus on the part of the original proposal that received the most positive support so far: a layer-2 solution for voting on Polkadot as a core technology buildout for Aragon.

A dedicated chain for voting will reach a consensus and broadcast the final voting results to the Ethereum network. This approach will help reduce Aragon’s current gas consumption from 150k+ to almost 0 fee burden. Transferring other functions to parachain will allow AraChain to be implemented. An additional advantage of this solution is the portability of DAO from Ethereum to Arachain and vice versa, thus expanding the reach of the Aragon ecosystem and helping bridge ecosystem tribes.

Looking forward to community feedback and happy to expand more on the monetisation models, particularly with reference to historical analysis of user-owned organisations have conducted and referenced in our original submission.

Thank you!

AA

2 Likes
Our new Nest proposal + Bug/Feature we found when building :) (PanAragon stage 0)
#18

We are presenting this Nest proposal after the feedback round the community gave us - we hope we can meet your requirements and build together - our intention is to make aragon more robust for all

3 Likes
#19

I was a bit confused and created pull request instead of issue in Nest proposal. And now I have both an issue https://github.com/aragon/nest/issues/154 and pull request https://github.com/aragon/nest/pull/153. Should I close our pull request or not ? @light @stefanobernardi

1 Like
#20

I’m not involved in the Nest process but @stefanobernardi should be able to help here.

1 Like
#21

Hey @ilgiz.akropolis,

As specified in this answer: Nest proposals should first be submitted in the issue tab, they are discussed and reviewed there and can be approved/rejected. If case the proposal is approved, a PR may be submitted in a second time as a request for funding.

It would be nice if you could close the PR as we’ll start by reviewing the proposal in the issue tab. Hope this clarifies the process :slight_smile: !

4 Likes