The Buyers Were Funded Before the Token Existed

At 10:09:31 UTC on 26 July, six Solana wallets received the first transaction of their lives. Same slot, 435312803. Most of them in the same transaction.

Forty-three slots later, about seventeen seconds, the wallet that paid them paid one more: J6FAJ2Pz2htqoKUD1WLZJC9RTsRuF9oQYo8RxS3s6dnH. At 10:12:12 that wallet created a token called United States Water Reserve, ticker USWR. The six wallets bought it.

They kept buying. Over the following days those same six accounts bought twenty different mints across three supposedly unrelated deployers. Every one of those mints belonged to the same invented catalogue: United States Oil Exchange, United States Uranium Reserve, Vanguard Oil Retirement Fund, Transnational Oil Supply, Seized Asset Custody Fund. Tokens dressed as sovereign commodity reserves, sold to nobody, because the only buyers were paid for by the seller.

Rugburn had scanned none of it. Not one of the 22 wallets carried a label, a deployer edge, a cluster membership or a single scan. The engine had been looking at this operation for two weeks and had nothing to say about it.

What the chain showed

The catalogue is the first thing that gives it away. Across 30 days those 22 wallets created 85 mints, and the names repeat in a pattern that copycatting does not produce.

USWR appears under six different deployer wallets across nineteen mints. USOH appears under six wallets across ten. USOX, USUR and TNOS each appear under four. On their own those numbers mean little, because a ticker that catches will be cloned fifty times within the hour on pump.fun.

The detail that rules cloning out is what individual wallets did. 3iM6FfJi shipped USWR, USOH, USOX, TNOS and NTFS. DrZhh8Uz shipped seven distinct members of the family. A copycat chases the one ticker that is moving. Someone working through a product line ships the catalogue.

The relaunch cadence says the same thing. J6FAJ2Pz fired USWR ten times between 10:12 and 15:54 on a single afternoon. DrZhh8Uz fired RISE eight times across 2 August. Relaunch the brand until one catches, let the winner run, extract.

The money is not trivial. Across the group the average peak liquidity in a rugged pool runs from $18,000 to $110,781. The spam factories that dominate pump.fun sit near $4,000 and never take a cent from anyone, because nobody ever buys. This is a different animal.

Why nothing flagged it

Two separate failures, and neither of them looked like a failure from the inside.

The first was attribution. Rugburn lists a deployer's tokens through Helius DAS getAssetsByCreator, which resolves the metadata creator. For all 22 of these wallets it returns a total of zero. As a control, three known pump.fun spam factories return ten out of ten on the same call. Every one of the 22 launched on pump.fun, confirmed against pump_evt_createevent, so this is not a venue gap. It is a metadata attribution split, and the effect is that the product returned a clean empty list for exactly the operators worth looking at. An empty list and an absent answer render identically.

The second failure was clustering, and it is the one worth the post.

Rugburn resolves who funded a wallet by walking to its first inbound transfer and reading the source. Run against these 22, three levels deep, sixty-six hops: twenty-two distinct funders at level one, twenty-two at level two, twenty-two at level three. One collision in the entire graph. By that measure these are twenty-two unrelated people who happen to like the same fake government tickers.

That result is wrong, and the way it is wrong is instructive. Twenty-two wallets with zero funder overlap is not what independent users look like. Independent users collide constantly, because they withdraw from the same handful of exchange hot wallets. Zero collisions across sixty-six hops is not a property of a crowd. It is a property of generated chains.

Transaction 5MH1joF6GwM7AM8rxL7UujoRhqKS2P84qaNPbpa89CxUUS7n6YHyUtHvB5Aguu96avqD4GLhXg3SGb72Rug7GWDW, slot 434968741, shows the shape. One fee payer, 6yD19aNx, twelve instructions, and inside them five pairs:

Roughly 265 SOL, near $48,000 at the time, into five wallets through five intermediaries that exist for the length of one transaction and are never used again. The hop is atomic. It happens inside the same signature as the payment it is hiding.

