Read GMGN aggregate bundle, sniper, fresh-wallet, and concentration signals through Noesis without treating them as wallet-level proof.
How to read Noesis bundle and bot signals
TL;DR. GET /api/v1/token/{addr}/bundles combines token metadata with GMGN's token-level and holder-category statistics. It reports aggregate signals such as bundler-classified supply, fresh-wallet rate, bot/degen share, holder concentration, and category counts. It does not return bundle groups, individual bundle wallets, same-slot transactions, SOL spent, or evidence that particular wallets sold.
The endpoint supports Solana, Ethereum, Base, BNB Chain, and Robinhood Chain when GMGN has data for the requested token.
Data sources and response contract
Noesis makes four independent reads:
- Unified token metadata (
token) - GMGN token statistics (
token_stat) - GMGN holder-category statistics (
holder_stat, nullable when unavailable) - Detailed bundle telemetry (
bundler_stat, nullable when unavailable)
Representative response:
{
"token": {
"address": "EPuZ1X...Fpump",
"symbol": "TOKEN",
"source": "gmgn"
},
"token_stat": {
"top_bundler_trader_percentage": 0.125,
"fresh_wallet_rate": 0.081,
"top_bot_degen_percentage": 0.032,
"top_rat_trader_percentage": 0.018,
"top_entrapment_trader_percentage": 0.009,
"top_10_holder_rate": 0.278,
"dev_team_hold_rate": 0.018
},
"holder_stat": {
"bundler_count": 28,
"sniper_count": 14,
"fresh_wallet_count": 35,
"insider_count": 12
},
"bundler_stat": {
"bundler_count": 63,
"bundler_swaps": 148,
"bundler_hold_ratio_raw": "12.5",
"bundler_max_hold_ratio_raw": "3.1",
"bundler_swap_quote_amount": 48123.5
}
}
Numeric availability depends on GMGN. Treat missing or zero-valued fields conservatively; they do not prove that the behavior is absent.
Run the analysis
Telegram bot
/bundle <token_address>
REST API
curl -H "X-API-Key: $NOESIS_API_KEY" \
"https://noesisapi.dev/api/v1/token/<TOKEN_ADDRESS>/bundles?chain=sol"
For EVM tokens, pass chain=eth, base, bsc, or robinhood when automatic detection would be ambiguous.
MCP
token_bundles(address="<TOKEN_ADDRESS>", chain="sol")
Field interpretation
top_bundler_trader_percentage: GMGN's aggregate share associated with its bundler-trader classification.fresh_wallet_rate: aggregate fresh-wallet signal from GMGN.top_bot_degen_percentage: aggregate bot/degen signal.top_rat_trader_percentage: aggregate rat-trader signal.top_entrapment_trader_percentage: aggregate entrapment/insider-style signal.top_10_holder_rate: top-ten holder concentration.dev_team_hold_rateandcreator_hold_rate: creator/team concentration signals.bundler_count,sniper_count,fresh_wallet_count, andinsider_count: upstream category counts when holder statistics are available.bundler_swapsandbundler_swap_quote_amount: detailed bundle activity totals when indexed.- fields ending in
_raw: deliberately unscaled provider strings. Do not render them as percentages until their response-specific unit is established.
These are provider-defined aggregates. GMGN does not expose its full classification methodology through these endpoints, so Noesis must not present the values as independently verified wallet relationships.
What this endpoint cannot answer
The response cannot establish:
- which wallets formed a bundle;
- whether wallets bought in the same slot;
- how many SOL a group spent;
- the group's current combined holding;
- whether the alleged bundle wallets sold;
- whether wallets share a common funder.
Use /fresh for the wallet-age-≤7-day trading cohort and /topholders for current large-holder positions. Noesis preserves the upstream Fresh tag but does not independently recompute wallet age. Even when several signals agree, present the result as risk evidence rather than proof of common ownership.
Caveats
- The endpoint depends on GMGN availability and classification coverage.
- Existing
token_statpercentage fields use 0-1 ratios. Detailedbundler_statratio fields remain raw strings because live responses have used inconsistent scales. holder_statis nullable because Noesis treats that supplementary GMGN request as fail-soft.- The REST endpoint is currently one credit, although its request-throttle class is Heavy (one request per five seconds). Credit price and throttle class are separate concepts.