Flavio Espinoza

In May 2026 a crypto trader hired me to automate a strategy his AI said would return 400% a year. I did not build it -- I tested it. A deterministic backtest engine, no AI in the loop, just math, proved the 400% was a mirage: it only held at a position equal to 42% of the market's entire liquidity.

His nine-rule strategy was a Ferrari. What he needed was a Ford -- the GT40 that beat Ferrari at Le Mans in 1966 by being simple, durable, and fast to fix. I cut his nine rules to one, a trend flip on 4-hour candles, and on his own data the one-rule GT40 won: more return, half the drawdown, a fifth of the trades, cross-checked on TradingView and QuantConnect.

That is the whole method -- build the control, ship it, test every idea against it, promote only what wins -- and Sol Bot is that method running in production on Google Cloud today: autonomous bots trading leveraged Kamino positions on Solana, every key sealed in a signing vault, the client operating it through his own login. I built all of it solo by commanding a strict hierarchy of AI agents: AI is a force multiplier, not a coding buddy.

What follows is what my process produced.

The Architecture

Sol Bot shipped in three phases. v1 is the foundation -- the blockchain layer, the backtester, the trend signal, and the dashboard. v2 is the autotraders -- Tall Boy and Shorty, the Signal Emitter, and the signing vault -- live in production on Google Cloud today, trading real Kamino Multiply positions on real capital. The core is delivered; v3 is on the horizon.

• v1 -- Foundation: Sol Backtester, Sol Signal, Sol Dashboard, Backend
• v2 -- LIVE IN PRODUCTION: Tall Boy, Shorty, Signal Emitter, Turnkey signing vault
• v3 -- On the horizon: deploy at scale, a fleet of bots across multiple strategies

Solana Blockchain -- everything on-chain, no SDKs

The platform is built for the Solana blockchain, and the chain itself is the source of truth at every layer. No protocol SDK sits between the engine and the ledger -- Kamino's own SDK returns malformed constants and is banned from the codebase. Every account the engine relies on is decoded from raw on-chain bytes.

• Trade execution and the full trade lifecycle are captured directly from Solana: transactions are decoded on-chain and realized P&L is computed from actual wallet deltas, not estimates.
• The engine builds its own JLP/USDC candles directly from on-chain reads -- the chain is polled every minute and the price series is assembled into 4-hour candles by the engine itself, not pulled from an aggregator or a vendor API.
• Borrow APR, JLP yield, LTV, and liquidation thresholds are computed from account state the engine tracks itself -- Kamino, Jupiter, Pyth, and Helius all decoded from first principles and validated against live chain state.

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.

• 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. Proven byte-identical to the live engine over the full SOL/USDC lifetime: 7,625 candles, 474 flips, zero drift.
• 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.
• Before real money moved, 84 leveraged positions were backtested with real soft-liquidation simulation -- positions marked the way Kamino would actually deleverage them, not left un-liquidated on paper.
• 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. It is folded into the bot as one shared math core: the historical backtester and the live signal feed run the identical code.

• 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.
• 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.
• 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 -> v2

The operator's control surface, deployed on Google Cloud Run behind a Google login allowlist. The client creates, funds, arms, and stands down bots here -- no terminal, no hand-signing.

• Built with Next.js and React in TypeScript, styled with Tailwind CSS, containerized and deployed on Cloud Run with secrets injected from Secret Manager at container start -- nothing baked into the image.
• The Bot Preflight Deck -- a guided flow that mints the bot's secure vault wallet, gates funding (a SOL floor for fees, deposit verified against the wallet's real balance), locks the wizard once an address exists so money can never be stranded by a stray click, and arms the bot to trade hands-off on the 4-hour trend flips.
• Every money action is ONE modal -- Take Profits, Withdraw funds, Recover funds -- straight into the amount picker with the destination list, because the balances and the address already live on the bot's card.
• Stand down from any state -- one control closes the position on chain, verifies it against the chain, sweeps, and disarms; rearm-and-redeploy brings the bot back on a fresh balance.
• Real-time UI -- live balances, position state, trade history, and the engine's published trend, polling the shared database on one cadence.

