Author: rdugger

Solana Arbitrage: What I Learned From 400 Trades (And $4 in Losses)

I built PhantomArbiter to detect and execute arbitrage on Solana. After 400 live trades across 3 months, I lost $4. Here’s what went wrong — and why the technology actually worked.

---

The Setup

Detect price divergence across Solana DEXes (Jupiter, Raydium, Orca, Meteora). Execute buy-low / sell-high atomically via JITO bundles for MEV protection.

$500 initial capital. Real money. 3 months. 400 completed trades. Net result: -$4.23.

---

Why It Failed

RPC Latency

Solana blocks come every 400ms. The system detects an opportunity, but by the time the bundle submits, 2-3 blocks have passed. The spread that looked profitable is now break-even or negative.

Local detection: 10ms. RPC call: 50ms. Signature submission: 100ms. Next block: 400ms. Too slow.

Professional MEV bots use validator infrastructure — direct connections, guaranteed inclusion. I used public RPC. Not competitive.

Network Congestion

Solana’s network is unpredictable. Sometimes transactions confirm in 1 block. Sometimes 10. Arbitraging on 1-2% margins, network variance turns winning trades into losing ones. My math said $2.50 profit. Slippage ate it before execution landed.

Bundle Fees

JITO bundles cost ~0.00005 SOL per transaction — $0.002-0.004 per trade. 400 trades, ~$1-1.50 in fees. The average arbitrage spread before costs was around $1.50. After slippage, fees, and MEV tax, nothing was left.

---

Why It Actually Worked

The system architecture was sound. 400 trades without a crash:

Zero transaction failures. Zero contract bugs. Zero memory leaks. Stable WebSocket price feeds for 24/7 uptime.

The software worked perfectly. The economic model didn’t. That’s an important distinction.

Arbitrage at retail scale on Solana isn’t viable right now — not because the code is broken, but because professional operations have better infrastructure, lower fees, larger capital to absorb slippage, and faster access to the same opportunities. The edge isn’t available at the level I was operating.

---

What I Kept

The Rust/Python hybrid architecture — Rust handling the execution layer, Python handling strategy logic — transferred into other work. The execution core doesn’t know what it’s trading. The strategy layer doesn’t know how fast the core is running. That decoupling is the right design regardless of what market it’s applied to.

The code got archived. The pattern didn’t.

PhantomArbiter trades live markets, handles real network conditions, survives real slippage, and loses money honestly. Most trading systems are backtested and overfitted, profitable in theory but brittle in practice, or they don’t exist at all. A system that ran 400 live trades and lost four dollars is actually a reasonable outcome. It proved what it needed to prove.

I didn’t keep trading. I kept the blueprint.

Building rpgCore: One Engine, Four Genres

The original ambition was simple: build something that didn’t need to be rebuilt every time an idea changed direction.

The execution was not simple.

---

rpgCore went through a phase that most solo projects don’t survive. Godot C# bridges wired to Python servers via IPC. Rust DLL experiments. Terminal rendering adapters. A cinematic simulator. A vector space battle engine. Dozens of game concepts running in parallel, each pulling the codebase in a different direction. At some point there were more than 60 test files archived as referencing modules that no longer existed.

The project had discovered everything it didn’t want to be.

The Architectural Singularity refactoring pulled 21,000+ items into a legacy vault — not deleted, preserved — and left behind something clean: a pure Python engine, pygame for rendering, a single command to run any of four distinct games.

---

The Orange Box was Valve’s 2007 bundle that shipped Half-Life 2, Portal, and Team Fortress 2 together. Three completely different genres, one release. The concept that stuck with me wasn’t the games — it was that the same underlying systems could drive experiences that felt nothing alike.

rpgCore now ships four built-in games testing the limits of the shared architecture:

Slime Clan — turn-based faction strategy. Grid simulation, overworld nodes, automated battle resolution. The engine’s systems thinking expressed as territory and conflict.

Last Appointment — narrative dialogue. You are Death. Your client has questions. Dialogue trees, dynamic UI card layouts, complex state across conversational nodes. No combat. No score.

TurboShells — breeding and racing simulation. Deep genetics, time progression, legacy management across generations of turtles.

Asteroids Roguelike — real-time action. The same engine’s high-performance rendering and physics under pressure.

The Constitution Law: nothing is built twice, and demos never reimplement shared engine systems. If a system exists in src/shared/, it belongs to all four games.

296 tests enforcing it.

---

The cross-language experiments are archived, not deleted. The Godot C# bridge that drove a Python core via WebSocket is documented as the blueprint for any future migration away from pygame. The Rust performance harness is there for the day it matters. Nothing was thrown away — it’s in cold storage, preserved as evidence of what was tried.

The lesson from the Architectural Singularity isn’t “don’t experiment.” It’s “know when the experiment phase is over.” The 21,000 archived items are the proof of work that made the current clean state possible.

A sprawling codebase that tried everything became an engine that does four distinct things well, from one shared foundation.

That was the point from the beginning. It just took a while to get there.

I Didn’t Want to Babysit a Dialer Forever

The unglamorous version of data administration is a lot of watching. Watching a dialer load leads. Watching a queue fill and drain. Watching the same manual processes run the same way they’ve always run because no one has had time to change them.

I didn’t want to do that indefinitely.

---

The first experiments were messy. Early Google Gemini API calls combined with Python Selenium — browser automation that could handle the dialer interactions I was tired of doing myself. The code was fragile, the model was still finding its footing, and the results weren’t perfect. But they were good enough to prove something: the repetitive parts of this job could be handled by something that wasn’t me.

That realization changed what I built next.

---

The Telesero Balancer is the clearest example — a live system that handles the distribution logic I used to manage manually. Convoso tools that shave seconds off agent workflows at scale. Brownbook Tools for the data sourcing problem. External partnerships that bring in raw lead data without someone manually pulling it.

None of these have a clean ROI number attached. I haven’t measured hours saved per week and multiplied by fifty-two. What I can say is that the class of work I was doing when I started — the babysitting — occupies a fraction of the same time, and what replaced it is more interesting.