Skip to main content
Transaction monitoring lets you track transaction execution, success/failure status, program interactions, and token balance changes across Solana in real-time. This guide covers filtering strategies and practical implementations using the helius-laserstream SDK.
Prerequisites: This guide assumes you’ve completed the LaserStream gRPC Quickstart and have an API key.

Transaction Filtering Options

LaserStream uses the same filter shape as Yellowstone gRPC, including the tokenAccounts (ATA expansion) filter. The fields you’ll set inside transactions.<label>:
  • accountInclude — match if any of these accounts appears (logical OR)
  • accountRequired — match only if all of these accounts appear (logical AND)
  • accountExclude — drop if any of these accounts appears
  • vote / failed — boolean flags for vote and failed transactions
  • tokenAccounts — opt-in associated token account (ATA) expansion ("balanceChanged", "all", or "none"), so an accountInclude wallet also matches transactions where it owns an SPL token balance. See Token Account (ATA) Filtering and the Watching a Wallet tab below.
Monitor transactions involving specific programsTrack all transactions that touch programs you care about:
Best for: Program-specific monitoring, DeFi protocol tracking, smart contract interactions.

Practical Examples

Example 1: Monitor DEX Transactions

Track transactions touching popular DEX programs:

Example 2: Monitor Failed Transactions

Track failed transactions to surface application issues:

Example 3: Monitor High-Value Transactions

Track transactions with significant SOL transfers:

Example 4: Watch a Wallet (incl. token transfers)

Monitor everything that moves money for a wallet — including incoming SPL token transfers that touch its ATAs — by adding tokenAccounts to a plain accountInclude filter:

Transaction Data Structure


Filter Logic Reference

Include Logic (OR)

accountInclude: Transaction must involve ANY of these accounts.["A", "B"] matches transactions involving account A OR account B.

Required Logic (AND)

accountRequired: Transaction must involve ALL of these accounts.["A", "B"] matches transactions involving account A AND account B.

Exclude Logic (NOT)

accountExclude: Transaction must NOT involve any of these accounts.

Combined Logic

Final filter: (accountInclude OR empty) AND (accountRequired AND all) AND NOT (accountExclude OR any).

Performance Considerations

Transaction streams can be high-volume. To keep up:
  • Start with specific program filters (don’t subscribe to “all transactions”)
  • Use confirmed over processed when you can tolerate ~1.5s extra latency
  • Monitor your processing capacity with a counter
  • Consider running parallel consumers behind a queue

Error Handling

Symptom: Overwhelming transaction volume.Solutions: Add stricter filters (accountRequired, accountExclude); use higher commitment; implement sampling or rate limiting; process asynchronously.
Symptom: Expected transactions not appearing.Solutions: Verify program addresses are correct; check that the transactions actually exist; try processed for faster updates; loosen restrictive accountRequired/accountExclude filters.
Symptom: Cannot parse transaction data.Solutions: Handle missing fields gracefully; validate structure before processing; wrap parsing in try/catch; see Decoding Transaction Data.

Next Steps

Slot & Block Monitoring

Track network consensus and block production.

Stream Pump AMM Data

Real-world example: monitor Pump.fun AMM transactions.

Decoding Transaction Data

Parse the binary transaction payloads into readable Solana transactions.

Yellowstone protocol reference

The same workflow against the raw Yellowstone gRPC protocol.