Eugen Soloviov
Trading-systems engineer
Trading-systems engineer building bots since 2017: cross-exchange arbitrage (connected up to 30 venues), cointegration-based pairs arbitrage across spot and futures, scalping, news and sentiment-driven strategies, trend algorithms, and portfolio management and balancing algorithms. Also builds sub-millisecond order execution, big-data warehouses, backtesting engines, AI agents, and trading interfaces (incl. open-source profitmaker.cc). Stack: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, architecture.
Articoli
Anatomia del MEV: sandwich, frontrunning e la foresta oscura della mempool
Ogni swap che invii a un RPC pubblico è un ordine a limite visibile che nessuno è obbligato a rispettare. Un'analisi tecnica di come funziona l'estrazione di MEV: ordinamento in mempool, la matematica del sandwich su Uniswap v2, PGA, Flashbots e le difese del trader.
Simulazione dei fill: la scala dal fantasy del close-price alla realtà queue-aware
Cinque gradini di fedeltà nella simulazione dei fill — dai fill al prezzo di chiusura ai modelli probabilistici di posizione in coda. I fill parziali come macchina a stati, i limiti di probabilità di fill come bracket di PnL, e un loop di calibrazione contro i fill live.
TWAP vs VWAP vs POV: scegliere un benchmark di esecuzione (e sapere quando ciascuno ti inganna)
TWAP, VWAP e POV sono scommesse su una previsione di volume. Sezioniamo le ipotesi nascoste di ogni scheduler, costruiamo curve di volume intraday per le cripto ed eseguiamo tutti e tre a confronto diretto su dati L2 riprodotti.
Almgren-Chriss senza fumo negli occhi: esecuzione ottimale implementabile in un pomeriggio
Derivazione completa del modello di esecuzione ottimale di Almgren-Chriss: impatto lineare, la traiettoria sinh/cosh, la frontiera efficiente e codice Python funzionante per calibrare eta, gamma e sigma da dati L2 e trade di Binance.
Il negativo onesto: decine di migliaia di backtest, cinque major, nessun edge robusto
Il culmine dell'arco narrativo su ricerca e overfitting, e si conclude con un risultato negativo — quello corretto. Una ricerca single-symbol dual-timeframe su ETHUSDT ha trovato una configurazione che valeva +16,35% out-of-sample e +2,62% su un holdout mai toccato; il Deflated Sharpe Ratio, tenendo conto di ~37.000 prove, l'ha sgonfiata a 0,00. Un passaggio cross-instrument su cinque major (ETH/BTC/SOL/BNB/XRP, ~1,18M di barre da 1m ciascuno), selezionando per mediana out-of-sample, la elimina definitivamente: dual DSR 0,24 / PBO 0,264, triple DSR 0,14 / PBO 0,327 — entrambi falliscono i gate. Il campione e profittevole su 1 di 5 simboli e negativo sugli altri. E' proprio a questo che serve l'apparato anti-overfit: a impedirti di spacciare il migliore del rumore per alpha.
Dimostrare l'assenza di look-ahead nei backtest multi-timeframe: perturbare il futuro per dimostrare che il passato non può vederlo
I backtest multi-timeframe fanno trapelare il futuro attraverso una barra di timeframe superiore ancora in formazione, la cui chiusura finale non esiste ancora. Non si può raggiungere la certezza con una semplice code review — bisogna testarlo. Riproduciamo esattamente la regola closed-bar del bot live, poi dimostriamo l'assenza di leakage con una probe a futuro perturbato: perturbiamo ogni barra futura e verifichiamo che ogni segnale e trade passato resti bitwise invariato. 25/25 controlli di parità superati, e la probe ha i denti.
Quando la GPU Ripaga: Il Roofline dello Sweep di Parametri, Dove un 167x da Titolo è in Realtà 27x di Algoritmo per 6.2x di Hardware
Il vantaggio della GPU sulla CPU cresce con la dimensione del batch — da 54.5x a un combo per chiamata fino a 359.6x a 61 sul nostro precompute di indicatori multi-timeframe — perché uno sweep piccolo non può ammortizzare l'overhead di lancio dei kernel e di trasferimento. Scomponiamo un 167x da titolo in una vittoria algoritmica di 27x che aiuta anche la CPU e una vittoria hardware di 6.2x, mostriamo che il vero vantaggio GPU-vs-migliore-CPU è solo 3.2x single-timeframe e 6.2x multi, e diamo una guida decisionale su quanto largo debba essere uno sweep prima che una GPU valga l'investimento.
La trappola della precisione GPU: come un backtest in fp32 su Apple Metal restituisce silenziosamente spazzatura
La GPU Metal di Apple non ha float64. Porta ingenuamente un backtest vettorizzato su di essa e la tentante WMA a somma prefissa manda in overflow l'fp32 — errore relativo massimo 211× — eppure gira comunque e restituisce numeri dall'aspetto plausibile. La soluzione non è più precisione; è una formulazione diversa: una convoluzione a finestra diretta, sicura in fp32 fino a 8×10⁻⁷ e 55,9× più veloce del numba a thread singolo. La trappola, l'aritmetica e come dimostrare di non esserci caduto.
Il Fidelity Gate: il Backtesting dal Grossolano al Fine Ti Inganna Più in Fretta a Meno che il Proxy Economico non Classifichi Come Quello Costoso
La ricerca drill-down / multi-fedeltà (ASHA, successive halving, Hyperband) filtra economicamente migliaia di configurazioni e promuove solo i sopravvissuti alla costosa valutazione completa. È un'accelerazione autentica — ma collassa silenziosamente se il ranking a bassa fedeltà non concorda con quello ad alta fedeltà. Abbiamo misurato la correlazione di rank tra fold: con un solo fold lo Spearman ρ può essere 0.03 (classifica quasi a caso), salendo a 0.43, 0.67, 0.78, 0.91 man mano che i fold si accumulano. La soluzione è un gate obbligatorio — misurare prima ρ(economico, completo) e alzare automaticamente la fedeltà minima al primo livello in cui ρ ≥ 0.5.
Ricerca casuale vs ricerca intelligente: il punto di incrocio è il costo di valutazione, non l'algoritmo
Quando un singolo backtest è economico, una sequenza Sobol scombinata e stupida vince in termini di puro throughput — i sampler "intelligenti" (TPE, CMA-ES, ASHA) pagano una tassa ask/tell in Python che li rallenta di 20 volte, facendo sì che valutino molti meno punti a parità di tempo reale trascorso, e perdono. Rendi ogni valutazione costosa (multi-TF + fold walk-forward) e il punto di incrocio si ribalta. Abbiamo misurato entrambi i regimi, e perché la fedeltà del rango tra fold (ρ@1 che sale da 0.03 a 0.43) è la precondizione perché il pruning ripaghi.
Lo spazio dei parametri a due assi: perché gran parte del tuo sweep dovrebbe essere quasi gratis
Non tutti i parametri costano allo stesso modo in fase di ricerca. I parametri di una strategia si dividono in un asse costoso (gli indicatori — ricalcolati sull'intera serie) e un asse economico (le soglie decisionali — una passata O(n) su segnali precalcolati). Poiché gli indicatori sono invarianti rispetto alle soglie, li calcoli una volta sola e scandagli migliaia di configurazioni di soglie a ~5,600 cfg/s — circa 1,600x più economico che ricalcolare a ogni configurazione. Una riprezzatura della maledizione della dimensionalità.
La tassa del framework: quando la tua libreria di backtest è più lenta di un ingenuo ciclo pandas
Abbiamo messo a confronto otto motori di backtest su un'unica identica ricerca di parametri — 150k barre, 80 combinazioni di incrocio HMA, parità del conteggio operazioni bloccata a 2707. Due dei framework event-driven più popolari sono risultati più lenti di un ciclo pandas scritto a mano, mentre un motore vettorizzato/compilato ha eseguito lo stesso lavoro ~13,000× più velocemente. Uno studio sull'overhead per barra che le librerie popolari non sono mai state costruite per ammortizzare.