The new architecture of DEX data

Two years ago, building a DEX meant choosing an AMM and an indexer. Both took real evaluation. But the indexer was meant to be chosen once and forgotten. That's what doesn't hold anymore: the data layer has become a permanent constraint, and teams now spend real engineer-time fighting their data infrastructure instead of building on top of it.

Part of the pressure is churn in the hosting layer. The Graph retired its free hosted service in June 2024. Alchemy sunset its Subgraphs product in December 2025 and pointed users to Goldsky. Chainstack sunset its Subgraphs service in February 2026, migrating users to Ormi. Every rotation forces engineering teams into re-validation and partial rewrites across manifests, mappings, schemas and query layers.

Underneath the churn is a deeper shift. The legacy subgraph stack was built for a previous era of DeFi, where queries were periodic, chains were singular, and the consumer of the data was a human looking at a dashboard. DEXs are increasingly building for autonomous software instead. Agents execute, monitor and rebalance on sub-second loops, and the data they consume has to be real-time, multi-chain and accurate at trace level. The standard tools weren't built to deliver that.

So we asked teams directly. Four DEXs answered six operational questions: QuickSwap on Polygon, Hydrex on Base, Nest on HyperLiquid, and Blackhole on Avalanche. All four run live on Algebra's CLAMM engine. That was deliberate: a controlled sample of teams building on the same core AMM, making entirely different decisions about the data layer around it. When four teams sharing one engine end up in four different places, the variance is telling us something about the data layer itself.

The variance was enormous. One team runs two indexers in parallel on purpose. One refuses to use an indexer at all and reads the chain raw. One migrated its entire indexing codebase in three days by pointing AI at it. One runs the hybrid setup everyone runs, and they can explain why. There is no consensus stack.

What emerged wasn't a spectrum but four distinct camps. Same engine underneath, four different answers above it. Each is a working answer to the same question: how do you build a data stack you can trust for a DEX in 2026?

QuickSwap Multi-indexer by design Run more than one provider in parallel; treat the data layer as a portfolio. Read their answers ↓ Hydrex Pragmatic migrator Pick what works now, migrate cleanly, use AI to cut the cost of moving. Read their answers ↓ Nest RPC-only purist No third-party indexer; a custom listener reads and decodes the chain directly. Read their answers ↓ Blackhole Hybrid by necessity Indexer for aggregated queries, RPC for real-time and user-specific data. Read their answers ↓

There's overlap, particularly on AI, where all four converged on the same answer from very different stacks. But the dominant story is divergence: four teams, four chains, four philosophies.

03

QuickSwap

Five years of onchain history. Added SQD as a second indexer alongside their existing stack.

Multi-indexer by design Polygon

The philosophy is simple: don't depend on a single data provider. QuickSwap added SQD as a second indexer deliberately, describing the goal as "a fast, debuggable option that gets us a reliable setup quickly, without locking into a single provider." The intent was never replacement. It was redundancy plus a faster feedback loop.

The migration, in two phases

Phase one was free: a Firehose validation that ran their existing, unmodified subgraph against SQD through a graph-node sidecar. "Purely to benchmark sync speed and sanity-check data before committing. Zero code changes. Genuinely drop-in." Phase two was not free. A full native rewrite onto the Squid SDK and TypeORM, and that's where the real cost sat.

The vendor pitch for migration is "swap your endpoint, you're done." The reality, for a five-year DEX with real liquidity history, is years of accumulated edge-case handling that lives nowhere except the old code. The technical surface is solvable; the buried institutional knowledge is what makes it expensive.

What broke

Schema and data parity was the hard gate. The team validated the native Squid against their old subgraph at a reference block, checking pool count, factory TVL and volume, top pools, top tokens and bundle price, and got everything within roughly 1%. Closing that final percent is what surfaced the buried invariants. One operational surprise: a backfill sat stuck for around 24 hours with the archive returning "not ready to serve block X of dataset polygon-mainnet", resolved through SQD support but an external dependency the team couldn't debug in-house. GraphQL query shape was close to The Graph's but not identical, so downstream consumers needed small adjustments.

