$Kettle

reading this pool's swap logs…

• · 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 $Kettle — 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 ↗

• · 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 $Kettle's 24h ETH across all 1 of its pools, not just the rows listed.
• · The chainwide index heartbeat is STALE, so the volume and share columns are older than they look. Depth snapshots are read live from the chain and carry their own stamp above.

• · Every row is the account that SIGNED the swap transaction — never the router the trade was routed through. (Measured while building this: every swap-event “sender” in a live window was a contract; a board of those would be a list of routers.)
• · Totals cover ONLY the indexed window: 103 swaps attributed for $Kettle between 2026-08-07 20:49Z and 2026-08-07 20:57Z — at least 49% of the 208 swaps our volume index counted over the same hours. Attribution is budgeted per tick and takes the highest-value blocks first, so every figure here is a floor over a stated period, never a lifetime total.
• · ETH in and ETH out are shown separately because net alone cannot tell “never sold” from “round-tripped”.
• · An account signing on others' behalf (a keeper, a relayer) appears as one signer. The “tokens” column is shown so bot- and infrastructure-shaped accounts are visible rather than silently ranked as people.

Our index has stopped reporting (last heartbeat 08-08 00:00Z). Nothing below is live. A removal that happened since then would not be here, and its absence is about us, not about $Kettle.

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) · 2 V4 events carry a liquidity delta and no amounts, so they are counted here and add nothing to the ETH figures. Floors over the pools and blocks we walked, not a census.

• 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.
• V4 rows report a liquidity delta (Δ) because that is all the event says. Turning one into ETH needs the pool’s price at that block, which is not in the event and not in the receipt — V4’s ETH side is native and moves with no log. Their ETH column reads “unmeasurable”, never 0.
• A signer shown as unread is one we did not resolve inside this tick’s block-fetch budget. It is never backfilled from the event’s own actor, which on this chain is a position manager essentially always.
• 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.

No holder concentration is shown for $Kettle: no Transfer events appear in the window we walked, and the token emitted no logs at all in the blocks we probed to check — so it looks quiet rather than clipped. No wallet could be nominated for a balance read.

· The read itself worked — this is what it found, not an outage. Candidate discovery covers the last 120,000 blocks (about 3.3 hours) of chain history, so a token whose transfers all predate that window is invisible to it.