Case study 1 of 2 · the system

One person. Coding agents. Two servers. A live trading system with my own money on-chain.

SKYNET turns Telegram calls and tracked wallets into ranked strategies and executes them on Solana with 66 ms of engine time per trade, from a Rust engine built by coding agents to my specification, tested and hardened under my direction.

A note on authorship

I am not a backend, Rust or smart-contract engineer and do not represent myself as one. I define what the system must do, its boundaries and acceptance criteria; I direct coding agents through research, design, implementation and review; I validate the resulting behaviour and own the release decision. The implementation-level expertise described below is substantially agent-mediated.

16months · one human, agents build
1,300confirmed trades, my own funds
66 msengine time per trade, median
Populations and datesShow less

A trade is one position. 2,843 on-chain signatures stand behind the 1,300 confirmed positions: 1,685 buy legs and 1,158 sell legs, because a position can close in several legs. Engine time is the engine's own work per trade, from price quote to submitted transaction, the dashboard's Bot Speed: 66 ms median across the 1,228 buys with stage timings, 90% under 200 ms. From signal to confirmation on chain the median is 1.3 s, most of it the blockchain's confirmation (625 ms median) and delivery from Telegram. Measured 3 September 2026.

See the system in action

Trading intelligence, connected.

Overview 0:50

Telegram signals. On-chain wallets. Research and execution.Open video
Read the transcript

I built SKYNET to bring trading intelligence and execution into one platform.

It tracks Telegram signals and on-chain wallet activity, with rankings that make their historical performance easier to compare.

Wallet profiles reveal trading results and behavior, while market intelligence adds context about changing conditions.

The strategy engine lets you replay historical signals with different exit rules and position sizes.

The trading terminal brings together Phantom wallet swaps, automated copy trading through my custom Rust engine, and live position monitoring.

Detailed transaction timelines show the journey from the source signal through execution to on-chain confirmation.

SKYNET connects the research, the trade, and the evidence behind it.

Full walkthrough 8:31

Regimes, sizing, swap engines, positions, and transaction evidence.Open video
Read the transcript

Skynet brings research, strategy design, position sizing, and trade execution into one connected workspace. Let’s walk through how it works.

It starts with signals from Telegram and tracked wallets. The research layer puts those signals in context. Strategies define the rules, sizing defines the exposure, and the terminal brings execution and monitoring together.

Start with the source rankings. Open a profile, and you can look beyond the headline numbers: how active the source is, the market caps it enters, and how different models perform. Time, chain, and market filters help narrow the comparison.

Here’s Trader A. We’re using a hundred-dollar paper entry across the full history. The leading models are below zero, but the regime labels reveal a pattern: positive results in bull markets, and losses in sideways and bear markets. Let’s follow Model Six through the filters.

Select Bull, and the ranking changes. Model Six moves to the top, with three thousand two hundred and fifty dollars in historical replay profit. Models Four and Two are positive as well. We haven’t changed the entry size. We’re looking at the calls that fell within bull-market conditions.

Now switch to Bear. Model Six shows a replay loss of one thousand five hundred and fifty dollars, and the leading models are below zero. That’s why market context matters. The overall result combines periods where the same strategy behaved very differently.

Before changing the sizing, return to all regimes. Model Six shows a three thousand five hundred dollar loss across seven hundred and seventy-two cases. Its exit rules are a fifty-percent stop loss and a five-times take profit. We’ll keep those rules fixed for the comparison.

Open Custom Sizing and select Test Four. This preset switches off entries below three hundred thousand dollars in market cap. From there, it allocates one thousand dollars to the next tier, two thousand to the one-to-ten-million tier, and three thousand above ten million. The two-percent limit is set to trim mode.

Apply the preset, and the strategy cards update. The date range, chain, and exit rules stay the same. In this recorded snapshot, Model Six moves from a three thousand five hundred dollar loss to fifty-five thousand dollars in historical replay profit. Models Four and Two are also positive. The monthly curves, regime breakdown, and ranking all reflect the new settings. Model Six now includes three hundred and fifteen cases.

