AI Research for MEV Devs: From Academic Papers to Code

The Pile of Things I Don't Know

When I sit down to keep building this MEV bot, I confront a list of things I need to understand that would have intimidated me a year ago. Concentrated liquidity math. The instruction layout of a dozen different DEX programs. Validator scheduling. Tip-priority competition on Jito. The exact byte layout of a versioned transaction. What changed in SPL Token-2022 versus the original SPL Token.

None of this lives in one book. Some of it isn't in any book — it's spread across academic papers, GitHub issues, scattered protocol docs, and the occasional X thread by someone who's been running a bot for two years. I'm a solo developer trying to compete in an arena where some of my competitors have venture funding and dedicated research teams.

So research has become the work, not a prelude to the work. And like the code itself, the research has changed shape now that I have AI assistants in the loop.

Why I Stopped Treating AI as an Oracle

When people talk about "using AI for research," they usually mean asking a chatbot a question and reading what comes back. That's the worst version of AI-assisted research, and it's the one most likely to send you down a hallucinated rabbit hole.

The way I've come to use AI in research is closer to how a small newsroom uses a research librarian, a fact-checker, and a study partner — three different roles, three different tools, three different prompts. None of them get my full trust by default. Every claim gets verified before it influences code.

The cost of getting this wrong is real. According to Suprmind.ai's 2026 hallucination benchmark, AI hallucinations caused $67.4 billion in global business losses in 2024 alone, and 47% of business executives admit to making major decisions based on unverified AI content. In academic settings the failure mode is even more direct: an INRA.AI study found that ChatGPT-3.5 fabricated 39.6-55% of citations in literature reviews — papers that simply did not exist, with plausible-sounding authors and journals.

So I've built a workflow. It's not perfect, but it's the one that actually keeps me shipping code instead of chasing ghost papers.

Stage One — Finding What Exists

The first job is discovery. When I needed to understand cyclic arbitrage routing in automated market makers, or how concentrated liquidity protocols handle tick crossings, I needed to know what serious people had already written on the topic. That's where tools designed specifically for academic discovery come in.

Two stand out for this stage: Elicit and Semantic Scholar.

Elicit, according to its official site, indexes more than 138 million academic papers plus 545,000 clinical trials, with semantic search that doesn't require knowing the exact technical keywords. That last point matters more than it sounds. When you're new to a field, the right keywords are exactly what you don't have. I can describe a problem in plain English — "how do automated market makers handle slippage in pools with very low liquidity" — and Elicit returns relevant papers ranked by citation count and recency, with extraction tables I can build to compare them side by side.

According to a Jotform review by Juliet John, SciSpace can generate a comprehensive literature review in roughly ten minutes for fields like climate science. For someone like me, reading across constant-product AMMs, concentrated liquidity protocols, orderbook DEXes, and bin-based liquidity systems, that compression of effort is the difference between writing code this week and writing code next month.

For really fast, free, no-frills lookup I use Semantic Scholar. It indexes more than 200 million papers, gives you TLDR summaries, and exports clean BibTeX. Its hallucination-to-verification ratio is 0.18 per the AtlasWorkspace benchmark — higher than dedicated tools, but still in the "risk-managed with verification" zone, and the citations it produces are real because it's surfacing real papers, not generating prose about them.

The lesson from this stage: discovery tools that return papers are different from chat tools that return prose. Always start with the former. Use the latter only for synthesis after I've read the actual sources.

Stage Two — The Hallucination Problem

This is the part that took me longest to internalize.

Early on, I'd ask a general-purpose chatbot something like "what are the canonical papers on MEV in Solana" and treat the answer as a reading list. Most of those papers didn't exist. Some had real authors but wrong titles. Some had wrong authors. Some cited journals that don't publish that field. Every time I followed up by searching the actual paper, I'd find that maybe one out of five was real.

The data backs up this experience, and the magnitude is grim. The Columbia Journalism Review citation accuracy benchmark found that on citation-specific tasks, even the best tool tested — Perplexity Sonar Pro — hallucinated 37% of citations. ChatGPT hit 67%. Gemini reached 76.7%. Grok-3 was at 94% — almost every citation it produced for a research query was fabricated.

A story from outside crypto makes the stakes vivid. In July 2025, per INRA.AI's compilation, a federal judge ordered two attorneys representing the MyPillow CEO to pay $3,000 each after they submitted a court filing containing "more than two dozen errors and non-existent case citations." As of mid-2025, more than 206 court cases had documented sanctions for AI-hallucinated citations. By April 2026 that number had climbed past 1,200 globally, with a single attorney facing a $109,700 penalty per Suprmind's compilation.