Backend | v1 -> v2

The engine is a headless Node/ESM TypeScript process on a dedicated, hardened Google Cloud VM. No human intervention, and no quiet failures.

• systemd-supervised with a dependency chain that fails safe -- the risk watcher is a hard prerequisite of the trading engine: if the watcher cannot run, an armed engine refuses to start, because a leveraged position without a stop is the one thing worse than downtime.
• Secrets never touch disk -- a process-start shim fetches every credential from Google Secret Manager via the VM's metadata identity and injects it into the process environment only. No env files with secrets, nothing for a later cat to find.
• Test-gated, stamped deploys -- a deploy builds locally, runs the full suite (1,064 tests), refuses to ship red, and stamps the artifact with its git sha; the engine publishes that stamp at boot so the dashboard names the exact build it is talking to.
• A Pushover alert system that pierces Do-Not-Disturb -- any service failure pages instantly through systemd failure hooks, and live heartbeats are written on a seconds cadence so a stale service is visible in one read.
• State management -- MongoDB Atlas is the system of record; candles, bot configs, position state, and trades live in their own collections, one writer per collection, each queryable and repairable in minutes.

Turnkey Environments | dev, preview, production

Three isolated environments, each with its own Turnkey signing configuration, its own database, and its own secrets.

• dev runs locally against a dev database -- fast iteration, no cloud cost, nothing armed.
• preview is a full deployed replica on Google Cloud where the client tests with real (capped) money and a manual Flip-to-long / Flip-to-short button -- only the button can open a position in preview, while the engine still watches the real market and can always stand a position down. Test flips are tagged in the trade history so they never masquerade as strategy performance.
• production runs on real market signals with its own signer -- the environment promotion is a credential and configuration change, never a code fork.

Tall Boy & Shorty | v2 -- LIVE

Two automated trading bots that listen to the trend and trade the flip. Tall Boy enters long when the trend flips long and exits when it flips short; Shorty runs the inverse. Both are live in production, each on its own vault wallet, with leverage from 2x to 5x -- a range proven against the chain itself, not the docs: Kamino's own program rejects 1x (a zero borrow) and 6x (over the 84% borrow ceiling once real slippage lands).

• An event-driven service that subscribes to the flip stream and dispatches the trade through the execution layer the moment a flip fires -- the same reverse-engineered, 16-instruction Kamino Multiply transaction, built with no SDK, simulated as a hard gate before every signature.
• A position state machine -- idle, entering, open, exiting, closed -- where every transition is an atomic compare-and-set in the database, so "never double-open" is enforced by the storage layer, not by hope; recovery is state-driven at boot and the process is killable at any instant by design.
• A three-axis risk watcher runs beside the engine -- price stop, LTV guard against liquidation drift, and a borrow-carry trap that exits when funding costs start eating the profit. Proven live: the stop fired on a real position at a 0.1% trigger.
• Signs its own trades through the vault -- the bot builds the transaction and ASKS the vault to sign; it never sees or holds a key, so it runs 24/7 with no human approving each transaction.

Signal Emitter | v2 -- LIVE

The thin layer that carries a trend flip to the autotraders without welding the two together. The trend engine reports a flip; the emitter wraps it in context -- market, price, candle -- and publishes it on an in-process signal bus the bots subscribe to. Neither side imports the other.

• The trend engine never knows a trade bot exists -- it returns a flip and nothing more, which keeps the same math core reusable in the backtester and the live system with zero trade logic baked in.
• The in-process bus is the ONLY trade trigger -- the database is a mirror, never a tripwire, so no stale row can ever fire a trade.
• Idempotent by candle -- every flip is keyed by market, timeframe, strategy, and candle-close time, so a duplicate frame or a restart replaying the last candle can never double-fire a trade.
• Freshness and finality gates -- the engine acts only on a CLOSED candle that is provably recent; a stale feed means no trade, never a blind one.

Wallet Protection | v2 -- LIVE AND PROVEN

