Create transaction
The Create transaction flow provides a direct execution route for a connected actor with Execute permission on the account. The actor submits actions without creating a proposal on that account.
Execute transaction page
Mechanics
The Transactions page shows an Execution button when the connected actor — a wallet, a Safe, or another account acting over WalletConnect — passes the account's Execute-permission check. The check evaluates the permission onchain with empty condition data (0x). A conditioned grant must accept that data for the button to appear; a condition that requires the actual execution call can leave the button hidden even when it permits particular batches. Opening the flow does not establish that the prepared batch is authorized: the account checks the actual call at execution.
The same eligibility check guards the wizard and returns an ineligible actor to Transactions.
Composing and submitting
Clicking Execution opens a one-step full-screen wizard around the shared action builder. There is no metadata or settings step because direct execution creates no proposal; it calls the DAO's own execute. The composer does not filter actions to the connected actor's permission scope; its catalog uses the account's plugins and permissions as described under allowed-action filtering.
Continuing from the action-builder step opens the direct-execution transaction dialog. When the user prepares several actions, the app encodes them into one DAO.execute call: a single transaction carrying an atomic action batch (protocol execution). A signer authorizes that one outer transaction. The third-party wallet controls its signing display; Aragon's action views provide the action detail before submission.
Before submitting on a chain with simulation available, the user can simulate the prepared actions or skip simulation. In this direct-execution flow the connected wallet is the caller and the DAO is the target; no proposal object or governance plugin participates. Submission then runs the direct-execution transaction dialog: a two-step send that shares the transaction dialog's chain-mismatch disclosure and pre-signing switch, but not its four phases or its memory of an interrupted attempt. Its exit guard releases as soon as the send succeeds and re-arms if it fails (leaving an unfinished flow).
Who reaches for it
The specialized action catalogue applies to direct composition as well as proposals.
This is how an actor holding execute permission on the DAO itself acts — a deliberate arrangement that sits alongside the governance processes rather than inside them. It is a different grant from executing a passed proposal on a process, which stays inside governance (direct execution grant to a Safe holds that contrast). It is also the same permission-gated button the linked-account flow drives — with the difference that when the connected actor arrives over WalletConnect, the composed call is handed back to that actor and rides its own governance instead of executing immediately (executing on a linked account).
Last updated on