Even peer review hasn't caught it. According to Suprmind's report, at least 53 NeurIPS 2025 papers contained AI-hallucinated citations that passed peer review — out of 4,841 accepted papers, more than 100 confirmed ghost references made it through.

For me, as a developer, the practical translation is simple: never trust a citation I haven't personally clicked through to. Never quote a "study showed" claim that I haven't sourced. Never act on a code suggestion until I've read the actual API documentation for the function being called.

This sounds obvious until you're tired and the AI gives you a perfectly-formatted paragraph with three plausible footnotes. That's when you slip. That's when MIT's January 2025 finding becomes uncomfortable: AI models use more confident language when hallucinating than when stating facts. The most authoritative-sounding paragraph is the one most likely to be wrong.

Stage Three — Source-Grounded Reading

Once I have a real paper in front of me, the next problem is reading it efficiently without losing rigor. AMM math papers, in particular, often spend ten pages defining notation before getting to the result I care about. I want to ask questions of the paper without paraphrasing it through a model that might add its own assumptions.

This is where NotebookLM earns its spot. The defining characteristic, per Google's documentation, is that NotebookLM operates only within the boundaries of the sources you upload. It does not generate answers from general training data. If a fact isn't in the documents you provided, NotebookLM either says so or doesn't include it — at least in theory, and in my experience the rate of out-of-document fabrication is dramatically lower than open-domain chat tools.

The practical workflow is: I drop in three to five papers on a topic — say, concentrated liquidity tick crossing, or constant-product DEX swap accounting — plus the relevant protocol documentation. Then I ask questions. "What's the difference in how these papers handle fee accumulation?" "Show me where the slippage tolerance is enforced in protocol X." Because the answers are grounded in the actual uploaded documents, I can verify by reading the cited section. The audio overviews and slide decks are nice for revisiting later, but it's the source grounding that matters.

This is the closest thing I have to a "reading partner" that doesn't lie to me. It still misreads things sometimes — long PDFs with mathematical notation are hard for any model — but the failure mode is "missed nuance," not "invented citation."

Stage Four — Cross-Model Verification

Even with source-grounded tools, I run anything important past more than one model. This isn't paranoia; it's empirical practice, and the Suprmind 2026 report found something striking: across 1,324 multi-model conversations with 299 users over 45 days, 99.1% of turns produced contradictions, corrections, or unique insights when the same question was sent to different models. Each model contradicted the others at a high rate — Gemini's high-confidence answers were contradicted by another model 51.4% of the time, with the lowest contradiction rate, Claude's, still hitting 26.4%.

The practical implication: a single model's confident answer is closer to a hypothesis than a fact. If two or three different models converge on the same answer, my confidence rises. If they disagree, I know where to dig in.

For long technical documents — DEX whitepapers, multi-section RFCs — I lean on Claude. According to a DataStudios comparison, Claude's context window allows uploading entire dissertations in a single shot, while some other tools "chunk" large documents and risk missing connections between distant sections. Lower citation hallucination rate, fewer split-section errors, better synthesis on long inputs — that's why it's my default for "summarize this whole protocol spec."

For current events and recent commits, I use Perplexity. It's the best at fact-finding with real-time web access. The same Suprmind report notes that web search access reduces hallucination rates by 73-86% across major models. GPT-5, for example, went from 47% hallucination without browsing to 9.6% with browsing — an 80% reduction. When I'm checking whether a DEX has shipped a new program version since my last check, Perplexity gets the first ask.

Stage Five — Knowledge Cutoff, the Silent Killer

This one cost me a week early in the project.

I was reading what I thought was current guidance on Solana versioned transactions. The model spoke confidently about limitations and workarounds. I built around them. Two days in, I discovered that the limitations had been lifted months earlier — the model's training data simply ended before the change.

The phenomenon is called the knowledge cutoff, and it's the single most underestimated risk in AI-assisted technical work. According to LLMPulse.ai, models "generally do not volunteer information about their uncertainty regarding post-cutoff technologies." They don't say "I don't know because my training ended in October 2024." They just confidently describe the world as it was on their cutoff date.

The fields most affected are exactly the fields I work in: rapidly changing technology, evolving APIs, new protocol launches. A blockchain protocol may have shipped three major upgrades since the model's data ended, and the model will discuss it as if no upgrades happened.

My defense is the same defense Hashmeta recommends for content teams: always verify factual claims against current sources. For Solana, that means the actual program source, the actual on-chain account inspection, the actual recent transactions — never the model's recollection of what those things looked like as of the training cutoff. AI gives me hypotheses about how something works; the chain gives me ground truth.

Stage Six — From Papers to Code

Reading is one thing. Writing the code is another. AI assistance in actual implementation is where the productivity gains are clearest — and where the new failure modes are most subtle.

The numbers on adoption are striking. CloudInsight's compilation cites a GitHub survey finding that engineers using AI-assisted development in 2025 produced 55% more code than those who didn't. The Stack Overflow Developer Survey reports that 84% of developers are now actively using or planning to adopt AI coding tools. And in early 2026, over 51% of code committed to GitHub was either generated or substantially assisted by AI.

I'm part of that 84%. My implementation workflow leans heavily on AI coding tools for boilerplate, scaffolding, and the bridge between "I understand this paper" and "I have working code." But the specific places I trust AI in code — and the places I don't — have crystallized over time.

Where AI helps: writing the deserialization for a documented account layout once I've confirmed the layout from the program source. Generating test fixtures. Translating math from a paper into a first-pass function I can then optimize. Boilerplate around well-documented standards. Drafting comments and documentation, which per the Google Cloud DORA 2025 report is now where 64% of developers use AI.

Where AI hurts: anywhere precision matters and the model's training data is stale or thin. Solana-specific instruction encoding for newer DEXes. Anything where the documentation is sparse and the model has to "fill in." Performance-critical hot paths where the model picks the convenient idiom rather than the fast one. Security-relevant code, where one quietly hallucinated parameter destroys you.

For coding tasks specifically, the Suprmind domain-specific data is sobering: coding and programming tasks show a top-model hallucination rate of 5.2% and an average of 17.8%. That's roughly one in five "facts" wrong on average — not acceptable for anything I'm going to deploy with my own money on the line.

Stage Seven — API Docs and the Trust Hierarchy

For API documentation, I've settled into a hierarchy of trust.

Tier one — read the source. When a DEX's program is open source, the source is the only authoritative documentation. Names, struct layouts, instruction discriminators — these are what they are in the code, regardless of what any documentation or AI summary says.

Tier two — read the official docs. If the team publishes documentation, that's the next-best source, with the caveat that documentation drifts. I've found docs out of date by months on more than one occasion.

Tier three — read the AI summary. Useful for orientation, terrible for facts. I use it to know which file to open and which struct to look at — never as the final word on what a field means.

This ordering matters more in MEV than in almost any other domain, because the difference between a bot that runs and a bot that mis-decodes one byte is the difference between earning a small tip and burning fees on every transaction.

What This Means for Solo Developers

The bigger picture, the one that keeps me from getting discouraged: AI research tools have flattened the slope for solo developers in exactly the domains where institutional researchers used to have an insurmountable advantage. I can now process literature, compare protocol whitepapers, and synthesize findings at a pace that would have required a team a few years ago.

But the same tools have introduced a new kind of fragility. Anyone who uses them without a verification ritual will publish hallucinated facts, ship hallucinated code, and trust hallucinated citations. The PhD candidate who discovered 12 of 45 citations in one dissertation chapter were fabricated lost six months to revisions. The MyPillow attorneys lost $3,000 each plus their professional reputation. The 53 NeurIPS papers with ghost citations lost a kind of credibility that's harder to recover.

In a bot context the analog is direct: a hallucinated parameter in your swap encoding is a transaction that fails on every run. A hallucinated assumption about validator scheduling is missed blocks. A hallucinated description of how a DEX handles a special token type is a sequence of failed transactions, each costing real SOL.

The tools are leverage. The verification ritual is what keeps the leverage from cutting backward.

Key Takeaways

• Use discovery tools for discovery. Elicit (138M+ papers), Semantic Scholar (200M+), and SciSpace (~10-minute literature reviews) return real papers — they don't generate prose about papers. That distinction matters enormously.

• Treat citations as untrusted until verified. Even the best AI tool on citation accuracy still fabricates 37% of references, per the Columbia Journalism Review benchmark surfaced by Suprmind. Click every DOI. Search every paper title. No exceptions.

• Use source-grounded tools for deep reading. NotebookLM operates only within uploaded documents, dramatically lowering the chance of out-of-document fabrication. This is the closest thing to a reading partner that doesn't hallucinate.

• Cross-check across multiple models. Suprmind's data shows 99.1% of multi-model conversation turns produce contradictions across models. Single-model confidence is closer to a hypothesis than a fact.

• Mind the knowledge cutoff. AI tools don't volunteer their uncertainty about post-training-date facts. For fast-changing fields, real-time tools with web search reduce hallucination rates by 73-86% on tested models.

• AI helps in coding but not without verification. Coding tasks show a top-model hallucination rate of 5.2% and an average of 17.8% per Suprmind's domain benchmark. AI is leverage for boilerplate and scaffolding; the source code is the only authoritative API documentation.

The research has become the work. The AI tools are how I keep up. The verification is how I stay honest about what I actually know versus what I think I know. The bot doesn't care about either; it only cares about whether the byte in field seven matches what the DEX program is going to read. The verification ritual is what bridges the gap.