So when the walk asks "who funded this wallet", the honest answer it gets back is a throwaway. Each throwaway is unique to its recipient. Grouping by funder address therefore reports no relationship between wallets that were paid by the same person in the same instruction list. The engine was not failing to find the link. It was reading a field the operator had made meaningless, and reporting the absence as a finding.

Defeating it cost one extra instruction per recipient.

What we changed

Group by the transaction, not the address.

resolveFunder had been returning the funding signature the whole time. Both callers discarded it with an underscore. The fix keeps it and uses it as the grouping key, falling back to the address when no signature is available.

Measured on the six wallets in the cold open: grouping by address gives six groups of one. Grouping by transaction gives one group of five and one of one. The bundling rule needs five to trip, so the same evidence that was silent now fires.

That mattered because the rule feeds the score, and the score was in trouble. Of 24 tokens the drain oracle has confirmed rugged, only ten were scanned before the rug happened. The other fourteen were scanned afterwards, when the confirmed-drain cap had already forced the score to 10, so they measure nothing. On the ten genuine predictions, five said Medium Risk. A structurally clean pump.fun launch scores 71 in our engine. The same launch with five buyers traced to one funding source now scores 35.

The verification was cross-source. The same transaction was pulled from Helius and from public Solana RPC: slot, fee payer, instruction count and error status match exactly.

The limits

The single-actor claim does not survive its own evidence, and I am not going to make it.

Three separate root purses fund these groups, not one: EAY8a66z, 6yD19aNx and D4AomtcU. Twenty of the twenty-two wallets share no common ancestor within three hops. One brand chain is proven, the USWR chain in the cold open, where the same wallet paid the buyers and the seller seventeen seconds apart.

Three readings fit everything else.

A. One operator, three funding trees. B. Three operators running the same playbook. C. A launch service selling the playbook to customers.

evidence	A	B	C
shared naming catalogue	fits	fits	fits
shared buyers across deployers	fits	weak	fits
no shared ancestor across the purses	fits	fits	fits
one purse paid buyers and deployer 17s apart	that chain only	that chain only	fits

Nothing in that table separates A from C. The catalogue and the funding shape are the two things that feel strongest in this investigation, and neither one discriminates between the readings at all. A shared invented product line is exactly what a service would ship to its customers, and exactly what one operator would ship alone.

I am spelling that out because the alternative is to let the volume of evidence stand in for its diagnostic value. There is a lot of evidence here. Most of it is consistent with all three answers, which means it is not evidence about this question.

The scoring fix has a narrower reach than it sounds. The behaviour indexer that produces these counts currently runs on roughly four percent of scans, from a queue rather than inline. A correct signal that reaches almost no tokens is still almost no coverage, and that gap is the real ceiling right now, not the detection logic.

The ten-token prediction set is small. It is the entire population of tokens we scored before a confirmed drain, so it is the honest denominator, but ten is ten and the next twenty will move the number.

And the attribution hole is open. getAssetsByCreator still returns zero for these wallets, so the deployer page still shows an empty catalogue for the operators who take the most money.

Update, 16 August 2026

Three things have changed since this went up. I am adding them rather than editing the numbers above, because a post that quietly rewrites its own evidence is worth less than one that shows its working.

The cold open is now verified against a second source, and it is bigger than six wallets. Everything above came from Helius. I re-ran the root purse against Dune's Solana tables, which index the chain independently, and the fan-out is not one transaction. Between slots 435312789 and 435312798, a window of four seconds on 26 July, EAY8a66z signed 48 transactions. Every single one paid exactly five recipients, with one sender each time. Four of them moved roughly 450 SOL apiece, near $80,000, and the rest were 0.5 SOL provisioning transfers. Same signer throughout.

Five recipients per transaction, forty-eight times, inside four seconds. That is not a person funding friends. It is a machine provisioning a buyer population, and it was sitting in public the entire time.

