Sign in Subscribe

How a DeFi Builder Cut Indexing Time from Months to Days with SQD

mojo

• 6 min read

“SQD Changed My Life”: A Builder’s Story

When DeFi teams talk about “indexing issues,” they often mean “our dashboard is slow.”

Marc meant something uglier: production data falling behind reality - and users seeing the wrong state of the world.

Marc is a core builder at UNCX (formerly UniCrypt), a DeFi suite used by token communities and teams across multiple chains. UNCX runs products like:

  • Lockers across Uniswap v2 / v3 / v4 (locking LP positions to build trader confidence)
  • Vesting (with data that often needs to combine onchain assets with offchain context)

UNCX has had smart contract lockers deployed since 2020. It’s long-running production infrastructure where indexing isn’t “nice to have” - it’s the product.

A year ago, Marc migrated UNCX’s indexing backend away from The Graph + Goldsky and onto SQD (Subsquid).

And he didn’t mince words about why.

The breaking point: Uniswap v4’s “singleton” architecture + an event firehose

Marc’s most painful experience came when indexing Uniswap v4, which introduced a singleton-style architecture:

“Uniswap v4 has a new architecture called singleton. So every event is emitted from one contract…”

That design concentrates event volume in a way that punishes indexers that can’t keep up.

In Marc’s case, it turned his previous stack into a bottleneck that grew worse over time.

What happened with The Graph: subgraphs drifted into “one-week delay”

Marc was previously running subgraphs on The Graph and also relying on hosted providers (including Goldsky). It worked - until it didn’t.

After Uniswap v4 support went live:

“After two weeks… the subgraph was not sync… after one month… on the biggest chain… I got like one week delay.”

One week.

That meant users couldn’t see new pools or positions in time:

“If someone was creating a pool… I had to wait like some days to one week to see in their wallet the new position.”

Marc’s conclusion was blunt:

“It’s just not possible with The Graph to index… due to the massive events needed.”

If your app is powering traders and token communities, and your indexer is a week behind, you don’t have “indexing.” You have a liability.

What happened with Goldsky: infra instability + database pain + migration risk

The Graph wasn’t Marc’s only pain point. Goldsky was supposed to make hosted indexing easier - but his experience was the opposite.

Marc ran into repeated infra issues - including node sync problems and database constraints.

He describes recurring issues:

“Many issues… their nodes… sometime the node was not syncing… some issue with their database… architecture… not able to support all our entities or activities.”

And the killer moment: he tried a common optimization workflow (“grafting”) to speed up a new version - then watched it backfire:

“When I did this I lost… a lot of data sources… lot of data…”

That’s the nightmare scenario: you’re already behind, you try to upgrade, and the upgrade introduces risk you can’t fully control or audit.

So Marc did what serious builders do when infra becomes the constraint:

He replaced the entire stack.

The migration: UNCX moved its indexing backend to SQD

Marc migrated his full backend:

“I have migrated the whole indexer back end to Subsquid from the graph… since January 2025.”

The first big win wasn’t just speed. It was developer experience and architecture.

One GraphQL URL across 7 EVM chains

UNCX runs across 7 EVM chains. Marc’s ideal wasn’t “one subgraph per chain and juggle endpoints forever.” He wanted a cleaner data layer.

With SQD:

“I was able easily to provide one GraphQL URL to the front end for all the chain… six seven EVM chain… everything in the same database.”

Marc later summarized this plainly:

  • With SQD: one all-in-one GraphQL URL
  • With subgraphs: effectively one URL per network, more moving parts, more friction

This matters because once you scale multi-chain, endpoint sprawl becomes a tax on every feature and every incident.

The headline performance proof: months to days

Then comes the benchmark that basically ends the argument.

Marc’s Locker V2 indexer sync time changed from absurd to usable:

“Our locker… V2 went from two months on [Ethereum], three months on BSC to one day on [Ethereum] and some days on BSC.”
  • Ethereum: ~2 months to ~1 day
  • BSC: ~3 months to a few days

Marc’s reaction:

“For real… it’s incredible.”

That kind of reduction doesn’t just make a graph look nicer. It changes what you can build and how fast you can ship.

Speed isn’t vanity. Speed is iteration.

Marc kept coming back to one word: iterate.

With slow indexing, dev cycles become painful:

“Before I was… waiting… and waiting one week to identify the issue…”

With SQD:

