How Stratium Works

TL;DR: Stratium detects target wallet trades on Solana in under 200ms via persistent WebSocket connections, analyzes your scaled position size and risk limits, then executes through Jupiter's DEX aggregator and Jito's block engine — delivering on-chain confirmation in under 1 second. Each phase runs as an isolated microservice with automatic reconnection and retry logic.

#How is Stratium built?

Stratium is a set of specialized microservices that work together to deliver sub-second copy trading on Solana. Each service has a single responsibility — detection, execution, key management, analytics — and communicates via Redis message queues. This isolation means a failure in one component does not cascade to others.

The three core phases — Detection, Analysis, and Execution — run sequentially for each trade signal, with the entire pipeline completing in under 1 second from target wallet transaction to your on-chain confirmation.

#How does Stratium detect and copy trades?

Every copy trade passes through three phases:

#Phase 1: Detection

Stratium maintains persistent WebSocket connections to Solana RPC nodes, monitoring the on-chain activity of curated target wallets in real time. Rather than polling via REST calls (which would add hundreds of milliseconds of latency), the WebSocket connection pushes transaction notifications the moment they appear on the network.

When a target wallet submits a transaction that involves a token swap — a buy or sell — Stratium's transaction parser identifies:

• The token being traded (input and output mint addresses)
• The direction (buy or sell)
• The amount in SOL terms
• The DEX used (Jupiter, Raydium, Orca, Pump.fun, etc.)

This detection happens in under 200 milliseconds from the time the transaction hits the network.

#Phase 2: Analysis and sizing

Before executing, the copy trading engine runs a sequence of checks for each user assigned to that target wallet:

• Balance check — Does the user have enough SOL to execute this trade?
• Scaling calculation — The trade amount is scaled based on the user's assigned scaling factor (e.g., 0.1× means a 10 SOL trade becomes a 1 SOL trade)
• Position cap — Does this trade exceed the user's maximum percentage cap (default: 25% of portfolio)?
• Minimum reserve — Will the user retain at least 0.01 SOL for future fees after this trade?
• Duplicate detection — Has this exact target transaction already been copied (7-day Redis dedup window)?

If all checks pass, the trade moves to execution. If any check fails, the trade is logged but skipped — it is never silently dropped.

#Phase 3: Execution

Stratium uses a two-pronged approach for optimal execution:

1. Jupiter API — Routes the swap through the best available liquidity pools across 20+ Solana DEXes. Jupiter's routing engine finds the optimal multi-hop path to minimize slippage and maximize output tokens. This is the same aggregator used by the majority of Solana DeFi protocols.

2. Jito Bundles — Submits the transaction via Jito's block engine with a priority tip. This ensures the transaction lands in the next block with high reliability, even during network congestion — critical for keeping your copy close to the target's execution price.

The result: trades execute in under 1 second from detection to on-chain confirmation.

#What are Stratium's key technical components?

#WebSocket Manager

Maintains shared WebSocket connections to Solana nodes. Multiple users watching the same target wallet share a single connection — the system does not open one connection per user, which would be both expensive and rate-limited. This shared model scales to thousands of users monitoring the same wallets with no degradation in detection speed.

#Copy Trading Engine

The execution core. Receives trade signals from the message queue, applies per-user scaling and risk rules in parallel for all affected users, and submits transactions. Processes up to 50 concurrent trades for different users when a single target wallet executes a swap.

#Wallet Manager

Handles wallet creation, AES-256-GCM encryption (NIST FIPS 197), and transaction signing. Private keys are encrypted at rest and only decrypted momentarily in memory during transaction signing — they are never written to disk, never logged, and never transmitted outside the wallet manager service.

#PnL Analytics

Tracks every trade's outcome using FIFO (first-in, first-out) accounting: entry price, exit price, realized P&L, unrealized P&L. Provides the data for portfolio analytics and strategy performance metrics visible in the dashboard and Telegram bot.

#What is the step-by-step trade execution flow?

Here is the complete sequence when a target wallet makes a trade:

1. WebSocket receives the target wallet's transaction notification from the Solana RPC node
2. Transaction parser identifies it as a token swap and extracts input token, output token, amounts, and DEX
3. Redis message queue distributes the trade signal to the copy trading engine workers
4. Engine queries all users assigned to this target wallet from the database
5. For each user (in parallel), the engine:
   • Calculates the scaled trade amount based on the user's scaling factor
   • Checks balance, position cap, minimum reserve, and duplicate detection
   • Builds the swap transaction via Jupiter (fetches quote → builds swap instruction)
   • Signs the transaction using the user's encrypted key (momentary decryption)
   • Submits via Jito bundle with priority tip
6. On-chain confirmation is received and the trade is recorded in the database
7. User is notified via Telegram with trade details, execution delay, and a Solscan link

#Which DEXes does Stratium route through?

Stratium routes through Jupiter, which aggregates liquidity from 20+ Solana DEXes:

DEX	Type
Raydium AMM + CLMM	Automated market maker + concentrated liquidity
Orca Whirlpools	Concentrated liquidity
Meteora	Dynamic AMM with multi-token pools
Phoenix	On-chain order book
Lifinity	Oracle-based proactive AMM
Pump.fun	Meme token launchpad AMM
OpenBook	Legacy Serum order book fork
And 13+ more	Aggregated by Jupiter

This means Stratium can trade any token that has liquidity on any major Solana DEX — no fixed token whitelist.

#How does Stratium handle failures and downtime?

• Automatic reconnection — WebSocket connections reconnect immediately on failure with exponential backoff
• Retry logic — Failed transactions are retried up to 3 times with adjusted parameters (slippage, priority fee)
• Health monitoring — All services are continuously monitored with automated alerts
• Trade logging — Every trade attempt (successful or failed) is logged with error category for transparency
• Redis deduplication — The 7-day dedup window prevents a retry from executing a trade twice even across service restarts

#Learn more

• Trading Strategies — How target wallets are selected and organized into strategies
• Security — How your private keys and funds are protected
• Risk Management — How position sizing, caps, and slippage protection work