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.
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 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.
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., frame.sh).
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”.
Hi @stellarmagnet - thank you for taking the time to write this thorough review.
The original formula in mind for Native has generally been Aragon + Bancor.
When we started developing the prototype for Native, we were not ready to commit to using Aragon as the ecosystem was in a nascent state, and we could not be sure that Aragon would meet our needs. We were connected with @proofoftom who shed light on the fact that Aragon is now ready to handle an ecosystem like Native.
Now that both projects have evolved, it has become clear that with a few additions to what is being built at Aragon already, Native is a great fit to be “Powered by Aragon”.
Regarding this, it seems very obvious to me that other ecosystems would plug into Aragon for the services Aragon provides. Extending the scope of what Aragon can provide seems like a pretty clear goal of the Flock Program, and that is what we are proposing to do.
Additionally, please see our response to @jorge about the nature of our token model. Taking time to understand our model and how we intend to partially back NTV by ANT should clear up any uncertainties around how we will add direct financial value to the Aragon ecosystem over time (on top of development time put into the ecosystem).
This initiative leverages Smart Tokens inspired by the Bancor contracts for both NTV and each organization token. In essence, these smart tokens enable convertibility and pricing between community tokens by leveraging a common reserve.
See answer below related to Aragon implementation.
This would introduce to Aragon a new token type and associated manager which would function as a liquidity calculator and instant token converter for communities sharing the 2SAAM token and would come bundled if the 2SAAM Template were chosen.
With our current plan, we do not envision this being a MiniMe token, but rather an ERC20 with Smart Token functionality. However, if there is a good reason to implement this as a “smart MiniMe token”, we are open to things that make sense, yet it seems that Aragon is attempting to move away from MiniMe as well.
There are two options here and we need to weigh the pros and cons of each. Both options require making the token for an organization a “smart token” (which gives the token both reserve and minting capabilities. This would be a new token type for Aragon organizations that do not give access/rights inherently but rather functions as a community currency. Regarding how to specifically implement the splitter component:
Implement a contract with a splitter function that, when a deposit is made it initiates two sends - one to the reserve and one to the Finance app. This contract would be an intermediary between a deposit into the organization and the Finance app. This would only be applicable if the organization chooses the 2SAAM token type.
Send all funds to the Finance app and then decide what percentage will auto-send to the reserve. This would add one additional send after base currency hits the Finance app from a new deposit and send a percentage of the transaction directly to the reserve.
Yes, this is smart contract logic. The reserve functionality of a smart token enables tokens to be backed by baskets of other tokens. Bancor calls them “token baskets” and Set Protocol calls them “sets”. The arApp in this case would allow any organization leveraging the 2SAAM token type to choose which tokens and at what weights the organization’s token would be backed by. This is how networks cross-pollinate from a value perspective, and how we will add value to the Aragon Ecosystem directly as communities continue to join Native.
Literally every time a user buys NTV it directly increases the price of ANT, as it is backed by ANT.
Ability to connect with other members can be thought of in multiple frames. At a basic level, it is like a contact book - see whatever social or comms channels each user has linked to their profile and be able to reach out to them. This is similar to earn.com’s paid list, but structured with contract registries, and would benefit as an extension of TPS’ Address Book.
When combined with membership benefits, members of an organization could even give time to new members as a benefit of joining the organization. Example - I join the Autark organization and get 30 mins on the phone with Yalda as a benefit.
Great! More time to work on other initiatives. Although a method of managing these permissions on a per member level could arguably be improved with a simple, user-friendly whitelist/blacklist table.
Because Native communities would be Aragon organizations, it is development work for both simultaneously. Native would definitely use this for members of the Native organization and also provide it as a service usable by other organizations/communities.
Of course. So there are a lot of different implications around how a lifestyle brand and a music festival function. In creating a template, here are some of the questions I think about that would all have associated variables in a template:
How much capital will the festival need at the beginning of the venture vs over time?
Is stability in token price or growth capital more relevant?
Are token holders expecting returns?
How do revenues flow back into the organization?
Is this a one-time membership or a recurring structure over certain time intervals?
What are some of the bounties/projects that could lead to a higher degree of success (see I04)?
How much should it cost to join?
Can the org tokens be utilized in other ways besides joining the organization?
Mapping these variables out for different verticals will create a simple plug and play experience for organizers who want to start organizations and have limited economics background to make informed decisions around monetary policy.
This would be a single app with a registry of recipes that would generate projects and tasks in TPS in bulk for a selected recipe and assign a suggested reward for each task. We would need to discuss how to specifically do this with the Autark team to ensure that we are thinking about this correctly, once TPS is deployed.
From TheGraph reporting, we can determine the usage and success of recipes to better formulate suggestions. Organizations could also create their own recipes.
This comment was made in relation to I05, which is organization healthgrades and valuations.
I disagree - starting work to determine how to effectively value organizations based on their activity and results is valuable immediately. Even research alone here is valuable. If you consider how totally screwed up company valuations are today, creating a framework to resolve this is very important.
It also enables funds to invest automatically into different organizations once they reach certain grades. This is huge.
I don’t think we said anything about local vs. global research being more or less valuable than the other. Rather we are just saying that the local aspect of engaging with organizations/communities is valuable, and we will be doing the legwork to make on-boarding and user experience engaging at the human level.
I have found that most people do not operate in the heady ethereal space of the blockchain world. Meeting in person with people is an essential aspect of learning about their needs and potential applications of a product.
We’ve been leading and/or hosting an average of one per week, rotating from developer specific presentations and roundtables to community gatherings, but try to be flexible depending on circumstances and interest.
ANT and NTV would be the first organizations to utilize this tool if desired. Ultimately, this would be a TCR app for any community to implement within their organization and utilize their token for prioritizing development efforts. This could be weighted by the number of tokens held, amount of reputation held, one vote per member, or any combination of the above.
Physical world connections - A backend arApp that - utilizing existing NFC and QR scanning wallets - will verify membership in a community. This allows access to a real-world interface such as a lock or a POS system at a store to get discounts.
Membership Benefits - each community has a series of benefits that users receive for becoming members. These can link to physical world connections or be links to things like song downloads. In the current implementation of Native, membership benefits are just structured via a list. We realized that this is not enough, as the end result of the benefits need to be accessible without a person in the community needing to intermediate the distribution of the benefit.
Apologies for the lack of clarity here. The ultimate initiative is to build a Merit Manager (or an addition to the Token Manager) which designates skill and experience in the form of a member’s merit and skills based reputation in and between organizations. This app will have a complementary voting app (or an addition to the current voting app) in which users would stake their reputation to create proposals based on a weighted vote using one’s reputation within an organization as one’s stake in said vote.
TPS would connect with the Merit Manager to allow for reputation to be rewarded to workers using any reputation plugin - Colony being the first on our roadmap for implementation.
There shouldn’t be any need to swap an individual’s reputation between Aragon and Colony (or another backend). The two instances would be tightly coupled. The projects and tasks created in TPS could be the same as those created and completed in the backend system, and reputation would be simultaneously earned on both platforms as they would share the representation of such.
TheGraph app will enable the possibility of organization healthgrades and ultimately valuations. This will be deployed for an organization if they want to utilize the grading system. We think the grading system is useful because it enables a user to get a sense of the organization and its activity before having to make the commitment to join.
Regarding other analytic app DAO proposals - if they meet the needs of our healthgrade system, then this removes the need for us to build it and lets us focus on other aspects of development, which is great.
Agreed that external voting widgets are an excellent path to start down in implementing external actions for an organization.
Thanks again for your feedback on this post Yalda! We would love to continue the conversation further - if we keep going here, it could get a little messy. Happy to schedule a call to dive deeper into each of these individually. It could also be helpful to address the initiatives individually, perhaps on our forum where we’ve facilitated the ability to do so. This will allow for more rapid responses.
After reading the Aragon whitepaper and original roadmap, this seems to be a completely different scope. I’m not sure if the Aragon community would buy into something so wildly different, especially seeing how the burn rate of the project has decreased during the past year.
Just starting in this community, so I may be wrong, but it definitely seems like Native could be built on Aragon, but doesn’t necessarily help build Aragon.
We went through your proposal carefully at the Aragon Association. Here are our comments:
The Flock program funds teams putting 100% of their time and resources in building Aragon. While it’s great that you plan to integrate with some pieces of the Aragon ecosystem, we cannot finance a team with split resources/interests between Native and Aragon at this point in time.
Also, we find it hard to draw a link between the concrete actual concerns of Aragon and the proposal. Initiatives sometimes overlap with other Flock teams’ effort or seem a bit out of scope:
I03 is a matter that is being worked on by several teams (including Autark as you mentioned)
It seems quite early for Aragon to implement something like I05 (and some of I01). We feel the initiative may become relevant only with a sizable pool of DAOs, which is something we don’t have at the moment. Flock teams’ effort is currently focused on finding market-fit and onboarding to start generating traction
I07 we’re not sure this is an approach that is cohesive with other go-to-market/adoption strategies in roadmaps. The focus for now is on developing the right product features for first short and medium term use cases
Overall, several initiatives in the proposal are a bit far from the current objectives of Flock teams. What’s proposed would add a level of complexity and diversity that we are not able to afford at this point.
While we highly value your interest and involvement in the community we don’t think this proposal is a match for the Flock program and we’re going to reject it.
We’d love to keep seeing you around in the community neverthless. If you want to start building on Aragon, one great way to proceed is to pick some of your preferred item in the list, preferably the one that fits most with current priorities, and come up with a Nest proposal or a Finance Track proposal in the AGP process. Doing so, you’ll be able to assess the precise needs of Aragon and craft another potential Flock proposal in the future.
Hello team Native! Echoing what @LouisGrx has written, (and in light of the second, updated Flock proposal you submitted), I wanted to paste here the message I wrote on Github:
Thank you so much for this amazing proposal team Native.
We really do appreciate the thought (and, undoubtedly, the time) that has gone into this.
All of those initiatives and apps are clearly very interesting, and would benefit the wider Aragon ecosystem. One problem with them is that they are all apps that would provide their benefit once there is some clear growing user adoption, and product-market fit has been completely achieved, something that we can’t unfortunately really claim at the moment. Therefore our current focus is on developing more “core” features and tools for the network.
Additionally, the Flock program is a very specific program for teams that want to dedicate themselves completely to building the Aragon core infrastructure.
It is not really thought for teams that want to integrate with Aragon, or collaborate in a more broad sense.
Those initiatives have traditionally been managed through our Nest grants program, which grants smaller amounts of capital.
Even with all of the above, it is so awesome to see teams developing their own protocols and projects wanting to have Aragon as a more fundamental part of their infrastructure - so we will take this opportunity to reflect more on a potential specific path or program for these kind of situations - but for now need to close this pull request.
In any case, we’d really welcome a closer collaboration with the Native team and are looking forward to connecting more often in the coming months - so as to also see if maybe we can work together on a Flock proposal for one of the upcoming ballots.