> For the complete documentation index, see [llms.txt](https://docs.ipor.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipor.io/build-on-fusion/atomists/vault-configuration-step-by-step/vault-governance-and-depositor-led-security-best-practices.md).

# Vault Governance & Depositor-Led Security Best Practices

## 1. Introduction: The Mechanics of Decentralized Checks and Balances

The IPOR Fusion architecture uses a system of complementary, interlocking roles and optional, structured timelocks to achieve checks and balances. While the system defines an **Owner** role with top-level administrative privileges, this power can be dynamically restricted, which is the primary focus of this document. In a fully secured deployment, the Owner's authority is bounded by temporal barriers and defensive vetoes, preventing any single administrative entity from acting unilaterally or compromising depositor assets.

Restricting and balancing this administrative power to protect depositors is the primary objective of the governance framework detailed in this document. Operational and protective power is distributed across the following roles:

* **Owner**: The primary administrative authority in the system. The Owner governs the access control manager, dictates which accounts hold administrative roles, and configures the execution delays (timelocks) for other roles. Crucially, the Owner's constructive actions can be restricted by the Guardian and configured temporal parameters, ensuring they cannot bypass the system's checks and balances.
* **Atomist**: The primary risk and configuration manager. Operating under the oversight of the Owner, the Atomist manages economic and risk boundaries. The Atomist configures price oracle middleware, sets overall supply caps, and dictates market allocation limits. To maintain a strict separation of concerns, the Atomist does not manage technical integration parameters such as substrates or fuses.
* **Fuse Manager**: The specialized technical integration manager. Operating under the oversight of the Atomist, the Fuse Manager is dedicated strictly to protocol integrations. The Fuse Manager manages which operation fuses (e.g., supply, borrow, or swap) are supported by the vault, attaches position-tracking balance fuses to specific market IDs, configures callback handlers, and manages market substrates (allowed assets, pools, and positions).
* **Alpha**: The strategic executor. Operating with maximum agility, the Alpha is responsible for active capital routing. Using only the whitelisted fuses, substrates, and parameters configured by the Fuse Manager, the Alpha routes capital across DeFi protocols in real-time to harvest yield.
* **Guardian**: The emergency protective backstop. The Guardian is purely defensive. It cannot execute strategies or alter configurations, but it can instantly trigger global contract pauses or veto pending, time-locked transactions scheduled by other roles.
* **Pre Hooks Manager**: The technical authority over pre-execution validation checks. Configures which pre-hooks (e.g., rate limiters, validation checks) execute before specific target functions to enforce strict safety boundaries.
* **Withdraw Manager Request Fee**: A technical role dedicated to configuring the fee rates charged to depositors when scheduling a withdrawal request.
* **Withdraw Manager Withdraw Fee**: A technical role dedicated to configuring and adjusting the fee rate charged to users withdrawing directly from unallocated balances.
* **Price Oracle Middleware Manager**: Manages price validation thresholds and maps individual assets to their respective oracle price feeds, ensuring the oracle middleware returns accurate valuation data.

### 1.1 Temporal Segregation: Optional Roles and Execution Delays

The fundamental mechanism of checks and balances in IPOR Fusion relies on *configurable, optional* execution delays (timelocks). By default, the access control manager allows for immediate, zero-delay execution of administrative and operational actions. However, deploying vaults with non-zero execution delays is a recommended security best practice for decentralized setups.

When configured, if the Owner, Atomist, or Fuse Manager initiates a change — such as updating fee parameters, setting market limits, or granting new substrates or removing a balance fuse — the access control manager enforces a mandatory temporal buffer.

During this delay, the proposed action sits in a transparent, pending state onchain. This structural delay serves a vital purpose: it gives the defensive Guardian role a reliable window to analyze the pending transaction. If the proposed change is malicious, accidental, or the result of a key compromise, the Guardian can execute an instant, zero-delay veto to cancel the transaction.

### 1.2 Strategic Agility vs. Structural Guardrails

Capital efficiency is highly dependent on the speed at which a vault can react to shifting market conditions. If a vault must wait days for a governance vote to exit a protocol when yields collapse, it suffers significant opportunity costs.

Fusion resolves the tension between responsiveness and safety by separating **structural vault management** from **active strategy execution**:

* **Capital Security** is maintained because the structural parameters of the vault—governed by the Owner, Atomist, and Fuse Manager—can be bound by configured timelocks. When activated, these parameters cannot be altered instantly, giving depositors a reliable window to evaluate changes or withdraw their funds.
* **Operational Responsiveness** is maintained because the Alpha role operates with a zero-delay timelock. As long as the Alpha's actions conform to the pre-approved, strictly bounded "sandbox" defined by the enabled fuses, whitelisted substrates, and market limits, strategy execution occurs at block speed.

#### 1.3 Tailoring Parameters to Depositor Coordination Dynamics

The optimal balance of parameters is determined by the depositor profile and vault access model, which dictates the coordination capacity of the participants:

* **Open Public Vaults**: These vaults are permissionless and open to a fragmented, uncoordinated depositor base. Because especially retail depositors face high coordination hurdles, they cannot easily organize a rapid veto or collective exit on short notice. Consequently, these setups highly benefit from configured, long timelocks on constructive administrative actions to guarantee depositors a reliable exit window before changes take effect.
* **Closed Institutional (Whitelisted) Vaults**: These vaults restrict entry to a pre-whitelisted, highly sophisticated set of large-ticket depositors. These depositors have direct communication channels and high coordination capacity and these vaults can securely operate with zero-delay or very short timelock profiles to maximize operational agility and market responsiveness.

## 2. Aragon Depositor DAO: Institutionalizing Depositor Power

To give depositors a direct voice, we recommend establishing an external Depositor DAO. While optional and not natively built into the core smart contracts, introducing an external Depositor DAO is a powerful best practice. [Aragon](https://aragon.org/) is one popular protocol that enables this, and we use it throughout this document as our running example. Membership and voting power in this Aragon-based Depositor DAO are natively tied to the vault's share tokens (minted by the vault upon deposit).

### 2.1 Voting Safeguards: Defending Against Capital-Backed Manipulation

Using live token balances for onchain voting creates a severe vulnerability where capital can be temporarily acquired or borrowed to force malicious proposals through governance.

**The Solution: Checkpointed Voting**

The core token framework natively anticipates this through delegation and checkpointing, routing voting-related queries to an active votes plugin if enabled.

* **Historical Checkpoints**: The Aragon DAO must be configured with a voting plugin that queries historical votes at a snapshot checkpoint (e.g., the state of balances before the proposal was submitted) rather than the active, live state.
* **Sub-Account Isolation**: To ensure that vault shares locked in other protocols (e.g., as collateral) can still vote, the voting plugin should support voting-by-delegate, allowing the vault's external positions to forward voting weight back to the depositor.

### 2.2 Aragon DAO as the Vault's Guardian

The Aragon DAO is granted the Guardian role in the access control manager. This role serves as the vault’s primary security veto and emergency circuit breaker.

**Guardian Capabilities:**

* **Veto and Cancellation**: The Aragon DAO can immediately cancel any transaction scheduled by the Owner or the Aragon DAO during its timelock period (if a timelock is configured).
* **Emergency Pausing**: In the event of a suspected exploit or key compromise, the Aragon DAO can instantly pause target contracts, freezing all execution actions.

## 3. Preserving the Balance of Power (Anti-Subversion)

A common flaw in standard role hierarchies is that the Owner role retains the right to unilaterally revoke roles, which would allow a compromised or malicious owner to strip the Aragon DAO of its Guardian role. When timelocks are configured, the system can prevent this subversion.

### 3.1 Optional Timelocks as a Veto Window

Any administrative action initiated by the Owner (such as granting or revoking roles) can be subjected to an optional, long-duration execution delay (e.g., 14 days) configured via the access control manager.

* **The Veto Window**: If a malicious Owner attempts to revoke the Aragon DAO's Guardian role, and a timelock is active, the transaction must be scheduled first.
* **The Reaction**: During this delay, the Aragon DAO can easily detect the pending transaction onchain and execute a cancellation via its Guardian permissions, rendering the Owner's attack impotent.

### 3.2 Graded Timelocks for Centralized and Decentralized Owners

Depending on the operational model and depositor base of the vault, the Owner role can be securely assigned in one of two configurations, aligning execution delays directly with the coordination profile of the participating entities:

1. **Decentralized Institutional MultiSig (Short or 0-Day Timelock) — Ideal for Closed Institutional Vaults**: The Owner role can be assigned to a highly decentralized, multi-institutional MultiSig consisting of a threshold of 4/6 or 5/8 keys consisting of e.g.:

   * Core vault developers (2 keys).
   * Independent, highly reputable partner protocols or DAOs (2 keys).
   * Professional third-party custodians or security firms (2 keys).

   Because this configuration distributes key management among independent, highly reputable entities, the risk of a single-party exploit, key compromise, or collusive attack is virtually non-existent. Under this setup, the Owner role can operate with a 0-day timelock, allowing for rapid administrative reactions and maximum responsiveness when market conditions pivot.
2. **Economic Owner / Asset Manager (Optional Long Timelock) — Ideal for Retail-Focused Public Vaults**:

   Alternatively, the vault's economic owner (the core asset manager or developer team) may choose to retain direct administrative control of the Owner role (e.g., via their own team MultiSig or EOA keys) to ensure operational independence.

   If this centralized approach is taken, binding the Owner role with a long execution timelock (e.g., 14 days) is highly recommended. This timelock ensures that any administrative change proposed by the team is visible onchain for a substantial period, giving the Aragon Depositor DAO (acting as the Guardian) a clear veto window to spot and cancel the transaction before it is executed.

### 3.3 Optional Co-Ownership and Rage-Quit Guarantees

For complete worst-case protection, the Aragon DAO can be configured as an additional Owner, since Fusion allows multiple Owner role holders. If this administrative configuration is used, the Aragon DAO's Owner actions can be subjected to a long execution timelock (e.g., 21 to 30 days) to prevent coordination issues or sudden governance takeovers.

This optional long timelock on the DAO's Owner actions provides several fundamental security and game-theoretic advantages:

1. **Defense Against Hostile Takeovers and Capital Accumulation**:

   While checkpointed voting prevents instantaneous flash loan exploits, it does not prevent a wealthy hostile entity from gradually purchasing a large volume of vault shares on the open market. If this entity accumulates a majority voting share (greater than 50%), they could pass a malicious DAO proposal to alter critical vault parameters or redirect fees. A long timelock (21 to 30 days) forces any approved proposal to sit in a pending state, giving the core development team, partner protocols, and remaining depositors ample time to detect the hostile takeover and coordinate a counter-strategy.
2. **Ensuring a Minority Exit (Rage-Quit) Window Tailored to Depositor Coordination Dynamics**:

   In decentralized systems, a voting majority may choose to steer the protocol in a direction that is highly detrimental or unacceptable to the minority. An optional long timelock provides a guaranteed escape window, but its necessity and duration are strictly aligned with the coordination capabilities of the depositor base:

   * **Retail-Focused (Open Public) Vaults**: Dissenting retail depositors cannot coordinate quickly to execute counter-governance. They require a long timelock (typically 21 to 30 days) as an absolute guarantee that they can redeem their shares and exit the vault cleanly before the proposed governance parameters go live.
   * **Closed Institutional Vaults**: Because of the whitelisted, high-coordination nature of the depositors, a lengthy timelock is often counterproductive. Dissenting institutions can quickly communicate and use off-chain agreements or rapid multisig vetoes, allowing these vaults to safely deploy shorter timelock profiles (e.g., 7 to 14 days) if desired.
3. **Mitigating Coordination Errors and Governance Quorum Failures**:

   DAO governance processes can occasionally suffer from low voter turnout, rushed voting windows, or coordination errors where a flawed proposal is inadvertently passed. A long timelock acts as an essential sanity buffer, ensuring that even if a problematic proposal successfully passes a vote, it cannot be executed instantly. This delay provides dissenting members and the Guardian a crucial window to analyze the transaction, sound the alarm, and deploy emergency overrides before permanent changes are finalized.
4. **Resolution of Dual-Deadlock Scenarios (Long-Term Unwinding)**:

   This slow-path recovery mechanism is designed specifically to resolve a catastrophic **dual-deadlock** scenario where **both** of the following conditions are simultaneously met:

   * The Alpha is permanently offline or abandoned, leaving the vault unable to adjust active positions.
   * The normal administrative entities (Owner and Atomist) have also abandoned the vault, lost access to their signing keys, or become completely unresponsive.

   Conversely, if only the Alpha is offline or inactive, the Owner/Atomist can hire a new Alpha service provider to re-activate capital routing. If only the Owner or Atomist loses access or abandons the vault, the active Alpha continues executing the automated capital routing strategies without interruption. Only when *both* entities are entirely incapacitated does this Aragon DAO co-ownership path become the necessary fail-safe. Over the course of the 21-to-30-day delay, the Aragon DAO can reassign the Alpha role to a backup keeper. 
5. **Strategic Asymmetry: Guardian (0-Day Delay) vs. Owner Timelock Profiles**:

   A robust governance model requires a fundamental timing asymmetry:

   * **Defensive Actions (The Guardian Role)**: Must always have zero delay (0-day timelock). When pausing an exploit or canceling a compromised Owner transaction, the Aragon DAO must act instantly to preserve vault safety, regardless of whether the vault is retail-focused or institutional.
   * **Constructive/Structural Actions (The Owner Role)**: The timelock is dependent on the Owner configuration:
     * *Under Option A (Decentralized MultiSig)*: Structural changes can be executed with a short or 0-day delay because the multi-entity signer structure itself acts as the preventative collusion buffer.
     * *Under Option B (Economic/Centralized Owner) or Aragon DAO ownership*: Structural changes are best bound by a long delay (21 to 30 days), ensuring that absolute transparency and exit rights are guaranteed to uncoordinated participants before changes go live.

## 4. The Graded Timelock and Security Matrix

To achieve optimal operations, security settings must scale with the risk profile of each role. We define a graded hierarchy where execution delays (timelocks) correspond directly to the signing threshold, risk profile, and decentralization of the entity holding the role.

<table><thead><tr><th width="103.20001220703125">Role Name</th><th width="119.20001220703125">Suggested Holder</th><th width="110.39996337890625">Recommended Timelock</th><th width="156.0001220703125">Operational Purpose</th><th width="114.4000244140625">Guardian Vetoable?</th></tr></thead><tbody><tr><td>Owner (Option A)</td><td>4/6 Institutional MultiSig</td><td><strong>0 - 24 Hours</strong></td><td>Top-level configuration with minimal collusion risk (ideal for Closed Institutional setups).</td><td><strong>Yes</strong> (If any delay is set)</td></tr><tr><td>Owner (Option B)</td><td>Asset Manager MultiSig </td><td><strong>14 Days</strong></td><td>Traditional administrative control, secured by long delay (ideal for Retail-focused setups).</td><td><strong>Yes</strong> (Vetoable by Aragon DAO)</td></tr><tr><td>Atomist</td><td>3/5 Developer MultiSig</td><td><strong>3 Days</strong></td><td>Day-to-day vault configuration, setting market limits, total supply caps, and price oracle configuration.</td><td><strong>Yes</strong> (Vetoable by Aragon DAO)</td></tr><tr><td>Fuse Manager</td><td>3/5 Developer MultiSig</td><td><strong>3 Days</strong></td><td>Activating/deactivating integration fuses, balance fuses, managing market substrates (allowed assets/pools/positions), and callback handlers.</td><td><strong>Yes</strong></td></tr><tr><td>Guardian</td><td>Aragon Depositor DAO</td><td><strong>0 Days</strong></td><td>Emergency pausing and transaction cancellation.</td><td><strong>No</strong> (Direct Execution)</td></tr><tr><td>Alpha</td><td>Automated Keeper / EOA</td><td><strong>0 Days</strong></td><td>High-speed strategy execution and instant asset routing.</td><td><strong>No</strong></td></tr><tr><td>Pre Hooks Manager</td><td>3/5 Developer MultiSig</td><td><strong>3 Days</strong></td><td>Enabling/disabling rate limits, validation checks, and pre-execution hooks.</td><td><strong>Yes</strong></td></tr><tr><td>Withdraw Manager Request Fee</td><td>3/5 Developer MultiSig</td><td><strong>3 Days</strong></td><td>Adjusting request-phase fees for scheduled withdrawals.</td><td><strong>Yes</strong></td></tr><tr><td>Withdraw Manager Withdraw Fee</td><td>3/5 Developer MultiSig</td><td><strong>3 Days</strong></td><td>Configuring final-phase direct withdrawal fees.</td><td><strong>Yes</strong></td></tr><tr><td>Price Oracle Middleware Manager</td><td>3/5 Developer MultiSig</td><td><strong>3 Days</strong></td><td>Mapping price feeds and managing price validation delta thresholds.</td><td><strong>Yes</strong></td></tr></tbody></table>

## 5. Summary: A Unified Framework for Fusion Vaults

By combining checkpointed voting, optional role-based execution delays, and a MultiSig matrix, IPOR Fusion vaults can achieve maximum onchain decentralization and Aragon DAO-led depositor security without sacrificing the agility required to capture market yields. Setting strict boundaries around constructive, risk-increasing modifications while keeping defensive, de-escalation pathways completely unencumbered ensures that the system is both highly secured against internal subversion and highly responsive to systemic market failures.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.ipor.io/build-on-fusion/atomists/vault-configuration-step-by-step/vault-governance-and-depositor-led-security-best-practices.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.