Trigger-Only Architecture: Why Reaction Beats Prediction in MEV

The Day I Stopped Asking the Chain Questions

For a long stretch of this project, my bot has been a very polite kid in the back of a classroom, raising its hand every few milliseconds to ask the teacher, "anything new? anything new? anything new?" The teacher — a Solana RPC endpoint — has been answering the same question thousands of times a minute, mostly with a shrug. Most of those answers carry no new information at all. A handful carry information that is already stale by the time the bot finishes parsing the response.

This week I am finally drawing the line. The next iteration of the bot is being rebuilt around a single architectural rule: no computation happens until an event tells the bot that something has changed. No timers. No "check every N milliseconds." No best-effort guessing. The codebase is moving from a polling model to what the literature calls a trigger-only, or event-driven, architecture. And the more I read about how the top searchers on Solana actually operate, the more I am convinced this is not a stylistic preference — it is the only way the math works at all.

What Polling Actually Costs

Polling is comfortable. You set a loop, you pick an interval, you fetch state, you decide, you sleep. It feels deterministic. It also, when you watch it run in production, feels like sitting in cross-town traffic during rush hour — most of your time is spent stopped at intersections waiting for a green light that never changes.

The most cutting summary I have read on this comes from an infrastructure provider's Solana bot guide, which compresses the whole debate into a single sentence: "Polling causes bots to react to history, streamers react to the present." That phrase has been rattling around in my head for days because it nails what is actually wrong with the polling design: every poll response describes the chain as it was when the RPC node serialized the answer, not as it is right now. On a chain where a new slot lands every 400 milliseconds, "as it was" is a different state from "right now."

The resource math is just as ugly. A Substack analysis runs the numbers on an API that allows 5,000 calls per hour, like GitHub's — polling 100 endpoints every 30 seconds produces 12,000 calls per hour, blowing through the cap by 2.4×. The same piece walks through a Salesforce Enterprise example where ten tenants polling five endpoints on a 30-second interval generate 144,000 requests a day against a 100,000 cap. The lesson translates directly to MEV. A bot scanning fifty DEX pools at tight intervals is asking the chain the same question over and over and throwing away most of the answers. It is paying for bandwidth, for CPU on the parsing side, and — most importantly — for latency that buys nothing.

Meanwhile, the chain's clock keeps ticking. Solana's slot time is roughly 400 milliseconds, and slot leaders rotate every four slots, or about 1.6 seconds, according to a leading sniper bot guide's analysis of Solana slot timing . Inside that window, the practical decision budget for a competitive bot is single-digit milliseconds. A polling loop with even a 50-millisecond cadence is taking turns at a NASCAR race where the other cars have already lapped you twice.

What Trigger-Only Actually Means

The alternative is conceptually simple and operationally hard. Instead of the bot driving the conversation, the infrastructure pushes events to the bot the moment they happen, and the bot's main loop is idle until something interesting arrives. A common framing of the reactive loop has three steps: Listen, Decide, Send Transaction. The bot maintains a persistent subscription to on-chain events, evaluates each one for profitability, and submits atomically before the world changes again.

The deepest shift here is inversion of control. In the polling design, the bot is the driver and the chain is a database. In the trigger-only design, the chain is the driver and the bot is a callback. This sounds like a small distinction. In practice it changes everything about how the code is structured, how state is cached, how failures are recovered, and — most of all — what the bot is even trying to do.

A polling bot is implicitly making a prediction: "the state I just fetched is probably still true a few milliseconds from now, so I will decide based on it." A trigger-only bot makes no such prediction. It reacts to a confirmed state change. The distinction matters because prediction is exactly where bots get killed. Block ordering is non-deterministic from a searcher's seat — the validator or sequencer decides the final order, and any prediction the bot makes about block contents can be wrong by the time the block lands. Reaction, by contrast, only engages once the state change has actually been observed.

There is a clean illustration of this from cross-chain MEV research. A 2024–2025 analysis across Ethereum, Solana, Optimism, and Starknet points out that Starknet has no public mempool at all. The only viable strategy on that chain is atomic arbitrage that reacts to confirmed state changes; predictive sandwich attacks are structurally impossible. The summary line — "the structure of the underlying chain largely determines the behaviour of the bot" — is a tidy way of saying that on chains where prediction has no edge, the entire MEV ecosystem converges on reaction.

