Aragon Button: Interact with DAOs everywhere


Interacting with Aragon organizations right now requires the usage of the Aragon client.

Sometimes, developers or even users may want to integrate Aragon into their existing dapp or app (even a Web2 app) without having to tell their users to open a new tab with the Aragon client.

Put it other way, right now Aragon adoption is very mololithic: you either buy all-in, or you don’t.


The solution could be to integrate a button that performs actions like voting, submitting a finance request, etc. in any existing frontend or app.

The flow would be similar to Stripe Checkout, where developers or even users can copy and paste a line of code and let the tool handle the hard parts. In this case, an Aragon Button could be a voting button, to vote yes for a given proposal on a DAO. But it could be configurable with parameters to perform any given action that a DAO exposes to the world via its installed Aragon apps.

Security considerations

One main reason why the Aragon client is great is because of security. Users just need to trust that they are getting the right Aragon client frontend, and then the client takes care of:

  • Describing outgoing transactions via Radspec, so users know what they are signing
  • Communicating with the signing provider/wallet to trigger the signing popup
  • Sandboxing Aragon apps from the client, so a malicious app cannot tamper the signing process

All of this could be built into an Aragon Button popup, so when the user clicks Vote on an Aragon Button, a popup is opened with the URL, giving users the trust they need.

They could also run it in a fully decentralized way if they have something like Frame installed, in which case they would load it directly from Aragon’s decentralized package manager from aragonpm.eth .

User Experience

Check out the prototype on Figma.

For developers and users

To make this kind of integrations happen, we would need something like aragonAPI Lite. This would be a lite version of aragonAPI/aragonJS that allows developers to easily fetch the state from their Aragon organization. Maybe that’s done by running aragonJS on their servers, and since the user already trust their frontend that wouldn’t be an issue. Users can also open the organization in the Aragon client to verify the organization’s state, if they don’t trust the developer’s website.

