Role-Based Access Control

Overview

The protocol implements a robust role-based access control system with several key roles that have distinct permissions and responsibilities. The main roles are:

1. Registry Owner - The highest level administrator who controls the protocol-wide settings and whitelisting

2. Node Owner - An administrator for a specific Node instance who controls its configuration and strategy

3. Rebalancer - An authorized entity that can execute rebalancing operations on a Node

4. Router - A whitelisted contract that handles specific asset type interactions

Role Permissions

Registry Owner

The Registry Owner has protocol-wide administrative control and can:

• Initialize the protocol with initial factories, routers, quoters, and rebalancers

• Set protocol-level fees (management, execution)

• Set protocol fee recipient address

• Set maximum swing factor for the protocol

• Whitelist/unwhitelist components for routers

• Add/remove registry roles (FACTORY, ROUTER, QUOTER, REBALANCER)

• Set router tolerance values

Node Owner

Each Node instance has an owner who can:

• Initialize the Node with initial settings

• Add/remove components to the investment strategy

• Update component allocations and parameters

• Set the target reserve ratio

• Add/remove routers

• Add/remove rebalancers

• Configure swing pricing settings

• Set node-specific fees and parameters

• Update rebalance cooldown and window periods

• Set maximum deposit size

• Rescue mistakenly sent tokens (except asset and components)

Rebalancer

Rebalancers are authorized to execute investment operations and can:

• Start rebalancing periods

• Execute component investments

• Process redemption requests

• Pay management fees

• Update total assets calculations

• Fulfill redemption requests from reserve

• Execute component liquidations

Router

Routers are specialized contracts that handle specific protocol integrations can:

• Execute transactions on behalf of the Node during rebalancing

• Calculate component asset values

• Process deposits and withdrawals for specific asset types

• Handle component-specific operations

Router functions that execute protocol interactions on behalf of a Node can only be called when the following criteria is met:

• Must be called by a rebalancer address that is whitelisted on the Node

• Must be targeting a valid Component address for the Node

• Must be a targeting a valid address whitelisted on the Router itself

• Must be executed on a valid Router that has been whitelisted by the protocol

• Must be executed on a valid Router that has been whitelisted by the Node Owner

If any of these criteria are not met the transaction will fail.

Access Control Implementation

The protocol implements these controls through several mechanisms:

1. Registry Contract

mapping(address => mapping(RegistryType => bool)) public roles;

Maintains protocol-wide role assignments for factories, routers, quoters, and rebalancers.

1. Node Contract

mapping(address => bool) public isRebalancer;
mapping(address => bool) public isRouter;

Maintains Node-specific permissions for rebalancers and routers.

1. Modifiers The protocol uses various modifiers to enforce access control:

modifier onlyRouter()
modifier onlyRebalancer()
modifier onlyOwnerOrRebalancer()
modifier onlyWhenRebalancing()
modifier onlyWhenNotRebalancing()

Security Considerations

1. Role Separation: Clear separation of duties between roles prevents any single role from having too much control

2. Time-based Controls: Rebalancing operations are restricted to specific time windows

3. Component Whitelisting: Components must be whitelisted before they can be used

4. Fee Limits: Protocol-wide limits on fees prevent excessive fee settings

5. Ownership Controls: Critical functions are restricted to appropriate ownership levels

Would you like me to expand on any particular aspect of the RBAC system?