Value proposition

The Aragon platform lets organizations, teams, and onchain operators securely execute actions to manage treasuries and operate protocols. Different kinds of actions can have their own governance processes, modularly composed and tailored to their needs, with an experience as intuitive and satisfying as that of a web2 platform.

Expressive onchain policy lets an organization decide who may act, how decisions are made, and which powers each process may exercise. Its permission configuration can give different processes access to different target contracts and functions: treasury operations, protocol parameters, and permission administration can each have their own decision-making process and execution scope. The configured grants and conditions enforce that separation onchain.

The app brings supported governance methods, action preparation, treasury activity, and permission inspection into one interface. Operators and participants can move from configuring authority to preparing, reviewing, and executing actions within the same product.

That experience depends on stewardship of the abstraction between people and onchain state. Users trust Aragon to make the relevant model, state, and consequences understandable: over-abstraction would be dishonest, while under-abstraction would make governance incomprehensible. The app therefore makes the common path coherent and provides a route to deeper facts when a decision needs one.

Key benefitsCopy Anchor Link

• Choice of governance methods — organizations can choose multisig approval for council-based decision-making, token voting for token-holder decisions, or combine methods in a staged process. The Aragon OSx plugin model makes governance methods replaceable and composable; the app presents the supported plugin methods. The platform is unopinionated about which method an organization adopts.
• Governing bodies — an account can define separate stakeholder groups, each a distinct body with its own membership and decision rules.
• Staged proposals — governance processes whose proposals move through multiple stages that can involve different bodies, with the whole pipeline displayed transparently so governance decisions visibly translate into onchain actions (staged proposals).
• Multiple proposal types — each type of action the account performs can have its own process (its own "proposal type"), with an execution scope defined through the account's scoped authority.
• Optimistic governance — a proposal can follow an accept-unless-challenged path: designated proposers author the concrete proposal while designated stakeholders retain a protected opportunity to veto, avoiding routine affirmative-voting transactions when nobody objects (optimistic governance).
• Build, reuse, and review action batches — the shared action builder gives operators purpose-built forms for recognized actions, typed contract-function inputs, and access to raw calldata. Operators can order actions, capture requests through WalletConnect, and export or import batches for reuse in proposals and direct transactions. Authors, reviewers, and voters can inspect readable actions and, on supported chains, simulate their execution to estimate whether the batch will succeed through its intended execution route.
• Inspect configured authority — the Permission Viewer makes an account's indexed OSx grants and conditions readable in list and graph views. Operators can inspect configuration after a change, and members or counterparties can trace who holds which powers, with recognized conditions exposing their configuration and other conditions inspectable by address.
• Evolving governance — governance is not frozen at setup: processes can be added and removed, and bodies and single-plugin processes edited, as the organization's needs evolve (governance designer); editing a multi-stage process is a hands-on engagement today rather than an app flow. Governance can also be replaced without reconfiguring the contracts that already authorize the account, because the account keeps its stable target-facing identity while its scoped authority is reassigned among processes.
• Modular and extensible UI — supported plugin methods share one interface, including proposal-based decisions and Gauge voting, which allocates voting power across destinations.