IPOR Protocol
  • The IPOR Protocol Documentation
  • IPOR Protocol V2
  • Research / Whitepapers
    • Conceptual Whitepaper
  • Audits
  • Community Links
  • IPOR Protocol Roadmap
  • IPOR FAQ
    • About the IPOR Protocol
    • Using the IPOR Protocol
    • Liquidity Mining
    • Swaps VS Perps
    • $FUSN Snapshot
  • About IPOR
    • Who Uses IPOR and for What?
    • Why IPOR?
    • IPOR Manifesto
  • IPOR Fusion ⚛️
    • Fusion Introduction
      • Defragmenting DeFi Yield
    • Why Fusion?
    • Users
    • Use Cases
    • Architecture Overview
      • Atomists
      • Alphas
    • Vaults
      • Access Management
    • Fuses
    • Security
      • For Liquidity Providers
      • For Vault Owners
      • Testing
    • Open-source Repository
    • Aragon Integration
  • IPOR Index
    • What is the IPOR Index
    • Working with the IPOR Index
    • IPOR stETH Index
  • Interest Rate Derivatives
    • Interest Rate Derivative
    • Index Calculation
    • IPOR Publication
    • IBT
    • Indicative Term Sheet
  • Automated Market Maker
    • The Automated Market Maker
    • Liquidity Provisioning
    • IPOR Swaps
      • Hedging example with Morpho protocol
    • Spread
      • Math behind the demand spread
    • Risk oracle
    • SOAP
    • Liquidations
    • Asset Management
  • Tokenomics
    • IPOR Token
    • Token distribution model
    • Power IPOR
    • Liquidity mining
      • Math behind the rewards contract
    • Power Token Liquidity Mining for Developers
  • IPOR DAO
    • IPOR DAO Governance
      • Discord - All Channels
      • Discord - Open Governance Forum
      • Discord - Formal Governance
      • Snapshot - Formal Governance
      • Governing Multisig wallets
    • Decentralizing IPOR
      • Configuration Parameters
  • Developers Docs
    • Fusion
      • Developing а Fuse
      • Configuring Pre-hooks
      • Vault configuration step-by-step
    • Deployed Contracts
      • Ethereum
      • Arbitrum
      • Base
    • Working with IPOR Router
    • ABI
    • V2 changes
    • IPOR Oracle
    • Vault Wrapper
Powered by GitBook
On this page
  • Access Management
  • Strategy
  • 1. Balance Fuses
  • 2. Functional Fuses
  • 3. Fuse Configuration
  • 4. Pre-Hooks
  • 5. Scheduled Withdrawals
  • 7. Fees
  • 8. Price Oracle

Was this helpful?

Edit on GitHub
  1. Developers Docs
  2. Fusion

Vault configuration step-by-step

PreviousConfiguring Pre-hooksNextDeployed Contracts

Last updated 2 days ago

Was this helpful?

Below best practices and vault setup algorithm is a guide you can use to configure your own Fusion Vault. All settings described below can be acomplished by using https://beta.ipor.io/fusion web application.

Access Management