The cost in engineer-time

Roughly six to eight engineer-weeks. QuickSwap was clear the number is misleading without context:

The lesson generalises: budget for re-validation and ops, not engineering. Handler rewrites are the visible work; the parity hunt is the hidden work.

The hybrid stance

QuickSwap runs multi-provider on two layers. Inside SQD, the production variant is RPC-lean: the Squid pulls history from the archive but reads live state over RPC, so "indexer and RPC work together by design." At the provider level, SQD runs alongside their existing stack: SQD for speed and debuggability ("iteration in hours vs the multi-week feedback loops we had before"), the existing stack for cost. In their words, "it's resilience plus cost-efficiency, and not being locked to a single data layer." That combination of code-first indexing plus direct RPC is a common pattern; we cover the tradeoffs in RPC vs indexed data.

Where it still hurts

QuickSwap's main friction was timing. They onboarded during SQD's transition from its archive data layer to the Portal, its newer retrieval architecture, and committed to the older layer before the migration guidance was explicit. "The technology is genuinely ahead; the documentation lagging behind the platform's own transition is what cost us." Fair. Smaller pains: archive warm-up for old start blocks, and cloud resource sizing being trial-and-error.

On AI agents

At the application layer, "best product fit, worst exposure": real traction today in execution and analytics copilots, LP tools and support, but the layer sits against untrusted user input where prompt injection and jailbreaks remain trivial, so "constrained agents with hard guardrails and a human in the loop for anything that moves money." At the data layer, "where we feel the real pull. An agent is only as good as the data under it: clean, real-time, multi-chain. That's why we cared about this migration. Build on top of a platform, not from scratch." At the engine layer, the team credits Algebra's design directly:

That last phrase, plug-in not build, comes up again from the other teams.

04

Hydrex

Migrated from GhostGraph to Goldsky in three days, with AI doing the heavy lifting.

Pragmatic migrator Base

Hydrex's story is shorter. They're the archetype most mid-sized teams will recognise: pick what works now, migrate when something better emerges, use modern tooling to cut the cost of moving, and spend the saved time shipping product. Their recent migration was from GhostGraph, a niche indexer whose logic is written in Solidity, to a subgraph hosted on Goldsky. Different language, different paradigm, full codebase rewrite. The team did it in three days.

What broke? Almost nothing. GraphQL endpoints and syntax differed slightly, surfacing a few edge cases that were quickly resolved. Goldsky's indexing speed was meaningfully slower than GhostGraph's, a production tradeoff the team accepted as the cost of a more standard stack. On hybrid fallback, Hydrex is case-by-case: hybrid where redundancy and uptime matter most, single-provider where cost and convenience win.

Where it still hurts

Cost, specifically per-storage-hour pricing on historical data.

Mature DEXs accumulate years of history that gets queried rarely but can't be deleted, and per-storage-hour pricing punishes exactly that shape of data.

On AI agents

Hydrex gave us the line of the report: "I see agents as the UX bridge that crypto has been dreaming of for years, so mostly at the application layer." And the cleanest version of the argument every team ended up making:

Users might not know the optimal path, or even what they're doing; agents are useful precisely because user journeys are non-deterministic to begin with. Two layers, two completely different fits for the same technology.

05

Nest

No third-party indexer. A custom RPC listener. The contrarian in the room.

RPC-only purist HyperLiquid

Nest stands alone in this report. They've never used a third-party indexer. Their entire data stack is built directly on RPC: a custom listener polls the chain, pulls logs, decodes them against contract ABIs and persists the results. The chain itself is treated as the only authoritative source of truth. Of the four philosophies here, this one has the strongest underlying argument and the heaviest operational burden. Their reasoning:

An indexer that's wrong doesn't tell you it's wrong. An indexer is software interpreting onchain events according to a configuration; if it drifts, falls behind, or quietly changes behaviour, the consumer has no way to detect the problem without an independent reference. The chain is the only available reference. Nest's position: if the chain is the only thing you trust, consume it directly.

How they handle redundancy

