Deterministyczny program · Python / asyncio
Darwin: program, nie LLM.
Darwin to żywy turniej konfiguracji strategii tradingowych z doborem darwinowskim — populacja strategii handluje równolegle na żywych danych, allocator awansuje i zabija słabe sloty, spawner mutuje najlepsze. To zwykły, deterministyczny kod (Python/asyncio), zero kodu LLM. Żadnego modelu językowego w pętli.
Populacja strategii, jeden żywy rynek, jeden model kosztów.
Darwin to populacja konfiguracji strategii handlujących równolegle na żywych danych rynkowych
(Binance spot + Hyperliquid WebSockets) z paper execution i jednym konserwatywnym modelem kosztów. Allocator ocenia
anty-szumowe bramki promocji, spawner ewoluuje populację, a dashboard na :8093 pokazuje to na żywo.
Deterministyczny silnik selekcji
Zwykły program, którego logikę da się prześledzić linia po linii. Brak losowości poza jawnym seedem kontroli C.
- Python / asyncio — async WS feed bus, jeden event loop, telemetria co 60 s.
- Żywe feedy: Binance spot aggTrade + Hyperliquid trades + HL
l2Book(M1). - Paper execution przez jeden współdzielony engine, jeden model kosztów (round-trip HL 12,64 bps).
- Stan w SQLite (
darwin.db, WAL):slots,trades,allocator_events,rejections.
Nie jest modelem językowym
W tym katalogu nie ma ani jednej linijki kodu LLM. Darwin niczego nie „rozumuje" — wykonuje regułowe bramki i statystykę.
- Zero kodu LLM — żadnego promptu, żadnego wnioskowania modelu w pętli decyzyjnej.
- Brak ścieżki składania zleceń — w katalogu nie istnieje kod order-placement.
- Brak kluczy API — wszystkie feedy to publiczne dane rynkowe.
- Decyzje promote / degrade / kill to bramki statystyczne, nie generacja tekstu.
Pięć klocków: feed → sloty → executor → gate → allocator.
Dane wpadają z WebSocketów, sloty generują sygnały, executor próbuje wykonać paper-fill, bramka orderbooka odrzuca filli, których księga nie utrzyma, a allocator co godzinę przesuwa sloty między stage'ami. Raz na dobę spawner mutuje najlepsze — to właśnie ewolucja.
feeds.py — magistrala danych
WS feed busAsync magistrala WebSocketów: BN spot aggTrade + HL trades + HL l2Book (M1), z wykładniczym backoffem reconnectu. Trzyma współdzielony stan rynku: historia spreadu, HL micro-ticki, momentum BTC i żywa księga L2 per coin.
Sloty — populacja konfiguracji
family A · C (B w M2)Slot = (rodzina, parametry, stage, stan). Rodzina A: spread/lag BN→HL (entry 25–50 bps). Rodzina C: seeded random entry z identycznym zarządzaniem ryzykiem — kontrola losowa (negative control). Rodzina B (funding-arb) planowana na M2. Przy odrzuceniu przez gate slot po prostu nie handluje (cooldown).
executor.py — paper execution
jeden model kosztówWspółdzielony silnik wykonania paper z jednym modelem kosztów: taker HL 4,32 + BN 5 + slippage 2 bps/stronę → round-trip HL 12,64 bps. M1: przed każdym otwarciem konsultuje bramkę — zwraca None i loguje REJECT, jeśli księga nie utrzyma filla.
gate.py — bramka głębokości orderbooka
honest fills (M1)Chodzi po żywej księdze HL L2 i odrzuca fill, chyba że wszystkie warunki spełnione: szacowany slippage ≤ 3 bps, spread księgi HL ≤ 20 bps, głębokość po naszej stronie ≥ $50. Logika przeniesiona z żywego pre-checku spread_trader_live.py::check_orderbook_fill. Odrzucenia trafiają do tabeli rejections.
allocator + spawner — selekcja i ewolucja
co godzinę · co 24hAllocator (co godzinę): rolling stats per slot + bramki promocji, bootstrap p-value z korektą Bonferroni; wykonuje przejścia — awans INCUBATOR→CANDIDATE (wszystkie bramki + histereza 72h), degradacja (rolling-7d net<0 lub przekroczony max-DD), kill przy 2× degrade; wagi Thompson-sampling cap 30%/slot. Spawner (co 24h): top-3 po net PnL → 2 mutacje ±20% każdy + 1 świeży losowy per rodzina; populacja max 24, najsłabszy zabity przy przepełnieniu. To jest dobór darwinowski.
M0 pokazał +773k bps. To był miraż płynności.
3,6-dniowy burn-in M0 wyprodukował +773k bps pozornego zysku. Dowód z żywej bazy: płynne majory (BTC/ETH/SOL) dały −13,4 bps średnio — zero edge, identycznie jak kontrole losowe — a cały pozorny zysk pochodził z niepłynnych altów. M1 dodaje bramkę głębokości orderbooka, która to naprawia.
HMSTR sam = 37% PnL. Na niepłynnych altach obserwowany „spread" BN-spot vs HL to artefakt nieświeżych printów i szerokich ksiąg. M0 zakładał fill po obserwowanej cenie bez sprawdzenia głębokości — więc te paper-fille były fikcją.
Liquid majors: −13,4 bps średnio. Na płynnych coinach wynik był identyczny z kontrolami losowymi — czyli żadnego prawdziwego edge'u tam nie ma. Pozorny zysk istniał tylko tam, gdzie księga nie mogła go obsłużyć.
Smoke test (~3,5 min na żywo): gate zaakceptował 21 / 182 prób (11,5%). HMSTR dostał 29 odrzuceń, wszystkie book_spread (średnio 57–111 bps szeroko), zero zaakceptowanych. To poprawnie zabija większość trade'ów typu HMSTR — o to chodzi.
| Warunek | Domyślny próg | Klucz config |
|---|---|---|
| szacowany slippage do filla docelowego nominału | ≤ 3 bps | max_slip_bps |
| spread księgi HL (bid/ask) | ≤ 20 bps | max_book_spread_bps |
| głębokość po stronie którą uderzamy | ≥ $50 | min_depth_usd |
| testowany nominał | $25 | notional_usd |
Od inkubatora do kill — selekcja, która wykonuje.
W M1 allocator nie tylko ocenia — wykonuje przejścia stage'ów. Każdy slot zaczyna jako inkubator, awansuje na kandydata po przejściu wszystkich bramek (+ 72h histerezy), degraduje przy ujemnym rolling-7d lub przekroczonym drawdownie, i zostaje zabity po drugiej degradacji.
Dwie rodziny żywe, jedna planowana — plus wbudowany detektor przecieków.
Początkowa populacja: 6 slotów A (entry 25/30/35/40/45/50 bps) + 2 kontrole C (seedy 1337, 7331).
Rodzina C to negative control — jeśli kontrola losowa kiedykolwiek pokaże promote_eligible: true, znaczy że bramki są za słabe.
| Rodzina | Typ | Co robi | Status |
|---|---|---|---|
| A | spread / lag | Spread/lag BN→HL (port z lag-scanner-dev v3 entry + v4 „Grok" filtry/exity). Entry przy utrzymanym spreadzie 25–50 bps — odpala rzadko z założenia (pojedyncze trade'y na godzinę, nie na minutę). |
żywa · M1 |
| C | negative control | Seeded random entry z identycznym zarządzaniem ryzykiem jak A — detektor przecieków. Średnio ~2 wejścia/godzinę. Jeśli C zaczyna „zarabiać", bramki przeciekają i logowany jest WARNING. | żywa · M1 |
| B | funding-arb | Funding-rate arb delta-neutral: HL funding 1h vs BN 8h. Model kosztów już niesie 5 bps taker BN dla nogi BN; wymaga FundingArbSlot + feedu fundingu. Te same bramki orderbooka. |
planowana · M2 |
Paper-only z założenia. Zero ścieżki do żywych pieniędzy.
Darwin nie może stracić ani grosza, bo nie ma jak złożyć zlecenia. Bezpieczniki są wpisane w architekturę, nie doklejone — łącznie z kontrolą losową, która sama z siebie wykrywa, gdy reszta systemu zaczyna oszukiwać.
Wyłącznie paper trading. W całym katalogu nie istnieje kod order-placement — nie ma jak złożyć żywego zlecenia.
Żaden klucz API nie jest czytany. Wszystkie feedy to publiczne dane rynkowe (BN spot + HL WS). Brak sekretów = brak ekspozycji.
Dashboard :8093 ma routes GET /, /api/state, /healthz — zero write endpoints. Brak żywych zleceń = brak kill switcha do pilnowania (ten przyjdzie z MICRO_LIVE w późniejszym milestone).
Unit systemd (user) z MemoryMax=2G. Tank ma zero swapu + historię OOM-kill, więc cap zamienia runaway w czysty restart zamiast OOM całego systemu. Graceful shutdown force-zamyka pozycje (exit_reason=SHUTDOWN).
Rodzina C (random entry, identyczne ryzyko) to kontrola losowa. Jeśli kiedykolwiek pokaże promote_eligible: true, oznacza to że bramki promocji są za słabe — system sam się demaskuje i loguje WARNING. To bezpiecznik na fałszywy edge, nie tylko na płynność.
Darwin = silnik selekcji. LLM = warstwa proponująca. Razem = autonomiczne R&D.
Darwin nie jest całością — jest deterministycznym silnikiem selekcji. Warstwa LLM (Satoshi) proponuje nowe rodziny strategii; Darwin je testuje na żywym rynku w sposób, który nie potrafi sam siebie oszukać. Każda warstwa robi to, w czym jest dobra.
Deterministyczny silnik selekcji
Bierze konfigi strategii, puszcza je na żywym rynku z honest-fill gate, statystycznie awansuje/zabija. Powtarzalny, audytowalny, bez halucynacji. 0 kodu LLM.
Warstwa proponująca hipotezy
Generuje nowe rodziny strategii i hipotezy o edge'u. Tu mieszka kreatywność i język — ale propozycja to nie wykonanie. LLM może rekomendować, nie wykonać.
Autonomiczne R&D
LLM proponuje → Darwin testuje na żywo → wynik wraca jako evidence → LLM proponuje lepiej. Samokorygująca pętla badawcza, w której rynek jest sędzią.
AI przyspiesza badania, żywe pieniądze = osobna decyzja Bartosza. Żadna warstwa — ani Darwin, ani LLM — nie dotyka kluczy API ani nie składa zleceń. Przejście paper → micro-live to osobna, jawna decyzja człowieka.