IPOR Fusion utilizes OpenZeppelin's AccessManager to restrict function access through a role-based system. The roles below are ordered from highest to lowest authority. (Developer note: The list of roles is available in the GitHub repository: )

  1. Owner: The highest administrative role, defined during the vault's bootstrapping process and immutable thereafter. Best practices:

    1. Use a highly secure multisig wallet for management.

  2. Guardians: This role has the authority to reject time-locked actions and to pause or unpause the vault. Best Practices:

    1. Use a secure multisig wallet for management to enhance security.

    2. If using automated risk monitoring, consider granting the Guardian role to an emergency mechanism to enable vault pausing.

    3. When using automation, monitor time-locked actions and send alerts to Guardian role holders, particularly for pre-hook events.

  3. PreHooksManager: As outlined in the pre-hook configuration, all changes made by the PreHooksManager must be subject to a timelock. This delay allows liquidity providers (LPs) and other administrators to respond if pre-hooks are set incorrectly. Best practices:

    • Implement a sufficiently long timelock for PreHooksManager actions.

    • Use a multisig wallet to administer pre-hooks for enhanced security.

  4. Atomists: This role serves as the primary managing accounts for the vault, overseeing most day-to-day settings, such as configuring FuseManagers, Alphas, fees, and other parameters. Best practices:

    • Use multiple Atomists to ensure redundancy.

    • Apply timelocks to selected Atomist actions whenever feasible.

  5. Fuse Managers: This role is responsible for adding, removing, and configuring fuses. Best Practices:

    • For a more decentralized setup, use a dedicated, time-locked account to manage fuses, as they impact the strategy.

  6. Alpha: This role operates the vault, typically as an automated strategy manager. Depending on the level of automation, the following roles can be assigned to the same wallet managed by Alpha in the IPOR Fusion system:

    • CONFIG_INSTANT_WITHDRAWAL_FUSES_ROLE (900): This role configures fuses, such as credit market deposit fuses, to enable instant withdrawals, allowing liquidity providers (LPs) to withdraw assets from the vault immediately. The role holder defines the order of configured markets to ensure asset availability for LPs. A key requirement is that the market (a collection of fuses linked to an external platform) must be fully liquid from the vault’s perspective. If liquidity is used as collateral for borrowing, instant withdrawals could trigger liquidation, so such markets should not be used. For complex vault strategies involving adding or removing credit positions, assign this role to Alpha for efficiency. Alternatively, a dedicated address or Atomist can manage it. Best Practices:

      • Ensure markets selected for instant withdrawals are highly liquid to avoid liquidation risks.

      • Use timelocks for changes to fuse configurations to allow review by Guardians or LPs.

    • WITHDRAW_MANAGER_REQUEST_FEE_ROLE (901): This role sets the request fee, charged when an LP submits a withdrawal request from a scheduled withdrawal vault. The fee is applied at the time of the request, not redemption. For strategies with algorithmically adjusting fees, assign this role to Alpha. Alternatively, Atomists can manage it based on the vault’s strategy. Best Practices:

      • Use a multisig wallet for managing this role to enhance security.

      • Monitor fee adjustments to align with the vault’s strategy and LP expectations.

    • WITHDRAW_MANAGER_WITHDRAW_FEE_ROLE (902): This role sets the withdrawal fee, analogous to the request fee but charged during instant withdrawals. Best Practices:

      • Align withdrawal fees with the vault’s operational strategy.

      • Use a multisig wallet for secure management.

    • UPDATE_MARKETS_BALANCES_ROLE (1000): This role manually updates cached market balances for deposits or withdrawals if automation (e.g., via pre-hooks) is not enabled. This is necessary for less active vaults to ensure accurate balance reporting. For efficiency, assign this role to an automated service. Best Practices:

      • Automate balance updates with pre-hooks when possible to reduce manual intervention.

      • Grant this role to a secure, automated service to ensure timely updates.

    • UPDATE_REWARDS_BALANCE_ROLE (1100): Similar to the previous role, this role updates the balances of incentives claimable by the vault through the rewards manager. For automated workflows, assign this role to Alpha. Best Practices:

      • Integrate with automated reward tracking systems to streamline updates.

      • Use a secure wallet or service for this role to prevent unauthorized access.

    • CLAIM_REWARDS_ROLE (600): This role allows claiming rewards on behalf of the vault. For practical reasons, assign this role to Alpha to automate reward collection. Best Practices:

      • Use a secure, automated system like Alpha to ensure timely reward claims.

      • Monitor reward claims to verify correct distribution.

    • TRANSFER_REWARDS_ROLE (700): This role enables the transfer of claimed rewards to the rewards claim manager. In the IPOR Fusion Plasma Vault, reward management (e.g., selling, staking, or transferring) can be handled by a dedicated module. If no such module exists, Alpha can manage rewards manually. Assigning this role to Alpha allows it to transfer rewards to itself for processing. Best Practices:

      • Use a dedicated rewards management module when available to streamline operations.

  7. Whitelist / Open Vault: By default, each new vault in the IPOR Fusion system is initialized with a whitelist, restricting minting and redeeming of shares to whitelisted addresses only. Atomists can add addresses to the whitelist or disable it entirely, making the vault open to all users. Once the whitelist is disabled, it cannot be re-enabled. Best Practices:

    • Retain the whitelist during the testing period, even if you plan to open the vault to all users.

    • Use a secure multisig wallet for Atomists managing the whitelist to enhance security.

Strategy

Strategy Configuration: Defining the vault’s strategy is the primary responsibility of Atomists and Fuse Managers. The following instructions provide a step-by-step guide to configuring the most critical aspects of the strategy settings.

1. Balance Fuses

  • ERC20 Balance Fuse: Tracks ERC20 token balances held directly by the vault. Include this fuse in most vaults to monitor ERC20 assets.

  • Standard Balance Fuses: Market-specific fuses, including:

    • ERC4626 Balance Fuses: Configurable in two ways:

      • Separate ERC4626 per Market: Tracks each market’s balance individually for easier monitoring.

      • Single ERC4626 for All Markets: Simplifies integration and reduces gas costs but tracks balances as a single sum. Best Practices:

  • Always pair Functional Fuses with a corresponding Balance Fuse or ZeroBalanceFuse.

  • Use separate ERC4626 fuses for complex strategies requiring granular balance tracking.

2. Functional Fuses

