u8

chart should be 'Updates per slot (for slots with a Market Tick)' not across all slots

Atomic Arb is not a substitute for good routing User lost 50.11 SOL to poor routing Mriya captured 40.1 SOL arb profit Even if 100% of that is rebated to the user (unlikely), they're still out 10 SOL If it turns out apps themselves profit from this, their incentives are misaligned with users. The worse the execution, the more the atomic arb profit.

upgraded our replay runtime (for recent epochs) to 4.4 and now replaying at 20-24 slots/s 2 epochs replaying concurrently on a 9275F

Ghost RouterEval is pretty good at spotting inefficiencies

Building a router, Part III We took past trades and replayed them through our router against the same onchain state they originally executed in. Compared that to what users actually got In this trade, better routing would have returned ~1,000 bps more, worth ~$600 to the user. As more trading moves onchain (incl tokenized securities), evals for execution quality become more important than ever: "what did I receive" vs "what could I have received" More on this in our talk at Scale or Die at BP2026

Spent a bit of time this morning looking into this Based on this initial examination, I believe at least 1 relay solver may be leaking private intent data to sandwichers Looking at the RH sandwich attacks conducted by these bots(*), every single sandwich contained at least 1 victim from Relay One interesting thing to note about this is that often the swaps have multiple pools they can route through and Relay solvers do a primitive (**) form of onchain routing where they swap multiple candidate routes, reverting each one, and then selecting the best one to run. So that means the attackers have to perturb the pool just enough that they can profit but not so much that the solver routes through another pool (*) Subset of bots where 100% of sandwiches have >=1 Relay victim (search period: last 6 days) 0x44c0ba0b734d4b7705fcd07ddae9fbbc078d74dd 0x38b3f8125bbbd45b56d0c3a535b90181d7dd3880 0x2a23c6d2522f07d230abf9c7a96d703520fd222b 0x18e0efe5be1cbb4e060c26f7f16f276be4dbc38c 0x9d61ad5c82586ae118af38e1cc68c8d1ad50771a (**) by primitive onchain routing, I don't mean it in a negative way, just that it's the simplest way

achieving 3,500,000 transactions/sec fetching + parsing Solana blocks on a single machine! using jetstreamer less than 3 minutes to parse all transactions in an epoch 75Gbps machine so there's more headroom, but start hitting upstream 429s if we fetch much more

upgraded our testnet node to agave for the alpenglow migration without our trusty franken/firedancer gui, I feel a bit like I would if I walked outside without my phone or keys

Horizon (jetstreamer-horizon) is super exciting stuff With it, anyone can easily run simulations against _historical_ Solana account states Looking forward to this!

Building a Router, Part II Quoting: direct quoting vs. simulations You can start with sims (ex: LiteSVM) but you'll quickly find it doesn't scale. Native quoting is 200-3000x faster What goes in to a quote? quote = f(input, pool state, clock, route, flow) Input: direction, input amount Pool state: reserves, ticks/bins, fees, curve params Clock: slot, timestamp, epoch Route: router/profile, hop position, route source/destination Flow: caller, accounts, surrounding instructions, route shape here's a table comparing direct quoting vs. simulation execution for some propAMMs and a subset of AMMs

We built a router. Not meant to compete with existing routers. We need it for our upcoming solana-wide execution quality scoring. More on that in a future post Supports 10+ propAMMs and many more AMMs Still early days and a bit hungry on the CUs