System Overview
NMT is a three-layer platform. Each layer has a clear responsibility and communicates with the others through well-defined boundaries.
The Three Layers
+---------------------------+
| USER (Browser) |
| Signs txs via wallet SDK |
+-------------+-------------+
|
+-------------v-------------+
| FRONTEND (Next.js 16) |
| UI, tx building, Prisma |
+------+------------+-------+
| |
Reads DB | | Submits transactions
via Prisma | | via Safe SDK / Gelato
| |
+------------v--+ +-----v---------------------+
| PostgreSQL | | BLOCKCHAIN (EVM Chains) |
| 45+ tables | | Gnosis Safe + Modules |
+------------^--+ +-----+---------------------+
| |
| | Events / Logs
+------------+------------v---------------------+
| BACKEND ENGINE (Rust) |
| Workers: indexing, valuations, prices |
| API: REST + Swagger |
+-----------------------------------------------+
Layer 1: Smart Wallets (On-Chain)
The foundation. Solidity contracts deployed on Base, Ethereum, Arbitrum, and Optimism. They provide:
- Gnosis Safe — a proven multi-signature wallet used as the execution environment
- PermissionsManager — controls who can do what on each wallet
- Protocol Modules — one module per DeFi protocol (Uniswap, Aave, etc.)
- DelegateBundler — bundles multiple operations into a single atomic transaction
This layer lives entirely on-chain. It doesn't depend on NMT servers.
Layer 2: Backend Engine (Off-Chain, Rust)
The data brain. A Rust application that:
- Indexes on-chain events (position opens, closes, swaps) into PostgreSQL
- Computes position valuations in USD at regular intervals
- Fetches pool data, APYs, and prices from DeFi protocols and oracles
- Serves a REST API for the frontend to consume
The backend never holds private keys or executes transactions. It is read-only with respect to the blockchain.
Layer 3: Frontend App (Off-Chain, Next.js)
The user interface. A Next.js web application that:
- Authenticates users via wallet connection (Dynamic Labs)
- Displays portfolio positions, P&L, analytics
- Builds transactions for the user to sign
- Reads data from both PostgreSQL (via Prisma) and the backend API
How They Connect
| Connection | Method | Direction |
|---|---|---|
| User to Frontend | HTTPS (browser) | Bidirectional |
| Frontend to Database | Prisma ORM (server components) | Read-heavy |
| Frontend to Blockchain | Viem/Ethers (via RPC) | Read + Write (signed txs) |
| Backend to Database | SeaORM | Read + Write |
| Backend to Blockchain | Alloy (via RPC) | Read-only (event indexing) |
| Backend to External APIs | HTTP/GraphQL | Read-only |
| Frontend to Backend API | HTTP REST | Read-only |
Key Design Decisions
Why two ORMs? The backend uses SeaORM (Rust) and the frontend uses Prisma (TypeScript). They share the same PostgreSQL database. This avoids the frontend needing to proxy every read through the backend API — server components can query the DB directly for fast page loads.
Why Rust for the backend? DeFi indexing requires processing large volumes of blockchain events with high concurrency. Rust's async runtime (Tokio) handles thousands of concurrent connections efficiently with low memory usage.
Why Gnosis Safe? Safe is the most battle-tested smart wallet in DeFi, securing over $100B in assets. Building on Safe means NMT inherits years of security audits and a large ecosystem of tooling.