Every removal, with its receipt
Amount removed, block, and transaction hash for each event — so you can verify any row on-chain instead of trusting our summary. Totals are computed over all matching rows, never over the returned page.
What already
happened.
A simulator tells you what a token does now. This tells you what was already done to it —
and who else it was done to at the same moment.
POST /api/v1/base/liquidity-history
§ the archive
A record, not a computation.
Anyone can read the chain as it is today. Nobody can read the chain of six months ago for events they were not watching for. true402 has been indexing Base pool creations and liquidity removals continuously and writing them to durable storage, so the observations themselves are the asset.
That number is fetched live from /v1/chain-coverage
when this page loads, not written into it — it is computed from the archive on every request, so it
cannot become a stale boast. Note the wording: liquidity-removal events, not rug pulls.
A removal is any liquidity withdrawal, and ordinary LP rebalancing emits the identical event.
Calling them rugs would be a fabricated statistic dressed as a measurement.
§ what you get
Evidence, not adjectives.
Tokens drained together
Other tokens whose liquidity left in the same transaction. One transaction, several pools, one actor — operator linkage with no heuristics and no clustering model behind it.
The window we actually searched
The exact block range our removal index covers, plus a complete flag. "None observed" is always scoped to a range you can see, never dressed up as a clean bill of health.
§ try it
Look one up.
Any Base token address. First few calls a day are free, no wallet, no account.
§ integrate
One call, in the risk path.
curl -X POST https://true402.dev/api/v1/base/liquidity-history \
-H 'content-type: application/json' \
-d '{ "token": "0xTokenAddress", "limit": 10 }'
# -> { indexed: true,
# removals: { count: 16100, totalQuoteRemoved: 1644.32, distinctPools: 5,
# events: [ { pool, quoteRemoved, block, txHash } ], eventsTruncated: true },
# linkedTokens: [ { token, pool, txHash, block } ],
# coverage: { removalsIndexedFromBlock, removalsIndexedToBlock, complete: false },
# verdict: "16,100 liquidity-removal events observed across 5 pools." }Discoverable in the OpenAPI spec, the live catalog and the MCP manifest, so an agent can find and call it with no integration written by hand. If you want this folded into a single go/no-go before signing, use transaction preflight — it runs this check on the counterparty for you.
§ questions
Answered for machines.
What does liquidity history tell me?
Everything true402 has observed happen to one Base token's liquidity: the pools we have indexed for it, every liquidity-removal event with the amount removed, the block and the transaction hash, and the other tokens that were drained in the same transaction. Each row carries its transaction hash, so you can verify any of it on-chain yourself rather than trusting the summary.
How is this different from a honeypot check?
A honeypot check simulates a trade right now — can I buy, can I sell, at what cost. It answers whether a token is tradeable at this instant and re-derives that from live state on every call. Liquidity history answers what already happened, which live simulation structurally cannot see: a pool drained last month simulates perfectly today if someone re-seeded it. The two are complementary, and most agents should run both.
What are "tokens drained in the same transaction"?
One transaction that removes liquidity from several pools is one actor acting on all of them. That linkage is read straight out of data we already hold — no address heuristics, no clustering model, no extra data source. It is the cheapest honest signal that a token belongs to an operator who has done this before, and it is the field most likely to change an agent's decision.
If it reports no removals, is the token safe?
No, and the response refuses to imply it. Three outcomes are reported as three genuinely different things: the token is not in our index at all (we know nothing about it), it is indexed and no removal was seen inside the covered block range, or removals were observed. Every answer carries the exact block range our removal index covers, so an absence is always scoped to a window you can see rather than presented as a verdict.
Why does the coverage window matter?
Because a negative result is only as good as the range it was searched over. Our pool index and our removal index cover different windows by design — pools backfill in minutes, removals take hours — so the response reports the removal window specifically, and a complete flag that is false while the two disagree. Quoting the wider pool window would overstate how much chain we actually looked at.
Why can't I just query this from a public API?
Because it is a record rather than a computation. Anyone can read the chain as it is today; nobody can read the chain of six months ago for events they were not watching for. The archive exists because true402 has been indexing Base DEX pool creations and liquidity removals continuously and writing them to durable storage — the observations are the asset, and they cannot be back-filled from a public API after the fact.