DEV Community: Abhay Nayak

Who's really behind a meme coin? We built a graph agent to find out

Abhay Nayak — Sun, 18 Oct 2026 14:08:10 +0000

By team QuantBase, for WeMakeDevs × FalkorDB Graph Hacks, October 2026

Every coin leaves a trail. The trick is knowing which threads to follow.

Watch the 2-minute story first:

A new coin, an unfamiliar creator

A new coin appears in your feed. People are buying it. You can see a name and a price, but you have no idea who made it. Before putting money in, you'd like to know who you're dealing with.

Meme coins are joke tokens anyone can launch in a minute. On pump.fun, the site where most of them launch, you can start by checking the creator's wallet, an account address. Funding a wallet means sending it the few cents it needs to launch. Follow that payment and you might find other creators the same payer funded.

We built Sniff during Graph Hacks to follow those connections. To a graph, this is a fraud-ring problem: accounts that look unrelated can share a payer. A shared payment is a lead to inspect, not proof of fraud or common ownership. You don't need to trade these coins to recognise the database problem.

Day 1: we loaded the graph, then connected too much

We started with a snapshot from our QuantBase collector, which existed before the event. It ends on 14 October 2026 at 18:45 UTC. First we had to remove other launch sites and old tokens that someone had reported as new. One established coin had a fake September launch date. It didn't belong in a launch history.

We kept 632,339 coins, 424,007 wallets and about 1.5 million links. FalkorDB's bulk loader took 30 seconds to load them. The graph used 521 MB of memory.

The lineage graph. Five kinds of thing, five kinds of link. The questions that had been painful in SQL became one Cypher pattern each.

Our first query followed the path we'd been trying to untangle with SQL joins: coin, creator, payer, other creators paid by that payer. In Cypher, FalkorDB's graph query language, we could write that path as one pattern.

Then we tried connecting random coins. Our first version kept finding paths within four hops. We'd built an excellent way to discover exchanges.

An exchange, a service where people buy and sell cryptocurrency, sends withdrawals from shared accounts. Those accounts appear as funders in our data. One had paid 33,747 wallets. Walking through it made strangers look like collaborators.

We labelled wallets that funded more than 200 others hubs. There were 89. We removed their incoming funding links and stopped queries from walking through them. You can see that a payment came from an exchange-like wallet; you can't use it as a bridge to thousands of other creators.

Day 1's biggest lesson. A hub is a bridge to nowhere, so we turned it into a wall.

We tried distinguishing exchanges from groups launching lots of coins by the share of funded wallets that became creators. Our funding data covered creators' funders, so even the biggest hub showed 80% creators. We'd selected the answer with our sample. We kept the 200-wallet rule and documented the limit.

With hubs excluded, algo.WCC, the connected-components procedure, found 6,556 rings: groups joined by funding and coin creation, with at least two creators. Of 3,900 multi-creator groups our collector had found by other means, 3,824 fell inside a single graph ring. That gave us a check against an existing method.

Day 2: we made Claude cite its sources

We asked Claude to explain a coin's history. Then we had to decide how much of its answer we could let through.

We gave it nine tools for looking up coins, following payments and finding shared connections, including early buyers and social accounts. Each runs fixed, read-only Cypher. Claude chooses tools and writes prose; it never writes the database query. It gets up to eight model/tool rounds, with several calls allowed in a round.

The tools return evidence IDs, labels such as E1 and E2 that identify the nodes and links behind a result. Every factual sentence must cite evidence of the matching kind. The server rejects sentences that don't. Explicit server-owned context and refusal text are exceptions.

An invented ID gets removed. So does a citation from the wrong tool: a payment result cannot support a claim about a reused social account. A sentence covering both topics needs both kinds of evidence. After those checks, the server deletes factual sentences with no valid citation and adds its own computed context line.

This checks sourcing, not truth. A made-up launch count can pass if Claude attaches a valid coin-lookup ID. The checker doesn't establish that a number matches the result or that the sentence names the right subject. You still need to inspect the evidence.

The model chooses the tools and the words. The checker enforces citation IDs and matching evidence kinds; the map lets you inspect the evidence.

Without an AI key, or if the call fails, server templates produce a fixed summary from the same tools.

