how to find a fomo trader's wallet address

if you want to copy a fomo trader automatically, you need one thing the app will never give you: their address. positions, quantities, realised pnl, follower count — all published. the twenty-hex-character string that ties it to a chain — not shown, anywhere.

this is not a wall. it is a puzzle with a published answer key, and the key is the quantities themselves.

the idea in one sentence

a profile that says "5.4M CASHCAT and 20M BULL" is telling you that somewhere on that chain there is an address holding about 5.4 million of one token and about 20 million of another, and there is usually exactly one.

each quantity on its own is weak evidence. plenty of wallets hold roughly 20M of a widely-held token. but holdings are close to independent: the set of addresses holding ~20M of one token and the set holding ~5.4M of another overlap in almost nothing. intersect two sets and the answer is normally a single address. intersect three and it is a single address you can be confident about.

the four steps

seed

on any chain with a public holder list — blockscout exposes one — pull the holders of the first token and keep every address whose balance falls inside the range the displayed quantity implies. that is your candidate set, typically a few dozen addresses.

intersect

if the profile shows more than one seedable token, take the same slice for each and intersect the candidate sets. this collapses fast. two tokens is usually enough to go from dozens of candidates to one.

verify

chains without a public holder list — bsc is the common one — cannot be seeded, but they can be checked. for each surviving candidate, call balanceOf directly on the token contract and see whether the answer lands in range. this works against any public rpc endpoint and needs no api key or indexer.

score

the score is the fraction of quantity claims confirmed, weighted by how tight each match was. a wallet that matches three quantities to within a fraction of a percent is a much stronger claim than one matching three round numbers loosely.

the rounding trap

this is where naive implementations quietly break, and it is worth the paragraph.

the tolerance has to come from the significant figures actually displayed, not from a fixed percentage:

and take a full unit in the last place, not half of one. the textbook says half, because the textbook assumes rounding. real interfaces truncate. we hit a wallet whose balance was 22,567,339 and whose profile displayed 22.5M — truncation, not rounding, and a half-ulp window would have excluded the correct address from the candidate set entirely.

the looser tolerance costs you nothing, because the intersection step takes the precision back. widening each individual window and then demanding agreement across two or three of them is strictly better than tightening one window and hoping.

what counts as proof

three rules, each of which exists because breaking it produced a wrong answer.

• two confirmed quantities, zero contradicted. one match is a coincidence with good manners. and a single contradicted quantity should sink a candidate even if four others agree — a wallet that does not hold what the profile says it holds is not that wallet.
• a network error is not a zero balance. the most expensive bug we shipped in this area treated an rpc rate-limit response as "no such position", which silently disqualified twenty tokens and lost the correct address. a failed read must raise, not resolve to zero. if you build this yourself, write that test first.
• account-abstraction signals are a bonus, never a filter. fomo wallets are erc-4337 smart accounts, and many delegate to the eth-infinitism reference implementation. finding that delegation on a candidate is mild positive evidence. requiring it is a mistake, because the same reference contract is used by other applications and by no means every account will show it.

a worked example

the case we use for validation is a leader who was ranked first on the 7-day board at the time. their profile showed four positions: CASHCAT 5.1M, CATSTR 27.2M, MERD 12.5M, POOLS 15.3M.

three of the four confirmed against a single address, 0x2408…F5a0, for a score of 0.698. the fourth, POOLS, did not — and the reason it did not is the useful part. it was a dust position worth about $171, down 82%, which the trader sold in the window between us reading the profile and running the resolution. the mismatch was not an error in the method; it was the method observing that the world had moved.

the independent corroboration is what closed it. that address appeared in the CASHCAT holder list at 11.0M on the morning of 24 august and at 5.19M by the evening. over the same hours, the trader's public fomo activity showed CASHCAT sells roughly every twenty minutes. two entirely separate data sources describing the same afternoon.

when it does not work

plan for a 20 to 40% failure rate on real profiles. the recurring causes:

• too few positions. one token cannot be intersected with anything.
• quantities too round. a single holding of exactly 1M of a popular token matches half the chain.
• an active trader. balances move between the profile render and the resolution. this is why the tolerance is generous and why the answer degrades gracefully instead of failing hard.
• chains without a holder list. if every position sits on a chain you can only verify and never seed, there is no candidate set to start from.

the shortcut

all of the above is a few hundred lines and a lot of rate-limit patience. if you would rather not, the copyfomo wallet finder takes a handle or a screenshot of a profile page from your phone, runs the same seed–intersect–verify–score procedure, and hands you the verified address. it covers the whole leaderboard, not just the top hundred.

with an address in hand, the next question is what to point at it: how to copy a fomo trader, and why the delay between their fill and yours is the entire trade.