The mental model i have of plugins is plugins === apps but this is not really the case is it?

1 Answer 1


You are correct in that plugins are different than apps as you remember them from the first Aragon version. In the old version, apps interacted with the protocol through Agent (an app manager) to then get access to the DAO and its assets. In the new protocol, plugins have direct access to the DAO contract through permissions.

The main contract in V1 didn't have the functionality for executing arbitrary code. That's the reason for the Agent, to be able to execute anything from the DAO (well, from the agent). Whereas in the new protocol, plugins can in fact execute directly to the DAO without the need of an intermediary contract (the agent).

The Kernel (DAO contract) and ACL (Permissions) look very similar to how they did in the past. However, the rest of components are "cooked" in a different way. In the new protocol, you grant permission to a Plugin to execute something directly from the DAO (no agent). On top of that, the most notable changes are in the plugin infrastructure.

  • All plugins have their PluginSetup (factory / custom install script) and the plugin itself
  • We have a "system" setup processor, handling the install/update/removal of plugins
  • Developer-made PluginSetup's don't have/need any permission to install new plugins on a DAO, we manage that
  • You can choose between different upgradeability patterns (if at all)

In a way, in terms of plugins, we can envision different families. Most notably:

  • Governance plugins: they can eventually execute something on the DAO
  • Utility plugins: streaming service to pay contributors (proposal-less) or others like Uniswap, AAVE, etc (which create a proposal on any of the governance plugins available)
  • UI-only plugins: no contract, just a new UI section to display on the main app

Each plugin consists of:

  1. PluginSetup contract: containing the instructions on how to install the plugin to a DAO
  2. The Plugins's implementation contract: the one containing the logic the plugin can do
  3. The contentURI: the IPFS root of the HTML/CSS/JS app to run within an iframe - be it in Aragon App, or any other UI who accepts this functionality
  4. An array of widget entrypoints: This is list of widget entry points (members widget, assets widget, etc) so that the plugin UI can come in to specific parts of the App's UI
  5. Metadata: name, description, screenshots of the plugin

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.