The clustering fix now renders. Grouping by transaction was the engine change described above; the graph could not draw it, because the read only ever returned edges touching the wallet you were looking at. The wallets paid alongside it in the same transaction, which is the entire signal, were excluded by the query rather than absent from the chain. That is fixed. The funding atlas on the deployer page now shows this purse as four bundles of five, each one clickable through to the transaction that paid them.

The purses do not converge, and what sits behind them is more interesting than if they had. The first follow-up below asked whether EAY8a66z, 6yD19aNx and D4AomtcU share an ancestor. Two of the three now have an answer.

6yD19aNx was funded on 24 July at 17:00:11, with 4,302.893 SOL, by 5tzFkiKscXHK5ZXCGbXZxdw7gTjjD1mBwuoFbhUvuAi9. That address is Binance. It holds over 800,000 SOL and signs continuously, and its public exchange tags are on any explorer.

EAY8a66z was funded on 26 July at 10:03:51, with 4,291.516 SOL, by 4zpckgKw13zXKWZqpQuRRPFHJHqDeGFD38D6WwaaSFJq. That one is not an exchange. It was alive for a single day. It accumulated across 619 transactions between 04:53 and 10:03, forwarded its entire balance to EAY8a66z in one transfer, and was never used again. Its peak balance and the amount it forwarded match to six decimal places, because they are the same event.

It is also, on its own explorer page, tagged a Pump.fun token creator. So the wallet that financed the purse is not some neutral waypoint the money passed through. It creates tokens itself.

I wrote a stronger sentence there first, and it does not hold. I called it another launcher in the same catalogue, which the tag does not establish. The tag says this address has created at least one pump.fun token. It does not say which one, and the catalogue is a claim about names. Our own cohort table contains every catalogue deployer named in this post and does not contain this address, but that table only counts wallets with two or more creations inside the window, so it cannot rule out a single launch either. Settling it takes one query against pump.fun create events filtered to this creator, which I have not run. What is solid is narrower and still unusual: the wallet that financed a six-minute purse was a token creator that lived for one day.

So no shared ancestor at one hop, and the two branches do not even have the same shape. One terminates at an exchange. The other passes through a wallet built to hold money for five hours.

That absence is not evidence for reading B. This operator provably hides address links: the relay trick in "Why nothing flagged it" costs one extra instruction per recipient and defeats funder clustering outright. Someone who does that to their buyers would also split their funding roots. Three purses that do not converge is what reading A predicts as much as reading B, so finding them separate moves nothing.

Two things are worth sitting with. The first is that the amounts are 4,302.893 and 4,291.516, sixteen SOL apart, two days apart, roughly $780,000 each. Two purses provisioned to within 0.4 percent of the same size is not proof of anything, and it is the most suggestive number in this investigation. The second is that EAY8a66z existed for six minutes: first funded at 10:03:51, last active at 10:09:49, 54 transactions in between, and inside that window it paid out the buyers for a token that did not exist yet.

Walking 4zpckgKw back one more step turns up the thing I did not expect. It did not receive its 4,291 SOL from one place. It collected across 288 inbound transactions over five hours and then emptied itself in a single transfer. One of the wallets that paid into it is BhkYbdKD7ibdhC22XVVd528PuY9ZXrH24hB9ADyDjwf3, and that address is also on the receiving end of the fan-out five and a half minutes later, taking 86.481 SOL from EAY8a66z.

The same wallet is on both sides of the treasury.

Its SOL history explains part of what it is. On 24 July it received 439.554 SOL at 19:44:32 and sent 439.654 out at 19:46:07, leaving exactly zero. It did that again at 20:34, again at 03:19 the next morning, again at 04:47, 18:35, 20:11, and on through the 26th. Every time: money arrives, everything leaves inside two or three minutes, the balance returns to zero. It never holds SOL between operations.

I want to be precise about what that does and does not show, because my first draft of this paragraph overreached. This wallet is not a pure relay. It holds tokens today, and a wallet that trades is not simply a pipe. What is true is narrower and still damning: it never retains the SOL it is handed, it paid into the collector that funded the purse, and it was paid back out of that purse five and a half minutes later. Both sides of the treasury.

