Long term funding of Aragon

I was reviewing a bit the economics section of the forum to see if there was a discussion around the long term funding of Aragon. I found one pertaining to how to use the current funds ( First Finance proposals under AGP-1: Funding for the Association, Nest, and Aragon teams ), but not how to increase them.

Right now Aragon owns a fairly large amount of various “high-quality” tokens, that we can use for different purposes to advance the project as well as related ones, through Nest, A1, conferences, etc. It’s great because thanks to that we certainly don’t have to rush the conversation around funding, but the sooner we start, the more time we have to come up with something great. Currently this amount is not exactly supposed to go up, although my understanding is that it just did through the usage of MakerDAO. I must say I consider this a smart move, but it’s also gambling and I don’t think we should plan to leverage this method too much to fund the project long-term.

As the world first digital jurisdiction, we’re going to have to start talking about taxation at some point, even if it doesn’t have to be implemented anytime soon. There are a few discussions already around how to make the ANT token valuable, which is great as we want to make sure investors are fairly rewarded for taking the risk to fund the project, but on the other hand we should also make sure Aragon can keep funding itself and related projects.

Please don’t understand this the wrong way though: although I am a token holder, I am not particularly impatient to define how to increase the value of ANT tokens (sure I’m curious), rather I am eager to clarify how we will make sure Aragon can self-fund itself for the long-term in order to enable a large scale success that would actually benefit humanity as a whole.

5 Likes

This is such an important discussion!

The primary utility of ANT is governance. I feel very strongly that governance is the foundation for value creation in digital communities like Aragon–but it is important to leverage governance in order to create sustainable network/community value.

The project has a significant treasury and runway, but as you point out this pool is ultimately finite and will eventually run out. I think Aragon can grow into a massive global community supporting and enabling new forms of organization but in order to get there and make the project sustainable we need to either 1) directly generate revenue or 2) generate demand for ANT.

The main challenge is how to go about approaching these goals in a way which is defensible. Since we are building open source software that runs on a public network, if we implement fees, taxes, or other forms of monetization which would make the experience of using Aragon worse, there is a significant risk that these changes will simply be forked away and such as fork would be value dilutive because it would undermine the significance of the defaults set by ANT holders through governance. This is not to suggest that there is not a defensible way to implement fees or taxes on the platform and its users, just that this is something that deserves great care and attention.

Broadly speaking, I think the best approach is for the Aragon Network to try and generate revenue through the creation and governance of service protocols–which are significantly more difficult to fork successfully because a fork of a service protocol does not immediately provide parity the same way the fork of a standalone smart contract does.

At a high level, we can think of ANT Governance and the Aragon Network as a way to aggregate value across multiple decentralized protocols. Each new service protocol supporting both direct revenue generation through fees as well as increase demand for ANT.

We can look at the proposed design of the Aragon Court as one example of a service protocol, and examine how the success of the court as a service protocol can lead to a sustainable economic model for the Aragon Network.

At a high level the Aragon Court coordinates human work in order to arbitrate disputes. In order to perform work a “Juror” must stake a court specific work token, for now we can call that token ANJ. ANJ can be minted by depositing ANT into a bonding curve. If you are not familiar with the mechanics of a bonding curves I recommend starting with this article, and if you want to go even deeper read the follow up.

In the case of the Aragon Court, the bonding curve creates a loose coupling between the ANT and ANJ, such that as demand for ANJ increases, market arbitrage will drive demand to purchase ANT and deposit it into the bonding curve. This allows the Aragon Network (and ANT holders) to benefit from the success of the Aragon Court while allowing us to reward jurors for participation without requiring every ANT holder to actively participate as a juror. There are other reasons for using a bonding curve in this situation, but the relationship above is sufficient to understand why the court as a service protocol would drive demand for ANT.

The other thing to notice in this diagram is that when court is used fees must be collected by the protocol in order to compensate jurors for their work. A portion of these fees can be routed to the network, providing a direct revenue stream which can support the continued growth of Aragon. These fees are more difficult to remove (relative to a fee tacked on to the normal operation of an Aragon organization), because a fork of the court would not carry with it the same history of successfully resolved disputes.

I’m optimistic that the Court will become a critical and broadly used service for Aragon organizations (and perhaps even more broadly) as it helps protect the rights of minority and passive participants in organizations, so the revenue potential of the court should scale with the adoption of on-chain organizations.

However, the beauty of using ANT as a governance token and not using it specifically as the “work” or “staking” token for one specific protocol is that we can aggregate and add to the value and utility of the token by deploying additional protocols over time. Some examples of other service protocols which may eventually make sense for the Aragon Network to deploy:

L2 Vote Relay Protocol

We’ve started to explore how to scale voting via aggregation at layer 2, this may offer similar opportunities to defensibly impose fees and use ANT (or a bonded derivative token) in order to coordinate activity of relayers. The result would be a decrease in cost for end users (as there would be less transaction overhead on Ethereum, while simultaneously increasing revenue generation potential of the Aragon Network).

The Ara-chain

Our research into scalability via L2 Vote aggregation has also lead us to start exploring the feasibility and implications of deploying Aragon (or parts of the Aragon Network) on an Aragon specific blockchain. Securing the Ara-chain via proof of stake would be another potential service protocol that could drive value to the Aragon Network.

ANT splitting

Another way to drive demand for ANT is to make it more useful and practical to use it as currency/collateral for on-chain enforceable agreements. This is one of the more controversial ideas in the Aragon Network Whitepaper, and definitely needs significantly more research and modeling–but is attractive because the “currency” use case does not suffer from the same commoditization risks that other decentralized services do.

