Purchase of Dappnodes to increase Aragon's decentralization

I’m sure we all appreciate the awesome work being done by Dappnode (if you’re not familiar please visit dappnode.io).

After our recent meetings in Berlin it became clear that several factors are hurting both the scalability and the decentralization of the Aragon Network:

  • Infuriating Infura
  • Loss of access to the Aragon Client when the default Ethereum nodes hosting the Aragon client are down
  • Extremely slow propagation of IPFS files
  • No relayers for layer 2 apps such as voting, no set of validators integrally part of the network

I am writing up this draft proposal to make sure each flock team has at least 3 dappnode devices. Also kindly requesting one person from each flock team to state the number of Dappnode devices they already have (disclaimer: Aragon Black has none).
The price for one dappnode basic is approx 750 DAI inc tax and 1000 DAI for dappnode advanced (doubled ram and storage capacity). The proposal budget after evaluation of network needs could thus range from 4500 to 9000 DAI. The monies would be sent to each flock team lead in order to make the appropriate purchase.

By having a minimum amount of Dappnodes available we will be able to have:

  • Preferred nodes hosting the Aragon Client and core infrastructure
  • IPFS Pinning/Clustering
  • Caching solutions
  • Relayers for L2 apps
  • Sidechain Validators
  • Future L1 Validators

Preferably these nodes should be as spread out geographically as possible and their location kept secret.

A future AGP could mandate a minimum number of dappnodes per flock/nest/aa and the services that are required to be run to be of benefit to the entire network.

I eagerly await feedback on this first proposal!


Im generally not opposed to Flock/Nest teams running infrastructure, but not really a fan of it being a requirement. I’m also not sure what the devops requirements would be for the network/users to get value from this sort of thing.

I wonder if rather than trying to deploy hardware we could work on integrating something like https://www.pokt.network which is intended to coordinate and incentivize people to maintain and operate full nodes.


I’m in the same boat where I like the idea of more people running nodes, but for users to really get value from it I think it would require more robust hardware and monitoring for the nodes to be maintained and kept online and synced. Ideally power users would each have their own DAppNode and then invite colleagues, friends, and family to connect to it. But for more intense usage than that (hundreds or thousands of users connecting) it would require dedicated servers in a high bandwidth data center somewhere.


I really like this proposal, I would add to have a process in place to request sponsor for running the Aragon infrastructure. It would be cool if we at Aragon Mesh are also able to request founding to run our own nodes :raised_hands:

On the other hand, I’m wondering the trade-off between a solution like Luke propose and having several community members running the necessary infrastructure. Considering that maybe at this point having 5-10 more nodes could be quite an improvement and eventually we can transition to a more scalable solution.


With deployment of 0.8 the Aragon default node had difficulties with some people (me included) not able to create orgs for 2-3 days.

Thanks for your replies @lkngtn @light @gabi !

Seems like 3 alternatives are open for increasing scalability while preserving decentralization:

  • Pay for nodes via pocket: interesting path as we might be able to connect mechanism to a dao for fees and governance to but unsure when we’d be able to deploy such a service in the short run)
  • Use a cloud computing platform with elastic load balancing a la Amazon: more reliance on corporate 3rd parties but can use several platforms and have sysadmins from various groups in the ecosystem (Association, Flocks , Mesh, Nest etc…)
  • Hardware nodes as in the original proposition: high upfront expense and semi-centralized but can quickly scale from a few base nodes.

We should use a combination of these for maximal decentralization and for studying the tradeoffs and frictions in actions.

At this point the unsolved question is how much each vector could add to scalability compared to the current node hosting in order to make this proposal a smart investment for the network.

Would you be able to fill us up about the current hosting situation @jorge @sohkai ?

Am intending to keep the thread open for for additional comments before producing some survey for consideration of the network and refining of the proposal.

