Access Management

Overview

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: https://github.com/IPOR-Labs/ipor-fusion/blob/main/contracts/libraries/Roles.sol)

Admin Role

An account with this role has the rights to manage the IporFusionAccessManager in general. The highest role, which could manage all roles including ADMIN_ROLE and OWNER_ROLE. This is a technical role used during bootstraping and should not be used when operating a vault.

Owner Role

The highest administrative role, defined during the vault's bootstrapping process and immutable thereafter. The account with this role has rights to manage Owners, Guardians, Atomists.

• Immutable

• Set at creation

• Single user (recommended use of multisig for this role)

Best practices

Use a highly secure multisig wallet for management.

Atomist Role

This role serves as the primary managing accounts for the vault, overseeing most day-to-day settings, such as configuring Fuse Managers, Alphas, fees, and other parameters.

• Configurable by the Owner

• Allows multiple users

Best practices

• Use multiple Atomists to ensure redundancy.

• Apply timelocks to selected Atomist actions whenever feasible.

Alpha

The account with this role has rights to execute the strategy on the vault using execute method, typically as an automated strategy manager.

• Configurable by the Atomist

• Allows multiple users

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.

Guardian Role

This role has the authority to reject time-locked actions and to pause or unpause the vault in case of emergency.

• Configurable by the Owner

• Allows for multiple users

Best Practices

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

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

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

Fuse Manager Role

The account with this role has rights to manage the FuseManager contract, add or remove fuses, balance fuses and reward fuses.

• Configurable by the Atomist

• Allows for multiple users

Best Practices

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

Claim Rewards Role

Account with this role has rights to claim rewards from the PlasmaVault using and interacting with the RewardsClaimManager contract.If PlasmaVault has a dedicated smart contract to handle the harvested rewards, the role should be granted to that contract.

• Configurable by the Atomist

• Allows for multiple users

Transfer Rewards Role

An account with this role has rights to transfer rewards from the PlasmaVault to the RewardsClaimManager.If PlasmaVault has a dedicated smart contract to handle the harvested rewards, the role could be granted to that contract.

• Configurable by the Atomist

• Allows for multiple users

Rewards Claim Manager Role

Technical role for the RewardsClaimManager contract. Account with this role has rights to claim rewards from the PlasmaVault. For practical reasons, it can be granted to the same entity holding either an Alpha or Atomist role.Configurable by the AtomistAllows for multiple usersPerformance Fee Manager RoleThe account with this role has rights to manage the performance fee, define the performance fee rate, and manage the performance fee recipient.Self managedAllows for multiple usersManagement Fee Manager RoleThe account with this role has rights to manage the management fee, define the management fee rate, and manage the management fee recipient.Self-managedAllows for multiple usersWhitelist RoleThe account with this role has rights to deposit/mint and withdraw/redeem assets from the Plasma Vault.Configurable by the AtomistAllows for multiple usersConfig Instant Withdrawal Fuses RoleAn account with this role has rights to configure instant withdrawal fuses order.

PreHooksManager Role

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.

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.