That evening we tried a coin called METHU. Its creator had launched one coin. We followed the payment to that creator and found that the payer had funded 71 other creators. Each had launched one coin. Across those 72 coins, none had "graduated": raised enough to move to a real trading pool, a rare outcome in our data. That's what we found in our snapshot, which ends on 14 October 2026 at 18:45 UTC.

Looking at METHU's creator alone, we'd have missed the other 71. We wanted someone reading that answer to be able to check the same path.

We prepared 30 evaluation questions, including six requiring refusal or "no evidence". The scripted run passed all 30; it tested the plumbing, not Claude's judgement. We tried 10 questions on the live site. All ten answers used the expected tools, valid citations and no trading advice. Only five stayed within five sentences. We added a five-sentence cap, plus the closing line.

Day 3: tap E4 and follow the payment yourself

Paste a coin into Sniff and you see the investigation steps arrive: checking who made it, who paid them, who else that payer funded. On Day 3 we put a map beside the answer.

Tap E4 and the map dims the other nodes, leaving the wallets and coins behind that evidence highlighted. You can follow the connection yourself without reading a query result table.

METHU, with evidence E4 selected: one payer, 71 other creators, 0 graduations. (Wallet addresses blurred for this post.)

Exchange-like wallets have dashed outlines where trails stop. The coin card reads the graph without AI, and the interface works on a phone. We expose the nine investigation tools over MCP, a protocol agents use to call tools. Connect your own client with:

claude mcp add --transport http sniff https://sniff.quantbase.live/mcp

Day 4: memory, and a company brain

Ask a follow-up about the same coin and we shouldn't have to start from scratch. On the last day, we added two FalkorDB graphs: saved investigations in memory, and QuantBase's public documents in brain.

On /memory, you can see four METHU findings. Follow-ups reuse recent results from the same session. Other agents can read findings across sessions through MCP and add observations. Each finding keeps its source tool and timestamp. Agent names are self-declared, and notes remain unverified.

