Onchain Governance & Aragon Integration

IPOR Fusion is designed to be "governance-ready" from day one. By utilizing the OpenZeppelin ERC20Votes standard and the modular architecture of the IporFusionAccessManager, Atomists can provide share owners with a decentralized safety net.

While daily operations are typically handled by specialized roles (Alphas and Atomists), onchain governance serves as a critical rescue mechanism to prevent capital lock-up and ensure vault continuity.

The Purpose: Governance as a Rescue Mechanism

The primary goal of integrating share-holder governance is not to manage the vault's day-to-day strategy, but to provide an emergency override for the following scenarios:

  • Abandoned Vaults: If the Atomist or Owner becomes inactive, the community can vote to appoint a new configuration manager.

  • Alpha Inactivity (Stuck Withdrawals): If the Alpha role stops calling releaseFunds(), scheduled withdrawals cannot be redeemed. Share owners can vote to appoint a new Alpha or trigger emergency exits.

  • Malicious Management: If operational roles attempt to set predatory fees or risky market limits, the community can use their voting weight to revoke those roles.

Architecture Overview

The governance integration relies on three main components:

  1. PlasmaVault Shares (ERC20Votes): Every Fusion vault share token inherits voting capabilities (checkpoints and delegation) via the PlasmaVaultBase contract and the PlasmaVaultVotesPlugin.

  2. Aragon DAO (The Executor): An Aragon DAO acts as the onchain entity that holds administrative roles for the vault, acting only when a community vote passes.

  3. IporFusionAccessManager: The authority contract that verifies if a recovery call originated from the authorized DAO.

Delegation Logic

Governance power is not automatically active upon deposit. Share owners must delegate their voting power (even to themselves) to activate their weight in the checkpoints.

Why Aragon OSx?

While not strictly required, Aragon OSxarrow-up-right is the preferred choice for a rescue DAO because:

  • Security at Scale: It provides a battle-tested executor (the DAO contract) that can hold the OWNER_ROLE.

  • Adaptive Governance: You can start with a high threshold for "Rescue Votes" to ensure the DAO doesn't interfere with standard operations unless absolutely necessary.

  • Transparency: Users can see the exact calldata of a recovery proposal (e.g., a proposal to swap the Alpha address) before voting.

Integration Blueprint: The "Guardian of Last Resort"

To enable recovery governance, the Aragon DAO is granted a high-level role in the IporFusionAccessManager.

Rescue Steps for Stuck Funds:

  1. Proposal: A user creates a proposal in the Aragon DAO to grant the ALPHA_ROLE to a new, active address.

  2. Vote: Share owners vote using their ERC20Votes shares.

  3. Execution: The DAO calls AccessManager.grantRole(Roles.ALPHA_ROLE, newAddress, 0).

  4. Recovery: The new Alpha calls releaseFunds(), allowing users to redeem their assets.

Atomist Setup Guide

1. Deploy the Vault and Aragon DAO

Deploy your Fusion Vault via the Build on Fusion web applicationarrow-up-right.

Create an Aragon DAO using the Aragon Apparrow-up-right.

2. Configure the Aragon Voting Plugin

Set up the ERC20 Voting Plugin in Aragon.

  • Token Address: Use the address of your PlasmaVault share token.

  • Quorum/Threshold: Set these high (e.g., >10% quorum) to ensure only significant community consensus can trigger an override.

3. Transfer Recovery Roles to the DAO

Grant the Aragon DAO address the OWNER_ROLE (1) or ADMIN_ROLE (0) in the IporFusionAccessManager. This ensures that if the human owner disappears, the DAO can still manage the vault.

4. Direct Users to Official Education Resources

For a rescue mechanism to work, users must have delegated their votes. Atomists do not need to create their own educational content for this process; instead, they should point their community to the User Education section of the official IPOR Fusion documentation.

This dedicated resource provides step-by-step instructions on how to perform manual delegation via blockchain explorers or third-party governance interfaces, ensuring that share owners can activate their voting power when a rescue operation is required.

Best Practices: Designing for Resilience

Avoid Daily DAO Management

Direct DAO management is usually too slow for DeFi yield strategies. Use the DAO as a backstop.

Multi-Role Guardianship

Consider assigning the GUARDIAN_ROLE to the Aragon DAO. This allows the community to quickly cancel a malicious operation scheduled by a compromised Atomist or Owner.

Execution Delays

Always configure an executionDelay for administrative actions. This gives the community and the DAO a "grace period" to propose and vote on a cancellation if a manager acts against the interests of the share owners.

Technical Note: The Fallback Mechanism

The PlasmaVault proxy contract handles all voting-related calls (delegates, getVotes, delegate) via its fallback() function, routing them to the PlasmaVaultBase logic. Third-party interfaces like Aragon or Tally can interact with thAe vault address as if it were a standard OpenZeppelin Votes token.

Last updated

Was this helpful?