Governance

The governance model describes decision-making independently of any single contract. Start with Aragon OSx and the platform for how accounts, governance processes, and bodies relate to the contracts. For the underlying mechanisms, see governance plugins and the OSx plugin model.

Governance modelCopy Anchor Link

• Governance process — the rules and flow that take proposals from creation through decision to account execution.
• Body — the members whose preferences contribute to a governance decision.
• Member — a participant within a body, with body-specific membership and participation rules.
• Plugin — a contract installed to add a capability to an account, and its roles in governance.
• Target — where a process's plugin sends its approved actions, and what that says about whether it is a process or a body.
• Action — one onchain call, combined with other actions in an ordered array for execution.
• Proposal — an ordered action array and explanatory metadata submitted through a governance process.

Configure governanceCopy Anchor Link

• Admin flow — temporary governance, why it is installed by default, admin management, and handover.

• Removing a governance process — where removal starts, what the app requires before it, publishing the removal proposal, and the rule for the last recognized process.

• Governance designer — the flow for designing and installing governance in the app, and what can be edited afterwards.

• Plugin compatibility — levels of app support and what makes an installed plugin usable.

• Aragon-deployed plugins — supported capabilities deployed through an arrangement with the team.

ParticipateCopy Anchor Link

• Token panel — the Members-page controls for wrapping, voting-escrow locking, and delegation, together with their onboarding re-entry points. The Members page owns list ordering.
• veLocker — the Members-page vote-escrow experience, time-varying voting power, dynamic delegation, and deployment boundary.
• Gauge voting — non-proposal, epoch-based allocation of voting power across gauges, with its dedicated installed-plugin page and management actions.
• BENQI lending-market gauges — the BENQI-specific integration for registering market incentives in Gauge voting.
• Delegate profile record — the network-and-token-scoped ENS record that points to a delegate statement on IPFS.
• Aragon Notifications — opt-in Telegram alerts for proposal creation, approaching deadlines, and execution.

Prepare and inspect proposalsCopy Anchor Link

The shared Action builder, Basic action views, and simulation prepare and inspect actions for both proposals and direct transactions.

• Proposal creation — selecting a process, applying creation eligibility, composing the proposal, and submitting it.
• Cross-chain execution — composing a source-chain message whose nested action batch executes through a configured destination account.
• Proposal status — the single status every proposal displays, derived in the app from onchain state.
• Proposal identifiers — the onchain proposal ID and the app's friendly slug, built from the process key.

Compose staged governanceCopy Anchor Link

• Stage — the semantic layer of a single stage: timing, per-body approval or veto roles, independent thresholds, and bodyless timelocks.
• Staged proposals — how one proposal progresses through its stages, from body decisions to advancement and execution.
• Optimistic governance — the accept-unless-challenged decision pattern: why it reduces affirmative-participation overhead, how roles remain configurable, and why passive veto rights still demand active monitoring.
• Multisig gates — a multisig governing a stage that gates a staged process, before or after a token vote, and why a visible stage is preferred over a direct permission grant.
• Safe as a body — a Safe serving as a stage's governing body, rather than a plugin.

For distributions that use gauge outcomes, see Capital Distributor. Its Rewards page lets recipients inspect and claim allocations.