Harden token governance against governance attacks

Configure a token-governance process so that capturing it costs an attacker more than the attack could gain. A governance attack here means using the process itself against the organization: acquiring voting power temporarily to pass a proposal, proposing malicious actions while few holders are watching, exploiting low participation, or executing a captured decision before anyone can react. Each defense below is a design decision inside the process — what counts as voting power, who may propose, what a decision requires, and what stands between a passed vote and execution.

Prerequisites and limits. The single-body decisions below are configured in the governance designer; the staged safeguards require setup by the Aragon team through Advanced — On request. Make these decisions before installing: advanced processes are not editable in the app, so changing a live process's safeguards later means working outside the app or contacting Aragon. These measures raise the cost and visibility of an attack; none makes one impossible. Weigh each against your token's liquidity and your holders' attention.

1. Make voting power expensive to acquire and reuseCopy Anchor Link

Work through Choose a voting-power mechanism for token governance first — it decides which economic claim counts and how the mechanism prevents voting with the same claim twice. Two of its consequences are security boundaries:

• Token Voting weighs each address at a checkpoint immediately before proposal creation, so moving tokens after the snapshot does not change that proposal's weight (the snapshot). On the wrapped route this cuts both ways: someone can acquire the underlying ERC-20, wrap it, create a proposal, then unwrap and sell while the checkpointed voting power still counts for that proposal. Evaluate that exposure against the token's actual liquidity before accepting the wrapper.
• Lock to Vote prevents reuse through custody instead: locked tokens cannot move to another address to vote again. A voter cannot exit and keep an open vote — Standard mode keeps cast voting power locked until the relevant proposal ends, and Vote Replacement permits an early unlock only by first withdrawing the holder's open votes — so an attacker's position stays committed for as long as their vote stands.

2. Decide who may create proposalsCopy Anchor Link

A governance attack starts as an ordinary proposal, so creation eligibility is the first gate. It is configured independently from who decides (proposal creation): narrowing creation does not narrow the vote, and the two choices protect against different failures.

• Know the defaults. A basic Token Voting or Lock to Vote process installs with a minimum proposer requirement of one whole token, so any address holding — for Lock to Vote, having locked — at least that much can propose, not only known members. A staged process on the designer's defaults restricts creation to members of the process's bodies; picking Anyone instead leaves creation open at the protocol level.
• Narrow creation to the group that should author proposals. Eligibility is independent per body, so a staged process can allow a multisig's members to create proposals without extending creation to token holders (multisig gates).
• Raise the proposer's required stake. Ask Aragon to compose an already-deployed condition contract into the advanced process's creation rule — for example the above-a-token-threshold VotingPowerCondition, which gates creation on token balance (existing conditions).

3. Set thresholds with the denominator in mindCopy Anchor Link

The three thresholds decide what a proposal must earn. The participation threshold is the one that stands against low-turnout capture: it sets how much of the total voting power must take part before a proposal can pass, so a small active minority cannot settle a decision most holders never saw.

What that percentage demands depends on the mechanism's denominator. Token Voting weighs a proposal against the token supply recorded with that proposal's settings at creation, so the demanded voting power stays fixed for the proposal's life; Lock to Vote reads the token's live total supply each time a proposal is evaluated. For a mintable or burnable token, treat supply policy as part of choosing the threshold — a supply change moves the bar with no vote cast (commitment and participation requirements).

4. Give every decision enough timeCopy Anchor Link

Attacks profit from speed; every window below is reaction time for defenders.

• Set the voting window deliberately. Token Voting enforces its configured minimum duration at proposal creation, and the multisig wizard recommends at least five days between start and end (creating a proposal).
• In a staged process, the stage duration is the window the stage gives its bodies. When any body can veto, the full duration is a protected objection window the stage cannot advance before; early advance exists only for approval-only stages.
• Time only protects holders who learn a proposal exists. Every veto or monitoring role needs a reliable path to discover proposals before its window closes (the attention risk).

5. Put safeguards between the vote and executionCopy Anchor Link

Work with Aragon to express each safeguard as its own stage of one staged proposal pipeline. Add a multisig gate to an advanced governance process helps prepare the multisig configuration for that setup.

• Gate what reaches token holders. A multisig stage before Token Voting means a proposal clears a smaller, accountable group before the wider vote, with creation limited to its members (multisig gates).
• Gate what executes. After Token Voting, an approving multisig stage adds a final sign-off before execution, and a vetoing body gives a security council a protected objection window while the proposal advances by default (optimistic governance). Reaching a stage's veto threshold blocks the proposal regardless of approvals (stage).
• Add a timelock. A bodyless stage is a pure delay that becomes advanceable only after its duration, putting guaranteed reaction time between a passed vote and execution (stage).

6. Keep every safeguard visibleCopy Anchor Link

Prefer a stage over a direct permission grant. Granting creation or execution directly to a Safe works, but it keeps that role out of the proposal page's stage view — real, yet invisible to the people the safeguards protect — and the creation variant buries the proposal's real actions in nested calldata that Safe signers cannot review with the app's action presentation (stages over direct permission grants).

7. Review what each proposal actually executesCopy Anchor Link

Design-time safeguards still depend on reviewers reading the proposal in front of them. The action builder makes the exact actions legible, and action simulation tests the permission and action-execution path — whether the intended caller will be permitted to execute and whether the actions succeed — during creation and on any proposal in a non-terminal state, on chains with simulation available.

Done stateCopy Anchor Link

The configuration is done when the mechanism choice prices in snapshot-and-exit acquisition, creation eligibility names its authors deliberately rather than by default, the participation threshold is chosen with its denominator's supply policy, every safeguard appears as a visible stage, and a passed vote still faces time — a full window, plus a delay or objection stage — before execution.

Two duties continue past installation: veto holders must keep discovering proposals in time to object, and reviewers must keep reading and simulating actions proposal by proposal.