Not marketing copy — the real rules the code follows, so you can check our work instead of taking our word for it. A few specific numbers are intentionally withheld, explained below, not hidden.
If a wallet only bought and never sold, it has no realized result yet — it's excluded entirely, no matter how the price has moved since. We don't count paper gains or paper losses, only money that's actually been locked in.
PnL is calculated from the wallet's real buy and sell amounts — never from the current price applied to a position the wallet still holds. A wallet that is up on paper but has never sold is not scored at all.
When a wallet sells only part of what it bought, we attribute cost proportionally. All of that wallet's purchases are pooled into a total amount spent and a total number of tokens bought; selling 40% of those tokens is charged 40% of the total spent. Concretely: a wallet that spends 1 SOL on 1,000 tokens, then 3 SOL on another 1,000, has spent 4 SOL for 2,000 tokens. If it sells 1,000 of them, the cost assigned to that sale is 2 SOL — half the total — and the reported percentage is the return on that 2 SOL.
This is proportional weighted-average cost allocation, not first-in-first-out (FIFO) accounting. We do not track individual purchase lots or match sales against the oldest tokens first. The two methods produce identical results whenever a wallet sells its entire position, or bought everything at one price; they differ only when a wallet bought at several different prices and then sold part of its holding. We use the proportional method because the on-chain data available to us does not carry reliable within-second transaction ordering, which lot-matching would require.
The displayed PnL and percentage are net of the real Solana network fee that wallet actually paid for each transaction (pulled from the transaction itself, not estimated). Swap/DEX fees are not a separate subtraction on top of that - the SOL amounts we measure are the wallet's real, observed transfers, which already reflect whatever the pool's fee reduced them to. There's nothing left to subtract without double-counting. A pre-fee version of the same calculation is retained internally for our own reference, but the public figure is always the fee-adjusted one.
To be eligible as the public winner or loser on a card, a wallet must have spent at least 0.1 SOL buying, or received at least 0.1 SOL selling (either side qualifies). Without this floor, a wallet that only ever moved a few cents could post a wild-looking percentage that's real but not meaningful. This floor only affects who's eligible for the public W/L headline - it doesn't change internal tracking of every wallet's activity.
Among eligible wallets, the headline pair is ranked by percentage return, not absolute SOL amount. Separately, we also track whichever eligible wallet moved the largest absolute amount of SOL on each side - if that's a different wallet than the percentage-ranked headline, it's surfaced as additional context (never a replacement for the headline pair).
On Solana, a token counts as graduated once it crosses a real market cap threshold of $69,000 - the same figure pump.fun's own bonding curve uses to migrate a token to open DEX trading. We independently verify this against the token's actual on-chain price and supply rather than trusting a label. Equivalent chain-specific graduation/migration events are used on the other tracked chains.
Automated market maker and liquidity-pool addresses move tokens in patterns that look nothing like a person trading - identified by analyzing net transfer direction and pairing patterns rather than a simple address blocklist, since pool addresses aren't announced in advance. These are filtered out before anything is ranked. We're not publishing the exact detection logic here, since doing so would make it a checklist for structuring a transaction to evade it.
Wallets showing patterns consistent with automated trading - unusually rapid, repetitive activity on a single token - are filtered out before ranking. The exact thresholds (trade frequency, timing patterns) are intentionally not published: publishing the precise cutoff would hand anyone running a bot the exact number to stay just under to avoid detection, which defeats the filter's purpose. This is standard practice for anti-abuse systems generally, not specific evasiveness about our methodology.
Every token we track gets a drama score: the winner's percentage gain plus the loser's percentage loss, added together as absolute values. A token needs a combined score of at least 100 AND at least $5,000 in real trading volume to get posted publicly. If we can't verify volume in USD for a token, it does not get publicly posted, full stop - there's no fallback threshold that lets a volume-unverified result through. Most tracked results don't clear this bar (a wallet up 2%, down 6%) and are correctly never posted - the full board, including these smaller results, is visible to holders. This formula is outcome-based, not something a trader can manipulate in advance, which is why we're comfortable publishing it exactly.
Rankings sort by percentage return, not absolute SOL/USD amount - a wallet that turned a small amount into a huge percentage gain ranks above a larger-dollar but smaller-percentage result. Exact percentage ties are resolved by the current result ordering, which we do not claim reflects chronological order.
We don't claim to detect coordinated/clustered wallets controlled by the same person as separate traders - a "winner" and "loser" shown together could theoretically be related, though nothing in the data suggests this is common. We don't claim insider knowledge or wrongdoing about any wallet - we report a completed round trip, not intent. We don't currently distinguish a token's creator wallet from any other trader unless it's caught by the pool-filtering above. These are real, current limitations, not implied capabilities.
We do not claim lot-level accounting. Our cost attribution is proportional, as described in section 2. Reproducing our figures requires the same proportional method; FIFO applied to the same trades can produce different results for wallets that made multiple purchases at different prices and then sold only part of their position.
Every wallet address shown is a real, truncated (not fabricated) on-chain address. Every result links through to the token's real pump.fun page, where the underlying transaction history is publicly visible on-chain to anyone, independent of us. We're not asking for trust on the numbers themselves — only on the selection rules above, which are now written down here.
This methodology hasn't been externally audited. There is no independent third party currently verifying that the code matches this description, beyond the fact that anyone can trace a shown wallet's real transaction history and confirm the result for themselves.
We're a new project. This page will be updated as the methodology evolves, not quietly changed without notice.