Make your DAO immutable

Making a DAO immutable freezes its plugin configuration and permissions while participants continue governing through the installed plugins. This is done by revoking permissions to change settings or upgrade contracts, then revoking ROOT to prevent those permissions from being re-granted.

One common use case is a Guardian DAO. Fixing its voting period, for example, prevents it from being extended beyond the vault's timelock, which could stop depositors from executing a veto in time.

These changes are permanent. Once a DAO is immutable, you would no longer be able to change the affected settings, upgrade its contracts, or re-grant the revoked permissions.

This guide explains how to revoke the desired permissions and prevent them from being re-granted.

Before you beginCopy Anchor Link

• A deployed and configured DAO. Your governance plugins should be installed, with their parameters and permissions configured as you want them. Once permissions are frozen, you cannot change those settings or install or uninstall plugins.
• Access to an authorized execution route. This could be Admin or a governance process through which you can execute proposals. If you are using Admin to set up your governance, you can continue using it throughout this guide and remove its authority in the final transaction.

The examples in this guide assume that the DAO still holds ROOT permission and uses a Basic Token Voting or Lock to Vote process.

Info: By default, a DAO created through Aragon or the DAOFactory holds ROOT permission on itself. ROOT allows its holder to grant and revoke permissions. This lets a plugin or address with Execute permission submit actions that make the DAO manage its own permissions.

1. Identify the permissions to removeCopy Anchor Link

Open the permission viewer. In List view, disable Hide permissions granted to DAO and Hide subplugin permissions to see the full list of permissions registered on the DAO.

Identify every permission that allows changes to governance settings, membership, execution targets, metadata, callbacks, the trusted forwarder, contract implementations, or permissions. Consider all installed governance plugins and all permission holders.

Keep Execute permission for the governance plugins you want to retain so they can continue executing approved proposals. Also keep their permissions for proposal creation, voting, and proposal execution.

Contact the Aragon team if you need help identifying which permissions to remove.

2. Build the revocation actionsCopy Anchor Link

1. Start a proposal and select the governance process. If Admin is installed, use it to execute the changes immediately without a vote.

2. In the action builder, add the DAO contract address and choose the revoke action.

3. Use the permissions you identified in the permission viewer to fill in the fields:

   • Where (_where) — The contract the permission applies to. Use the DAO address for DAO permissions or the voting plugin address for plugin permissions, as shown in the example table below.
   • Who (_who) — The address whose permission you are removing.
   • Permission (_permissionId) — The hexadecimal ID of the permission to remove, available in the permission viewer or in the example table below.

4. Add a revoke action to the same proposal for each permission that you identified in step 1.

   • Remove settings and upgrade permissions before ROOT, since revoking ROOT alone leaves existing permissions usable.
   • If you are executing through Admin, include an action to revoke the Admin plugin's Execute permission in this proposal.
   • Remove ROOT from any other holders before revoking the DAO's own ROOT permission as the final action.

5. Double-check the action addresses and permission IDs against the permission viewer.

Example: Basic Token Voting or Lock to VoteCopy Anchor Link

In this example, the actions freeze the DAO and voting plugin's configuration, including metadata, upgrades, and execution settings, and end Admin control. The voting plugin executes directly through the DAO. External token, Safe, and vault rules remain unchanged.

Each row is one revoke action on the DAO. Use the contract addresses for DAO, Voting plugin, and Admin plugin, and choose the settings permission for your plugin in action 1. If Admin was already removed, skip its two rows.

To adapt action 1 for an Aragon Multisig, use UPDATE_MULTISIG_SETTINGS_PERMISSION_ID: 0xb1750e46d35a0069c8465b8643e7838d2149a842a2db8ee233d9835590040cad. This freezes its approval settings and membership, including the ability to replace signers.

3. Execute the changesCopy Anchor Link

Publish the proposal through your selected governance process and confirm the transaction.

With Admin, the changes execute immediately, including removal of Admin's authority; with another governance process, obtain the required approvals or votes, then execute the proposal when it becomes executable.

4. Verify the resultCopy Anchor Link

Confirm that execution succeeded. Check the permission viewer against your original inventory: every permission you intended to revoke should be absent, Admin should no longer hold Execute, and the intended governance should retain its permissions for proposal creation, voting, and execution.

Confirm that the governance parameters and contract implementations match what you intended to preserve, and that no other permission holder or configuration control can restore the removed authority. Checking only the example's permissions does not cover additional plugins or permission holders.

For a Guardian DAO, return to Verify the DAO setup before assigning the DAO to your vault.