The fallback for a failing RPC provider is a different RPC provider running the same listener code. "Same code, same approach, just a different node answering the calls." Redundancy at the provider level, not the architecture level. Recovery is layered: the listener re-scans block ranges on a schedule and periodically rolls its cursor back to re-read recent history, so a log missed on one cycle gets caught on a later one. When a user acts, the app notifies the backend with that transaction and the system decodes its events directly, giving user-driven activity an independent second path. Even if the listener misses an event in the moment, the data converges to correct.

Where it still hurts

The honest part of Nest's answer: RPC-only doesn't escape third-party dependency, it relocates it. The dependency moves to RPC providers, and the failure modes are real.

More interesting is that RPC providers aren't even consistent with each other:

Two "successful" responses to the same query, different answers, no error anywhere. Which is correct? The chain is, but verifying that costs engineering. And running your own listener means resilience is entirely on you: "a gap in polling, a missed range, or an unnoticed stall turns into missing data that we then have to detect and backfill ourselves." Database load during event spikes is its own concern. This is the failure mode indexers exist to absorb; we walk through it in RPC vs indexed data and HyperLiquid data for agents.

06

Blackhole

Indexer for complex queries, RPC for real-time. The most common architecture in DeFi, explained clearly.

Hybrid by necessity Avalanche

Blackhole's stack will be the most familiar to anyone running a DEX in production today. An indexer handles aggregated and historical data; RPC handles real-time and user-specific calls. What's interesting is how clearly they've articulated why.

Note "multi-week synchronization times." Every team in this report hit some version of that wall. Blackhole's hybrid is partly a sensible routing decision and partly a workaround for an indexer that can't re-sync fast enough to iterate against.

Where it still hurts

Blackhole listed five specific pains, more than any other team:

• Development and sync latency. New, complex UI data requires recoding and re-publishing the indexer. Full synchronization can take weeks, during which data availability is compromised.
• Performance optimisation. Post-sync, manual query indexing is required to prevent high latency. Without it, data goes stale and user experience suffers.
• Third-party dependency. Downtime in external infrastructure directly affects business continuity.
• Concurrency issues. Race conditions when events arrive out of sequence can crash indexing, hitting core operations.
• Rate limits. Scaling is constrained by API rate limits imposed by infrastructure providers.

Five different complaints, one root cause: an indexer designed for completeness being asked to do iteration. Everything downstream of that mismatch is friction.

On AI agents

Blackhole lands with QuickSwap and Hydrex: agents live at the application layer, the engine and protocol layers stay deterministic. But they're the only team that framed it as a P&L item:

The DEXs that make their pools agent-readable first will end up with more efficient capital than the ones that don't. On build versus plug-in, Blackhole runs an internal framework weighing proprietary edge against operational load for each integration, which is more discipline than most teams apply to the question.

Four teams, four chains, four philosophies. Where they converge anyway is the strongest signal in the report. Their pain points, mapped side by side, make the pattern visible:

Pain point QuickSwap QuickSwap Hydrex Hydrex Nest Nest Blackhole Blackhole n/4

• Sync and backfill time 4/4
• Third-party dependency 3/4
• Provider rate limits 2/4
• Cross-source consistency 2/4
• Ops fragility under load 2/4
• Cost of retaining history 1/4
• Migration docs and guidance 1/4

01AI agents belong at the application layer; the engine and protocol layers stay deterministic.

Three of the four teams answered the AI question independently and all landed on the same architecture. The application layer is where agents live: users already encounter non-deterministic outcomes there, statistical reasoning is useful, uncertainty is the default. The engine and protocol layers stay deterministic because the entire trust model of DeFi depends on it. "We don't need statistically likely processes here," as Hydrex put it, "it defeats the entire point of blockchain and consensus." It's the closest thing to industry consensus on AI architecture in DeFi today.

02Plug-in beats build for engine-layer AI.

Where AI does touch the engine, it arrives as an opt-in plugin, never as autonomous logic in the AMM core. QuickSwap was most explicit, citing Algebra Integral's per-pool plugin architecture as the right model. Blackhole formalises the build-versus-plug-in call per integration. Hydrex's deterministic-engine argument requires opt-in by definition. AI in the DEX engine is a slot architecture problem, and "core plus plugins" V4 designs like Algebra Integral are already positioned for it.

