Smart Contract Architecture

Smart Contract Topography

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.