# Custom Router Development

### Extensible Architecture

The Node contract's `execute()` function allows whitelisted routers to perform arbitrary external contract interactions. This enables routers to integrate complex DeFi protocols while maintaining the Node's security model. See Node Execute Function for more details.

See [Node Execute Function](/nashpoint/node-execute-function.md) for more details.

#### Custom Routers

Custom routers enable integration of new vault types or DeFi protocols into the Node system. All routers must inherit from BaseComponentRouter to ensure proper security checks and Node compatibility.

#### Why Create a Custom Router

* Integrate new vault standards (beyond ERC4626/ERC7540)
* Add support for specific DeFi protocols
* Implement custom deposit/withdrawal logic
* Handle protocol-specific interactions

#### Required Implementation

Custom routers must inherit from BaseComponentRouter and implement two key functions:

```solidity
contract CustomRouter is BaseComponentRouter {
    constructor(address registry_) BaseComponentRouter(registry_) {}

    function getComponentAssets(address component) 
        public view override returns (uint256) {}

    function getInvestmentSize(address node, address component) 
        public view override returns (uint256) {}
}
```

**getComponentAssets**

Returns the current value of assets held in a component, used by the Node to calculate total assets and ratios. Must return value denominated in the Node's asset decimals.

**getInvestmentSize**

Calculates the amount that should be invested in a component based on the Node's target allocation and current holdings. Must account for protocol-specific constraints.

#### Custom Router Security Requirements

**Required Modifiers**

All functions that interact with Node assets must use:

```solidity
function someOperation(address node, address component) 
    external
    nonReentrant                  // Prevent reentrancy
    onlyNodeRebalancer(node)      // Only rebalancer can call
    onlyNodeComponent(node, component)  // Must be valid component
{
    // Implementation
}
```

**Security Rules**

1. State-changing functions:
   * Only callable by valid Rebalancer
   * Must verify component validity
   * Include reentrancy protection
2. Execute calls must:
   * Validate return values
   * Track balances before/after
   * Revert on unexpected results
   * Account for protocol fees

See ERC4626Router and ERC7540Router for implementation examples.

#### BaseComponentRouter Security Features

The `BaseComponentRouter` contract provides essential security and integration features:

* Protocol and component whitelisting enforcement
* Node and rebalancer authorization checks
* Protocol fee collection and distribution
* Execution guards for privileged operations
* Standardized interfaces for Node interaction

#### Governance Process

New routers undergo a strict approval process:

1. Router code must pass due diligence review and security audits
2. Protocol owner whitelists approved router:

```solidity
registry.setRegistryType(routerAddress, RegistryType.ROUTER, true);
```

3. Registry owner can then whitelist specific components:

```solidity
router.setWhitelistStatus(componentAddress, true);
```

4. Once approved, the router becomes available to all Node owners

#### Important Considerations

* Router security is critical as they have significant privileges within Nodes
* Router implementations should optimize for gas efficiency
* Components must be individually whitelisted even on approved routers
* All Nodes can access any whitelisted router
* Consider composability with existing DeFi protocols


---

# 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/upgrading-a-node/custom-router-development.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.