# Smart Contract Architecture

### Smart Contract Topography

<div data-full-width="true"><figure><img src="/files/hDUv0sRgLZaum68z0GMq" alt=""><figcaption></figcaption></figure></div>

### Core Contracts

#### NodeRegistry

The central registry and governance contract for the protocol. It:

* Maintains whitelist of protocol participants (factories, routers, nodes, rebalancers, policies)
* Store a list of valid Nodes
* Stores protocol-wide parameters and fee settings
* Controls deployment permissions through role-based access
* Acts as the source of truth for valid protocol components

#### NodeFactory

A factory pattern contract that standardizes and controls Node deployment. It:

* Creates new Node instances with standardized initialization
* Deploys associated Escrow contracts
* Registers new Nodes with the NodeRegistry
* Ensures proper initialization of Node parameters and permissions

#### Escrow

A simple but critical security contract that:

* Holds assets during the withdrawal process
* Provides secure asset custody during async operations
* Grants specific permissions to its associated Node
* Prevents direct manipulation of held assets

### Extensible Contract Classes

#### Nodes

Nodes are the core investment vehicle contracts that can be implemented for different investment strategies and mechanics.

**Current Implementation - Node.sol:**

* Manages reserve ratios and component allocations
* Handles deposits and redemptions
* Coordinates with Routers for component interactions
* Processes management and execution fees
* Controls rebalancing windows and cooldowns

Future Node implementations could support:

* Various investment strategies
* Alternative asset management approaches
* Specialized financial instruments

#### Routers

Routers are specialized contracts that handle interactions with specific asset types or protocols. They abstract away the complexity of different asset interfaces.

**Current Implementations:**

1. **ERC4626Router**
   * Handles standard yield-bearing vault interactions
   * Manages deposits and withdrawals
   * Tracks component assets
2. **ERC7540Router**
   * Manages async vault interactions
   * Handles request/claim patterns
   * Coordinates multi-step operations

Future Router implementations could support:

* DEX integrations
* Lending protocol interactions
* Complex derivative positions
* Cross-chain assets
* Other specialized protocols

#### **Policies**

Each Policy can be enabled or disabled on a per-function-selector basis for any Node. The current set of Policies includes:

* **CapPolicy** — enforces deposit caps on a Node.
* **GatePolicyBlacklist** — blocks interactions with the Node (including share transfers) for blacklisted addresses.
* **GatePolicyWhitelist** — permits interactions only for explicitly whitelisted addresses.
* **NodePausingPolicy** — allows Node Owners to pause or unpause their own Node.
* **ProtocolPausingPolicy** — enables protocol-wide pausing, controlled by NashPoint.

The system is designed to be fully extensible, and additional Policies will be introduced over time.

### Libraries

#### **RegistryAccessControl**

Basic contract that enforces access-control rules defined in the NodeRegistry, providing modifiers such as `onlyNodeRebalancer`, `onlyNode`, `onlyRegistryOwner`, and `onlyNodeComponent`.

#### BaseComponentRouter

A foundational library that:

* Provides common Router functionality
* Implements standard security checks
* Manages component whitelisting
* Handles fee calculations

#### Other Libraries

* **ErrorsLib**: Standardized error handling
* **EventsLib**: Standardized event emissions
* **MathLib**: Safe mathematical operations

### Protocol Extensibility

The protocol is designed for extensibility through:

1. **Modular Architecture**: Clear separation of concerns between contracts
2. **Abstract Base Contracts**: Common functionality in base contracts
3. **Standardized Interfaces**: Clear interface definitions for new implementations
4. **Registry Pattern**: Centralized control and validation

This architecture allows for:

* New asset type support through additional Routers
* Different investment strategies through new Node implementations
* Flexible compliance enabled through customizable Policy contracts
* Protocol evolution without core contract modifications

The current implementation focuses on MMF-style functionality, but the architecture supports expansion into various other financial instruments and strategies while maintaining security and standardization.


---

# 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/smart-contracts.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.