Switch back to Paper, and Model Six returns to its three thousand five hundred dollar loss. Apply Test Four again, and the positive replay returns. Two things have changed: which entries are included, and how much is allocated to them. That changes both the results and the exposure. Maximum drawdown in the custom view is twenty-eight thousand dollars. These are historical simulations with trading costs excluded. The comparison helps you understand the effect of your rules; it doesn’t establish how they’ll perform in future trading.

Strategy Center brings these trader-and-model combinations into one view. Compare exit rules, replay results, market regimes, and consistency across the cards. When something deserves a closer look, open its statistics or continue into simulation.

Market Intelligence adds the wider context: daily regimes, intraday alerts, and reversal indicators. Coverage and freshness are shown alongside the signals, so you can see how much information is available and how recently it was updated.

Now let’s move into the trading terminal. The chart, swap controls, strategies, and trade history share one workspace. You can move from researching a setup to managing its execution, then come back to inspect the result.

The wallet balances are loaded here. You can see the available Solana balance and the tokens held in the wallet. Open the selector to inspect quantities and displayed values. Choose a holding, and its available balance appears in the swap panel, ready for the amount you want to enter.

For a manual Phantom swap, the system prepares an unsigned transaction. You review and approve it in your wallet. Phantom signs it, and the selected engine handles submission.

The Ultra option uses Jupiter’s order and execution flow. With Phantom connected, the prepared transaction returns to the wallet for signing. The selected tokens, amount, and active engine remain visible together in the swap panel.

The custom route is labelled Legacy in the terminal. Jupiter supplies the quote and swap instructions. The Rust engine builds the transaction, Phantom signs it, and the custom submission path sends it through Helius Sender.

Automation uses a different signing flow. The bot checks incoming signals against the configured strategy, and its execution wallet handles signing. The Rust service connects transaction preparation, submission, confirmation, and the monitoring of the resulting position.

Inside the custom engine, the instructions become a transaction with the configured compute budget, priority fees, and submission settings. Once the trade is confirmed, that execution connects back to its position record.

The published measurements report a median engine time of sixty-six milliseconds, and around one point three seconds from signal to confirmation. Those figures describe different stages. Next, let’s inspect the timings of an individual recorded trade.

Open a recent copy trade from Positions. This entry was triggered by the automation. The record brings its outcome, costs, and entry context together. From here, we can open the timing breakdown and follow what happened after the signal arrived.

The displayed end-to-end time for this entry is two point four two three seconds. Within that, quoting, swap instructions, transaction building, and submission took eighty-one milliseconds combined. Network confirmation is shown separately at four hundred and seventeen milliseconds. You can see the engine’s speed in context, alongside the rest of the recorded workflow.

This position was later closed manually. The exit record shows seventy-nine milliseconds of engine work, with confirmation measured separately at four hundred and sixteen milliseconds. You can also inspect the route, slippage, fees, and transaction links. Open the log trace to follow the recorded events in more detail. The timing numbers connect to evidence you can check.

That’s what makes this view useful. You can inspect the stages behind an execution, see where time was spent, and follow the transaction evidence. Manual swaps and copy trades each keep their own breakdown.

Back in the terminal, the strategy rail lists each configured source and model, its status, and recent performance. Search or sort to find a strategy, then open its overview, positions, history, or configuration. Those views stay connected within the same workspace.

The overview brings net profit and loss, win rate, trade count, and exit outcomes together. The realized performance curve shows how results developed over time. The fee breakdown helps explain how gross trading results translate into net performance.

Open Configuration to see the rules behind those results: base investment, daily trade limits, take profit, stop loss, the selected wallet, and buy and sell slippage. The model and status stay visible, keeping the strategy’s setup close to the activity it produced.

Positions connects each open lot to its source and model. Entry details, valuation fields, exit rules, and transaction links sit together. You can move directly from a strategy to the positions it created and inspect their current state.

Trade History gives you the individual records behind the summary: entries, exits, execution status, outcomes, and transaction references. Together with the fee breakdown, it helps explain the result over time. These execution records are kept distinct from the historical replays used in research.

The wider system also includes vault and wallet views. Portfolio monitoring, manual wallet approval, and automated execution each have their own role, with different signing responsibilities.

Monitoring continues throughout the workflow. Token tracking keeps entry context, current observations, historical highs, and data freshness visible. Wallet research adds another view of activity, while the strategy and execution records show how the system responded to the information it received.

