$BATMAN&ROBIN

The index has not attributed an ETH-quoted pool to this token, so there is no pool to read a tape from. That is a statement about our index, not about whether this token trades.

No swaps have been attributed to a signer for $BATMAN&ROBIN yet. Trader attribution covers only the window since it was switched on, and only what its per-tick budget could read — so this is a statement about our coverage, not about whether anyone is trading. The chart and volume above come from a separate, older measurement.

• · These strings were written into the token contract by whoever deployed it, and some of what is above came from our index rather than from this request — each part says which. Anyone can deploy a contract and write anything into it. A link here is not evidence that the account, site or person it points to has anything to do with $BATMAN&ROBIN — we do not check, we do not ask them, and we never follow the link to see where it lands.
• · We asked the six metadata getters the launchpads on this chain actually implement (socials, twitter, telegram, tokenURI, description, metadata). None returned anything renderable. Most tokens here publish nothing — that is the normal case, not a warning, and a token that publishes a great deal is not thereby safer.
• · Read them yourself: the contract on the explorer ↗

last 24h 0 ETH added over 0 events · 0 ETH left the pools over 0 movements (V3 collects and V2 burns — the two ways tokens actually leave a pool contract). Floors over the pools and blocks we walked, not a census.

No liquidity event has been indexed for $BATMAN&ROBIN inside the blocks we walked. Read the coverage line above before treating that as calm: it is the absence of an observation over a bounded window, not evidence that nothing moved.

• Every row is a log we decoded, stamped with the block it came from. This panel states what moved, when, and who signed for it — it does not label a removal, and it never will. Taking liquidity out is an ordinary operation; the reader draws the conclusion from the numbers and the times.
• V3 splits a removal in two: closed is the burn, which only credits what the position is owed, and withdrawn is the collect, where the tokens actually leave the pool. A collect carries accrued fees as well as principal and the event does not separate them, so we do not either. V2 does not split: a V2 removed transferred in the same call, with no collect to wait for, which is why the summary counts it as ETH that left rather than as principal credited.
• Percentages are deliberately absent. “80% of the liquidity left” needs the depth before the removal, and we hold depth only as a live read at one block — no history to divide by. The absolute amounts above are what we actually measured.

• · Depth figures were read at block 30,191,405 — snapshot at 11:55 UTC. Liquidity can leave in one block; treat these as that instant, not as now. “ETH held” is the WETH a V3 pool contract holds: a ceiling on what a sell can be paid, not depth at spot — it includes out-of-range positions and uncollected fees, so a trade near spot may reach less.
• · V4 depth is UNMEASURED, not zero: V4's PoolManager is a singleton holding every pool's tokens in one contract balance, so per-pool reserves cannot be read as balances. We say so rather than guess.
• · Volume is the 24h ETH leg the chainwide index attributed to each pool — a floor over what its per-tick budget could walk, never a lifetime total. Share divides by $BATMAN&ROBIN's 24h ETH across all 2 of its pools, not just the rows listed.

• · The walk only NOMINATES wallets; every percentage above is a balanceOf read, exact at the block it was taken. Balances were read live across blocks 30,191,405–30,191,415 — this chain produces about ten blocks a second, so this is a short span, not a pinned snapshot.
• · These are FLOORS, not totals. Candidate discovery covered the last 120,000 blocks (about 3.3 hours), not full history — a wallet that has not moved $BATMAN&ROBIN inside that window is missing from the count. A missing wallet can only push the real figures UP, never down: the shares shown are measured, the set they are measured over is incomplete.
• · Circulating supply = total supply − the burn address's balance (that is the “burned” figure above, subtracted once) − the balances of 0xc557…aE51 Uniswap V3 pool · 0.30% tier, 0x8366…0951 Uniswap V4 PoolManager — the singleton holding every V4 pool's tokens. Pools quoted against something other than WETH are not discovered by this read and so are not excluded — such a pool's liquidity would appear here as a holder.
• · Separately, 0x0000…0000 the zero address — mints come from here, 0x0000…dEaD the burn address are skipped when RANKING wallets, so a mint source or a burn can never appear as a holder. The zero address is skipped from that ranking only — its balance is NOT part of the subtraction above, so a token that sends supply to 0x0…0000 instead of the burn address still has that supply counted as circulating here.
• · This is the identical read, over the identical exclusion set, that /scan/0x9909…912e uses — the same engine, the same window, the same exclusion set. /scan additionally raises a lower-tone flag from 25% (top holder) and 60% (top 10) — this panel does not tint those, so read the numbers rather than the colour. These are measurements, not a verdict: no threshold here makes a token safe or unsafe, and one wallet holding a large share may be a locker, a bridge, a treasury, or one person.