Flavio Espinoza

Sol Backtester | v1 — Runs the trend-flip algorithm across full historic candle data to show how the strategy would have performed before it ever trades live.

1. A.Deterministic by design -- the same candles always produce the same flips, so the backtest matches live behavior exactly, with no drift between backtest and production.
2. B.Replays historic candles through the same engine the live signal uses and produces interactive HTML reports charting every flip and the resulting performance end to end.
3. C.Independently verified -- reproduced the algorithm as a custom Pine Script strategy on TradingView and a custom Python strategy on QuantConnect, confirming the engine's flips match across all three implementations.

Sol Signal | v1 — Takes in any market's interval candles -- such as 4-hour candles -- and uses a proprietary algorithm to signal when the market trend flips long or flips short.

1. A.Built in TypeScript -- a proprietary trend-flip algorithm that ingests a market's interval candles and detects the exact moment the trend reverses, emitting a long or short flip signal.
2. B.Operates in two modes -- it runs the trend-flip algorithm across historic candle data, and in live mode it takes each new interval candle (e.g., every 4 hours) and instantly determines whether that candle caused a flip: if it did, it emits a signal; if not, it appends the candle to the historic series and waits for the next.
3. C.Market-agnostic by design -- the engine accepts any trading pair and any candle interval as input; it is not hardcoded to a single market.

Sol Dashboard | v1 — The front-end operational interface of the platform. It displays current open trades and past trades two ways: in a side menu and plotted directly on a custom-built D3.js trading chart -- a TradingView-style price chart showing the market's candles, Sol Signal's trend-flip markers, and live position tracking. Everything updates in real time and is backed by on-chain data rather than estimates. When Sol Bot is finished, the dashboard becomes its control surface: configure the bot's parameters (stop-loss, exit strategy), monitor automated trades in real time, and trigger the kill switch to exit a trade at any moment.

1. A.Built with Next.js and React in TypeScript, styled with Tailwind CSS, and deployed on Vercel.
2. B.Custom-built D3.js trading chart -- a TradingView-style price chart rendered from scratch, plotting candles, trend-flip markers, and live position overlays.
3. C.Real-time UI -- open trades, trade history, and live positions update automatically as new data arrives, keeping the side menu and the chart in sync.

Backend | v1 — The real-time data and process layer behind the platform -- a WebSocket-first backend that ingests live market and on-chain data, persists it to a database, and keeps itself alive 24/7 with no human intervention.

1. A.WebSockets -- three persistent connections run 24/7, pushing data the instant it occurs instead of polling on a timer: a live price-oracle feed, an exchange candle feed, and an on-chain transaction feed subscribed to the client's wallet, with a direct-RPC fallback to backfill anything a socket ever misses.
2. B.State management -- MongoDB is the system of record; all candle data, trade data, and signal state live in their own collections, each queryable and repairable in minutes.
3. C.PM2 -- manages seven persistent Node.js services running on Railway, with auto-restart and exponential backoff persisted across reboots. A feed watchdog polls every health endpoint every 15 seconds and fires emergency alerts that pierce Do-Not-Disturb the moment a feed goes stale; a boundary checker verifies each interval closes on schedule and auto-restarts a feed if a candle is missing.

Sol Bot | v2 — An automated trading bot that listens to Sol Signal and waits for the trend to flip. It can be programmed to enter a trade when the trend flips long or when it flips short. It includes programmatic controls such as stop-loss percentage and exit strategy, plus a kill switch that lets the client exit a trade at any time from the Sol Engine dashboard. Currently in development.

1. A.Designed in TypeScript as an event-driven service that subscribes to Sol Signal's flip stream and dispatches a trade through the execution layer the moment a flip fires.
2. B.Designed around a position state machine -- idle, entering, open, exiting, closed -- so every transition is explicit, recoverable on restart, and fully auditable.
3. C.Internal trade methods -- the bot exposes its own methods to open a trade, close a trade, and receive instructions, so both the Signal Emitter and the dashboard can drive it through one clean interface.
4. D.Signs its own trades -- designed to trade from dedicated, backend-provisioned wallets and sign every entry and exit itself, so it runs 24/7 with no human approving each transaction. The client never has to sign a flip by hand, even from a hardware wallet that would normally require manual authorization on every trade.
5. E.Custody stays with the client -- the client funds the bot from a single Master wallet that only they can sign for, and each trading wallet is whitelisted to send funds only back to that Master. The whitelist is locked in the backend and cannot be bypassed, so even a fully compromised backend can never move money anywhere but home.

Signal Emitter | v2 — The thin layer that carries a trend flip from Sol Signal to Sol Bot without welding the two together. Sol Signal reports that the trend flipped; the Signal Emitter wraps that flip in context -- which market, what price, which candle -- and publishes it on an in-process signal bus that Sol Bot subscribes to. Neither side imports the other, so the trend engine stays a pure brain and the bot stays a pure listener. Currently in development.

1. A.Sol Signal never knows a trade bot exists -- it returns a flip and nothing more. The emitter is the only piece that decides what to do with that flip, which keeps the same trend engine reusable in both the historical backtester and the live system with zero trade logic baked in.
2. B.Local-first ordering -- when a closed 4h candle flips the trend, the row is written to a local CSV first for durability, the signal is published second so the bot reacts at local speed without waiting on the network, and the MongoDB mirror is written last. If the process dies mid-trade the CSV already holds the flip, so a restart reconciles the database from it.
3. C.Idempotent by candle -- every flip is keyed by market, timeframe, strategy, and candle-close time, so a duplicate socket frame or a restart replaying the last candle can never double-fire a trade.
4. D.Transport-agnostic bus -- it runs in-process today, but the publish/subscribe seam is designed so the bot can later move to its own process or machine over Redis or a database change stream without changing the emitter or the bot.
5. E.Testing -- the connection is exercised end to end before it ever touches real money: unit tests on the open and close methods, and a backtest that can fire a flip at any moment to confirm the bot reacts correctly.
6. F.Prove the bot in isolation -- deploy a single bot to the server and let it run one trade at a time: when the trend flips long, it goes. One bot, fully proven on its own, is the finish line for this phase.

Deploy at Scale | v3 — The next phase, once a single bot is proven: deploying and managing many bots from the platform itself. The items below are intentionally left open -- they will be specified from what the first live bot teaches us. Not yet started.

1. A.Deploy from the dashboard -- a trader clicks New Trade, picks a direction, sets the trade parameters, and the platform provisions a dedicated wallet and bot for that trade.
2. B.Run many bots in parallel -- multiple positions across multiple wallets at once, each bot isolated with its own endpoint, all managed from one dashboard.
3. C.Specs to follow -- the exact shape of these is deliberately deferred until finishing Sol Bot surfaces the real requirements.