03Sync time is the universal bottleneck.

Every team flagged some version of it. QuickSwap's six to eight engineer-weeks were dominated by parity hunting. Blackhole's pain list opens with multi-week sync compromising data availability. Nest's RPC-only architecture exists partly to avoid the problem. Hydrex compressed migration to three days but still flagged Goldsky as "much slower than GhostGraph." Slow sync means slow shipping. Treat sync speed as a first-order criterion when evaluating a data layer, not a nice-to-have.

04The real risks are re-validation cost and single-vendor dependency.

Two quieter patterns run through every response. First, the hidden cost of any migration is proving the new system gives the same answers as the old one; the vendor pitch is "swap your endpoint," the reality is parity hunting. Second, nobody trusts a single data provider with their whole product anymore. QuickSwap hedges with two indexers, Nest self-hosts, Hydrex keeps its exit cheap, Blackhole names third-party dependency as systemic risk. The open question is which answer wins: multi-vendor resilience, self-hosted independence, or vendor architectures that earn deeper trust through decentralisation. We have a view. It's the next section.

This section is ours.

Read the four responses side by side and every pain named is a data-layer pain. Hydrex is paying per-storage-hour to retain history nobody queries. Blackhole loses weeks of shipping to re-syncs. Nest built and now operates an entire in-house pipeline because they couldn't verify that a third-party indexer was telling the truth. QuickSwap runs two providers because trusting one is no longer a defensible position.

We built SQD around the bet that these aren't four problems. They're one problem: the data layer everyone inherited was designed as a service you rent, when what a DEX actually needs is infrastructure it can verify.

Start with the trust point, because Nest is right. An indexer that's wrong doesn't tell you it's wrong. Our answer is structural rather than reputational: SQD is a decentralised network of 2,000+ worker nodes serving over 2 petabytes of data across 225+ chains, not a single company's database behind an API. No single operator to fall behind, no single provider whose quiet behaviour change becomes your silent data corruption. The trust question Nest solved by building their own pipeline is the question the network architecture exists to answer.

The sync problem is really a pricing problem. Re-indexing is slow when your provider has to replay the chain through shared infrastructure that was priced for dashboards. QuickSwap's numbers tell the story from our side: iteration in hours against the multi-week feedback loops of their previous stack, and a five-year Polygon backfill where the cost sat in validation, not waiting.

On Hydrex's storage bill: history that's expensive to hold is history priced wrong. Archival data on SQD lives in the network's storage layer, not in a per-storage-hour meter that punishes protocols for having a past. The archival tier Hydrex wishes existed is roughly a description of how the network already works.

And on the agents everyone in this report is planning for: an agent consuming pool state at machine speed needs exactly what a decentralised data network produces anyway. Real-time, trace-complete, consistent across chains, verifiable rather than vouched-for. We didn't design the network for agents. It just turns out that infrastructure built to be trusted by strangers is also infrastructure agents can act on.

Algebra's perspective on building the DEX engine for an AI-native era: the plugin architecture and the AI Kit.

If the operator view shows where DEX teams are heading, the engine layer is what makes that direction possible. This section is Algebra's, in their words. When we built Algebra Integral three years ago, the goal was a production-ready, upgradeable liquidity engine for DEXs. Three years later the conviction is stronger: the right place for AI in a DEX is in opt-in plugin slots, not the AMM core.

That conviction is baked into the product. Integral's per-pool plugin configuration lets fees, incentives and AI modules attach to a pool through a defined slot model, independent of the core swap logic. The AMM stays deterministic; the plugin layer is where everything else lives. When QuickSwap described this as "opt-in, sandboxed plugins with guardrails, never autonomous logic in a core where determinism and auditability are non-negotiable," they were describing the position we built the engine to enable.

