System architecture across frontend, API, database, and external services.
Solenvus uses a monorepo architecture with a React frontend, an Express API server, and a PostgreSQL database.
The platform is designed to keep discovery, execution, comparison, and integration inside one connected system.
Architecture at a glance
Experience layer
React + Vite frontend
Public discovery pages
Authenticated execution flows
Skill browsing, testing, and comparison
Platform layer
Express API server
Standardized execution handling
Activity and health endpoints
Structured JSON responses
High-level flow
Platform flow
User interface
-> skill discovery and selection
-> authenticated execution or comparison
-> standardized API response
-> platform logging and activity updates
-> live status, score, and result visibility
Request lifecycle
1
Discover
Users start by browsing skills, protocols, agents, and ranked views.
2
Select
The selected skill, mode, and action determine the next product flow.
3
Execute or compare
The platform routes the request through the relevant API and protocol path.
4
Return structured output
The result comes back as a consistent response with execution context, logs, and related metadata where available.
Frontend layer
The frontend is built with React and Vite.
It provides the public product pages and authenticated execution flows.
Key user-facing areas include:
Home
Skills
Playground
Arena
Leaderboard
Integrations
Protocol Status
API layer
The API server is built with Express.
It exposes REST endpoints for discovery, execution, comparisons, activity, health, and pricing.
Core services include:
Execution engine
Protocol runners
Activity engine
Real-time data ingestion
Data layer
The data layer uses Drizzle ORM over PostgreSQL.
The schema stores platform entities and operational records.
Core tables include:
skills
agents
protocols
battle_results
execution_logs
activity_events
saved_skills
supporting taxonomy tables
Data and protocol connectivity
Solenvus connects supported skill flows to live protocol and network data where relevant.
Common examples include:
network health context
price-related context
swap and routing-related context
activity visibility for supported flows
These integrations are surfaced through the documented platform features rather than as separate user setup steps.
Why this architecture works
For users
Cleaner discovery flow
Safer testing modes
More consistent outputs
Easier comparison across skills
For integrations
Standardized API structure
Reusable skill model
Better ranking and evaluation signals
Clearer path from testing to implementation
Design intent
The platform separates UI, execution logic, persistence, and data ingestion.
That keeps protocol integrations modular and makes new adapters easier to add.
