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 mechanisms, 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 operational and configuration 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 operational and configuration 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 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 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 Guardian can cancel the Owner's operational and configuration transactions during their timelock (any function gated through the access manager's target-function-role map). Role-management calls (grantRole / revokeRole) are OpenZeppelin admin functions and are NOT guardian-cancellable — only the scheduler or an ADMIN can cancel those.

• Emergency Pausing: In the event of a suspected exploit or key compromise, the Aragon DAO can instantly pause target contracts, freezing all execution actions.

Limits of the Guardian: The Guardian is an emergency backstop for operational actions and pausing. It is not a defense against a compromised Owner's role escalation: it cannot cancel role grants/revocations and can itself be removed by the Owner. Defending against Owner compromise relies on (a) making the Owner a multisig with an execution delay, (b) the depositor exit window during timelocks, and — for a hard on-chain veto — (c) retaining a trusted ADMIN (via cloneSupervised) rather than renouncing it. Note that grantDelay is not configurable after ADMIN is renounced.

2.2 Voting Safeguards and Composability

Because the Guardian role holds these critical emergency powers, securing the underlying voting mechanism is paramount. Using live token balances for onchain voting creates a severe vulnerability where capital can be temporarily acquired or borrowed (e.g., via flash loans) to force malicious proposals through governance.

The Solution: Checkpointed Voting

To defend against this, the core token framework natively routes voting-related queries to an active votes plugin if enabled, implementing the following safeguards and trade-offs:

• 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.

• DeFi Composability Trade-offs: While delegation allows passive depositors to assign their voting rights, it does not solve the challenges of deep DeFi composability. If vault shares are deposited into an external protocol (e.g., as collateral), the external contract becomes the token holder of record. Because checkpointing snapshots the contract's aggregate balance, the original depositor loses their voting power unless the external protocol implements bespoke delegation logic.

• Future-Proofing for Composability: Currently, IPOR Fusion vault shares are primarily held directly by depositors, making standard checkpointing highly functional. However, if deep composability becomes a priority as the ecosystem matures, token-level checkpointing can be bypassed entirely. For instance, using an Aragon LockToVote plugin, users would simply lock their shares in a dedicated voting contract to acquire voting power, ensuring governance scales seamlessly with external DeFi integrations.

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. Timelocks make an Owner's actions — including revoking the Guardian — visible on-chain during the delay, but they do not let the Guardian veto them. The Owner is the admin of the Guardian role and can remove it after the delay; the Guardian cannot cancel its own removal. Timelocks provide detection and a depositor exit window, not a Guardian veto over role management.

3.1 Optional Timelocks as an Exit 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 Detection 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 detect the pending revocation on-chain. It cannot cancel it as the Guardian — revokeRole is an admin function, cancelable only by the scheduler or an ADMIN — but the delay guarantees a rage-quit / exit window: depositors (and the DAO) can redeem before the Guardian is removed. If an onchain veto of this action is required, the DAO must retain ADMIN (deploy via cloneSupervised), not merely hold the Guardian role.

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 operational transactions or utilize the exit window before role changes are executed.

3.3 Optional Co-Ownership and Rage-Quit Guarantees

The real protection against a malicious Owner or Atomist relies on a combination of factors: a decentralized MultiSig Owner, a long timelock ensuring detection, and a guaranteed rage-quit exit window for depositors. For absolute worst-case protection and a true on-chain veto, the Aragon DAO must either retain the ADMIN role (via cloneSupervised) or be configured as an additional Owner.

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 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.

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

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.