That’s Skynet: from the first signal to the strategy, the trade, and the evidence behind the result.

Choose the introduction or explore the complete workflow.
How it was built

From a Grok chat window to a two-server operation in sixteen months

Commits per month from git across the three repositories, April 2025 to September 2026. One file at the start; three codebases and an on-chain program at the end.

020040060025·0425·0625·0825·1025·1226·0226·0426·0626·08
Analytics · PythonExecution engine · RustOn-chain program · Anchor
Commits per month, from git across the three repositories · Apr 2025 to Sep 2026
The milestonesShow less
Apr 2025
One 1,295-line Python file, written in a Grok web chat. I had never opened an IDE.
Jul 2025
Dashboard. Continuous tracking begins.
Oct 2025
Claude Code becomes the workshop. Sharded price feed. First independent AI auditors.
Nov 2025
Second server, Rust engine, encrypted tunnel. The delivery workflow is born.
Feb 2026
Specialist sub-agents: research, plan, implement, audit, verify.
Mar 2026
First confirmed on-chain trade.
Jun 2026
On-chain program live on mainnet.
Sep 2026
Three codebases, 112 documented workflow runs, my own funds in production.

The delivery loop is its own case study. This one is about what it produced.

What it does

From a chat message to an on-chain trade, unattended

Four jobs, one dashboard. I choose which public signals to follow with my own funds; the system listens, ranks, executes inside fixed caps and contains the damage when something goes wrong.

Listen
149live sources: 63 groups, 86 wallets, 4 chains

Every message and every wallet transaction, around the clock.

Rank
17exit strategies replayed per source, per regime

Every source scored by what each strategy would have done.

Execute
66 msengine time per trade, median of 1,228

A Rust engine on its own server builds the transaction itself, from quote to submit, and manages the exit. The chain then takes about 0.6 s to confirm.

Contain
4fail-closed control layers

Kill switch, per-trade and daily caps, circuit breakers.

See it on the dashboardShow less

I choose which public signals to follow with my own funds. Execution stays inside fixed caps, and every step is observable on one dashboard.

Infrastructure

Two servers, one encrypted tunnel, and the Solana blockchain

Analysis is heavy and chatty; execution has to be fast and quiet. So the brain and the hands live on two Hetzner machines joined by an encrypted tunnel, and the hands keep closing positions even if the brain goes down.

The full map, box by boxShow less
External feeds

Signals in

raw signals · prices · transactions
  • Telegram · 63 groups, read as messages arrive
  • Birdeye price WebSocket · 15-second candles · 8 sharded connections
  • Helius wallet WebSocket · every transaction of 86 tracked wallets
  • Market data · Nansen · DefiLlama · CoinGecko · CoinMarketCap
My servers

Finland · Hetzner

the brain · Python
  • Detection and queues · 8 workers, 5-layer dedup
  • TimescaleDB · 28 GB · 12.3M rows
  • Replay and sizing engine · nightly, 17 strategies
  • Regime classifier · 27 signals, daily
  • Operator dashboard · 202 endpoints
My servers · WireGuard tunnel between them

Nuremberg · Hetzner

the hands · Rust
  • Signal subscriber · verify, dedupe, fan out
  • Jupiter routing · hand-built transactions
  • Helius Sender · ~1 s to confirmation
  • Position monitor · prices decoded on-chain
  • Two lanes · main wallet · program-owned account
  • Controls · kill switch, caps, breakers
On-chain

Solana mainnet

signed transactions out · confirmations and live prices back
  • Anchor program · on-chain limits on the trading key
  • Jupiter v6 · live since Jun 2026
external inputsmy serverson-chain

Why two servers? Analysis is heavy and chatty. Execution has to be fast and quiet. Splitting them keeps a dashboard spike or a nightly job off the trade's critical path, and the engine keeps closing positions if the brain goes down.

The execution engine · built, not bought

No trading library. The engine assembles the transaction itself.

22 modules and 54,000 lines of Rust on their own server, doing one job: turn a verified signal into a landed Solana transaction and manage the exit.

