Aragon Flock Proposal: Native



Hellllo Aragon!

I’m Tommy Cox, you may remember me from recent job applications such as the Developer Relations role at Aragon One! While I will fulfill that role with my full heart and soul no matter the outcome there, I’m here today to announce something (maybe even more) exciting that Jake Vartanian has been working on for the passed year now, whom I’ve had the luxury of partnering with the past couple of months to make this Flock proposal happen.

Native is a truly unique project and I sincerely hope that it’s given the time necessary to understand the amazing value it provides to the Ethereum, DAO, and of course Aragon ecosystem.

We’ve launched our own Discourse - where you can find all of the respective initiatives with their own topics - allowing for the long form conversations that each initiative deserves - where we’d love to answer any questions and expand on any of these initiatives in depth.


We’ve also launched a chat, also much like Aragon’s :wink:, where you can reach our community directly for whatever your heart desires.


We look forward to everyone’s feedback, as harsh or critical as it may be, and hopefully to the AGP in April!


P.S. - Don’t forget to check out Native, you won’t regret it!


You talk a lot about using Aragon’s backend – will it also use the Aragon client?


Absolutely, all of the arApps developed will have an interface, if one makes sense, in the Aragon client. I’d like to point out that one of our deliverables (see I10) would be a Services arApp that would allow any front-end client to interact with a DAO outside of the Aragon client.


To provide some extra clarity on this point @luis, we intend to utilize the Aragon client for the near-term within Native, as this will free up the most possible development time for us to work on the fundamental components that we are building on Aragon.

Over time, I can definitely see a situation where we at Native will develop our own client which interacts with the backend of Aragon. We would want to do this because the types of organizations we are onboarding will be better served with different onboarding and user experiences. This is why we proposed I10, which Tommy mentioned above - it will ultimately serve many companies that build on Aragon in the future who need to interact with the backend while using a separate interface.

I want to be clear that is not a critique of the Aragon client/interface, but rather an acknowledgment of the fact that different interfaces ultimately will be needed for different organization verticals. This could be looked at similarly to how Veil and Guesser are currently building on top of Augur.

That said, to me the underlying question here is:

How is Native fundamentally adding value to the Aragon ecosystem over time beyond just developing arApps in the short term?

I am curious to know from you Luis which aspects of using the network you feel will add the most value for Aragon.

At Native, we think in terms of network effects specifically related to tokens. In my response to @jorge on this thread, I noted how the Native Token (NTV) will hold a basket of other tokens in reserve to help price and provide liquidity to the token. One of the most interesting and correlated points here is that whichever tokens are held in the Native Reserve Basket automatically creates a connective effect between the included tokens.

To simplify the above and tie back directly here, we are willing to commit to back NTV partially by ANT. This means that every time a Native organization is created and/or a new member joins an organization, they are adding value to the reserve (by creating and backing the new NTV), and thus increasing the market cap of both ANT and NTV directly.

The exact percentage that we can back NTV by ANT is not only a matter of desire, but also one of practicality - organizations will need to spend in USD or other fiat currencies (for the foreseeable future), and cannot be subject to exorbitant amounts of volatility. Therefore, a large portion of our reserve basket will initially need to be in DAI.

To conclude, we want to ensure that we are adding value to the Aragon ecosystem in as many ways as possible while not compromising our need to effectively execute Native. We are open to suggestions to make this the most beneficial collaboration between all parties and look forward to your feedback.


High level feedback: I think there is too much included in this proposal to fully understand what is actually being proposed for the 6 month period. It’s hard to determine if it’s an Aragon app development effort, or a Native app development effort.

Due to how much Native and NTV is referenced in the proposal, there may be a conflict of interest in some manner as far as which ecosystem the team would be focused on growing, and whether the relationship can be indeed be complimentary.

Native could have been leveraging the Aragon technology stack for over a year – why now? That’s not to say that only teams that have previously built on Aragon should apply for Flock funding (or maybe that would make more sense…), but you may be better off applying for a Nest grant requesting a smaller amount of funding first and/or developing a proof of concept of one of the apps proposed.

Just offering my opinions here. There are more detailed questions below.

I01 - Network Economic Model

Can you please describe in more detail with how you plan to roll this out in the context of Aragon apps.

What changes would be needed to the existing tech (such as the vault)?

What new apps would be created?

Will the token be a minime token?

As part of this initiative do you indeed intend to integrate with Uniswap, Bancor, and 0x within 6 months? How do you see these integrations working in the context of Aragon?

Any revenue that is earned can be split between the reserve and community fund at the organization’s chosen split ratio.

Can you describe how you intend to accomplish this within the context of Aragon?

