Home / Solana monitoring

Monitor tokens, wallets and trades.

Track Solana tokens, wallets and trades through your own data pipeline and alerts.

[ CHOOSE YOUR DATA STACK ]See the recovery workflow
Illustrative client event ledger
tx-A / token transferRECORDED
Connection interruptedRECOVERING
tx-A / seen in backfillDUPLICATE
tx-B / decoded swapRECORDED
Trading transactions sent0

Monitoring can stop at a stored event, a dashboard update or an alert.

From an event to a logical alert.

A stream carries observations. Your application turns them into records and decides what deserves a notification, including after a connection fails.

Sample sequence: restoring a known watchlist and reconciling the gap.

  1. Observe

    Store confirmed tx-A and its interpretation. Advance the checkpoint after the record is durable.

    LIVE

  2. Mark the gap

    The connection drops. Mark coverage as recovering; keep the last processed checkpoint.

    OUTAGE

  3. Resume & buffer

    Restore subscriptions from your watchlist. Buffer new live observations while checking history.

    LIVE + HISTORY

  4. Merge the overlap

    Read address signatures and missing transactions. Repeated tx-A updates evidence without a new logical alert.

    DEDUPLICATE

  5. Reconcile

    Classify recovered tx-B. Close the bounded interval only when the checkpoint and required payloads are accounted for.

    CHECK COVERAGE
Missing payload or checkpoint?Keep event_gap_unknown visible. A fresh balance can repair the current view without recovering every missed event.

Recover within the available window. Solana RPC provides 2 days of replay; gRPC provides 100 slots. Resume live data, reconcile the gap and validate recovered records.

Local deduplication is separate from delivery. A client outbox can avoid creating a second logical alert. Delivery retries can still reach a receiver twice; use an idempotency key where the destination supports it.

Read shared gRPC restrictions

Define the event before the alert.

Follow on-chain activity, understand what changed, and turn it into useful data or alerts. Build the watchlist, interpretation and recovery around your own application.

An account change and a wallet trade need different evidence. Store the raw observation with its interpretation.

Scroll to compare the event types.

Observation, interpretation and client responsibility
Event typeWhat the feed gives youWhat your application still does
Account updateChanged account data or lamports, with a slot.Decode the account layout. Standard WS account updates do not identify the transaction that caused the change.
Balance changeA difference between snapshots or transaction pre/post balances.Keep mint, decimals and account ownership. A balance delta alone does not establish a transfer or swap.
Token transferA transaction containing Token or Token-2022 instructions.Identify source, destination, mint and amount, including inner instructions. A transfer can be one part of a larger operation.
Swap / tradeTransaction instructions, logs and available metadata.Use a decoder for the specific program and version. Check transaction success and distinguish protocol legs from the wallet's net movement.

Pick the feed. Own the interpretation.

Solana RPC, WebSocket and filtered gRPC. Your application owns decoding, storage and notifications.

Supanode data

WebSocket + RPC

Account changes and address-filtered transaction logs, with HTTP reads for state and transaction details.

Filtered gRPC + RPC

Yellowstone account or transaction streams when their filters fit your workload. RPC remains useful for reads and recovery checks.

Choose by watched addresses, subscription layout, activity and processing needs. Measure latency in your own deployment.

Your server-side listener

  • Watchlist and account discovery
  • Program-specific decoders and commitment policy
  • Durable records, checkpoints and coverage state
  • Alert rules, outbox and delivery retries
Event store / Dashboard / Notification

Use bounded subscriptions.

Supanode documents logsSubscribe with a mentions filter on shared WS. Solana accepts one address per mentions call. Shared all and allWithVotes log streams are blocked.

Validate the methods your listener needs during the trial.

WebSocket documentation

Keep credentials on the server.

The documented WS connection authenticates with an x-token header at the handshake. This design uses a server-side listener. A browser dashboard reads from your backend.

Keep the Bundle token on your backend, out of browser bundles.

Authentication documentation
Only need the current state?

For an early implementation, RPC polling compares snapshots at your chosen interval. Use event streams when intermediate changes matter.

Inspect the record, including its limits.

Sample client record for a recovered CP-Swap event, normalized by the application.

Sample normalized record
{
  "network": "solana",
  "signature": "tx-B",
  "instruction_path": "3.1",
  "event_ordinal": 0,
  "type": "swap",
  "decoder": "client:cp-swap",
  "commitment": "confirmed",
  "transaction_error": null,
  "origin": "address_backfill",
  "logical_alert": "queued",
  "coverage": "bounded_interval_reconciled"
}
Sample data with synthetic aliases and values.

Check the result first.

Raydium CP-Swap source emits a SwapEvent before later token transfers finish. A log can exist in a failed transaction. Require a successful transaction before recording a successful trade.

Decode the supported version.

Match the program, instruction path and event schema to the deployed version you support. Inspect token balances and fees separately to calculate the wallet's net receipt.

