01. Real events, bounded coverage
Market data comes directly from Robinhood Chain mainnet (chain ID 4663) through its public RPC. We read Uniswap v4 PoolManager swaps, official instant-launch strategy events, transaction receipts, block headers, and token contracts. Explorer links provide evidence; the explorer does not supply our market data.
The page initially loads a captured on-chain snapshot, then checks for updates about once a minute while visible. Successful server refreshes are cached for 60 seconds. When a refresh fails, the last captured data remains visible with a delayed-update notice. Capture time and source block always describe the displayed data.
By default, we discover launches in the last 100,000 blocks and cover the newest eight supported instant pools. Each selected pool includes swaps from its launch through the common cutoff. This is a recent sample, not a chain-wide screener. The cutoff trails the scan head by 128 blocks; that buffer is not a claim of L1 finality.
Collection checks deployment code, successful launch receipts, PoolKey-derived pool IDs, event emitters, and block hashes. Only native ETH/token pools without hooks are included. The cutoff hash is checked again before publishing a snapshot.
02. Spot prices and observed volume
Prices are ETH per token, derived from the post-swap square-root price and token decimals. They describe pool spot price after execution, not the average execution price or a guaranteed quote for a new trade. The chart follows those observations.
Volume sums the absolute ETH amount of each decoded swap. Counts represent swap events, so one transaction can contain multiple swaps. The displayed period runs from each selected pool’s launch to the cutoff; it is not labeled 24-hour volume. Buy and sell directions follow token movement into or out of the pool.
All values remain in ETH. No USD price feed or conversion rate is used. Token supply and metadata are read from contracts at the cutoff. The displayed LP fee is distinct from protocol fees and gas.
03. Realized means sold
The on-demand trader audit covers one pool, with its own capture block and time. It uses average-cost accounting in integer wei and raw token units. Buys add inventory and cost; sells remove the proportional cost of the tokens sold.
For example, buying 100 tokens for 1 ETH and selling 40 for 0.6 ETH realizes +0.2 ETH. The remaining 60 tokens retain 0.6 ETH of cost. Rounding residue stays with inventory until the final sale.
This is gross realized swap PnL before gas. Swap fees reflected in the pool’s execution amounts are not subtracted again. It does not establish total wallet returns, historical USD profit, or profit after every router or application-level fee.
Unknown inventory or cost basis excludes a position from PnL. We never treat unknown acquired tokens as free. The audit’s eligibility filter requires complete supported positions with at least 10 swaps in that pool’s covered history. A small sample may have no eligible wallets.
Windowed performance and behaviour
Windowed realized PnL carries cost basis from the pool’s full audited history, then sums only sales realized inside the selected window. Net ETH instead subtracts purchases from proceeds inside that window, including spending on inventory still held.
Realized ROI divides profit by the cost of tokens sold. A win or loss is a fully closed inventory cycle; break-even cycles are omitted from win rate. Average hold measures first buy to closing sell for closed cycles in the window. Best sale is the largest individual realized disposal, not a hypothetical peak price.
Open inventory is marked at the latest observed price in the same audit, so its balance and price share a cutoff. Refresh the audit to update that mark. Early-buy share measures supported token purchase quantity in the first five blocks after launch divided by supported buy quantity in the selected window.
The minimum-swap gate supports 10, 25 or 100. No-purchase, oversold and under-60-second closed-hold filters are visible. Unknown-basis and unsupported positions always remain excluded; a blacklist filter is unavailable because no such source is connected.
04. Addresses need evidence
A transaction sender alone is not proof of the trader. Audits check complete receipts, supported router/token flows, ERC-20 transfers, sender contract code, and token balances at the audit cutoff. Transfers are reconciled against tracked inventory.
Unsupported routes, contract senders, unmatched transfers, and balance or inventory mismatches are shown as exclusions. These conservative checks do not identify every bot or prove that trading is organic. An address is not a verified person.
The launch sender is labeled as such. The launch event’s final position recipient can be a fee-splitting contract and must not automatically be labeled the creator.
05. Coverage before rankings
Wallet profiles and share cards use one audited pool at a time. Creator pages group covered launches by transaction sender. Global trader rankings, complete wallet histories, holder concentration, reserve-based liquidity, USD metrics, and crowd-auction accounting still need verified inputs and sufficient history.
Refreshes are bounded RPC scans, not a persistent indexer. Busy pools or provider limits can prevent an audit from completing. A failed refresh keeps the last successful result instead of publishing partial totals. A durable worker can extend history later while reusing the ingestion and accounting code.
Back to markets