Route quote from Jupiter13 msBuild and sign the transaction4 msSubmit through Helius Sender14 msOn-chain program checks80 msWait for the blockchain to confirm621 msNot instrumented per stage292 ms
One production trade, stage by stage · 1,024 ms end to end, of which 292 ms is not instrumented per stage · latest confirmed trade. 31 ms of the engine's own work; 621 ms waiting for the chain.
66 msengine time per trade, median
196 ms90th percentile
1,245test functions in the engine
How the transaction is built and hardenedShow less
  • Exactly one compute-unit limit and one price, Jupiter's instructions verbatim, a validator tip from a 10-account pool, address lookup tables. Preflight off, zero retries, confirmation polled every 200 ms against a ~400 ms block.
  • Solana gives a transaction 1,232 bytes, and a fresh pump.fun route does not fit. Seven constant venue accounts are pre-warmed into the engine's own lookup table, appended and never prepended, because prepending re-inflates every healthy route.
  • Exit prices are decoded from the pool's own bytes on-chain, 8 venues at exact byte offsets, with the router only as fallback. Signals cross the tunnel HMAC-signed with a freshness window and an idempotency cache, so a duplicate message is designed never to become a duplicate buy.

Engine time counts the engine's own work per trade: price quote, route, transaction build and submit. Median 66 ms and 90th percentile 196 ms across the 1,228 buys with stage timings; 90% under 200 ms. The chain's confirmation adds a median 625 ms on top. Every control fails closed: kill switch on entries, a 30 SOL cap enforced in three independent places, sizing that refuses on a missing SOL/USD price, a sell circuit breaker at three retries. 32K lines of tests.

Real-time data

The price provider caps a connection at 100 addresses. I needed 552.

So the live price feed is split across auto-scaling connections, placed by a stable hash so nothing moves on a restart, and every 15-second candle lands in a time-series database built for exactly this.

8shards live · 6 needed, 2 headroom
552contracts on the feed
12.3Mrows in TimescaleDB
How the feed is shardedShow less
  • The feed is sharded across auto-scaling WebSocket connections, placed by SHA-256 hash so placement survives restarts. Python's built-in hash is salted per process and was rejected.
  • The scaler acts on the busiest shard, not the average, with hysteresis and a dry run before any scale-down. An average of 77 can hide a shard at 85.
  • Every 15-second candle lands in TimescaleDB. The hot read runs 230× faster through a continuous aggregate.

Still open, and written down: the feed is certified for today's load, not for 1,500 contracts. The docs say so, and they list the defects that block the next step.

On-chain controls

A trading key that cannot move the money

My funds sit in a program-owned account on Solana. The engine holds a separate trading key that can open and close positions inside limits the program enforces on every transaction, and can never withdraw.

My wallet key

  • Deposit
  • Withdraw
  • Pause
  • Revoke the trading key

Trading key, held by the engine

  • Open positions
  • Close positions
cannot withdraw · ever
73tests run on a fork of mainnet
46unit tests
14program instructions · 43 error codes
How the program enforces itShow less
  • My funds sit in a program-owned account on Solana. My wallet key is the only authority that can deposit, withdraw, pause, or revoke the trader.
  • The engine holds a separate executor key that can only open and close positions, inside limits the program enforces on every transaction.
  • Router instructions arrive as opaque account lists, so they are constrained rather than trusted: capped at 64 accounts, every writable account allowlisted, only two route discriminators accepted.
Rules enforced by the program, not by policy
0.5 SOL per trade2 SOL per daylamports spent and tokens sold counted separately10 Token-2022 extensions rejectedtransfer fee capped at 200 bpsthe account pays its own fees from a separate counter

Signing detail: Phantom rewrites the message at signing, so raw-byte binding is impossible. Authorization verifies Ed25519 at the signer's slot index and binds each meaningful field individually.

Intelligence

Every tracked source replayed through 17 strategies, nightly

Every source is scored by what each of 17 exit strategies would have done, across chains and market regimes, precomputed each night so every page loads instantly.