“Now… few minutes later I can… identify the issue… try fix… iterate a lot.”

That’s how products evolve: tight feedback loops and fast recovery. If your indexer makes every change take a week to validate, you don’t refactor. You stop touching it.

Marc explicitly called this out:

“With the speed I can… make it cleaner… refactor more often…”

“Full pipeline control”: debugging stops being a guessing game

Another major shift: ownership and visibility.

Marc explains that with SQD he can validate his pipeline end-to-end:

“I can… check from A to Z… I have all on the data pipeline… I’m able to see every issue is from on my side…”

Contrast that with hosted/black-box infrastructure where “what’s wrong?” becomes a blame triangle between the chain, the provider, and your own code.

Building complete systems on top: alerts, automation, and onchain triggers

This is where SQD stops being “an indexer” and becomes an app foundation.

Marc loves that it’s a Node environment where he can pull in libraries, integrate tooling, and ship real workflows:

“I’m in a node environment… I can download some libraries… implement something…”

He gave production-style examples:

Real-time alerts (Telegram bots)

Marc built systems that watch for signals and send alerts:

“It’s very easy to create a telegram bot… get a message every time… I want to get an alert…”

He even shared a concrete example: a channel for real-time notifications of new tradable Uniswap v4 pools:

  • @UniswapListingsSqd (a side project that he later integrated into the official UNCX channel @Unicrypt_locks, which has ~2.5k subscribers)

And he describes the pattern clearly:

  • stream DB changes
  • trigger an action (Telegram message)

Triggering onchain transactions (automation)

Marc also built indexers that trigger onchain actions:

“I made some index that trigger onchain transaction for rebalancing.”

His hackathon project SigmaVault (Euler Finance bounty at ETHGlobal Cannes) used SQD specifically for this “index → trigger” automation pattern.

His summary is exactly what builders want to hear:

“With subsquid it’s way, way, way more easy than subgraph…”

SQD at UNCX: lockers, vesting, and combining onchain + offchain data

Marc shared more context on how SQD fits into UNCX’s product surface.

UNCX’s flagship services include:

  • Lockers (Uniswap v2 / v3 / v4) - powering exploration and monitoring across chains
  • Vesting - where it’s valuable to bind onchain assets with offchain company/project metadata

Marc calls out a key capability:

  • Easy to combine onchain and offchain data
    “Useful for binding off-chain company details to their on-chain assets.”

This is the kind of thing subgraph-first architectures often make painful—because you end up bolting additional systems around the indexer instead of treating the indexer as a composable backend.

A surprisingly powerful use case: technical support + debugging

One of the most interesting parts of Marc’s experience: he runs SQD indexers specifically for technical support.

Why not just use a scanner?

Marc’s answer is brutally practical:

  • if a contract isn’t verified, scanner data isn’t clear
  • scanners don’t provide the filters you actually need at scale
  • specifically: Etherscan advanced filters don’t let you filter by log arguments, and with thousands of logs you can’t isolate what matters

So instead:

“I filter on one wallet and I can retrieve all his activities…”

And:

“For support… finding the right data quickly… it’s better than the scanner… more accurate…”

That’s real operational leverage for a production DeFi service.

Support that actually supports: DZ + dev chat

Performance is nothing if you’re stranded.

Marc highlighted his experience with SQD support:

“I asked… why do I have to choose subsquid… directly DZ the co-founder answeredYou stop touching it. me… he was accessible…”

And ongoing:

“In the dev chat… many people are answering… when there is some issue about data… they are taking seriously what we are reporting…”

That’s what developers remember: fast and accurate responses.

“SQD changed my life.”

Marc said the quiet part out loud:

“It changed my life.”

That’s not marketing copy. That’s a builder describing what happens when infrastructure stops blocking the product.

UNCX went from:

Uniswap v4 indexing that drifted into one-week delays & hosted infra issues that introduced instability and risk to:

  • multi-chain indexing across 7 EVM chains
  • a cleaner DX with one GraphQL URL
  • sync times collapsing from months to days (or one day)
  • faster iteration, cleaner code, and more features shipped
  • and even new operational workflows (alerts, automation, support tooling)

If you’re building DeFi apps that need production-grade indexing at “millions of events” scale, Marc’s takeaway is simple:

“Everything that takes millions of events… I can do [it] with subsquid.”

Building something similar and have questions? Talk to the dev team on t.me/HydraDevs.

UNCX:

Hackathons: