Connect live signals to your strategy, signed transactions and verified outcomes.
Track the returned signature to check confirmation and the swap result.
A trading bot turns a signal into a decision, then follows the transaction through to its result. Update state and reconcile each attempt before taking the next related action.
Supanode supplies data access and transaction delivery. Connect them to your strategy, wallet, risk checks and recovery logic.
Read account state. Receive account or transaction updates with a slot and chosen commitment.
Decode, remove duplicates and refresh state. Check size, slippage, balances and allowed programs.
Compose instructions with an external builder or protocol SDK. Set fees, simulate and sign locally.
Send signed bytes through regular RPC or TPU Sender. Record the signature and expiry.
Check commitment and execution error. Inspect the result and refresh balances before the next related action.
Start with the event type and the processing you can maintain. Keep RPC alongside any stream for state reads, simulation and confirmation.
| Interface | What arrives | Your application handles | Use it when |
|---|---|---|---|
| RPC + WebSocket | Requested state and subscription notifications for selected accounts or signatures. | State refresh, protocol decoding, reconnect and missing-data checks. | You watch a small, defined set of accounts and your measured load fits the plan. |
| RPC + Yellowstone gRPC | Filtered account writes, transactions, slots and other supported streams. | Decode and order updates, track commitment, deduplicate and control the consumer backlog. | Your backend needs richer filters or handles enough events to justify a streaming pipeline. |
| RPC + Raw ShredStream | Native block fragments delivered over UDP to your registered receiver. | Receive, reconstruct and decode data, handle gaps, then verify state and execution. | You have a shred-processing pipeline and have measured the benefit for your workload. |
Recovery changes the choice. Solana RPC provides 2 days of replay; gRPC provides 100 slots. Reconcile reconnect gaps within the available window and validate recovered records.
Raw shreds deliver data for your own parsing. Use transaction status to verify execution and check the service’s documented plan limits.
Consider a bot with a target-allocation rule you define. An account update prompts a fresh state read. Your rule may approve a swap or decide to do nothing.
A WebSocket account notification is a trigger. Refresh the relevant balances and state at an explicit commitment before evaluating your rule.
Jupiter Swap API V2 /build is one external option. It returns instructions, blockhash metadata and lookup-table data for a transaction you compose and sign.
Check mints, size, slippage and fee budget. Simulate the final instructions. Keep the signing key in your own application environment.
Save the intent, signed bytes, signature and lastValidBlockHeight before sending. Track the same attempt until you can reconcile its result.
For TPU Sender, add a transfer to an accepted tip account before signing. Jupiter's tipAmount belongs to its own submission path; it is not a substitute for the TPU Sender tip. The self-managed /build route does not use Jupiter /execute.
on account_update:
state = refresh_confirmed_state()
intent = strategy.evaluate(state, limits)
if not intent: return
instructions = external_builder.build(intent)
attempt = simulate_then_sign(instructions)
journal.persist(intent.id, attempt)
submit(attempt.signed_bytes)
reconcile(attempt.signature,
attempt.lastValidBlockHeight)If submission times out, check the original transaction before attempting another swap.
Use an intent ID for the business decision and a signature for each signed attempt. A retry of the same signed bytes and a newly signed transaction have different consequences.
Check the known signature through regular RPC. If the outcome is unresolved and the blockhash is still valid, retry the same signed bytes with bounded backoff.
On TPU Sender HTTP 429, respect Retry-After. Repeated requests share the client profile's quota. Inspect JSON-RPC errors even when HTTP returns 200.
Compare the current block height with the saved lastValidBlockHeight. Stop rebroadcasting after expiry. Check the earlier result and current state before requesting a new quote and signing again.
Use block height to determine expiry, then check the saved signature to see whether the transaction landed while it was valid. A fixed timer in seconds cannot establish expiry.
Deduplicate transaction events by signature and event position when one transaction contains several actions. A higher commitment updates the existing event rather than creating another decision.
For gRPC account writes, retain account, slot and write_version with source context. Several writes can occur in one slot; slot alone is not a safe duplicate key.
Pause new decisions. Reconnect with backoff, restore filters, buffer new events and refresh the relevant account state. Reconcile outstanding submissions before resuming.
Use address history to investigate transaction gaps within the RPC retention window and quota. Refresh account state separately, since transaction history may omit intermediate account writes.
Record the execution error and refresh state. Conditions can change after simulation: a stale quote or a slippage check can still reject the swap.
For the example, success means the target commitment is reached and err is null. Inspect transaction details for the actual outcome.
Processed is the node's newest processed view and can roll back. Confirmed has a supermajority vote. Finalized is the strongest standard confirmation state.
Set commitment explicitly and keep blockhash and preflight settings consistent. Continue checking unresolved null statuses.
Start with RPC reads, signed-transaction submission and WebSocket access, all included in both entry options below.
RPC + WebSocket from $40 / 30 days. Add gRPC or a separate sender when your workload needs them.
For a focused account list and a measured workload.
Request a free trial up to 24h; our team confirms availability and setup. Purchase with a Solana wallet and USDC portal balance.
For backends that need Yellowstone account or transaction events.
Request a free trial up to 24h; our team confirms availability and setup. Check subscription and watched-address limits.
Size the actual workload. RPC methods have different weights: getTransaction costs 10 RPS units and getAccountInfo costs 2. Subscription changes also use quota. Include state reads, confirmation checks, reconnect bursts, active filters and sends when choosing a plan.
Forward signed transactions through parallel delivery channels, including staked TPU connections with SWQoS. Use your RPC for reads, simulation, network confirmation and execution status.
Request an API key or a free trial up to 24h through Supanode on Telegram. Our team confirms trial availability and setup.
The Bundle price covers its included services within plan limits. Buy through the portal using a Solana wallet and USDC. Request a free trial up to 24 hours from our team; availability and setup are confirmed separately.
Budget Solana base and priority fees, plus a TPU Sender tip if used. External API terms, your server and storage are separate. The signing wallet also needs the required balances.
Connect your strategy and protocol decoder to the data feed. Build and sign transactions, persist each attempt and add recovery and operational controls.
RPC with targeted WebSocket subscriptions can support a small account-focused loop. Add gRPC when you need its filters or event volume, and size the plan using method restrictions, subscription quotas and measured consumer performance.
Regular Solana RPC supports sendTransaction. TPU Sender adds a separate delivery path with its own key, tip and request limits. Keep RPC for reads and confirmation checks.
Solana RPC provides 2 days of replay; gRPC provides 100 slots. Restore current state, recover within the available window and validate the resulting journal. Keep unresolved gaps visible and confirm the coverage needed by your application before relying on it.
A timeout can hide a successful submission. Keep the original signature, check its status and retry the same signed bytes while valid. Before creating a replacement, reconcile the earlier attempt and state. A new blockhash and signature create a separate attempt that could execute as well.
Use Jupiter V2 /build to obtain instructions for a transaction you assemble and submit yourself. The /order and /execute endpoints form a separate managed path. Validate transaction format, instruction composition and any TPU Sender tip before integrating your builder.
Add raw shreds when your team can operate the receiver and processing pipeline and measurements justify the work. Use historical data for research and backtesting alongside your live execution loop.
Use these references for RPC behavior, transaction construction and the published product limits.