A wallet label helps users read an activity table, but it is not the wallet's identifier. Store addresses as keys and attach identity as optional context. SDK 0.5.0 extends that context to enriched live trades and liquidity without changing the existing basic event types.
Run the Node.js example
Use Node.js 24 LTS and keep the API credentials on your server. Create an empty directory, then install:
npm init -y
npm install @solana-tracker/[email protected]
npm install --save-dev tsx typescript @types/nodeSave the TypeScript block as index.mts. Put ST_API_KEY in an uncommitted .env file. Streaming examples also need ST_DATASTREAM_URL, the full private WebSocket URL from your Data API dashboard. REST and streaming access depend on your plan.
node --env-file=.env --import tsx index.mtsimport { Client } from '@solana-tracker/data-api';
const apiKey = process.env.ST_API_KEY;
if (!apiKey) throw new Error('Set ST_API_KEY');
const client = new Client({ apiKey });
const mint = process.env.TOKEN_MINT ?? 'So11111111111111111111111111111111111111112';
const holders = await client.getTokenHolders(mint, 'all');
console.log('Enriched holder accounts:', holders.accounts);
const trades = await client.getTokenTradeHistory(mint, {
events: 'trades', enrich: 'identity', limit: 50,
});
console.log('Enriched trade history:', trades.trades);Request only the enrichment you use
Holder enrichment can include identity, wallet/token PnL, or both. Choose identity when the UI needs names and roles; request all when it also displays the PnL fields. Avoid adding larger analytics objects to every small autocomplete response.
Trade history uses enrich: 'identity'. The equivalent live option is { enriched: true } on supported swap and liquidity subscriptions. These are separate request contracts; a REST query does not configure a WebSocket room.
Keep roles and names distinct
A wallet can have a KOL profile, SNS domain, platform tag, and token-specific role. Those fields describe different relationships. A developer role for one mint does not imply the wallet created every token it holds.
Display the most useful name with the address still accessible. Keep other roles in a secondary detail view. Escape names as text, validate external links, and do not let an arbitrary label impersonate a verified UI badge.
Treat labels as current context
Historical trade enrichment returns current wallet identity. It does not prove that the same label was known at the time of the trade. That distinction matters in backtests: using today's labels to choose historical trades can introduce hindsight into the result.
If your application needs reproducible historical analysis, store the identity snapshot and observation time used by that analysis, separately from the current profile.
Handle null and partial identity
Unknown identities are valid. Render an address fallback instead of hiding the trade. Enriched live events can arrive later or out of order, and a partial lookup does not receive a guaranteed follow-up correction for that event.
Allow identity to refresh independently of the monetary record. Do not replace raw trade amounts or deduplication keys because a display name changed.
Avoid unnecessary name lookups
If the response already contains identity.sns.domain, use it. Use the SNS RPC methods for screens that have wallet addresses but no identity enrichment. Batch visible addresses and cache names with an expiry.
Pair labels with the first-buyer guide to distinguish observed wallet roles from assumptions about insider activity.
FAQ
Does a KOL label verify profitability?
No. Identity and performance are separate data.
Can one wallet have multiple labels?
Yes. Preserve the identity object instead of reducing it to one permanent category.
Are labels historically fixed?
No. Enrichment is current context; store snapshots if an analysis needs the labels known at a specific observation time.