# 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, and rebalancers
* Set protocol-level fees (management, execution)
* Set protocol fee recipient address
* Whitelist/unwhitelist components for routers
* Add/remove registry roles (FACTORY, ROUTER, REBALANCER, NODE)
* 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 policies
* 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**

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

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

2. **Node Contract**

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

Maintains Node-specific permissions for rebalancers and routers.

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

```solidity
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