Currency Stabilization Insurance

An alternative, and perhaps less controversial approach, to creating an Aragon Network currency is to use ANT to govern and insure a stability mechanism. This model would look similar to the token models of SpankChain, Gnosis, and Maker.

App Center Insurance

One of the planned features of Aragon is to enable developers to provide third-party applications for organizations to install and use. However, installing an application into an organization will always require some trust that that the code is not faulty. This presents an opportunity for the Aragon Network to certify (and offer insurance on applications). Users would pay a fee to the network, and in the event that a qualifying bug is found in covered application, the network would provide compensation.

Apiary & ANT Reserve Requirements

Apiary, a platform for accountable crowdfunding being built on Aragon, could impose a minimum ANT reserve requirement. This would ensure that as organizations build on the platform they hold some percentage of their market cap in ANT reserves which would enable them to participate in the governance of the platform. By making this a requirement we can provide a stronger alignment between the governance of the platform and its users.


This ended up being a long post, and I’m sure I didn’t even scratch the surface… I expect that over time we will discover many other potential avenues to generate revenue for the network.

However, it’s important to remember that every single one of them depends on us being able to build a compelling product that people get value from–that is the hard part!

Ultimately, as a platform we will be successful if and only if we can make our users successful. When we see people not just creating and playing around with Aragon organizations but using Aragon to operate successful businesses which would be either not possible or significantly less efficient without Aragon–then the potential for generating revenue from the platform will be massive.

If it’s not already apparent from this post I’m incredibly bullish on Aragon. Our success is far from guaranteed, but there is huge potential here. We are a community aligned around a vision and I firmly believe we will be able to collectively navigate around any obstacles along the way. :eagle::rocket:

15 Likes

I don’t know how long I will need to say something useful after your post, so I’ll keep it short and sweet: Thanks for clarifying all this!!

3 Likes

One initiative that I am starting to write some (unpublished) ideas around has to do with organizations that use the Aragon platform for fundraising (e.g. the Apiary app). I think what should be baked into that smart contract is a “pay it forward” line item where members of the DAO using Apiary choose to kick back a certain percentage of their funds raised to go directly into the Aragon Network bank/vault. This wouldn’t be a requirement, but if it’s coded in the smart contract and exposed in the interface at the moment that a DAO is setting up their fundraising campaign, I think this can really work. Like even 1% from 100 organizations every year would provide a sustainable revenue source for the Aragon Network.

If the DAO doesn’t set up their campaign to give back a % of their funds to Aragon, it can also be exposed at the interface of the individual acquiring tokens (asking for a small individual contribution to the Aragon Network). This model worked very well for YouCaring.com which GoFundMe acquired (asking the people who are participating as donors to the crowdfunding campaign to kickback some $ to the platform (YouCaring), instead of the platform taking a cut from campaign owners).

But if DAOs find Aragon’s technology to be useful, then they will find it important to opt-in to continuing to fund the network and allow it to flourish.

With this path, I’m not sure if more ANT should be minted for these financial contributions, or if it ends up being some other Aragon-network like DAO that mints a new token that doesn’t care so much about inflation/is continuously funded, or if no token minting of any sort occurs at all. The latter case would increase the value of ANT – assuming this revenue model is successful.

10 Likes

Thank you for this post! Really great ideas :rocket:

2 Likes

This makes a lot of sense. Currently many projects do not have a strong connection between fundraising and use of finances. Baking functionality like this into Aragon should strengthen the relationship between financiers and makers.

3 Likes

Not sure what you’re saying here. Can you please explain more? Also, the whitepaper link here returned a 404.

100% Aggregating ideas on how to drive adoption and improve developer UX here :slight_smile:

Updated the link. Though the whitepaper has since been edited so people might have to dig through the history for the relevant bits.

Rather than digging through the history, can you please just explain what you meant when you said:

This sounds like building an app that acts as a neutral 3rd party to handle transactions between people. If so, wouldn’t any developer be able to build variations on that theme using apps/vaults that take in any token as the currency/collateral? Or were you implying that there would be a platform wide requirement to use ANT in all apps? Or something else entirely?

In earlier versions of the paper there is a focus on the challenge of collateral choice in a collateralized agreement. If you imagine organizations using the court to enforce general agreements (as opposed to just proposal agreements), say for example someone agreeing to complete some project that will take multiple months. To provide recourse the capital payment should be placed in escrow for the durations of the agreement, so that in the event of the dispute parties have adequate recourse. The problem is that this is generally very capital inefficient, and there are challenges associated with the volatility of the asset used as collateral. If you use a stable coin, and you lock it up for a long period, you have an opportunity cost, and if you use a volatile asset you introduce exchange rate risk into the transaction.

In the previous paper there was an argument for optimizing ANT for use as a collateral asset, and doing so by introducing a stability reserve and a splitting mechanism to allow ANT to both be price stable in terms of unit, but still allow holders to benefit from speculative increases in demand.

Those ideas are still interesting, but add a lot of complexity and not much actual benefit considering that proposal agreements do not necessarilly need to lock up a tremendous amount of capital for a long period of time to be effective.

2 Likes

Wow that sounds really interesting from a research perspective, but extremely tenuous from an implementation perspective. Thanks for explaining that though. Makes more sense now :slight_smile:

What about implementing that in a DAO/app so that if people want that feature they could incorporate it into their proposals, but it wouldn’t effect all ANT holders unilaterally? Not sure what the benefits of that would be beyond just having more ANT for ANVs vs DAI and also driving more buyers/hodlers to ANT, but it seems like something that could exist in the ecosystem as an option for people