For the company brain, we loaded 12 public documents. Ask "How does QuantBase handle paper vs live?" on /brain, then open a [B#] citation to read the source section. Paper trading means trying a strategy with play money; live trading uses real money. We combine graph lookup with full-text search. Today's source-only graph connects documents, sections and named products or policies; it contains no extracted relationships between entities. Reloading changed sources retires old sections. Our graph documentation covers the privacy checks and the optional richer builder.

Day 4 architecture: the live brain uses MENTIONS/PART_OF; SUPPORTS in this illustration is an optional AI-builder capability. Agent notes are attributed observations, labelled "agent note · not verified".

Then we tested whether the graph could predict anything

We took 23,408 graduated coins and tried predicting how they did afterwards. We run trading research on this data too, and needed to know whether these connections helped.

We used only information available at graduation: the payer's other creators, payments two steps back, reused social accounts and shared early buyers. We trained on older coins and tested on the newest third.

In isolation, we found associations. Coins reusing a social account from another creator's coin were 18 percentage points less likely to be alive an hour later.

Then we included the first minutes of trading. In this test, the graph added no measurable predictive value. The change in AUC, a measure of how well the model ranks outcomes, stayed within ±0.01. We couldn't turn the connections we'd found into a demonstrated improvement over those early trading signals.

Sniff can light up where a coin came from. It can't see through the fog ahead, and it doesn't pretend to.

That result set the boundary for Sniff. We describe recorded history and show the evidence. We don't recommend buying or selling, label coins "safe" or "scam", or promise a return. Answers close with history, not a prediction.

METHU's 72 connected launches remain worth examining. You can check their history without treating it as a forecast for the next coin.

What we liked in FalkorDB, and where we tripped

Changing the hub rule meant rebuilding the graph. With a 30-second bulk load, we could afford to try again. That was our favourite part of working with FalkorDB 6.0.2.

We used range indexes for node keys and a full-text index for coin names and symbols. algo.WCC found the rings in 2.9 seconds. For connections between two things, we used algo.SPpaths, filtering out hubs and social handles shared across platform-sized groups. GRAPH.RO_QUERY kept investigation queries read-only, with per-query timeouts.

We also lost time following documentation that didn't match our running server. Procedure names varied between pages. On 6.0.2, the names included algo.WCC, algo.BFS, algo.pageRank, algo.labelPropagation and algo.SPpaths. We checked them with CALL dbms.procedures().

The documented db.idx.fulltext.createNodeIndex('Coin','name','symbol') failed. CREATE FULLTEXT INDEX FOR (c:Coin) ON (c.name, c.symbol) worked. WITH projections needed AS aliases. Query timeouts couldn't exceed the server's TIMEOUT_MAX, 15 seconds by default. sum() returned floats, so we cast counts to integers.

And some coin names were a backslash. The bulk loader uses that as its default escape character, so we had to pass -x none. Of course a database import for joke coins would break on a joke-sized name.

We'd love a generated procedure reference per version, full-text docs that lead with the working CREATE syntax, and a loader warning for lone escape characters. Those changes would have saved us time. The fast rebuilds let us keep experimenting through the rough edges.

Where this goes next

Open METHU, select a citation, then visit memory. You can follow a finding from a payment through to something another agent can reuse.

We're building this research into QuantBase, where users can try trading strategies with play money. The demo is live at sniff.quantbase.live; the homepage still describes the dashboard integration as in development.

From a pixel dog to a product

The day before the event began, sniff.quantbase.live was a coming-soon page with one thing on it: a small animated pixel dog, sniffing a coin, on a 3.2-second loop.

Four days later, you can follow a payer across 72 launches, check the agent's sources on a map and carry findings into another session. We also have a prediction test that gave us a reason to narrow our claims. We're taking that work into QuantBase, with the dog still out front.

From a pixel dog on a coming-soon page to a product. History, not a prediction.

Try it

Paste METHU's address into the app, or choose its example, and follow the payer:

App: sniff.quantbase.live. Try the METHU example.
Your own agent: claude mcp add --transport http sniff https://sniff.quantbase.live/mcp
QuantBase: quantbase.live
Code: github.com/avasis-ai/quant-agent

Built in four days by team QuantBase, on FalkorDB, Claude and a lot of pump.fun history. Nothing here is financial advice.

Who is behind this meme coin? Building Sniff on a graph

Abhay Nayak — Sat, 17 Oct 2026 11:28:24 +0000

By team Quant Agent, for WeMakeDevs × FalkorDB Graph Hacks, October 2026

More than ten thousand meme coins launch on pump.fun every day. Almost all of them die within hours. When a new one shows up on your screen, the question people actually ask isn't "will it go up?", because nobody can answer that honestly. It's simpler: who made this, and what happened to the last things they made?

That question is hard to answer by hand. The wallet that launched the coin is usually brand new. The real trail runs through whoever paid that wallet to launch it, and through whoever else that payer has paid. That takes two or three hops of "who sent money to whom", across hundreds of thousands of wallets.

So we built Sniff: paste a coin, and an AI agent walks a graph of on-chain history and answers in a few plain sentences. Every sentence links to the exact part of the graph that proves it.

Try it: https://sniff.quantbase.live

Why a graph

We already had the raw material. Our QuantBase collector records public pump.fun data: launches, the wallet behind each one, who funded those wallets, the wallets that bought in the first seconds, and the social links each coin lists. Before the event it lived in Postgres tables, and every question we asked of it turned into a tower of self-joins.

The questions are all shaped like paths:

Who paid the creator? → Who else did that wallet pay? → What did they launch? → Did any of it graduate?
Do these two coins share a funder, an early buyer, or a Twitter account?
Which wallets form one connected group of launchers?

In FalkorDB each of these is a single Cypher pattern. We loaded 632,339 pump.fun launches, 424,007 wallets and about 1.5 million relationships (CREATED, FUNDED, SNIPED, LINKS) with the bulk loader in 30 seconds. The questions that had been painful became one-liners. Rings of connected launchers come from algo.WCC, and "how are these two connected?" comes from algo.SPpaths.

Surprise 1: hubs make everything link to everything

The first version of the graph said every coin was connected to every other coin within four hops, which is true and useless. The reason was exchanges. When a creator withdraws SOL from an exchange, the exchange's hot wallet shows up as their "funder", and that one wallet funds tens of thousands of creators.

We call these wallets hubs: any wallet that funded more than 200 others. There were 89 of them. They get their own label, keep a note of how many wallets they funded, and no query is allowed to walk through them. A funding trail that reaches a hub stops there and says "this came from an exchange-like wallet, which tells us nothing about who is behind it."

We tried to be cleverer and tell exchanges apart from big launch farms by what share of their wallets went on to create coins. It didn't work, because our funding data only covers wallets that created coins. The biggest hub funded 33,747 wallets and 80% of them were creators, simply because those were the only wallets we had looked up. So we kept the simple rule, wrote down why, and moved on.

Surprise 2: the docs and the database disagreed

FalkorDB 6.0.2 was a pleasure to work with, but a few things in the docs didn't match the running server. Here's what we hit, so you don't have to:

Procedure names: they differ between pages. On 6.0.2 they are algo.WCC, algo.BFS, algo.pageRank, algo.labelPropagation and algo.SPpaths. CALL dbms.procedures() is the source of truth; check it first.
Full-text index: the three-argument db.idx.fulltext.createNodeIndex('Coin','name','symbol') from the docs is refused. CREATE FULLTEXT INDEX FOR (c:Coin) ON (c.name, c.symbol) works.
WITH: projections need an AS alias.
Timeouts: a query timeout can't go above the server's TIMEOUT_MAX (15 s by default).
Bulk loader: its default escape character is a backslash, and meme coins are sometimes literally named \. Pass -x none and let your CSV writer double quotes instead.

None of these took long once we knew, and they're all written down in the repo.

Surprise 3: one payer, 72 creators, zero graduations

The first time the whole thing ran end to end, we asked about a coin called METHU. Its creator wallet had launched exactly one coin, which on its own looks like a first-time creator. One hop back told a different story.

The wallet that paid METHU's creator, 0.009 SOL, had paid 71 other brand-new wallets. Each launched exactly one coin. None of the 72 coins graduated. In the graph it's one funder with 72 spokes, each ending in a dead coin.

That's the whole idea of Sniff in one picture. The creator alone looks clean; the payer is the story. And you can only see it if the data is shaped like the question.

An agent whose citations are checked

The agent is Claude with nine tools, each a fixed, read-only Cypher query: coin lookup, funding trail, sibling creators, shared early buyers, shared socials, rings, shortest connection, top operators, and search. Claude decides which tools to call, up to eight, and writes the answer. It never writes Cypher itself.

Every tool result carries evidence ids: E1, E2 and so on. The answer has to end each sentence with the id that proves it. Then we check:

A cited id has to be one a tool really returned.
It has to come from a tool that can show that kind of claim. A sentence about reused socials can't cite the funding tool.
A sentence left with no valid citation is deleted. A shorter answer beats an unsupported one.

In the app, tapping a citation lights up exactly those wallets and coins on the map. If there's no AI key, or the AI call fails, the same tools produce a fixed summary instead, so the facts never depend on the model.

We scored it on 30 questions, including six it should refuse ("will this pump?", "is it safe?", made-up addresses). On the live site all 10 questions we spent real calls on picked the right tools, cited valid evidence and stayed within the no-advice rule. What failed was length: half the answers ran past five sentences, so answers are now capped at five.

The honest part: it explains, it doesn't predict

We also run trading research on the same data, so we asked the uncomfortable question: do these graph signals help predict which coins do well after graduating?

We built the features strictly as they would have been known at the moment each coin graduated: how many other creators the funder paid, two-hop funding, reused socials, shared early buyers. Then we tested them on 23,408 graduated coins, training on the older ones and testing on the newest third.

On their own, the signals mean something. Coins whose social account had been used on another creator's coin were 18 points less likely to still be alive an hour later. But once you add what anyone can already see in a coin's first couple of minutes of trading, the graph adds nothing measurable: the change in predictive accuracy was within ±0.01. Whatever the graph knows has already shown up in the price.

So Sniff doesn't say "safe" or "scam", and it never says buy or sell. It tells you who is behind a coin and what their other coins did, with receipts, and ends every answer with the same line: history, not a prediction. We think that's the honest version of this product, and the useful one.

Try it

App: https://sniff.quantbase.live (try the METHU example).
Your own agent: claude mcp add --transport http sniff https://sniff.quantbase.live/mcp
Code: https://github.com/avasis-ai/quant-agent

Built in four days on FalkorDB, Claude and a lot of pump.fun history.