Execution routing
An execution route determines who submits actions to an account and what must happen before the account can execute them. The app supports direct execution by an authorized actor and execution through a governance process's proposal lifecycle.
Both routes reach the DAO's execute function. The account checks the caller's Execute permission, including any conditions, before executing the actions.
Direct execution
The most direct route is for an authorized actor to submit actions to the account's execute function without creating a proposal on that account. In the app, Create transaction provides this route from the Transactions page, where the connected actor prepares and submits the actions. An authorized primary account acting on a linked account can use the same route.
Execution through governance
A governance plugin can itself hold Execute permission on the account. The plugin manages its own proposal lifecycle: an author submits actions in a proposal, and participants decide whether they should execute under the process's rules. Once the proposal meets its execution requirements, the plugin can submit the actions to the account's execute function. This adds a governance decision before the account executes the actions.
The app uses a shared selector to choose the governance process when creating a proposal, adding governance, removing a process, or upgrading contracts. This selector currently offers installed process plugins; direct execution uses the separate Transactions entry point.
Choosing a process
The selector lists visible, supported process plugins installed on the account and its linked accounts. The choices can be restricted by the flow's requirements, such as requiring a process with unrestricted execution for uninstallation. Each process's execution scope determines which actions it may ask the account to perform.
Some flows already determine the process and continue without a separate choice. For example, proposal creation and adding governance use the only available process automatically. When a choice is needed, the selector asks which process to use; in proposal creation, this is labelled the proposal type.
Creation requirements
The connected actor must meet the selected process's proposal-creation requirements. These can depend on membership, voting power, or other configured conditions. The app checks this before continuing with the selected process.
The selector first simulates proposal creation. Processes with a successful check appear first. A process whose simulation returns a definite rejection remains visible but disabled; View requirements opens its Process details page. If the simulation cannot run or returns an inconclusive result, the process remains selectable and the app checks eligibility when the flow continues.
The selected process's execution scope and the target's authorization rules also apply when the actions execute.
Preparing and submitting actions
In general proposal creation and direct execution, the user composes actions with the Action builder. Use case-specific flows, such as contract upgrades and governance installation, assemble the actions from the user's choices and any preparation transactions. The app builds the contract calls needed to make the requested change, so the user does not have to identify and compose each call manually.
Submission follows the chosen route: the user publishes a proposal through the selected process or submits the actions directly to the account. Each transaction involved uses the applicable submission flow.
Last updated on