Keep event identity stable.

Use network + signature + instruction path + event ordinal for the logical event. Update its commitment and provenance separately. Repeated tx-A must not create another logical alert.

2stored events
2logical alerts
0trading transactions

Illustrative successful reconciliation: tx-A was already stored; tx-B was recovered. If the required payload is unavailable, keep the gap unresolved instead.

The example follows a known wallet and two known token accounts. Discover additional token accounts to extend the watchlist.

Make uncertainty visible.

A transaction is unavailable.

Retry getTransaction within a bounded budget. A null result does not prove there was no event. Keep unresolved signatures and the gap status.

The program is unknown.

Keep the observation as unknown_semantics. Save evidence for a supported decoder; do not label the balance movement a trade.

The confirmation changes.

processed can roll back. The example uses confirmed; use and track finalized if your application requires the strongest confirmation level.

A new token account appears.

Refresh owner-based discovery and update subscriptions. Check that account's retained history before claiming coverage for the missed interval.

Retries hit the budget.

Back off on rate limits and pace resubscription and history reads. Persist work before advancing the checkpoint. Show recovery backlog separately from live health.

A notification is repeated.

Retain one logical alert and track delivery attempts. Reuse an idempotency key where the receiver supports it to handle repeated deliveries.

Start with the smallest useful stack.

A single Bundle includes the interfaces in its tier for observing activity and producing alerts.

Solana

RPC + WebSocket

STARTER · entry Bundle

For a focused account list and a measured workload.

  • 15 RPS · 5 TPS
  • 10 WebSocket connections
  • 100 subscriptions / connection · 1,000 total
  • No gRPC in this tier
From $40
/ 30 days

Request a free trial up to 24h; our team confirms availability and setup. Purchase with a Solana wallet and USDC portal balance.

[ REQUEST A TRIAL ]Documentation
Solana

RPC + WebSocket + gRPC

FOCUS · optional filtered events

For backends that need Yellowstone account or transaction events.

  • 25 RPS · 10 TPS
  • 1 gRPC subscription · up to 100 addresses
  • 20 WebSocket connections
  • WebSocket included · gRPC replay: 100 slots
From $99
/ 30 days

Request a free trial up to 24h; our team confirms availability and setup. Check subscription and watched-address limits.

[ COMPARE BUNDLE PLANS ]Documentation

STARTER is the entry tier for a bounded monitoring listener without gRPC. FOCUS adds gRPC when its stream filters fit your monitoring application. The RPC budgets above are measured in RPS units.

Compare Bundle plans · Check gRPC limits

Include discovery and transaction reads in your budget.

getTransaction and getTokenAccountsByOwner each cost 10 RPS units; getAccountInfo costs 2. Include discovery, reconnect bursts, retries and backfill. The budget uses a 10-second sliding window.

WS subscribe/unsubscribe calls also use RPS. Keep WS ping intervals at 60 seconds or less. gRPC filters have additional node and plan caps.

Allow for your own operation.

Processing, storage and notification delivery are your infrastructure costs. Read-only monitoring does not send a trade or create its transaction fees and tips.

Measure activity during the trial to choose a tier. Account for history depth and missing metadata when planning recovery.

Try the interfaces with your watchlist.

Request a free trial up to 24 hours from our team; availability and setup are confirmed separately. Paid Bundle plans start in the portal with a Solana wallet. Choose a tier and keep the issued token on your server.

[ REQUEST A TRIAL ]Trial details

Check the linked documentation for method weights, subscription limits and setup.

Before you build.

Does Supanode send wallet alerts or parsed swaps?

Use Supanode streams and RPC reads to feed your monitoring application. Maintain a watchlist, decode the programs you support and apply your alert rules before sending notifications.

Can I recover every event after a disconnect?

Solana RPC provides 2 days of replay; gRPC provides 100 slots. Reconcile the gap within the available window and validate recovered signatures and payloads. Keep an unresolved gap visible when the evidence is incomplete.

Which confirmation level should an alert use?

Choose and label the confirmation level your application needs. Processed can roll back; confirmed has supermajority votes; finalized is the strongest cluster confirmation level. This example uses confirmed.

Can my browser connect directly?

Run the listener on your server, where the WS client can send the authentication header. Feed the browser dashboard through your backend and keep the Bundle token out of client code.

Does watching a wallet cover all its tokens?

Token accounts have separate addresses. Discover accounts for the relevant token programs, maintain the watchlist and check new accounts. A wallet mention filter alone does not prove every incoming token transfer is covered.

Do I need a transaction sender?

No sender is required for this read-only workflow. If you later add a strategy that signs and submits a transaction, treat that as a separate execution path with its own controls, costs and confirmation checks.

Sources & next steps.

Use the interface and program references below to build and validate your listener.

Build a trading botExplore copy trading infrastructureHome