300+ sources ever tracked 17 exit strategies 5 chains × 4 market regimes 6.2M precomputed rows 17,820 tasks · about 25 minutes · every night
The replay cube · one cell per source × strategy × chain × regime · 6.2M rows, refilled by 17,820 replay tasks a night
17exit strategies
6.2Mprecomputed rows
27regime signals
How the replay worksShow less
  • 300+ sources ever tracked × 17 exit strategies × 5 chains × 4 market regimes, precomputed nightly so every page loads instantly.
  • Any result can be re-rendered at operator-defined position sizes, seven market-cap tiers deep.
  • The market-regime label is validated on 21,345 real outcomes (z = 4.07, p < 0.0001). Caveat kept: 183 of 407 labeled days are backfilled with a simpler classifier, so this validates the labeling concept, not retroactive production accuracy.

The replay table carries five chain values; today's 40,908 tracked contracts sit on four of them. 17,820 tasks a night, about 25 minutes.

Failures → controls

The controls that exist because something broke

Three real failures, and the permanent check each one left behind. None of them can happen the same way twice.

What broke
A guard that was too eager deleted 28 real wallet trades across four instruction shapes.
What exists now
A 7,150-cell differential corpus that asserts every improvement is consumed, run before any parser change ships.
7,150cells checked before a parser change
What broke
A concentrated pool was priced 3.02× wrong by reserve ratio, producing a phantom stop-loss.
What exists now
A structural gate before any decoded price is trusted: decimals match, legs move opposite, both non-zero, then drift bands.
3.02×the error the gate now refuses
What broke
The nightly sizing job froze the web process 24 ms per spawn: uvloop's fork against a 3.3 GB address space.
What exists now
The worker moved out of process, 2,623 s → 329 s, and refuses to boot on uvloop at all.
7.97×faster, and a boot-time assertion
In their own wordsShow less

These three failures are retained as regression gates. Each now fails a build before it can reach production.

Where AI verification stops

Agent consensus is not correctness

I do not assume that agreement between agents means the code is right. For high-consequence components the check moves outside the agent system, and that escalation is written into the workflow, not left to judgment on the day.

Key custody

Human specialist, formal audit

Changes to custody or withdrawal authority never go through the agent panel alone.

Money-moving code

Must run before it ships

A runtime test on a fork of mainnet is required for every fund-moving change. Reading the code does not count as running it.

Every risky change

A model from another vendor, run by me

The external review reads a frozen commit cold. Without a code and runtime receipt, its findings stay open.

What this means in practiceShow less
  • The order is: agents implement, independent agents challenge, I validate the behaviour in production, and external specialists validate where the consequences justify it.
  • The panel's own ledger records that on 78 of the 92 runs where it was measured, the outside review found something the internal lanes had missed. That number is why the outside check exists.
Measured on the production system · 3 September 2026

Measured, with the populations printed

Six numbers from the live database, each with the population it was measured on.

1,300
confirmed trades, one per position
2,843 on-chain signatures behind them, verifiable on any explorer: 1,685 buy legs, 1,158 sell legs.
66 ms
engine time per trade · median of 1,228 buys
Quote to submitted transaction, the dashboard's Bot Speed; 90% under 200 ms. Signal to on-chain confirmation: 1.3 s median, of which the chain's confirmation is 625 ms.
40,908
contracts tracked · 4 chains
SOL 34,215 · BSC 3,060 · ETH 2,870 · Base 763
12.3M
rows in TimescaleDB
28 GB · 95 tables
1,245
engine test functions
32K lines of tests
119
on-chain program tests
46 unit + 73 mainnet-fork
Where the numbers come fromShow less

371K implementation lines and 5,066 commits across three repositories were generated under the delivery workflow. They measure the workflow's output, not me.

See it running

The system is the proof.

Two things I can show live in an interview.

01

The product, live

Any page of the running system: the feed, the engine, the on-chain controls, and the data behind every number here.

02

The workflow, live

A real task taken through the delivery loop: research, plan, AI implementation, separate review lanes, my go / no-go, verification in production.

the boundaryWhere I would not use this: a change to key custody or withdrawal authority. That gets a human specialist and a formal audit, not a review panel.

Lukasz Rodzen
product owner · release owner · operator
Poland · remote

I own the product intent, the system boundaries and constraints, the acceptance criteria, the release decision and production verification. AI agents provide much of the implementation-level technical depth: they research, propose designs, write the code and review one another independently. I resolve their disagreements through evidence and decide what ships. I do not claim the unaided technical depth of a senior backend or Rust engineer.