# Smart Contract Architecture

### Smart Contract Topography

<div data-full-width="true"><figure><img src="https://1075741769-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6yeOl0TElnVRI1K1E8Bo%2Fuploads%2FyARw0nljHgNlNnMSUFSc%2FNashpoint%20-%20Architecture%20v0.1.1.jpg?alt=media&#x26;token=42a70a36-5f20-466b-a040-8ff37f2e529f" 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.