A. Two kinds of wallets, two jobs.

The client's Master Wallet (his Ledger) holds his money. He controls it. The bots never touch it. Each bot mints its own small trading wallet inside the vault -- like loading a prepaid card, not handing over a bank login.

B. The bots can only send money back to him.

The return wallet is hard-coded in the server's cloud configuration -- it cannot be supplied by a command, a dashboard field, or an API call. Even a fully compromised bot can only send money home.

C. The signing key is never left lying around.

Every key lives inside a Turnkey signing vault -- generated in the vault, never exported, never on a server, never in an environment variable. The bot asks the vault to sign; it never holds the key. Key theft is the number one way people lose crypto. That door is closed by construction.

D. The signer only allows the one move that makes sense -- and this is PROVEN, not promised.

Signing runs through a policy-gated NON-ROOT vault user that is allowed to talk to Kamino and its swap route and nothing else. Proven live on mainnet: the same signer signed a real Kamino Multiply, then was refused when the identical code path asked it to send funds to an arbitrary address. The limit is enforced by the vault, not by our code -- it holds even if the software is compromised. No blind signing; blind signing is exactly what cost a major Solana protocol $285M this year.

E. Safety switches that never sleep.

The independent risk watcher (price / LTV / borrow-carry) monitors every open position from outside the bot, and the engine will not arm without it. Stand down closes any bot in one action; an interrupted bot creation cannot strand funds -- an invalid bot keeps exactly one button, Recover funds, and recovery was proven to the last cent on chain.

F. Start small, grow only as it earns trust.

Preview runs capped positions with manual flips; production arms only behind green backtests and a funding gate. Money is the last thing wired, every time.

Kamino Guardian | in build

The vulnerability watchdog, designed against the Drift Protocol exploit of April 2026 -- a governance takeover, not a code bug, that went from first malicious transaction to drained vaults in roughly twelve minutes. Audits had passed. The lesson: the attack surface is upgrade authority, multisig membership, collateral whitelists, and oracle configuration -- and the warning signs are on chain, readable before the drain.

• Two processes, separated on purpose: a read-only watcher with no keys polls the chain and diffs live state against a pinned, committed baseline -- upgrade authority, program hash, multisig membership and threshold, timelocks, the reserve set, oracle wiring; a separate exit process holds signing access and does exactly one thing on a fire signal: unwind every position across every wallet, in parallel, on a stopwatch, and sweep the proceeds home.
• Tuned toward false positives by design -- a false fire costs slippage and a missed trend window; a missed fire costs the book. Governance-level changes execute the unwind immediately, without waiting for a human.
• Specced end to end with its own test plan -- fixture-mutation tests for every fire condition, the Drift attack replayed on a locally cloned validator, latency budgets as assertions, and a live fire drill on capped preview positions before automatic fire is ever enabled. Guardian reduces the odds of being caught in a drain; the honest control it complements, never replaces, is position size.

Deploy at Scale | v3 -- on the horizon

The core is delivered: the client clicks, the platform mints a dedicated vault wallet, gates the funding, and arms the bot -- as many bots as he wants, each isolated on its own wallet, all managed from one screen. The next phase is deploy at scale, and it is where the platform gets interesting:

• A fleet, not a pair -- the strongest backtest we ran spawns a new bot on EVERY trend flip and lets each one ride, so the book compounds across flips instead of resetting on each. Running that strategy for real means dozens of bots in parallel, which the per-wallet isolation was designed for from day one.
• Multiple strategies, one platform -- the live OTT strategy is one point in a configuration space (EMA length, band percent, timeframe), and the strategy is config-driven, never hardcoded. A family of EMA/band variants has already been through the backtester; at scale, different bots run different configurations side by side and the control-versus-variant loop picks the winners with real capital instead of paper.
• Fleet-scale operations -- a master stand-down across every open position at once, a second independent price feed that must agree before a trade fires, and the Guardian's automatic fire. Each specced, each gated behind the same discipline everything else shipped through: control, variant, measure, promote the winner.