How a loss is counted, and what is deliberately not counted DD

1. What counts as a trade

Every token transfer that touches the wallet is grouped by transaction. Inside one transaction:

A stock token is the payment asset when a memecoin is on the other side of the trade, and the thing being traded when only ETH or USDG is on the other side. Losing money on NVDA is still losing money.

2. Native ETH, which the transfer list cannot see

Most buys on this chain are paid in plain ETH, not WETH, and most sells hand plain ETH back. Neither appears as a token transfer, so a naive method would show every buy as free and every sell as pure profit. That is the single biggest way a tool like this gets it wrong, and it is handled in two places:

• What you paid is the value on the transaction you sent, from the explorer's transaction list.
• What you received is the sum of the internal transactions that paid ETH to your address inside that same transaction. An internal transaction is a value transfer made by a contract rather than by a person, which is exactly what a router does when it settles a sell.

Native legs are only attached to transactions that already move a token, so sending ETH to a friend is never mistaken for a trade.

An earlier version of this page described a different method, and it was wrong. It read Withdrawal events off the WETH contract out of each transaction receipt, on the theory that a router unwraps WETH and hands ETH back. Measured against a real active wallet: across its 300 most recent transactions, zero receipts contained a Withdrawal, while the internal-transaction list showed 291 real ETH arrivals over the same span. That method cost 2,034 RPC calls and four minutes to find nothing, and every sale it missed would have made a loss look bigger than it was, which is the one direction this page promises not to err in. It is recorded here rather than quietly deleted, because a method page that only lists the things it got right is a marketing page.

3. Cost basis

First in, first out. When you sell, the oldest lots are consumed first, and the loss on that sale is proceeds minus the cost of exactly the lots it consumed. A partial sale consumes a partial lot. This is the same method a tax office uses, and it means the number is not sensitive to how you would prefer to think about it.

4. Dollars, and which day's dollars

5. What "worst exit" means

The single sale with the most negative loss. Not the worst token, not your total, one transaction. It is linked on every row so you can open it and see the sale, the proceeds, and the date. The "by token" tab adds up every sale of one token instead. The total on the sidebar is realized losses across scanned wallets that are net down, and it excludes anyone who is net up.

6. Who is on the board

The front page is a roster. Each wallet on it was added deliberately, by whoever runs the site, under a name they chose, and the page says "added by the mods, not submitted" at the top so nobody mistakes it for a queue of volunteers. With nothing in the roster the page says nobody has posted.

An earlier version was a leaderboard built by harvesting wallets out of the busiest pools and ranking whatever the script found. Every loss on it was real and every one was linked to its transaction, but nobody had posted any of them and each row said "submitted 2 days ago". A site whose entire argument is that its numbers can be checked does not get to describe a scrape as a submission, so that board came down. This is the same page on honest terms.

Being on it or not says nothing about you. There is no ranking against it either: a lookup tells you what you lost and links the sale, not where you place.

7. Things this cannot do, said plainly

• It cannot tell two wallets belong to the same person. A transfer between your own wallets is a transfer out and a zero-cost lot in, which understates your loss, never overstates it.
• It cannot price a token-for-token swap, or a transaction that moves several tokens at once. Those are counted and shown, not valued.
• Gas is not counted. Every trade cost something to make and none of that is in these numbers, so your real loss is larger than the one on the card by whatever you paid the chain.
• A whole-history read returns thirty thousand rows. A wallet past that loses its newest rows, so a recent sale can go missing entirely. If the fast lane is exhausted and the lookup falls back to paging, the loss runs the other way: paged rows arrive newest first, so the oldest history goes, which is where the buys are, and a sale whose buy went missing has no cost basis and reads as a gain. The page says outright which of these happened.
• Stock tokens used as payment are valued at today's price, not the day's. It is the one known approximation and it is flagged as todayOnly in the data.

Every one of these errs in one direction: it makes a loss smaller or missing. Nothing here can make a loss bigger than it was.

8. Comments, and why they are not evidence

You can pick a username, react to a row, and argue underneath it. None of that is verified and none of it is meant to be, so it is worth being exact about which half of this site is which:

A username here is a display name. It is kept in your browser next to a random id, and that id is only there so you can delete your own comment and so a vote can be taken back. No figure depends on it and no number changes because of it. Comment votes move comments, never losses. That separation is the point: the reason this site is worth reading is that the losses cannot be faked, and a comment section is not allowed to quietly become part of the evidence.

If this copy of the site has no comment server configured, every thread says so and your comments are visible only to you. That is stated rather than hidden, because a comment box that looks like a room full of people and is not is its own kind of lie.

9. Why the lookup is fast, which is also why it is honest

The block explorer offers the same data through two APIs, rate limited in opposite ways, and the response headers say so outright:

The long window has been measured anywhere between ten minutes and an hour, so nothing here assumes a number for it. The lookup page reads how many requests you have left and how long until they refill straight out of the response headers, and shows you both.

The obvious reading is that the second one is eighteen times more generous. For reading one wallet that reading is wrong, because the cost here is round trips rather than permission. Measured on the same real wallet, the same day:

Forty times faster and complete instead of truncated. The ten-minute read finished with 173 of its 180 requests unspent, so the allowance was never the constraint at all. A lookup therefore spends three of your ten whole-history requests, and only falls back to paging if you run out, which makes the slow path the floor and never the ceiling. That matters for accuracy and not just for patience: truncation is the main thing that makes this site understate a loss, and the fast path is the one that avoids it.

The build script does the opposite, because it reads hundreds of wallets and ten requests per ten minutes cannot do that. It pages, it is slow, and it runs offline where slow is free.

10. Reproduce any number

node data/test.mjs                    # the rules on this page, as tests
node data/build.mjs --wallet 0x…      # one wallet, printed
node data/build.mjs --wallet 0x…      # the same path the site takes

Same wallet, same price table, same output. --wallet takes the same whole-history path the lookup takes, so the terminal and the card agree by construction. The hashes of the engine, the price table, and the snapshot are pinned on verify.

Every claim on this page that can be turned into a test is one: that a transfer out records no sale, that native ETH paid counts as cost, that lots are consumed oldest first, that a stock token is the subject when only ETH is opposite, that a sub-cent bag is not a bag, and that no malformed row anywhere in real chain data can turn a figure into NaN. node data/test.mjs runs them with no network in under a second.