ClaimScan V2.8: 11 Launchpads, Vault Intelligence and the x402 API

ClaimScan V2.5 shipped in early April with 9 launchpads, a visual redesign, real-time SSE streaming and a public leaderboard. The three weeks since then have been the densest development sprint we have run on the product. V2.8 adds two new launchpads, a vault classification engine, a pay-per-query API tier via the x402 protocol, and a security hardening pass across all inbound request paths. This post covers what shipped and why each piece was worth building.

From 9 to 11 Launchpads

Flaunch on Base (Phase 11). Flaunch.gg is a token launchpad on Base that routes creator fees through a RevenueManager contract. The contract exposes a balances(wallet) view that returns a single wallet-wide claimable amount, not a breakdown per token launched. Getting accurate per-token fee attribution would require scanning every TotalFeesReceived event emitted since contract deployment, which is a heavy operation we deferred to a later version.

The current adapter emits one row per token with its total allocated fees shown as earned, plus a separate synthetic BASE:flaunch-legacy row that shows the actual wallet-wide claimable balance. The per-token rows give creators a picture of which launches generated income. The legacy row tells them exactly how much is available to claim right now. The table labels that row "Flaunch (claimable)" to make the distinction clear without requiring the user to understand the contract architecture.

The Phase 11 work also fixed a pagination gap that affected creators with large portfolios. The original Flaunch adapter stopped fetching tokens at the default page size. Creators running 130+ coin launches (common on Takeover.fun operator wallets) were getting truncated results. The fix loops through pages up to 1000 tokens per wallet before cutting off.

Flap on BSC (Phase 12). Flap.sh is a token launchpad on BNB Chain. Its vault model is different from every other platform we had integrated before. Most launchpads store claimable fees in a vault owned by the creator wallet. Flap uses a portal system where each token gets a vault, but the fees are routed to a "fund recipient" address that is separate from the wallet that deployed the token.

That required a new detection layer. The adapter calls a detectFundRecipient function that probes the vault contract, reads the fund-recipient address, then queries the claimable balance against that address. When the probe returns a valid EOA, ClaimScan shows the real claimable amount. When it returns a zero-address (meaning the vault uses a different model), the adapter falls back to querying the creator wallet directly.

Flap also presented an i18n edge case: some tokens on BNB Chain use CJK characters or emoji in their symbols. Reading symbol() on-chain via ERC20 rather than relying on an API response handles these correctly, but the sanitizer downstream was stripping non-ASCII characters. The fix was a one-line regex change to make the token name sanitizer Unicode-aware. A symbol like DOGE🐶 now renders intact through the UI, explorer links and export data.

Vault Classification Engine (Phase 13)

After shipping the Phase 12 adapter, about three categories of Flap vaults were coming back as "unknown" in the classification logic. Unknown vaults rendered a fallback badge and an external link to flap.sh. That is safe but not useful to a creator who wants to know their balance.

Phase 13 built out the vault intelligence layer in four waves. First, the FlapTokenRow type was extended with a fundRecipientAddress field and the classification query was rewritten as a dual-axis WHERE clause: a row can match on vault-owner address OR fund-recipient address. That alone reclassified a significant share of previously unresolved rows.

Second, detectFundRecipient was wired into the background cron classification loop (not just the on-demand scan path), so historical rows get reclassified automatically on the next cron cycle rather than waiting for a user to trigger a fresh scan on their profile.

Third, a VaultStatusBadge component was added to TokenFeeTable. It renders at two positions in the table: next to the token name and in the claim action column. Badge states are base-v1 (standard vault model), base-v2 (the fund-recipient model) and unknown (fallback with external link). The badge gives creators immediate visibility into why a particular row behaves differently from others.

Fourth, unknown vault types now trigger a Sentry alert with vault address deduplication. Each distinct unknown vault fingerprint generates one alert, not one per scan. This lets us track unrecognized vault models as they appear in production without creating alert noise that gets ignored.

API v2 via the x402 Protocol

ClaimScan now has a paid intelligence tier. Three endpoints are live under /api/v2/:

/v2/fees returns aggregated fee records for a creator, structured for programmatic consumption. Same underlying data as the free scan, designed for teams building dashboards or analytics on top of ClaimScan data. Priced at $0.01 per request.

/v2/intelligence returns Allium wallet PnL enrichment: realized gains, unrealized positions and trading history for all resolved wallets tied to a creator identity. This is the data behind the Alpha indicators on creator profiles. Priced at $0.02 per request.

/v2/export returns the full creator dataset as structured JSON for spreadsheets, custom dashboards or third-party integrations. Priced at $0.05 per request.

Payment flows through the x402 protocol, a USDC micropayment standard built on Base Mainnet. When a client hits a v2 endpoint without a payment header, the server responds with HTTP 402 and a X-Payment-Required header containing the exact payment terms. The client settles via a facilitator, retries with the payment receipt, and the endpoint serves the response. No API keys. No account creation. No subscription. Pay per query, on-chain, verifiable.

Security Hardening

Two security improvements shipped alongside the v2 API tier.

Webhook IP allowlist as environment variable. Helius sends webhook events to /api/webhooks/helius when on-chain transactions match our subscriptions. The IP allowlist was previously hardcoded in the proxy, which meant updating it required a code change and a full deploy. It is now driven by a HELIUS_WEBHOOK_ALLOWLIST environment variable. Rotating allowed IPs is an environment update, not a shipping event.

HMAC request signing on live endpoints. The /api/fees/live and /api/balance endpoints now require signed requests. An unsigned request returns 403. The signature is HMAC-SHA256 of the request path and a timestamp, verified with timingSafeEqual to prevent timing attacks. These are the highest-cost RPC paths in the system. Requiring signed requests means scrapers cannot poll them directly without the signing key.

What V2.8 Looks Like Today

Current coverage: 11 launchpads across 4 chains.

On Solana: Pump.fun (including PumpSwap pool fees), Bags.fm, Believe, RevShare, Coinbarrel and Raydium LaunchLab. On Base: Clanker, Zora, Bankr and Flaunch. On BNB Chain: Clanker and Flap. On Ethereum: Zora.

600+ wallets scanned. $2M+ in creator fees tracked. Roughly 40% of those fees still go unclaimed at any given snapshot. The leaderboard is live, sortable by total fees earned or unclaimed amount, and every creator profile has a shareable URL.

Direct claim execution is available for Bags.fm (zero-custody, Solana). The v2 API is processing requests. SSE real-time streaming is active on every profile page. The vault classification engine is running on each cron cycle.

What Comes Next

Four items are on the active roadmap for V2.9 and V3.

One-click claim for EVM platforms. ClaimScan currently executes claims only for Bags.fm on Solana. Adding Clanker, Zora and Bankr on Base and BSC is the next major user-facing upgrade. It requires a multi-chain wallet integration so users can sign EVM transactions from the same interface that handles Solana claims. We are evaluating Reown AppKit for this.

Token Fee Scanner. Paste any contract address and see all creator fees associated with that token, regardless of which wallet deployed it. Useful for secondary buyers, analysts and anyone doing due diligence on a launch before investing.

Arbitrum support. The Zora adapter already covers Ethereum mainnet. Arbitrum is the next EVM chain in the pipeline.

ClaimScan SDK. A typed npm package for teams that want programmatic access to cross-chain creator fee data without building directly on raw HTTP responses.

What This Means for Your Project

ClaimScan V2.8 is a working example of what production DeFi infrastructure looks like at a cross-chain scale. Eleven platform adapters across four chains. A vault classification engine that handles multiple contract architectures. Real-time SSE streaming with React Context state management. A micropayment API that settles on-chain with no subscription overhead. Security hardened down to request signing and timing-safe comparisons.

Every component was built from scratch by the same four-person team that handles websites, branding and Telegram tooling for crypto projects. If you need a DeFi utility, a cross-chain dashboard, an analytics tool or any on-chain product that has to work reliably with real money, this is the level of execution we bring. Reach us on Telegram @lwarts or check the ClaimScan API docs if you are building on top of the data.