For users, we could also envision a widget generator (similar to the 0x Instant Configurator) that allows users to select:

  • An Aragon organization (e.g. governance.aragonproject.eth )
  • The app to interact with (e.g. Voting )
  • The parameters (e.g. vote #10 and outcome yes )

That’d then generate HTML code that could be added into a WordPress blog or even a tweet.


Aragon Button allows users to interact with Aragon organizations from any website or app, and allows developers and makers to integrate Aragon functionality without having to redirect users into the Aragon client.


This was sort of the headless wrapper idea that was scrapped. I think it’s pretty cool.


Just a thought not sure weather this is possible. I imagine interacting with DAOs (DAPPs) within my phone. My private key is stored on my phones TEE by services like When I then click on vote the TEE of my phone and the blockchain are communicating directly with each other and the Trusted Display from the TEE shows me what the blockchain says. So I just have to type in the ammount of tokens i want to stake and click vote and thats it. You only see a field to type in a number and a button vote and when you click on it you have voted no pop up needed.

Not sure whether a TEE can decode data to display a transaction’s metadata, but sounds interesting

This would be really cool. Then you could integrate Aragon DAO related actions into things like community forums or games. This would make the experience much more dynamic and improve the UX 10X (along with expanding the possible use cases for DAOs 10X as well)

1 Like

I would really like to keep working on the Aragon Button.
This is what I did during the ETHBerlin hackathon, just a very simple Proof Of Concept:

If anyone wants to join and contribute (please do!), feel free to let me know. This is my Telegram handle: @Bitcoinera.

As a design I am thinking of making it very lite, all-in-one library. Also as simple as possible. Maybe make a version with web3 included and another one without, so developers can decide one of the two and therefore avoid web3 versions incompatibilities. But I am afraid I miss out completely the security aspect of it.

Please feel free ping me here or through telegram for any suggestions.
I have confidence this is a great project for Aragon.


I can imagine that the guys from rivetz could have an answer to that. The CEO has knowledge

I would like to follow up on this.

Partially inspired by Deam, I went on and took it as a challenge to use the current aragon-wrapper lib to ‘listen’ to a DAO’s app events from outside.

Here you can find the repo:

The conclusion is that currently you need to make some changes in the aragon-wrapper itself to be able to accomplish this function as well as that other packages are needed, such as @aragon/apm and @aragon/os. And this shouldn’t be the case.

As I stated in my previous post, the ideal is that the lib to do this is as lite and simple as possible.

Now I would like to continue experimenting and make a first prototype for this aragonJS lite lib.

The Aragon Black team has already shown a clear interest in also undertaking this very important project. I love seeing this project being taken as a clear priority for Aragon. Collaboration is the way :wink:


Was just talking to someone who started building Aragon DAOs, but switched to DAOstack and Bancor integrations because the Aragon client felt too much like an admin portal and didn’t organically integrate with the more social/community oriented use cases in mind. Being able to integrate Aragon DAOs into UX flows that people are already engaged in would really help. First, it would allow applications that already have users to enhance the experience with decentralized governance and/or token rewards. Second, it would allow people to use Aragon without committing to the client as the main UI for their community.


I see this as extremely important for PMF, and users have definitely gave us feedback in favor of it. We should build this.


Been thinking about this initiative a lot and I think its quite an interesting idea, however, I also think that it might make sense to better understand the use cases and implementation details a bit better.

It is currently possible to interact with an Aragon DAO / Aragon Apps from an external website without using aragonJS at all. These are just contracts deployed on a blockchain after all. So what we get from the client and transaction pathing is primarily a modular and composable interface.

If someone is building an external app that needs to interact with the voting app, say we want to provide a voting portal on our website for a larger community to interact with, and which is tightly integrated into our branding and style… we can create a standard dapp that interacts with the voting app (proxy address) and prepares a castVote function on behalf of the user.

If the user is willing to trust the publisher (most dapp users seem to be willing to do that) then they do not need to interact with aragonJS at all.

In this scenario, the Aragon Client (or CLI) becomes a “backend” management tool and an alternative user interface for advanced users if they want to interact directly with the DAO. The external app does not need to expose any Aragon interface to the user if they don’t want to, they can also introduce things like meta transactions and alternative web3 connections without needing the Aragon Client to support those things. It would be difficult to create a general purpose DAO outside of the client but that would be the case with or without aragonJS lite, each external interface would need to have custom logic and assumptions about the organization configuration embedded.

So I think we have a couple options:

Status Quo: We can document how these interactions can be done currently, and potentially make some improvements to the CLI to make it easier to bootstrap apps that interact with Aragon apps for deployed Aragon DAOs without changing aragonJS or the Client at all.

AragonJS Lite: We can create an alternative version of aragonJS which provides some basic functionality for embedding the transaction confirmation so that users can potentially interact with an external website, but then having the signing interaction come directly from

The first part seems relatively low lift and really valuable.

The second part (AragonJS Lite) Im less sure about – is this something that should actually exist in Frame, or as metamask extensions? Is it something that is Aragon specific, or something that is perhaps an extension to radspec that should be adopted much more broadly?

If we do decide to go the AragonJS Lite, what is the expectation for Aragon App developers? is the expectation that they should focus efforts on building modular “headless” components (currently this is possible but uncommon), and the have Aragon DAO developers create fully custom interfaces which combine multiple of these components together? Do we de-prioritize efforts on the client to pursue this different direction (eg permissions, app installation, and the app center as end-user are not particularly relevant outside of the Client). Similarly some of the architectural decisions, like the ACL make a lot of sense in the context of the Client being a modular interface that allows applications to be installed and configured, but may not be the most efficient architecture in the case where each Organization “template” is fairly static (since the interface is tailored to the specific configuration).

Going to tag a few people here that I think could add a lot of value to this discussion, I also think this is a really important discussion to have as it can impact a lot of related strategic decisions and priorities.

@jorge @sohkai @bingen @facuspagnuolo @ajsantander @gabi @fabriziovigevani @onbjerg @stellarmagnet @Quazia @osarrouy @bpierre


Agree that this should totally be explored further :slight_smile:

The UX of this would be amazing. If we can accomplish a similar experience using the processes currently available that would be great. If not however, we should explore what we need to do to make something like this possible. Simple for developers + simple for users = things happening.

1 Like

Love that there’s some momentum generating around this since this is probably the most limiting aspect of integrating with Aragon. Regarding the two options laid out:

Status Quo: I didn’t realize that these capabilities were even possible! Some documentation around such would be invaluable and would open up the immediate ability to start experimenting with decoupled UI interfaces. I think this, being low hanging fruit, is a great first step forward.

AragonJS Lite: Ultimately though, what would be most useful in my opinion is a Javascript library as a simple Web3 wrapper for interacting with Aragon App contracts. This is something that Colony has nailed down really well with colonyJS which might serve as a good beacon for implementation. In my mind, arApps would implement their own wrappers for user facing capabilities of their app while the arApp itself that lives in the client would be more for admin configuration.

With all of that said, the Aragon Client makes for a great backend administration panel where power users can configure an organization (i.e. permissions, app installation, etc.) and efforts should still be put into making that as powerful and straightforward as possible. The ability to have a decoupled frontend that is able to interact with modular headless apps via aragonJS Lite allows for a lot of that admin complexity to be abstracted away for end users and is very similar to how web 2.0 CMS frameworks like Drupal and Wordpress address this separation of concerns. I’d also say that Drupal might serve as a good beacon for implementation.

While I like the idea of a button or widget for simple actions - comparable to a Paypal payment button - these widgets are generally difficult to customize and wouldn’t provide the flexible solution that Luke has laid out with AragonJS Lite; I’m leaning much more towards that as an end goal.


the Aragon Client (or CLI) becomes a “backend” management tool and an alternative user interface for advanced users if they want to interact directly with the DAO

FWIW this is how the Aragon Client is considered for the daonuts project. It is a useful interface for advanced users and admin features but not what will be expected as the primary end-user interface.

Yes, i agree Status Quo is ok. These are just contracts after all so load up the abi with your favorite web3 library and away you go. I have a urge to say that more could be available to facilitate dev of off-Aragon Client interactions but am finding myself not actually coming up with much! Given a dao address it is a little cumbersome to instantiate a particular app contract but not that bad really and probably a niche consideration at that. Maybe I can think of more, you mention transaction pathing which could still be useful externally, but I guess that leaves me in the Status Quo camp - dev will be about as good as with the rest of the Ethereum ecosystem :sweat_smile:.


I agree with Status Quo and probably we want to have a simpler UI than the client exposing the whole power of the aragonCLI without dealing with the terminal.

On the AragonJS Lite my opinion is trying to abstract as much as possible to expose the central idea of what an Aragon Organization represent. In one hand we have core components: Access Control List (i.e. Permissions) and Entities (Aragon apps and EOA). And then we can think of each Aragon organization as a state machine were after every new transaction the outcomes could be:

  1. The tx will potentially modify the organization state

    1. If the entity have the right permissions, the state is modified
    2. If the entity have not posses permissions, the state remains the same
  2. The tx don’t modify the organization state

So from this analysis I think the most important is expose an API that allow user to check if the tx will modify the state of the underlie Aragon organization. In conclusion this library will be heavily oriented towards analyze the permissions system (e.g. custom permissions, forwarders)

In this model we will be allowing the users to create any kind of interfaces on top of aragonOS and the most challenging problem is going to be how to educate users that there is an underling structure keeping them “safe” :thinking:


I think users could minimize their trust on the app developer by using the sort of interaction that I described in the original post, similar to how Stripe does it with its own form that users already trust.

On your other questions, I agree they are relevant and we need to find answers to them in terms of focus for client vs external integrations.

Love your take on this @gabi.


They would still need to trust (as opposed to running locally), right? Whereas in the current flow, it’s possible for someone to run Aragon in a completely trustless manner. Though most people opt to just use as a gateway.

I think the analogy to Stripe makes sense, but the trust anchor shouldn’t be but rather dependent on how they are connected to the chain. (they choose to trust infura, or their own dappnode and their wallet provider’s codebase, they don’t need to trust our domain).


The thing is that developers may choose to connect to the chain in multiple ways to alter data – but with an hosted popup, you have a reality check since both the developer and the popup need to be maliciously altered for you to mistakenly sign an action you don’t aim to take. Does that make sense?


But wouldn’t it be better to have this type of assurance integrated not through a popup and connection a central server, but rather in the signing provider the user has chosen?

In the scenario you are describing, wouldn’t it be impossible to both leverage Aragon Button and run a “dapp” or “dao” because it would not be possible for users to use the application without depending on the domain?

Indeed, it’d be great if signing providers offered transaction pathing and Radspec!

About the second question: they could install an extension or use Frame under the hood to load the Aragon Button pop up directly from IPFS

1 Like