At the moment, the AA runs the infrastructure to serve the client with a Kubernetes cluster on Google Cloud Platform. Currently that is:

  • Ethereum nodes: 2 load balanced geth nodes for mainnet and 1 geth node for rinkeby.
  • IPFS node: an IPFS node that automatically pins all the content archived in the deployments repo on every push to master
  • APM serve: an instance of apm-serve which uses the Ethereum and IPFS nodes to fetch the latest version of different packages and serve them (e.g. https://mainnet.aragon.org or https://finance.mainnet.aragonpm.com/artifact.json)
  • Notification service: which was recently added in 0.8 and it is also hosted in the same infrastructure.

Out of all of these, the lowest hanging fruit would be to have many IPFS nodes that pin Aragon content. For Ethereum nodes, I think it is really important for people to run their own nodes and use that for their own use, however I would keep the AA nodes as the sole default option for users that don’t set their own node in Preferences, as a ‘mesh network’ of Ethereum nodes in people’s DAppNodes would be hard to make reliable.

In any case, it would be interesting to have DAppNode packages for all of the above (except for notifications which would be more complicated to self-host) and allow people to support the infrastructure and run Aragon themselves in a totally decentralized way.


Hi everyone, thanks for considering a decentralized infrastructure solution like DAppNode!

Just for for those who might be reading this and not know: I am the Project Lead of DAppNode :slightly_smiling_face:

So the situation seems to be:

  • Aragon is sometimes subject to availability/stability/scalability problems. Some of these are annoying, some are quite critical, like the partial outage of 2-3 days described by @DanielS.

  • IPFS propagates painfully slow.

  • I would like to understand a bit better the workings of layer 2 apps and its relayers.

Solutions proposed have been:

  • Pocket network, which is great and we are very close to them. In fact, we are about to implement their testnet version as one of the audited packages in the installer! DAppNode is one of their ways of getting Decentralized nodes. Unfortunately, it is not on mainnet and I would say it does not fit all of your requirements.

  • The other option raised is to try to solve it through increasing the exposure to centralized services. While this is completely understandable due to cloud computing being a “tried and tested” solution, I think we are in a position to test decentralized solutions that can work.

  • Also, DAppNode. We are extremely excited to be able to work on solving real problems that decentralized organizations have, in a decentralized manner :).

I see two ways in which we can help:

  1. Hardware-wise, we can look at your requirements and see if it’s possible to provide a tailor-made configuration that will suit your needs. DAppNodes are thought nowadays for “all-purpose” and probably there’s some wiggle room to get to what you want.

  2. DevOps-wise. There are several configurations that could help you be more resilient - we can dig deeper, but, in order to take a conservative approach we could keep your main load balanced nodes on GC and add 3 High Availability clusters (one for each team). This HA clusters would be formed by 3 DAppNode each, or we can explore other options that make sense for you.

Moreover, these could run an IPFS pinner -a variation of the one we use for quick propagation of our own packages (APM based)- that locally would detect changes in the smart contract and pin them in a decentralized manner. And of course we can create a package for the APM serve too.

To @jorge 's point of the importance of people running their own nodes - we couldn’t agree more! It would be easy to automatically connect people who run their own node to the app, especially if they run DAppNode, but in case they don’t we have all of the above.

Lastly, I would like to address the concerns about deploying your own hardware as raised by @lkngtn. This is a completely justified point, as we come from a world where the risk and hassle of running infrastructure is delegated to big, efficient, wealth-concentrating and power-wielding actors. The solution in the long term, as intuition tells us, is not to go back to a point where everyone hosts their own infrastructure. But decentralizing infrastructure needs early adopters too! It’s outside of the scope of this post to talk about our vision, but hopefully we can create a network where you could, just like in AWS, ask a smart contract for X nodes and reward those who will run it for you.


hey @DanielS just to say that I totally support this proposal, but after reading the different replies, specially the following:

I’d propose that instead of giving the hardware to the Flock teams (who are already 100% engaged with the Aragon project), giving them to community members that would not only like to support the network, but also spread the awareness about the importance in having nodes to support the decentralization of the Aragon infrastructure.

For example, I would love to serve as a bridge in order to acquire and install a Dappnode dedicated HW in this co-working in Madrid which is focused on gathering together crypto people: http://cryptoplaza.es

I can assure you that this community here would appreciate having a Dappnode and understanding its benefits, as well as the Aragon community ofc. What are your thoughts??