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.
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.
Trading intelligence, connected.
Overview 0:50
The video could not load. Try Play again, or use the Open video link.
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
The video could not load. Try Play again, or use the Open video link.
Jump to a chapter 32 chapters
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.
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.
The milestonesShow less
The delivery loop is its own case study. This one is about what it produced.
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.
Every message and every wallet transaction, around the clock.
Every source scored by what each strategy would have done.
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.
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.
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
Signals in
- 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
Finland · Hetzner
- 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
Nuremberg · Hetzner
- 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
Solana mainnet
- Anchor program · on-chain limits on the trading key
- Jupiter v6 · live since Jun 2026
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
In their own wordsShow less
These three failures are retained as regression gates. Each now fails a build before it can reach production.
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.
Human specialist, formal audit
Changes to custody or withdrawal authority never go through the agent panel alone.
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.
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, with the populations printed
Six numbers from the live database, each with the population it was measured on.
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.
The system is the proof.
Two things I can show live in an interview.
The product, live
Any page of the running system: the feed, the engine, the on-chain controls, and the data behind every number here.
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.
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.