CRX Network Backend Architecture

Infrastructure, service topology, data flows, and deployment model for COREX Exchange

Platform: CRX Network (bggex.com)
Last Updated: April 2026
Version: 2.0

System Overview

flowchart TB subgraph Frontend["Frontend Layer"] UI[React SPA
crx-landing] Admin[Admin Dashboard
React 17] Mobile[Mobile App
React Native] end subgraph Gateway["API Gateway"] Traefik[Traefik
SSL/Routing] end subgraph Core["Core Trading (OpenDAX)"] Peatio[Peatio
Trading Engine] Barong[Barong
Identity/Auth] Ranger[Ranger
WebSocket] end subgraph ShareAPI["Share-API Microservices"] Wallet[Wallet Service] Earn[Earn Service] Staking[Staking Service] Referral[Referral Service] Email[Email Service] More[+ 11 more services] end subgraph RustBackend["Rust Backend"] HttpServer[HTTP Server
Axum :8080] EvmScanner[EVM Scanner] EvmStream[EVM Stream] SolScanner[Solana Scanner] SolStream[Solana Stream] end subgraph Data["Data Layer"] MySQL[(MySQL
30+ DBs)] Redis[(Redis
Cache)] MongoDB[(MongoDB
Time-series)] Postgres[(PostgreSQL
Rust Backend)] end subgraph Blockchain["Blockchain Networks"] Ethereum[Ethereum
Uniswap V2/V3] BSC[BSC
Uniswap Pools] Solana[Solana
Pump.fun] end Frontend --> Gateway Gateway --> Core Gateway --> ShareAPI Gateway --> RustBackend Core --> Data ShareAPI --> Data RustBackend --> Postgres RustBackend --> Blockchain

Share-API Microservices (Node.js/NestJS)

Service Groups

Financial

  • wallet-main - Wallet operations
  • earn-main - Yield products (port 5112)
  • staking-main - Locked staking (port 5113)
  • profit-main - Investor tracking (port 4000)
  • withdrawLimit-main - Limit validation

Engagement

  • referral-main - Referral system
  • competition-main - Trading competitions
  • announcement-main - System announcements
  • popup-main - Popup notifications
  • postNews-main - News posting
  • email-main - Email campaigns

Data & Security

  • data-main - Data aggregation
  • security-main - IP scanning, activity analysis
  • coinList-main - Coin listings
  • markettime-main - Market schedules

Background Jobs

  • cronjob-share-main - 14 sub-services
  • bots-liquid, ieo, hold-reward
  • stake, competition, referral
  • trades, gift, profit, pre-sale
  • email-notification, lucky-spin
  • eth_withdraw, withdraw-refundation

Core Platform (OpenDAX)

ComponentVersionPurposePort
Peatio2.6.48Trading engine, order matching, wallets8000
Barong2.6.44Identity, KYC, 2FA/TOTP8001
Ranger-WebSocket real-time data8080
Traefik-Reverse proxy, SSL termination80/443
Vault-Secret storage, TOTP generation-

Communication Flow