The reason is simple. A DEX engine carries the trust burden of the entire stack above it. The moment any non-deterministic logic touches swap pricing or fee calculation, every assumption above it has to be re-examined, and no AI feature is worth that bill. But the engine can't stay frozen either. The answer is the slot model: a defined surface for plugins to attach, sandboxed behaviour, explicit configuration per pool. Each plugin is an opt-in decision by the DEX deploying the pool, and none of them can change what the core does.

The AI Kit

The AI Kit is Algebra's first explicit step toward agent-friendly DEX infrastructure: an agentic layer that exposes the primitives agents operate against, readable pool state, structured event data and programmable hooks, without requiring DEXs to rebuild their engine. According to Algebra, it lets teams bring agent-ready functionality into their products with an included MCP server, transaction guardrails, agent analytics, x402 micropayments, custom tools and support for agentic wallets, compatible with Claude, Cursor, Codex and any MCP client.

The pattern in the operator section, application-layer agents reading from a real-time multi-chain data layer, is the pattern the AI Kit supports from the engine side. Blackhole's framing that "by exposing our liquidity pools to these agents, they can analyze, simulate, and execute transactions" describes the same opening. The data layer makes the pools readable; the engine layer makes them addressable. If you want to see the data side of that pattern, the Portal MCP server exposes onchain data to any MCP client the same way.

Pull the four responses together and the next 18 months come into focus. The monolithic single-indexer era is over. None of these teams, including the ones that depend most heavily on indexers, will run a single provider as their only data source. QuickSwap runs multiple in parallel, Hydrex switches as conditions change, Blackhole runs hybrid, Nest refuses the layer entirely. The question a serious DEX team asks in 2026 isn't "which indexer is best" but "which combination of indexers, RPC providers and self-hosted components gives the right balance of speed, cost and resilience."

The AI-native DEX stack is forming in parallel, and the data layer determines what the rest can deliver. Across the security layer (Uniswap's adoption of Nethermind's AI-assisted auditing), the execution layer (Algebra's plugin architecture for agents) and the application layer (every team in this report converging on the same answer), the consistent constraint is the data underneath. Security agents can't monitor what they can't see. Execution agents can't act on stale state. Application agents can't reason about pool state delivered with seconds of lag.

Three things follow for any DEX team planning the next 18 months. First, treat the data layer as architecture, not procurement: the teams doing the best work stopped treating data infrastructure as a buy-once decision and started treating it as a continuous engineering surface with named ownership. Second, design the engine for plugins, not features: engines built to accept plugins from day one adopt AI features as plugins, while hard-coded logic faces a rewrite first. Third, choose a data layer agents can actually use: the standard data layer was built for human dashboards on five-to-thirty-second refresh cycles, and agents need real-time, multi-chain, trace-complete data with sub-second latency and no ambiguity about correctness. That's the layer SQD Portal exists to be: real-time onchain data across 225+ chains, queryable by humans through the SDKs and by agents through the Portal MCP server.

SQD and Algebra are building for this from the two sides of the stack we know best: the Portal on the data layer beneath, Integral and the AI Kit on the engine layer above. The DEXs in this report are building the part that matters most, the products on top. What their answers convinced us of is that the AI-native DEX isn't a 2028 conversation. It's happening now, unevenly, in production, and the teams in this report are further along than the public discourse suggests. For the wider picture of how these layers fit together, see the blockchain data stack in 2026, and for a direct comparison of the data-layer options named here, SQD vs The Graph, SQD vs Goldsky and SQD vs Chainstack.

This report was researched between 4 and 19 June 2026 through a structured set of six questions distributed via a shared working group hosted by Algebra. Four teams returned detailed responses: QuickSwap (Polygon), Hydrex (Base), Nest (HyperLiquid) and Blackhole (Avalanche), all running live on Algebra's CLAMM engine. All four chose to respond in writing. Each team reviewed the section quoting them before publication. Direct quotations are reproduced faithfully; punctuation is normalised to house style, and light editing for flow applies only to non-quoted material.

The report was co-authored by SQD and Algebra and is co-published on both organisations' channels. Particular thanks to the team at Algebra for hosting the research group and coordinating partner outreach, and to the engineering leads at the four contributing DEXs for answering like engineers rather than press offices. The report is only as good as their answers.