NODO AI Agent Architecture

1. Contract Roles & Functions

Vault Contract

Manages user deposits and withdrawals of USDC. Issues and burns NDLP tokens based on the conversion rate. It calculates and tracks Total Credited USDC, performance fees, and pending withdrawals, handles cooldown logic, and interacts with the Execution Agent to ensure liquidity is available for claims, and exposes APIs for profit realization (realizeProfit) and crediting (creditProfit).

Strategy Manager Contract

Stores and configures the strategy parameters (e.g., ΔP_range, δ_trigger). Interfaces with AI agents to receive updated strategy configurations. Maintains state of active strategies and their performance metrics, and may support multiple strategies/vaults (multi-strategy compatibility planned).

Token (NDLP) Contract

ERC-20-like token standard on Sui, representing a claim on the vault’s USDC. Fully transferable (unless restricted), non-interest-bearing directly, but appreciates in value via vault logic. Minted on deposit, burned on withdrawal. Conversion rate determined by the vault’s total credited USDC ÷ NDLP supply.

Execution Handler Contract

Orchestrates all liquidity provisioning and rebalancing actions. Executes addLiquidity, removeLiquidity, and swap operations on integrated DEXs (e.g., Cetus). Ensures slippage thresholds, gas efficiency, and strategy alignment. May include time locks or batch operation support in future versions.

2. Deployment Addresses

Mainnet / Testnet Contract Addresses

🚧 Placeholder – Will populate after final deployments.

• Vault Contract: TBD (Testnet), TBD (Mainnet)

• NDLP Token Contract: TBD

• Execution Handler: TBD

• Strategy Manager: TBD

Network-Specific Differences

Current deployment focuses on Sui. Contracts use the Sui Move smart contract standard. Vault and token logic are adapted to Sui’s object-based design and permission model. Future integration with non-Sui EVM chains (e.g., Base, Arbitrum) may require different token standards and liquidity routing logic. Cross-chain compatibility and liquidity bridging are not currently enabled but may be on the roadmap.

3. Upgradeability Pattern

Proxy Implementation

• 🚧 Placeholder – Confirm if proxy pattern is used (e.g., for upgradable vault logic).

• If used, Contracts are deployed with a proxy-controller mechanism enabling upgrades to implementation logic while preserving state and address.

Governance Control

Upgrade permissions are gated by a multi-sig or DAO-controlled governance module. Governance may be granted via $NODO token voting in the future. Current upgrade rights likely reside with the core protocol team for the MVP phase. Each upgrade must be reviewed, audited, and announced before deployment.