Why Milliseconds Are the Whole Game

If I had to point at one table that justifies the rebuild, it would be the latency-versus-capture chart from a leading MEV infrastructure guide . The shape of the curve is brutal:

P95 Latency	Arbitrage Capture Rate
Under 30ms	80–90%
30–100ms	50–70%
100–200ms	20–40%
Over 200ms	Below 10%

A bot living above 200ms of P95 latency is essentially playing the lottery. That same guide includes a case study that makes the cost concrete: one trading firm carried 400ms of node latency and lost 40% of potential arbitrage captures to it. After switching to faster infrastructure, profitable trades per 100 attempts rose from 60 to 85. The same writeup contains the line that keeps coming up in every latency discussion: "a 50ms delay can mean the difference between a profitable backrun and a missed opportunity."

The academic side reinforces this. Academic research on MEV latencies notes that in traditional high-frequency arbitrage, the modal race to capture an opportunity lasts 5 to 10 microseconds. Crypto MEV is not yet at that floor, but it is heading the same direction, and the report is unambiguous about what closes the gap: dedicated block delivery networks shave up to two seconds off standard propagation, and simulated caching alone produces a 33% latency reduction.

The production-grade Solana sniper targets cluster around the same envelope: detection-to-execution under 150ms, RPC response under 50ms (achieved by roughly 70% of production bots in one observed sample), full cycle under 200ms. Missing a single slot, that same source estimates, raises opportunity cost by 15 to 25%.

The pattern across all of these numbers is the same: at the timescales where MEV is actually decided, a polling architecture is not a slow version of a streaming architecture — it is a fundamentally different and inferior product. The decision window does not have room for a round-trip.

The Mechanics of "Push"

Once I accepted that polling is structurally hopeless, the question became: what does the push side actually look like? The picture I have assembled, mostly from a leading data streaming writeup and an infrastructure breakdown and , comes down to a comparison of methods that all sit on the same Solana validator but expose data with very different latency profiles:

Method	Approximate Latency	Where Data Comes From
HTTP polling (getBlock, getAccountInfo)	Round-trip plus serialization	Standard RPC layer
WebSocket (PubSub)	50–300ms	RPC layer, push channel
Validator-embedded gRPC stream (Geyser plugin)	Sub-50ms	Validator memory, before RPC serialization
LAN-local gRPC (co-located)	Sub-1ms	Validator memory, same data center

The interesting line in this table is the validator-embedded gRPC row. A Geyser plugin pattern embeds itself inside the validator process and intercepts account updates, slot changes, transaction data, and block notifications directly from validator memory — before the data is ever serialized through the standard RPC layer. One infrastructure write-up describes this as creating "a much shorter path between what happens on-chain and what your bot sees," and that is the right mental model. Each protocol has different characteristics — different delivery guarantees, different reconnection behavior, different filtering capabilities — and the choice between them depends on what the consuming code actually needs from the feed.

A crucial point I want to flag for anyone learning this from scratch: WebSocket is a full-duplex protocol built on a TCP connection that started life as an HTTP handshake. It is not a one-way pipe and it is not a lightweight notification channel; it is a bidirectional stream. The reason its latency is often higher than gRPC in MEV contexts is not that it is "one-directional" — it is that the data it carries has already passed through the RPC serialization layer. gRPC over HTTP/2, by contrast, supports native multiplexing and binary Protobuf framing, and when paired with a validator-embedded plugin, the data never enters the slower path in the first place.

There is one more accelerator worth naming because it specifically attacks trigger propagation latency, the first of the four latency segments identified in academic MEV research : shred-level streaming. Shred-streaming infrastructure can deliver raw transaction shreds 50 to 200 milliseconds before gossip propagation completes. That is a quarter of a second of advance notice on what is about to land — eternity in this game.

Where the Real Compute Savings Come From

