Recover GMGN Fresh buy/sell makers on Solana and EVM chains with explicit cursor coverage and resume support.

Bot /freshREST GET /api/v1/token/{address}/fresh-walletsMCP token_fresh_wallets

GMGN Fresh wallet activity

TL;DR. /fresh now follows GMGN's actual Fresh tab. Noesis walks the opaque cursor from GMGN's multi-region v2 trade feed, keeps Fresh-tagged buys and sells, removes duplicate events, and returns one aggregate row per maker. It works on Solana, Ethereum, Base, BNB Chain, and Robinhood Chain.

GMGN's Fresh filter means wallet age ≤ 7 days. It is a wallet-age category, not GMGN's separate "newly active on this token" label.

GMGN describes wallet Age as the time since the wallet's first on-chain activity. /fresh reports GMGN's provider-assigned category; it does not independently recompute or certify that age from chain history.

Source and retrieval algorithm

The integration uses the same current route as GMGN's Fresh trade tab:

GET /vas/api/mul-region/token_trades_v2/{chain}/{token}
    ?limit=50
    &maker=
    &tag=fresh
    &cursor={opaque-next-cursor}

For each request Noesis:

validates the token against the selected address family;
lowercases EVM contracts, because GMGN can return a false empty result for a checksummed path;
walks data.next until GMGN returns no cursor or the request reaches an explicit page, cursor-cycle, or rate-limit stop;
accepts only event=buy|sell rows whose maker_tags contains the literal fresh_wallet;
removes repeated event IDs across and within pages;
groups the remaining events by maker and sorts wallets by latest activity.

The ranked /token_traders?...tag=fresh_wallet and filtered holder endpoints are not used for completeness. Their cursor repeated page one in live testing, so they are only Top-100 snapshots even when they return a non-empty next.

Telegram command

/fresh <token_address> [chain]
/fw <token_address> [chain]

Examples:

/fresh Tqj8yFmagrg7oorpQkVGYR52r96RFTamvWfth9bpump
/fresh 0xDb99d819e93B06Ed83A17c01Fed2B7dcA5774Bbb robinhood
/fw 0x... bsc

Base58 addresses resolve directly to Solana. A 0x address is automatically resolved from live trading activity. Add eth, base, bsc, or robinhood when you want to override that choice; a genuinely unresolved EVM address gets a chain picker rather than a silent guess.

The response includes:

unique Fresh buy/sell makers;
raw events and accepted trade events scanned;
pages fetched and whether the cursor was fully exhausted;
known bought/sold USD volume plus the number of events for which GMGN published amount_usd;
buy/sell counts, activity time, and balance/PnL snapshots from each maker's newest recovered event when GMGN publishes those fields;
links to the correct chain explorer and GMGN profile.

Long wallet lists are split across Telegram pages. /fresh intentionally does not offer the legacy supply Track button: that tracker scans at most 5,000 token accounts and cannot honestly guarantee coverage for a large Fresh cohort. Use the feed continuation controls for Fresh coverage; supply tracking remains available only from commands whose result explicitly offers it.

To keep one bot interaction responsive, Telegram fetches at most 50 GMGN pages per segment. When more history is available, tap Continue feed. The bot keeps the accumulated unique wallet addresses and offers another continuation until the natural end. A cursor-cycle stop has no Continue button because replaying the repeated cursor cannot advance.

REST API

curl "https://noesisapi.dev/api/v1/token/Tqj8yFmagrg7oorpQkVGYR52r96RFTamvWfth9bpump/fresh-wallets" \
  -H "X-API-Key: se_..."

EVM example with an explicit override:

curl "https://noesisapi.dev/api/v1/token/0xdb99d819e93b06ed83a17c01fed2b7dca5774bbb/fresh-wallets?chain=robinhood" \
  -H "X-API-Key: se_..."

REST query parameters:

chain=sol|eth|base|bsc|robinhood overrides automatic chain resolution;
max_pages=1..500 bounds this request (default and maximum: 500);
cursor=<opaque value> resumes from coverage.next_cursor returned by an earlier max_pages or rate_limited response for the same token and chain.

For example, a latency-sensitive client can fetch ten pages at a time:

curl "https://noesisapi.dev/api/v1/token/0xdb99d819e93b06ed83a17c01fed2b7dca5774bbb/fresh-wallets?chain=robinhood&max_pages=10" \
  -H "X-API-Key: se_..."

For stop_reason=max_pages or rate_limited, URL-encode the non-null coverage.next_cursor and send it back in cursor. A cursor_cycle value is diagnostic: immediately replaying that repeated cursor cannot make progress. Each response contains only the wallet aggregates recovered in that request segment, so a client reconstructing multiple segments must merge rows by wallet address. Across rows for the same address: sum buy/sell counts and present USD totals and USD coverage, take the earliest first_activity and latest last_activity, and union tags. Retain identity from the newest non-null segment. For balance/PnL/total_trade, retain the first segment containing that maker even when a snapshot value is null; otherwise an older event would silently replace a missing newest-event fact. Sum usd_amount_event_count and compare it with the merged buy/sell count before treating USD totals as exact. Only sum quote totals across segments when every row has quote_totals_available=true and the same non-null quote asset identity; otherwise keep quote totals null. The opaque cursor is assumed not to overlap adjacent pages; the aggregate response does not expose event IDs for cross-request deduping.

Important top-level fields:

{
  "chain": "robinhood",
  "source": "gmgn_multi_region_token_trades_v2_fresh",
  "definition": "GMGN Fresh means wallet age ≤ 7 days",
  "total_supply_available": false,
  "total_supply": 0,
  "fresh_count": 194,
  "total_analyzed": 194,
  "total_analyzed_scope": "unique_gmgn_fresh_makers_in_response_segment",
  "supply_controlled": 0,
  "position_metrics_available": false,
  "position_metrics_complete": false,
  "balance_wallets": 0,
  "missing_balance_wallets": 194,
  "coverage": {
    "complete": true,
    "started_at_head": true,
    "end_reached": true,
    "pages_fetched": 36,
    "page_limit": 500,
    "events_scanned": 1763,
    "fresh_trade_events": 1506,
    "duplicate_events": 0,
    "stop_reason": null,
    "next_cursor": null
  },
  "wallets": [
    {
      "address": "0xc611...9a42",
      "balance": null,
      "percentage": null,
      "category": "Fresh",
      "gmgn_tag": "fresh_wallet",
      "tx_count": 12,
      "tx_count_scope": "recovered_pair_fresh_buy_sell_events",
      "locked": null
    }
  ]
}

The feed-level counts above are a verified Robinhood snapshot from 2026-08-23 and will grow as trading continues. The abbreviated wallet row illustrates nullability and field semantics rather than a retained wallet fixture. The important contract is the relationship between the fields, not those values.

Each wallets[] entry can include:

address, GMGN name, Twitter identity, avatar, ENS, and tags;
buy_count, sell_count, tx_count;
usd_amount_event_count, buy_usd_total, sell_usd_total, net_usd (known-only when not every recovered event has amount_usd);
quote_amount_event_count, quote_totals_available, quote_asset_address, quote_asset_symbol, buy_quote_total, and sell_quote_total. Quote totals are null when units are missing or mixed;
first_activity, last_activity Unix timestamps;
snapshot_timestamp, latest_balance, amount_percentage, percentage;
realized_profit, unrealized_profit, total_trade from that same newest recovered event.

Position fields preserve unknown values instead of fabricating zeroes:

total_supply_available=false means the numeric total_supply=0 is a compatibility placeholder for unknown supply, not an observed zero-supply token;
balance_wallets and missing_balance_wallets report how many recovered makers' newest events did and did not have a valid GMGN balance snapshot;
position_metrics_available means total supply and at least one maker's newest-event balance snapshot are available;
position_metrics_complete means total supply is available and every maker in this response segment has a valid balance;
supply_controlled sums only known newest-event maker balances. It is a lower bound if position metrics are incomplete, and it is not the whole Fresh cohort when coverage.complete=false. Treat its compatibility zero as unavailable whenever position_metrics_available=false.

Compatibility fields such as balance, percentage, category, tx_count, funder, and locked remain in the REST response, but unknown facts remain null. The legacy category value is Fresh; gmgn_tag=fresh_wallet preserves the provider classification explicitly. tx_count is not the wallet's lifetime transaction count: tx_count_scope=recovered_pair_fresh_buy_sell_events states that it is the recovered buy/sell event count for this pair and request segment. The trade feed does not publish funding sources or evaluate lock status, so funder, funder_name, and locked are null.

Completeness contract

GMGN returns at most 50 events per page. A Noesis REST request defaults to and is capped at 500 pages, for a ceiling of 25,000 raw upstream rows. Callers can choose a smaller max_pages and resume from the returned cursor.

coverage.started_at_head=true means this request did not supply cursor.
coverage.end_reached=true means this request segment received no further cursor from GMGN.
coverage.complete=true means the same response started at the feed head and reached the natural end.
A final resumed segment has started_at_head=false, may have end_reached=true, and still has complete=false because that response did not contain the earlier segments.
coverage.page_limit records the max_pages bound used for this response.
coverage.complete=false means this response alone is not the full wallet set.
stop_reason=max_pages means the selected page bound was reached.
stop_reason=cursor_cycle means GMGN repeated an already requested cursor.
stop_reason=rate_limited means bounded retries were exhausted after at least one page; the recovered pages and current cursor are preserved.
next_cursor is a resume point for max_pages and rate_limited; for cursor_cycle it is the repeated diagnostic cursor and should not be replayed immediately.

Never interpret an incomplete response as "all Fresh wallets". This is also why the endpoint reports event count separately from wallet count: one wallet can appear in many buys and sells, and add/remove/burn events are scanned but do not belong in GMGN's visible Fresh trader count.

How to interpret the data

Fresh activity is context, not proof of insider control.

Many Fresh-tagged makers buying with little selling can show a broad young-wallet cohort.
A small cohort with high known net buying and concentrated newest-event balance snapshots can merit funder/team analysis.
High selling from Fresh makers can indicate early distribution rather than accumulation.
Shared tags or identities are provider labels, not cryptographic ownership evidence.

Use /bundle for bundle aggregates, /topholders for current concentration, and the wallet-connections API where transfer-graph coverage exists. Those features answer different questions and should not be collapsed into the Fresh label.

FAQ

Does Fresh mean the wallet was just created?

GMGN's current filter tooltip defines Fresh as wallet age ≤ 7 days. GMGN describes wallet Age as time since first on-chain activity, so this is an age classification rather than a claim about first activity on the requested pair.

Why not use GMGN's fresh_wallet_count aggregate?

That aggregate can include transfer/position-only wallets. In the verified Robinhood snapshot it was 226 while the visible Fresh trade tab was 194. The tab count matched unique buy/sell makers from the v2 cursor feed exactly.

Why not use the richer token-trader list?

It returned only a ranked Top-100 snapshot and repeated page one when its cursor was supplied. Noesis uses the cursor-reliable event feed for the wallet universe and exposes the fields available there.

Does it work without a GMGN login?

Yes. The business endpoint was verified through Noesis without a GMGN cookie, JWT, or Authorization header. The existing browser-like GMGN transport remains necessary because crude HTTP clients can hit Cloudflare challenges.

Which chains work?

All chains supported by Noesis: Solana, Ethereum, Base, BNB Chain, and Robinhood Chain.