Each market integration requires at least one Balance Fuse and typically one or more Functional Fuses. Some markets support multiple Functional Fuses for additional functionality (e.g., Morpho supports Deposit, Borrow, and Flash Loan fuses, plus an ERC4626 fuse for MetaMorpho deposits). Non-standard fuses include:

  • Universal Swapper Fuse: A flexible interface for complex transactions (e.g., aggregators, staking, DEX interactions). It validates:

    • Whitelisted assets (only substrate-defined assets).

    • Whitelisted markets (e.g., DEXes, aggregator proxy contracts, staking contracts).

    • Beneficiaries (default: the vault).

    • Allowed method signatures.

  • ERC4626 Fuse: Enables deposits to any ERC4626 vault, including IPOR vaults.

  • Custom Fuses: Built for unique scenarios (e.g., airdrops). Non-whitelisted custom fuses trigger alerts in the IPOR Fusion interface.

  • Rewards Fuses: Used by the rewards manager to harvest token incentives. Best Practices:

  • Whitelist all assets and markets for Universal Swapper transactions to ensure safety.

  • Add custom fuses to the whitelist to avoid user alerts.

3. Fuse Configuration

  • Substrates: Configure substrates (e.g., asset or market addresses) based on fuse requirements. Consult individual fuse documentation if managing substrates manually (outside the IPOR Fusion interface). Common substrates include asset addresses (e.g., for DEXes, Universal Swapper) or market addresses (e.g., for Morpho, ERC4626).

  • Price Feeds: All Balance Fuses, except ZeroBalanceFuse, rely on the Price Oracle and its feeds. Ensure matching price feeds are configured (see "Price Oracle" section below). Price feeds can be set via the IPOR Fusion interface.

  • Dependency Graph: Fusion caches asset balances for gas efficiency, updated when Alpha adjusts allocations or balances are manually refreshed. For some markets (e.g., DEXes), update related balances (e.g., ERC20 after a swap). Configure the dependency graph by selecting a market and defining additional balances to update. Best Practices:

  • Verify substrate compatibility with each fuse to avoid misconfiguration.

  • Configure the dependency graph for markets requiring multi-balance updates (e.g., DEX swaps).

4. Pre-Hooks

5. Scheduled Withdrawals

Fusion vaults support two withdrawal types: Scheduled and Instant (both can be used in the same time). To disable scheduled withdrawals, set the withdrawal window to 0. Otherwise, define the withdrawal window (in seconds) before requests expire. Alpha should prepare assets well before expiration to allow LPs time to claim. Best Practices:

  • Set a withdrawal window that balances LP convenience and vault stability.

  • Ensure Alpha prepares assets early to avoid expiration issues.

6. Instant Withdrawal OrderUnallocated assets and specific fuses configured for instant withdrawals are available immediately. Define the order of markets for instant withdrawals via the IPOR Fusion interface. Important: Avoid including markets where withdrawals could cause liquidations (e.g., if assets are used as collateral for borrowing). Best Practices:

  • Exclude collateralized markets from instant withdrawals to prevent liquidations.

  • Use timelocks for changes to instant withdrawal configurations.

7. Fees

By default, each vault charges a fixed management fee (0.3% annually) and performance fee (2% on profits). Atomists can define additional fees by specifying addresses and rates, ensuring total fees do not exceed 5% (management) or 50% (performance). Fees are displayed in the vault overview for LPs. Best Practices:

  • Use a multisig wallet for fee management to enhance security.

  • Clearly communicate fee structures to LPs to maintain transparency.

8. Price Oracle

Vaults include a standard Price Oracle middleware provided by Fusion, with verified price feeds from reputable sources (e.g., Chainlink). Additional price feeds or custom middleware can be added as needed. Best Practices:

  • Ensure price feeds match the assets and markets used by Balance Fuses.

  • Use verified price feeds to maintain reliability and security.

Setting Up Fuses: Configuring fuses is the most critical process in defining the vault’s strategy and must be executed carefully. A list of available fuses for supported blockchains is available in the whitelist contract or the IPOR Labs repository . Below is a step-by-step guide to configuring the key aspects of fuse settings.

Fuses are paired as "Balance Fuses" and "Functional Fuses." Balance Fuses track the vault’s asset balances after transactions, while Functional Fuses perform actions. Each fuse is identified by a unique marketId, assigned during deployment. All Functional Fuses must be paired with a Balance Fuse. If a Balance Fuse reads no balance, use the ZeroBalanceFuse .

Refer to the dedicated pre-hooks documentation for configuration details.

(https://github.com/IPOR-Labs/ipor-fusion)
(https://github.com/IPOR-Labs/ipor-fusion/blob/main/contracts/fuses/ZeroBalanceFuse.sol)
see a dedicated page on pre-hooks
https://github.com/IPOR-Labs/ipor-fusion/blob/main/contracts/libraries/Roles.sol