One of the most under-appreciated arguments for trigger-only is not latency at all, but compute economy. The same MEV infrastructure guide includes a striking number on this: transaction simulation reduces a typical arbitrage workflow from 100 RPC calls to 36, and execution time from 5 seconds to under 1 second. The mechanism is straightforward — simulations only run when an event has signaled a potential opportunity, instead of being fired off on every poll cycle just in case.

The reference implementation in the open-source MEV bot repository makes the pattern very clear . AMM calculator objects are pre-loaded into memory at startup. When a streaming event arrives signaling an account change on a watched pool, the bot does not re-fetch state — it applies a delta update to the already-resident AMM object, recomputes the quote, and, if the quote crosses a profitability threshold, builds a bundle and submits. The hot path looks roughly like this in pseudocode:

subscribe(event_stream, [target_program_accounts])
  on_event(account_change):
    update_amm_state(change)        # delta only, not a full re-fetch
    quote = calculate_opportunity(amm_state)
    if quote.profitable:
      build_bundle()
      submit(bundle, tip=fraction_of_expected_profit)

The efficiency win here is not subtle. A polling bot has to fetch and parse every pool's state on every cycle and then compare it to a cached previous version to detect what changed. A trigger-only bot has the change handed to it, applies the delta, and skips the rest. Server-side filtering compounds the win: a validator-embedded gRPC subscription lets the bot ask for only specific programs, accounts, or transaction patterns, so irrelevant on-chain activity never reaches the bot's processing thread. That kind of filtering is structurally impossible with polling — a polling bot has to fetch the irrelevant data itself and throw it away.

In other words, trigger-only is not just faster; it is also cheaper in CPU, in network bandwidth, and in RPC budget. The bot does less work and gets a better result. That is the part that finally broke down the last of my resistance.

What the Top Bots Actually Look Like

Numbers help here, because they show what reaction-based design produces at the top of the market. A 30-day window analyzed from December 7, 2024 to January 5, 2025 captured the DeezNode sandwich bot executing 1.55 million sandwich transactions with an 88.9% success rate, generating 65,880 SOL of gross profit (about $13.43 million) and paying 22,760 SOL (about $4.63 million) in tips along the way — roughly 34.5% of profit back to the auction. That is per month, on one bot.

The cross-chain analysis profiles a second bot, E6Y, that captured about 42% of sandwich attack volume in a 30-day sample, with the top three bots collectively controlling roughly 60% of the Solana sandwich market. E6Y's 30-day numbers: $1.6 billion in trading volume, 57,400 SOL gross revenue, about 49,400 SOL net profit, in the neighborhood of $300K of daily take. None of these bots are sitting on a stopwatch loop asking the chain for new state every 50 milliseconds. They are wired into event streams and reacting on the trigger.

The aggregate 2024 numbers put the broader market in scale: more than 3 billion bundles processed, 3.75 million SOL paid in tips, 90.4 million successful arbitrage transactions at an average of $1.58 each, with a single most-profitable arbitrage of $3.7 million and a total annual arbitrage take of $142.8 million. One analysis pegs Solana's 2025 MEV revenue at roughly $720 million, and notes that Solana accounted for about 40% of all-chain MEV revenue in Q2 2025 — somewhere around $271 million in a single quarter. This is not a niche anymore. It is a multi-hundred-million-dollar market where the entry ticket is a working event-driven loop.

A HyperEVM case study rounds out the picture: a single team using event-driven WebSocket subscriptions for mempool monitoring generated $5 million in profit over 8 months on $12.5 billion in volume. Different chain, same architectural pattern.

The Trigger-Only Tax

There is no free lunch here. The same infrastructure analysis that lays out the gRPC latency advantage also lays out what I am starting to think of as the trigger-only tax: because every competent bot in this market has converged on the same reactive design, the differentiator is no longer "do you see the event quickly" but "how much of the captured value are you willing to give back to the auction." Arbitrage bots typically pay 50 to 60% of expected profit as bundle tips. DeezNode's roughly 34.5% sandwich tip ratio is on the low end because sandwich economics are different. On Ethereum, the cross-chain analysis estimates searchers pay more than 90% of gross revenue to proposers.

