# 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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://nashpoint.gitbook.io/nashpoint/developer-documentation/role-based-access-control.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.