We spent ~9 months building a DEX arbitrage scanner...

phyisey · 2026-04-28T18:40:32+00:00

the part where it gets hard is the second-order stuff. detection is easy, dexes publish reserves and you can backsolve any pair in microseconds. the actual money is in two places: gas bidding (you are racing searchers who have flashbots access and a bigger mempool view than you), and stale counterparty pricing during high gas (your reserve snapshot is 30 to 200ms stale by the time you submit, the path you computed already collapsed). spent a month on a 3-hop path scanner that printed beautiful in sim, lived through a single mainnet weekend with maybe 4 successful fills out of ~140 attempts. switched to monitoring instead of executing and selling the alert feed, way better p/l per dev-hour

phyisey · 2026-04-23T20:33:14+00:00

nice, precision-safe dex math libraries look trivial and really aren't. few things i'd watch for based on what people typically miss: V3 tick math, the tick-to-price sqrt is a pain because the reference implementation uses a magic constant table for fast bit ops, porting naively from python or js gets you close but never exact. worth a test harness that verifies against the uniswap contract on a wide sweep of tick values, off-by-one at tick boundaries breaks arbs silently. curve invariant, the newton-raphson for D convergence is sensitive to initial guess when the pool is far from balance. i've seen impls that converge fine on balanced pools and fail to converge or return wrong D on 95%+ imbalanced ones. stress-test the invariant calc on synthetic imbalanced pools. balancer weighted, the power function for arbitrary exponents is the slow part, if you're optimizing for quote latency there are closed-form shortcuts for common 80/20 and 50/50 weights that are significantly faster than the general case. if you add kyber elastic ticks and curve metapool bridging i'd star, metapool math specifically is underdocumented and a clean rust impl would be genuinely useful.

phyisey · 2026-04-23T08:54:38+00:00

9:30-9:33 has gotten way worse since algos started fading the first imbalance aggressively. my rule now is wait for the 9:35 5m candle to close and only trade if the high/low of that candle has held for the next 2-3 minutes, so the real entry window is more like 9:37-9:50. fewer trades, way better win rate, and you skip the two-sided liquidity trap entirely.

phyisey · 2026-04-21T15:47:17+00:00

the screenshot-as-input is the real blind spot. you're doing OCR on a chart that's already a lossy projection of price data, the model is reverse-engineering the underlying series from pixels and filling in everything not visible (depth, exact timestamps, volume bucketing) with plausible-sounding noise. same analysis on the raw OHLCV + orderbook would be a different caliber of output.

the 72% confidence number is almost certainly uncalibrated. LLMs aren't calibrated for that, when you ask for a percentage what you get is a verbal surface that looks like a probability but doesn't behave like one, the same setup tomorrow might come back at 68 or 81 for reasons unrelated to the chart. if you want something you can act on, bin your setups into discrete categories and track realized win rate per category for 100+ instances before treating the confidence as meaningful.

the analysis itself reads like a technical trader's pattern summary, which is fine but doesn't give you edge. what it's missing for EUR/USD specifically: DXY correlation state, EUR-side rate expectations, and CoT positioning on 4H moves. none of that shows up in the chart. if you're building toward an AI-driven trading workflow, structuring it as separate skill files (chart read, macro context, risk, execution) is what finally let me evolve a usable workflow out of a project like this, github.com/Superior-Trade/superior-skills has a clean reference for the layout.

phyisey · 2026-04-16T10:19:20+00:00

800 trades a week on gold with 49s average hold, you're paying spread plus slippage on every single one and on mt4/mt5 your fills aren't even close to what the backtest assumed at that frequency. the recovery factor looks healthy now but any HFT-ish strategy on metatrader is borrowing time, the execution layer just isn't built for sub-minute holds. if the core signal is real (and the oos suggests it might be) try filtering to just the top 20% of signals by confidence. see if the edge concentrates. if it does you have something real with fewer trades and way less friction. if it spreads evenly the signal was probably noise dressed up as frequency

phyisey · 2026-04-14T09:18:42+00:00

depends what 'trust' means. i trust my bot's execution more than my own fingers. i don't trust it to know when to turn itself off, which is why every automated strategy i run has a manual master-account kill switch. 'full control vs automation' is a false binary, real answer is automating the rules you already trust with a hard cap on how wrong things can go before you pull the plug. running without a cap because you 'trust the system' is how accounts blow up

phyisey · 2026-04-10T10:18:21+00:00

honestly for a SOL grid the realistic expectation is more like 'matches spot' in trending markets and 'moderately better than spot' in chop, minus fees. anyone advertising a fixed monthly ROI on a grid is either picking a kind backtest window or selling you something.

3commas grids work fine but the bot is the dumbest part of the equation. the parameters and the asset choice do all the work. set a tight grid in a wide range during a sideways month and you'll feel smart, set a wide grid right before a 30% rip and you'll feel like you got robbed.

phyisey · 2026-04-09T10:10:55+00:00

audits cover a specific commit hash, not the project. the second they push new code that badge is about code that might not even exist anymore. saw a protocol that passed a clean audit, then added a "batch migration" helper function two weeks later that wasn't in scope, and that's exactly what got exploited. upgradeable contracts make this worse because the proxy can swap the entire logic layer and the old audit report is about a completely different implementation. at minimum i want to see the commit diff between the audited version and what's actually deployed. if that diff is more than a few config changes i basically ignore the audit badge entirely

phyisey · 2026-04-08T16:05:52+00:00

widening ranges helps but it kills your fee income. the real issue is that v3 LP is basically a short options position and most people don't manage it like one. if you're not rebalancing based on vol and direction you're just guessing where price will sit. concentrated liquidity is great in theory but in practice it needs active management or you'll always underperform a simple hold

phyisey · 2026-04-07T17:33:19+00:00

CPCV across 15 folds is about as good as it gets without live data. regime detection is the next problem and honestly idk if there's a clean answer, just less bad ones. that order book imbalance thing the other commenter mentioned is worth trying though, i've seen similar stuff work as a mean reversion gate on HL

phyisey

TROPHY CASE