This is the part of the trigger-only world that I think gets underplayed in beginner write-ups. The architecture is necessary but not sufficient. Once you are reacting at sub-50ms latency, you are also entering a tip-efficiency competition where the question is no longer "can I see this opportunity" but "how thin a margin can I survive on." One analysis estimates only about 10% of sniper bots ever reach sustainable profitability, and manual traders capture under 5% of early-stage opportunities on Solana token launches. The reactive architecture is a precondition for being in the game; the survival rate inside the game is another problem entirely.

A March 2026 Medium piece summarizes the consequence cleanly : "The searchers who captured the majority of that value weren't running the most sophisticated strategies. They were running the best infrastructure." When strategy is commoditized — and it is, because everyone has read the same writeups I am reading — the differentiator is how quickly the bot receives and processes the triggering event. Trigger-only is the floor of competence, not the ceiling.

Reaction as Engineering Discipline

The more I sit with this, the more it feels like a discipline, not just a technique. Reactive systems force a kind of honesty on the developer. There is no place to hide a stale assumption. Either an event arrived and the bot acted on it, or no event arrived and the bot did nothing. The middle ground — "I think the state is probably still this, so I will act" — is exactly where polling bots quietly bleed money.

It also restructures how I think about failure. In a polling design, failure modes are usually about the loop being too slow or returning incorrect data. In a trigger-only design, the failure modes are different: missed events during reconnects, out-of-order delivery, backpressure when too many events arrive at once, and silent subscription drops where the bot stays alive but stops receiving anything. Each of these has to be designed for explicitly. A validator-embedded gRPC pattern typically provides a from_slot replay mechanism for exactly this — a way to recover missed events during a disconnect. That is the kind of primitive that does not exist in the polling world because polling has no concept of "missing" an event; it just refetches state on the next tick.

A reference framing of a complete reactive MEV system breaks it into four components : a mempool listener, a profitability calculator, a transaction builder, and a submission system. None of these run continuously. Each is invoked only when the prior step signals an actionable event. That is the architecture I am moving the bot toward — a chain of dormant components, each one waking up only when the previous one has produced something worth working on. It feels less like a program and more like a well-organized kitchen, where the line cook only starts the sauce when the order ticket lands, not on a timer.

What This Means for the Rebuild

The practical implication for the project right now is that the bot's main loop is going to disappear. The new design has no top-level scheduler at all. The whole system idles until an event arrives, at which point a callback chain runs the listen-decide-send pipeline as fast as the hardware allows. Polling code that exists today will be deleted, not refactored, because porting the wrong abstraction is worse than starting over.

There are real risks attached to this. Event-driven systems are harder to reason about than polling ones — concurrency, ordering, and backpressure all become first-class concerns. The debugging surface changes in ways I have not fully internalized yet. And the operational story for a trigger-only bot — what happens during a stream outage, how to detect a silent subscription failure, how to verify the bot is actually receiving the events it thinks it is receiving — is non-trivial.

But the alternative is being the kid in the back of the classroom raising my hand every few milliseconds, asking a question that almost always has the same answer, while the front row is already three steps ahead. The numbers from the latency studies, the MEV reports, the infrastructure breakdowns, and the cross-chain analyses all say the same thing: on a chain where the slot clock ticks every 400ms and the modal arbitrage race is measured in microseconds in adjacent markets, prediction is a losing trade. Reaction is the only design that survives contact with the actual market.

Key Takeaways

• Polling versus trigger-only is not a stylistic choice. On Solana's 400ms slot clock, a polling loop is structurally behind the market; a streaming subscription reacts to confirmed state changes in real time.
• The latency-versus-capture curve is brutal. Available data shows bots below 30ms P95 capture 80–90% of opportunities while bots above 200ms capture under 10% — the curve has no flat spot to hide in.
• Trigger-only is cheaper, not just faster. Pre-loaded state objects plus delta updates plus server-side filtering means the bot does less computation and uses less bandwidth than the equivalent polling design.
• The top bots all use this pattern. Published data on DeezNode, E6Y, and the top three sandwich operators show event-driven design at the heart of every production system worth studying.
• Architecture is the floor, not the ceiling. Once everyone has converged on reactive design, the competition moves to tip efficiency and infrastructure quality — but you do not get to play that game at all without trigger-only as your starting point.