Governance process

A governance process can take a proposal from creation through decision to execution on an account, without necessarily depending on any other governance component. Its configuration determines who may propose, how decisions are reached, and the scope of actions it may direct.

A process connects participating bodies with account execution. Each body supplies its members' preferences, and its governor applies the voting or approval method. A standalone multisig plugin can act as process, body, and governor.

Staged governance processesCopy Anchor Link

A staged governance process uses the Staged Proposal Processor (SPP) to coordinate one or more stages. Its configuration sets the order of the stages and, for each stage, the participating bodies, approval and veto thresholds, and timing requirements.

A staged process can combine different governance plugins. For example, a multisig of trusted members can approve proposals before a token vote or review them afterward; multisig gates explains these arrangements.

SPP is an Aragon-deployed plugin. The Aragon team arranges installation and configures the process through the governance designer's Advanced — On request setup.

Each staged proposal follows this configured sequence. The rules of each stage determine whether and when that proposal can advance to the next stage or reach execution.

Configuration optionsCopy Anchor Link

Stages created through the app leave proposal cancellation and action editing disabled. SPP supports enabling these options for authorized addresses during specified stages.

Administrators considering these options or other stage configurations beyond those provided by the app can contact the Aragon team for setup and guidance.

Processes in the appCopy Anchor Link

For supported plugins, the app partitions the proposals list by process. Each process appears as a proposal type, grouping the proposals that follow its decision-making flow.

The app also shows processes from linked accounts in the same set, with an indicator identifying the account they belong to.

An account can have zero or more processes. The governance designer configures the plugins and their relationships when adding governance.

Process details pageCopy Anchor Link

The Process details page lets members inspect a process's execution scope and proposal-creation requirements, and access its removal action.

The page identifies the process by its name, description, and key, with its proposal count and latest proposal activity. Its contract and launch links lead to the plugin and installation record in the block explorer. For a linked-account process, the target address identifies the account it directs. Its governance section shows the single body of a Basic process or the stages and bodies of an advanced process read-only, with contract details for existing bodies. Governance changes follow the supported action or Aragon-assisted route.

• Authorized actions shows the contract functions the process is configured to call, with readable contract and function names where available. Rows include the function selector when supplied and a link to the target contract in the block explorer. It distinguishes an unrestricted process from a restricted process with no allowed actions. Scoped authority explains how those limits apply.
• Proposal-creation requirements shows the current eligibility rules when the process exposes them. The View requirements link in execution routing leads here when an author needs to understand a creation restriction.
• Uninstall process starts removing the process.