[Use cases](https://telegram.me/supanode_tgs) / Build a Solana trading bot

# Build a Solana trading bot.

Connect live signals to your strategy, signed transactions and verified outcomes.

[\[ CHOOSE YOUR STARTING STACK \]](https://supanode.xyz/cases/trading#stack)[Read RPC docs](https://supanode.xyz/docs/solana/rpc/overview)

Attempt journalIllustrative

One decision.  
One tracked intent.

Signal

Account changed

Decision

Risk checks passed

Submission

Signature recorded

Outcome

Awaiting confirmation

Track the returned signature to check confirmation and the swap result.

[The execution loop](https://supanode.xyz/cases/trading#route)[Choose an interface](https://supanode.xyz/cases/trading#interfaces)[A swap attempt](https://supanode.xyz/cases/trading#example)[Failures & recovery](https://supanode.xyz/cases/trading#recovery)[Cost & access](https://supanode.xyz/cases/trading#stack)[FAQ](https://supanode.xyz/cases/trading#faq)

## Close the loop on every decision.

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.

1.  Supanode data
    
    ### Observe
    
    Read account state. Receive account or transaction updates with a slot and chosen commitment.
    
2.  Your application
    
    ### Decide
    
    Decode, remove duplicates and refresh state. Check size, slippage, balances and allowed programs.
    
3.  Your application
    
    ### Build & sign
    
    Compose instructions with an external builder or protocol SDK. Set fees, simulate and sign locally.
    
4.  Supanode delivery
    
    ### Submit
    
    Send signed bytes through regular RPC or TPU Sender. Record the signature and expiry.
    
5.  Your app + RPC
    
    ### Reconcile
    
    Check commitment and execution error. Inspect the result and refresh balances before the next related action.
    

Result feeds the next state checkReconcile → refresh state → decide again

## Choose the data your bot can use.

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](https://supanode.xyz/services/solana/rpc) | 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](https://supanode.xyz/services/solana/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](https://supanode.xyz/services/solana/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.

[gRPC restrictions](https://supanode.xyz/docs/solana/grpc/restrictions)[gRPC quotas & filters](https://supanode.xyz/docs/solana/grpc/limits)[WebSocket restrictions](https://supanode.xyz/docs/solana/websocket/restrictions)

## Follow one swap attempt.

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.

**Conceptual example**Example application flow for assembling and tracking a swap.

1.  ### Read the current state
    
    A WebSocket account notification is a trigger. Refresh the relevant balances and state at an explicit commitment before evaluating your rule.
    
2.  ### Obtain swap instructions
    
    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.
    
3.  ### Validate the final transaction
    
    Check mints, size, slippage and fee budget. Simulate the final instructions. Keep the signing key in your own application environment.
    
4.  ### Persist, submit, then inspect
    
    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`.

[Jupiter /build documentation](https://developers.jup.ag/docs/swap/build)

Illustrative pseudocode

```
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)
```

Example journal entryIllustrative

intent\_id

allocation-A

signature

recorded before send

target\_commitment

confirmed

state

unresolved

next\_action

check signature status

If submission times out, check the original transaction before attempting another swap.

## Keep a failure from becoming a second trade.

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.

### Submission times out

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.

### The blockhash expires

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.

### The same event arrives twice

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.

### The stream disconnects

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.

### The transaction executes with an error

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.

### Choose how much certainty to wait for.

**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.

[Confirmation & expiry](https://solana.com/developers/cookbook/transactions/confirmation)[Safe transaction retries](https://solana.com/developers/cookbook/transactions/retry)[TPU Sender retry handling](https://supanode.xyz/docs/solana/sender/send)

## Choose the base.  
Add delivery when needed.

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.

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 \]](https://telegram.me/supanode_tgs)[Documentation](https://supanode.xyz/docs/solana/rpc/overview)

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 \]](https://supanode.xyz/pricing/solana#bundles)[Documentation](https://supanode.xyz/docs/solana/grpc/overview)

**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.

[RPC method weights](https://supanode.xyz/docs/solana/rpc/limits)

Solana

### TPU Sender

Optional · transaction delivery

Forward signed transactions through parallel delivery channels, including staked TPU connections with SWQoS. Use your RPC for reads, simulation, network confirmation and execution status.

-   50 requests/s per client profile by default
-   Plus Solana network fees
-   No monthly subscription · trial on request

0.00015 SOL

minimum tip / transaction

Request an API key or a free trial up to 24h through Supanode on Telegram. Our team confirms trial availability and setup.

[\[ REQUEST KEY \]](https://telegram.me/supanode_tgs)[Documentation](https://supanode.xyz/docs/solana/sender/start)

### Infrastructure

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.

### Execution & your application

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.

[Full pricing & included services](https://supanode.xyz/docs/solana/pricing/plans)[TPU Sender tips & limits](https://supanode.xyz/docs/solana/sender/tips)[Discuss a dedicated workload](https://supanode.xyz/services/solana/dedicated-node)

## Before you connect.

### What does my application need to implement?

Connect your strategy and protocol decoder to the data feed. Build and sign transactions, persist each attempt and add recovery and operational controls.

### Do I need gRPC to start?

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.

### Do I need Sender to send transactions?

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.

### How do I recover after a reconnect?

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.

### Can I sign again when submission times out?

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.

### Can I send any Jupiter transaction through this route?

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.

### When do I need raw shreds or historical data?

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.

### Go deeper into your actual strategy.

[Token & wallet monitoring](https://supanode.xyz/cases/monitoring)[Historical analysis & backtesting](https://supanode.xyz/cases/analytics)[Copy trading](https://supanode.xyz/cases/copy-trading)[Arbitrage infrastructure](https://supanode.xyz/cases/arbitrage-bot)

### Technical references

Use these references for RPC behavior, transaction construction and the published product limits.

-   [Solana RPC and commitment levels](https://solana.com/docs/rpc)
-   [Signature-status reference](https://solana.com/docs/rpc/http/getsignaturestatuses)
-   [Address-history lookup](https://solana.com/docs/rpc/http/getsignaturesforaddress)
-   [Yellowstone gRPC protocol and clients](https://github.com/rpcpool/yellowstone-grpc)
-   [Jupiter V2 custom transaction builder](https://developers.jup.ag/docs/swap/build)
-   [Supanode Bundle plans](https://supanode.xyz/docs/solana/pricing/plans)
-   [Supanode shared gRPC restrictions](https://supanode.xyz/docs/solana/grpc/restrictions)
-   [TPU Sender HTTP JSON-RPC and retry handling](https://supanode.xyz/docs/solana/sender/send)

---
Source: https://supanode.xyz/cases/trading