sequenceDiagram participant User participant Traefik participant Barong participant ShareAPI participant Peatio participant Redis participant MySQL User->>Traefik: HTTPS Request Traefik->>Barong: JWT Validation Barong-->>Traefik: User Context Traefik->>ShareAPI: /api/v2/* ShareAPI->>Redis: Check Cache alt Cache Hit Redis-->>ShareAPI: Cached Data else Cache Miss ShareAPI->>MySQL: Query Data MySQL-->>ShareAPI: Result ShareAPI->>Redis: Store Cache end ShareAPI->>Peatio: Trading Operations Peatio-->>ShareAPI: Result ShareAPI-->>User: JSON Response

Rust Backend (Blockchain Monitor)

Architecture Overview

Modular blockchain event monitoring system with dual support for EVM and Solana networks. Each chain has two monitoring modes: polling (scanner) and real-time WebSocket (stream).

Workspace Layout

crates/ Shared Infrastructure

  • shared - Env config, error handling, validators
  • database - SeaORM + PostgreSQL
  • http-server - Axum REST API (port 8080)
  • ws-client - TLS WebSocket client

evm/ EVM Chain Modules

  • lib - Alloy client with fallback RPC
  • scanner - Polling (2000-block windows)
  • stream - WebSocket subscription

solana/ Solana Modules

  • lib - Anchor parser (Pump.fun)
  • scanner - Cursor-based pagination
  • stream - logsSubscribe

API Endpoints

MethodEndpointDescriptionAuth
POST/auth/signing-msgRequest signing challengeNone
POST/auth/sign-in-evmVerify EVM signature → JWTNone
POST/auth/sign-in-solVerify Solana signature → JWTNone
GET/users/meGet authenticated userBearer
GET/random-u64WebSocket demo endpointNone
GET/swaggerSwagger UINone
GET/scalarScalar API docsNone

EVM Monitoring Flow

flowchart LR subgraph Scanner["EVM Scanner (polling every 6s)"] S1[Read checkpoint
from DB] S2[Fetch logs
2000 blocks] S3[Decode events
V2/V3] S4[Save checkpoint] end subgraph Stream["EVM Stream (WebSocket)"] W1[eth_subscribe] W2[Filter Uniswap
pools] W3[Decode events] W4[Ping every 30s] end subgraph Handler["Event Handler"] H1[Check log_memo
deduplication] H2[Decode with
Alloy ABI] H3[Persist to
log_memo] end S1 --> S2 --> S3 --> S4 S3 --> Handler W1 --> W2 --> W3 --> Handler W4 -.-> W1 H1 --> H2 --> H3

Supported Chains & Pools

ChainPool TypeContractPair
Ethereum (1)Uniswap V30x4e68...USDT/WETH
Ethereum (1)Uniswap V20x0d4a...USDT/WETH
BSC (56)Uniswap V30x0076...USDT/WETH
BSC (56)Uniswap V20x8a1e...USDT/WETH

Solana Monitoring Flow

flowchart LR subgraph Scanner["Solana Scanner (polling every 6s)"] SS1[Read cursor
signature] SS2[Fetch signatures
Pump.fun program] SS3[Get transactions
concurrency=30] SS4[Extract logs] SS5[Update cursor] end subgraph Stream["Solana Stream (WebSocket)"] SW1[logsSubscribe] SW2[Filter Pump.fun
mentions] SW3[Parse logs] SW4[Ping every 30s] end subgraph Handler["Event Handler"] SH1[Skip failed txs] SH2[Parse with
Anchor] SH3[Check log_memo] SH4[Save event] end SS1 --> SS2 --> SS3 --> SS4 --> SS5 SS4 --> Handler SW1 --> SW2 --> SW3 --> Handler SW4 -.-> SW1 SH1 --> SH2 --> SH3 --> SH4

Database Schema

EntityFieldsPurpose
Userwallet_address (PK)EVM/Solana address storage
SigningMessageaddress (PK), messageChallenge for signature verification
Settingkey (PK), valueScanner checkpoints, config
LogMemohash (PK), log_ix (PK), timestampProcessed events deduplication

Key Settings

  • EvmScannedBlock(chain_id) - Last block scanned per EVM chain
  • SolCurrentScannedSignature - Last Solana transaction signature processed

Data Architecture

Share-API Database Topology

flowchart TB subgraph Shared["Shared Databases (read-only)"] Barong[(barong_production
Users, Profiles, Labels)] Peatio[(peatio_production
Members, Accounts, Orders)] end subgraph Owned["Service-Owned Databases (read-write)"] Wallet[(wallet_production)] Earn[(earn_production)] Stake[(stake_production)] Referral[(referral_production)] Email[(email_production)] More2[(...20+ more)] end subgraph Services["Microservices"] WalletSvc[wallet-main] EarnSvc[earn-main] StakeSvc[staking-main] RefSvc[referral-main] end Services --> Shared WalletSvc --> Wallet EarnSvc --> Earn StakeSvc --> Stake RefSvc --> Referral

Redis Usage Patterns

PurposeKey PatternTTLService
Product cacheearn:products:*15 minearn-main
Staking productsstaking:products:*15 minstaking-main
Popup cachepopup:list:*On invalidationpopup-main
Referral statsreferral:dashboard:*15 minreferral-main
Bull job queuesbull:email-*Job lifecycleemail-main
Session datasess:*Session TTLBarong

Security Architecture

Authentication Flow

sequenceDiagram participant User participant Service participant Barong participant Vault Note over User,Vault: Share-API (JWT via Barong) User->>Service: Request with JWT Service->>Barong: Verify RS256 signature Barong-->>Service: User context (uid, email, role) Service-->>User: Authorized response Note over User,Vault: Rust Backend (Wallet Signature) User->>Service: POST /auth/signing-msg Service-->>User: Challenge message User->>Service: POST /auth/sign-in-evm + signature Service->>Service: Recover address from signature Service-->>User: JWT token

Access Levels

LevelMiddlewareDescription
PublicNoneNo auth required, cached responses
UserUserAuthMiddlewareValid JWT required
AdminAdminMiddlewareJWT + role === 'admin'
OTPOtpMiddlewareJWT + TOTP code (withdrawals)
SecretSecretMiddlewareAPI key (inter-service)

Security Layers

Network

  • Traefik SSL/TLS termination
  • CSRF protection on frontend routes
  • Helmet security headers
  • Rate limiting (@nestjs/throttler)

Data Protection

  • HashiCorp Vault for secrets
  • UID privacy (partial masking)
  • Financial precision (number-precision)
  • Idempotency keys on financial ops

Deployment Architecture

flowchart TB subgraph Docker["Docker Compose Orchestration"] subgraph OpenDAX["OpenDAX Services"] P[peatio] B[barong] R[ranger] T[traefik] V[vault] end subgraph ShareAPI["Share-API (16 services)"] SA1[wallet] SA2[staking] SA3[earn] SA4[referral] SA5[email] SAMore[...] end subgraph Cronjobs["Cronjob Services (14 containers)"] C1[bots-liquid] C2[ieo] C3[hold-reward] C4[stake] CMore[...] end subgraph Data["Data Stores"] MySQL[(MySQL)] Redis[(Redis)] MongoDB[(MongoDB)] end end subgraph RustDeploy["Rust Backend (VPS)"] HTTP[http-server
PM2 managed] EVM[evm-scanner
evm-stream] SOL[solana-scanner
solana-stream] PG[(PostgreSQL)] end subgraph CI["CI/CD"] GH[GitHub Actions] SCP[SCP to VPS] end OpenDAX --> Data ShareAPI --> Data Cronjobs --> Data RustDeploy --> PG GH --> SCP --> RustDeploy

Container Policies

PolicyValue
Restarton-failure
Loggingjson-file driver (Datadog collects)
Health checksEnabled on critical services
Volume mountsLogs (/logs), data persistence

Build Pipeline

1
Share-API: Docker multi-stage build → node:16-22-alpine → yarn install → NestJS compile
2
Rust Backend: cargo build --release → SCP to VPS → PM2 restart
3
Database: Prisma push (Rust) / TypeORM migrations (Node.js)