With the aragonOSx protocol, you can chain actions, but not chain them with dynamic, dependent content.
So - you can say, perform action A, action B, and action C when a proposal passes.
BUT - you can't say, perform action A, and when that's done, grab that variable, and place it to do action B, then use that new output to do action C
This design allows plugins to execute a predefined and static list of actions.
This is intentional, so that non-tech-savvy community members can clearly understand what will happen before they approve a proposal.
If we open the door to dynamic execution, it would be easy for malicious actors to craft confusing proposal executions that go to some random contract, forge a dynamic payload and execute it with the privileges of the DAO.
From a technician perspective, it's an exciting feature. But from a human-centric perspective, we need to provide as much clarity as possible.
A couple of scenarios:
- You want to install a plugin with a certain configuration, that depends on the given parameters:
To allow for this, every plugin has the
Plugin contract itself and a
PluginSetup, in which developers program any kind of "install script" that they need. Same for updates and uninstalling.
The install scripts are 100% known ahead of time. You know what prepareInstallation(...) will do.
- You want to execute a complex chain of operations:
In this case, you probably want to use a governance plugin along with a
Helper contract, which internally implements such complex logic. You request permission for the helper to do whatever it needs on the DAO, and people know ahead of time what this helper could do.