There is a second thing on its balance sheet, and I am deliberately not going to draw the conclusion it invites. Right now it holds 0.1 SOL and 449,020 WOFL. So does 2ZmPNi13UUfmRzBNg22cmGYbh1e8SQNRuChcg47Xvyho, the largest single contributor to that same collector at 929.9 SOL. Identical token, identical amount, identical SOL balance.

The obvious reading is that both were provisioned by one script. The boring reading is that WOFL is a dust airdrop and both wallets are two of ten thousand recipients who never asked for it, which would make the match worth nothing at all. Those two produce the same screenshot. Telling them apart takes one number I have not measured: how many wallets hold exactly that balance. If it is two, it is a fingerprint. If it is thousands, it is spam and I was pattern matching on noise.

I am leaving it in, unresolved and labelled, because the alternative is to publish the half that flatters the investigation.

What is not in doubt is that these wallets are active. Both moved within the last hour of writing, receiving SOL from two common signers minutes apart and selling into an AMM. Some of that co-occurrence is certainly junk: they also both appear in a single dust transfer from a gambling-spam domain, which links them to each other exactly as much as it links them to every other wallet that transfer touched, which is to say not at all. The parallel structure of the rest, same signers, same minutes, matched small amounts, is harder to explain away. The catalogue stopped being interesting in July. The wallets did not stop.

The Binance branch is also the clearest possible argument for a rule we now enforce. If you cluster wallets by shared ancestor without excluding exchanges, and both purses had come from Binance, you would have "proven" one operator. What you would actually have proven is that two people used the same exchange. Any link that runs through a CEX, a bridge or a launchpad program is not evidence of common control, and treating it as such manufactures findings out of infrastructure.

Two numbers above are stale, in opposite directions. The drain oracle has confirmed 31 rugs now, not 24, so the prediction split in "What we changed" is measured against a smaller population than the one that exists today. And the behaviour indexer no longer runs from a queue at four percent of scans: it runs inline on every scan source. The coverage ceiling turned out not to be the queue at all. It is that only nine to twenty-three unique tokens are scanned per day, of which four to fifteen clear the liquidity floor. Fixing the plumbing revealed that the real constraint was demand, which is a less satisfying answer and the true one.

The follow-up, because this is not finished

Four things are unresolved, in the order I intend to take them.

Finish the purse walk. Partly answered in the update above, and the answer moved the question rather than closing it. 6yD19aNx terminates at Binance in one hop. EAY8a66z does not terminate at all: it runs through a single-day pass-through wallet that needs walking further. D4AomtcU has not been tested. The single-actor claim is still unproven, but it is now unproven for a specific reason at a specific address, which is the difference between an open question and a vague one.

Test the co-buyer overlap across all 22, not the eight I sampled. Twenty-five wallets were found buying across two or more deployers, in three groups of exactly six with matching purchase footprints. That was a sample. The full pass either finds one buyer population behind the whole catalogue, or it finds three, and that answers the same question as the funding walk from the other end.

Follow the extracted SOL. This is the one that separates the three readings, which is why it moved to the top of the list in everything but order. Everything so far traces money going in, and the inflows are compartmentalised by design: that is what the relay trick is for. Outflows have to land somewhere. If they converge where the inflows do not, reading A holds and B is finished. If they scatter to three destinations that never touch, B and C survive and A does not. Nobody has looked.

Establish whether 85 mints is the whole catalogue. The 22 wallets came from a filter on peak liquidity and graduation rate. The naming family is now known, and a search across all pump.fun create events for that family will show whether this is the operation or a corner of it. The Dune cohort table holds 140,994 deployers and 32 of them carry a Rugburn label. That ratio is the actual state of coverage, and it is the reason a catalogue this legible sat unread for a fortnight.

The wallets in the cold open were funded two minutes and forty-one seconds before the token they were created to buy. Every one of those transfers was public the whole time.

The ledger is public: rugburn.io