Leveraging a chosen base token for a subset of organizations’ tokens creates a network effect, so that when one community grows, the value held in reserve by the other communities also increases. This could apply to ANT, and the arApp would enable any token to be used as a base.

I’m a bit confused by what you are describing here, is it smart contract logic or something more general?

I02 - Staking for Membership

In addition to these components, a registry can provide member-specific content (either for organizers or the public) and the ability to connect with members (who have chosen to be public).

Can you explain what you mean by “ability to connect with members”. How would that be accomplished in the context of Aragon?

A whitelist function within a registry enables anyone to own tokens, but still limits who is actually able to participate in governance decisions and who can complete tasks/bounties.

This is already possible with Aragon’s permission system.

Blacklists enable organizations to kick someone out of the governance and operational aspects of an organization but let them keep their tokens to be used as currency.

Assuming one has created an Aragon DAO with two tokens, this is already possible with Aragon’s permission system.

Access Scripts

Access scripts allow for communities’ native applications or web content to only be accessible if a user is a member of the organization and/or holds a minimum number of tokens (ultimately leading to tiered access within organizations).

This can unlock entire web pages, download links, discount coupons, text content, and more. The only thing that would be required is for a developer to inject a few lines of web3 code into their website or mobile application and for the user to be browsing on a web3 browser.

Is this proposed development work for ?

I03 - Community Templates

Templates will be created for various community verticals (examples: music festival, event, lifestyle organization, etc.) and make it simple for anyone to deploy a DAO that effectively meets their needs.

Can you give an example of how a lifestyle organization’s DAO template would differ from a music festival? Which apps would they launch with, and what would the initial governance parameters be?

I04 - Community Action Recipes

Community growth recipes are a series of projects and tasks/bounties that are deployable within an organization to achieve a new level of growth. They can be general or vertical-specific.

For example, there could be a “gain members from Facebook” recipe that has tasks getting members to invite friends on Facebook into the organization and a project to run a social media marketing campaign (also on FB in this case).

Over time, each recipe has a success metric, and the most effective will rise to the top and be implemented across many communities/organizations.

Can you describe how you would accomplish this within the context of Aragon? How many applications would be needed? Which existing ones would you be leveraging?

I05 - Organization Healthgrades and Valuations

This initiative is to more clearly understand the activity levels of each organization and how that activity correlates to its valuation.

In a world where 40% (and increasing) of internet traffic is “fake,” it is important to have insight into the underlying KPIs of an organization to determine whether or not they are creating a false image of success.

I don’t think this initiative will provide any near-term value. We need more active organizations in Aragon first and foremost.

I06 - Member Experience Research and Reporting

This initiative is to contribute (and collect) as much in-person education (and feedback) as possible via the flourishing crypto community in Denver, as well as to organize our digital feedback and ultimately leverage a TCR for member-driven prioritization of development goals.

What do you mean by “member-driven” - who are the members here?

Why do you think in person feedback from one crypto community (Denver) is more valuable than expanding the research area globally, to organizations more likely to use Aragon-- and interviewing with video calls?

How many meetups a month do you plan on organizing?

A TCR would be implemented to prioritize and align development efforts (see District0x for TCR implementation), as determined by NTV and ANT holders. Ultimately, the TCR could trigger capital allocations directly to specific projects, developers, contractors, etc. and make the outcomes binding.

So you are proposing developing a TCR app just for the purpose of NTV and ANT voters prioritizing development?

I07 - Member Benefits Packages and Physical World Connections

The physical world connection of these benefits primarily relates to how they are accessed and utilized. QR codes and NFC are the clear frontrunners of interaction between planes. Native will be the first to implement and optimize these functions over time as we gather opt-in feedback from users.

I’m having a hard time understanding what you plan on actually building (development-wise) as part of this initiative.

I08 - “That Planning Suite” Reputation Modularity

I have to admit, this section is a bit over my head in ways. What is the MVP that you intend to accomplish in this initiative in 6 months?

E.g. can you describe the relationship between TPS and colony?

If i am earning reputation in colony, how often do I have to swap my rep in Aragon?

Would the tasks in TPS be the same as the ones in colony?

I09 - Gamification

I don’t think this initiative will solve near-term adoption of Aragon.

I10 - Connect API

In the not too distant roadmap we’d be contributing a Services arApp to provide permissioned endpoints for interacting (i.e., voting) with any DAO using any front end interface (i.e., Native) and utilizing authentication via any web3 provider (i.e.,

I’m not sure about how needed The Graph work is (especially as there are a few community funding DAO proposals related to analytics), but external Voting widgets sound useful assuming they will indeed work with “any front end”.