A unified Solana wallet-transfer stream for SOL and SPL tokens

The first thing most newcomers to Solana get wrong is treating “a transfer” as one thing. It isn't. SOL and SPL tokens move through different programs with different account conventions and different instruction shapes.

The SPL side has the extra step of resolving Associated Token Accounts back to their wallet owners. The Token program transfer instruction names the source ATA, the destination ATA, the authority, and the amount, but it doesn't name the human wallets. That mapping lives in the transaction's preTokenBalances and postTokenBalances metadata, which the validator emits alongside the instruction list. Our parsed event resolves the ATA-to-owner walk for you, so the field you read is fromOwner, not fromATA.

Real wallet activity blends SOL and SPL flows in the same transaction routinely. The most common case: you send USDC to a wallet that doesn't have a USDC ATA. The sender pays ~0.00204 SOL via System Program Transfer to fund the new ATA's rent, and then the SPL TransferChecked moves the USDC. Both instructions land in one signature.

If you subscribe to the two programs separately, you see those as two unrelated events arriving on different sockets. Reconciling them after the fact is annoying, error-prone at scale, and adds latency. A single subscription that includes both programs and parses transfers from both into a uniform shape lets you treat the transaction as one event with two legs.

Other patterns where the merge matters:

• Bot fee + token swap. A trading bot wraps SOL, swaps via Jupiter, and unwraps SOL all in one signature; the wrap and unwrap are System Program transfers, the swap leg is SPL.
• NFT purchase. SOL flows to the seller, SPL transfers move the NFT mint and any royalty token; both inside one tx.
• Stablecoin payouts. Some payroll programs settle SOL gas reimbursement and USDC salary in the same tx for efficiency.

The unified stream surfaces these as a single event with both legs attached. You decide downstream whether to dedupe by signature, group by sender, or count each leg as its own movement.

Yellowstone gRPC supports two filter axes that matter here: accountInclude (which programs the tx must touch) and accountRequired (which addresses must appear in the tx, in any role). Combine them and you've got a precise per-wallet feed.

For exchange deposit detection, the pattern is one subscription with accountInclude set to System and SPL Token, plus accountRequired set to the list of exchange hot-wallet addresses you care about. We've sustained tests at 50,000+ wallets in the required list on a single subscription with no measurable latency hit; accountRequired is OR'd at the validator level, so the cost is mostly fixed.

The same pattern works for whale tracking, treasury monitoring, smart-contract treasury accounts, and protocol fee accounts. Subscribe once, get only the transactions touching addresses you care about, decode the transfer leg.

A common gotcha: if you put a wallet in accountRequired but forget the SPL Token program in accountInclude, you'll only see SOL movements, not token movements. Always include both programs when watching wallet activity.

The same address spraying SOL to many destinations in one tx is a high-signal pattern. The interpretation depends on context, but the shape is usually one of these:

The stream gives you the events; the classifier is yours. We don't score wallets for you because the right scoring is domain-specific (a sniper-detection product wants different weights than a compliance product).

We see five durable categories of consumer for this feed.

Whale trackers and copy traders. Watch a curated set of high-PnL wallets, post their swaps and transfers to a Discord, copy the trades on a separate execution wallet. Latency matters: most of the alpha decays inside 30 seconds. gRPC.

Exchange flow analytics. Net deposits to / from CEX hot wallets, tracked in real time, charted alongside price. Useful internally for trading desks; useful as a public dashboard for engagement.

Compliance and AML. Sanctioned wallet monitoring, mixer-output tracking, sanctions-list deposits to exchanges. The stream is the ingestion layer; the rules engine sits downstream.

Wallet apps. In-app push notifications for incoming transfers. The stream lets a wallet provider notify a user before the transaction even shows up in their explorer of choice.

Treasury monitoring. DAO treasuries, protocol fee accounts, foundation wallets. Real-time visibility on every movement, with optional Slack/email alerts for thresholds.