A KOL label identifies a tracked wallet, not a proven trading edge. Addresses can be operated by teams, change strategy or be deactivated. Use the Solana API to identify the source of a trade, save what you observed at the time and compare later outcomes. For general wallet monitoring, see how to track whale wallets.
This is the research workflow. The Wallet Tracker setup guide covers account setup, while the webhook guide covers push delivery.
Discover and evaluate wallets
GET /api/v1/kol/wallets lists the tracked roster, defaulting to active wallets. It supports limit, offset, q, strategy and active; follow has_more to enumerate beyond one page. The roster has names and strategy labels, not performance metrics. Use /api/v1/kol/leaderboard for a ranked view and /api/v1/kol/{wallet} for an address profile. The KOL tracker offers a visual starting point.
The leaderboard supports period=today|7d|30d|90d|180d, several sorts and a strategy filter. Its ranking universe is bounded to 50 wallets before some presentation filters; do not treat a page as an exhaustive ranking of the whole roster. Compare win rate with the number of observed buys and sells, realized PnL, typical hold time and whether the address is still active. Save dated snapshots: a leaderboard viewed after a winning token launch contains hindsight.
A KOL's public identity does not prove every transaction expresses an investment view. Transfers, test buys, partial exits, automated activity and social coordination can change the meaning of a swap. Repeated buys or several KOL wallets buying the same mint warrant review, but they are not inherently bullish or independent. Check exits, liquidity and the first trade timestamps before attributing conviction.
Build your own watchlist
The personal Wallet Tracker is separate from the KOL roster. Its POST /api/v1/wallet-tracker/watchlist accepts wallet_address and an optional label. It requires Pro or higher. Current Solana watchlist caps are 50 on Pro, 250 on Ultra and 1,000 on Business; the route's GET response gives the caller's actual limit and remaining, and current pricing should be checked for plan changes.
curl -X POST "https://madeonsol.com/api/v1/wallet-tracker/watchlist" \
-H "Authorization: Bearer $MADEONSOL_API_KEY" \
-H "Content-Type: application/json" \
-d '{"wallet_address":"<Solana-base58-address>","label":"KOL research: verify activity"}'
Use GET /api/v1/wallet-tracker/summary?period=7d for activity summaries of wallets already in your watchlist. A summary is not a KOL leaderboard. It includes counts, SOL flow and last event time, with the period chosen from 24h, 7d or 30d. If the stats query fails, the route can still return wallet rows without populated stats, so distinguish absent activity from unavailable metrics.
GET /api/v1/wallet-tracker/trades returns watchlist events. Filter by wallet, action or event_type and paginate rather than assuming the first page is complete. The default order uses on-chain slot; block_time and ingested_at describe the tracker ingestion clock and can put recovered trades later than their chain order. A replayed event arrived through recovery, so do not treat its arrival as a fresh buy. The API reference describes the fields and cursors.
Analyze patterns without overclaiming
- Multiple buyers: Count distinct addresses, inspect whether trades came from the same slot or bundle, and compare buys with later sells. A cluster can be coordinated promotion or a common automated strategy.
- Repeat buys: Preserve transaction signatures and token amounts. Two swaps may form one routed order, while a larger second buy can still be followed by an immediate exit.
- Timing: Compare source transaction time, signal receipt time and your own fill. A follower may be unable to reproduce a KOL's entry price even when the wallet has good historical metrics.
- Deployer context: The Deployer Hunter provides a different view of launch history. Its data may overlap with the trades that brought a token to your attention, so it is context rather than an independent “double confirmation.”
Store observations before outcomes, include tokens that never became popular and inspect losing signals. If building monitoring for others, the wallet-tracking infrastructure overview covers the product side. Start with passive monitoring and measure coverage and alert delay before routing any signal to an execution system.
