Connect balances, wallet approval and transaction status in your Solana DeFi application.
Supanode supplies RPC and live account updates. Your team builds the interface, integrates the protocol and keeps each state in sync.
A user changes an amount, waits to sign, switches wallets or opens another app. Keep the wallet view, swap preview and transaction record separate so the interface can explain what it actually knows.
Scroll table horizontally.
| State | Keep with it | Refresh it when |
|---|---|---|
| Wallet view | Wallet address, selected token accounts, balance, commitment and context slot. | The wallet changes, an account updates, a swap completes or the stream reconnects. |
| Swap preview | Input and output mints, raw input amount, route, expected output and slippage threshold. | The user changes the intent or the preview becomes stale. |
| Transaction intent | Your intent ID, exact message, signature and last valid block height. | The wallet signs, submission changes or a signature status arrives. |
Read related addresses together with getMultipleAccounts where useful. Label the returned commitment and slot. Separate RPC responses and a Jupiter quote do not form a single atomic snapshot.
Your browser talks to your application API. Your backend holds the upstream credentials, prepares the transaction and tracks its result. The user's wallet approves the exact message.
Balance view
Swap preview
Pending / confirmed UI
Credentials & quota budget
State cache & subscriptions
Build, simulate & validate
Intent + signature journal
Read and update state.
Simulate, send, verify.
Route and swap instructions.
Your app assembles the transaction.
Execute signed instructions.
Apply protocol rules.
Supanode WebSocket authenticates with an x-token header during the handshake. The browser WebSocket constructor has no arbitrary-header argument. Use a backend bridge for this design and expose only the application data each session needs.
The swap preview comes from Jupiter. This example has no separate oracle feed. Lending positions, oracle freshness and protocol-specific risk checks require their own integration.
Turn a wallet action into a verified result. This Jupiter swap example connects balances, user approval and transaction status through your own backend.
A user requests 0.1 SOL to USDC. The amount is illustrative; no market quote or USDC output is assumed. The wallet retains the signing key throughout.
Discover the selected token accounts. Read balances, request Jupiter V2 /build and show the route, input, minimum output and fees. Refresh when the intent changes.
Your backend validates the instructions, assembles the message and simulates it through RPC. Set a compute budget and fee cap. Simulation checks current conditions; execution may still fail.
The user approves the exact message. Persist its signature before submission, then send the signed bytes through RPC. A changed message needs a new preview and signature.
Check the known signature. Show confirmed success only when err=null and the selected confirmation level is reached. Refresh balances independently and label finalization separately.
Scroll table horizontally.
| Event | Transaction UI | Balance UI |
|---|---|---|
| Wallet signs | Signing complete | Fresh at S |
| RPC returns signature | Submitted - checking | Refresh pending |
| WebSocket disconnects | Check known signature via RPC | Stale - reconnecting |
| Confirmed, no program error | Confirmed | Refreshing accounts |
| New snapshot arrives | Confirmed | Fresh at S2 |
S and S2 are symbolic slots. A wallet balance can also change through other apps. A detailed amount receipt should decode the transaction identified by the signature, rather than attribute every balance change to this swap.
on RPC_ACCEPTED(signature):
show "Submitted - checking"
on STATUS(err = null, level = confirmed):
show "Confirmed"
refresh_wallet_accounts()
on TIMEOUT or UNKNOWN_STATUS:
check_saved_signature()
keep "Checking" until reconciled
require new approval for a new messageA socket reconnect restores the connection. Your application still needs a new account snapshot and a decision about pending transactions.
Known accounts
Commitment + slot
Mark cache stale
Keep the signature
Resubscribe
Discover + read
New snapshot
New preview if needed
Buffer updates while taking the snapshot. Use context slots to reject clearly older data; reread ambiguous same-slot changes. minContextSlot is a lower bound for evaluation, not a request for historical state at an exact slot.
A snapshot restores the balances the UI needs now. Discover newly created token accounts before rebuilding the watchlist.
Keep your own intent and signature journal. A snapshot cannot reconstruct every event missed during the gap. Solana RPC provides 2 days of replay; gRPC provides 100 slots.
Scroll table horizontally.
| What happened | What the user sees | What your backend does |
|---|---|---|
| Wallet rejects | Cancelled | Stop before submission. Keep the intent editable. |
| Quote or balance changes | Updated preview | Rebuild and request approval for the new message. |
| Program error | Failed, with signature if submitted | Record the error and refresh state. |
| Send timeout / null status | Checking | Look up the saved signature. Retry identical bytes only while valid under your retry policy. |
| Blockhash expires | Reconciliation or explicit retry | Check block height and available history. A new message needs new approval. |
| 429 / subscription limit | Refresh delayed | Back off, coalesce reads and avoid reconnect storms. |
For this user-approved swap, the baseline is RPC + WebSocket behind your backend. Subscribe to the accounts you need. Measure the fanout before adding a larger stream.
Initial reads, account updates, simulation, submission and confirmation checks. Both are included in the Bundle.
Explore RPC / WebSocketFrontend, wallet adapter, backend API, protocol decoding, cache, quota controls and intent journal.
Read authentication requirementsUse V2 /build for instructions and transaction control. Your app owns assembly and self-managed landing through its RPC.
Jupiter /order returns an assembled transaction; your user signs it and /execute manages landing. This is a separate integration path. Supanode can still serve your balance and state reads.
/build transactions cannot use /execute. An extra Sender is not required for Jupiter-managed landing.
Polling can replace push for an early prototype if you show cache age and budget the extra reads. gRPC becomes useful for measured backend address and filter volume, with its own plan limits. Raw shreds, an Indexer and Dedicated nodes are separate choices.
Free trial up to 24 hours on request; our team confirms availability. RPC + WebSocket from $40 / 30 days.
Request a free trial from our team, then measure weighted RPC calls, submissions, concurrent subscriptions and reconnect traffic to select a plan.
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.
RPC methods have different weights. Token-account discovery and transaction receipts cost more than simple status checks. Share a backend quota budget across users; a user session does not need its own upstream connection.
Your backend compute, storage and monitoring; Jupiter access and route-specific charges; Solana network and priority fees; token-account creation where needed. Bundle RPC and WS are already included together.
Request a free trial up to 24 hours; our team confirms availability and setup. Buy Bundles in the portal with a Solana wallet and USDC. Each Bundle runs for 30 days.
This example composes instructions for an existing Jupiter-routed swap. Your frontend and backend can integrate that flow without adding a new on-chain application program. A custom vault, lending market or other protocol has its own contract and security work.
Keep the Supanode token on your backend. Its WS client supplies the x-token handshake header and sends application data to the browser.
It is a quote for a particular input, route and slippage policy. This example does not integrate a separate oracle feed. A lending or risk engine must check the specific protocol's oracle and position requirements.
It means RPC accepted the signed transaction for submission. Track the signature and inspect its error and confirmation status. Keep pending, confirmed error, confirmed success and finalized states distinct.
The recovery shown here rereads current accounts and restores subscriptions. Solana RPC provides 2 days of replay; gRPC provides 100 slots. Validate recovered intervals and use your own operation journal to reconcile intermediate changes.
When the backend workload needs its account and transaction filtering or higher-volume streaming. First measure your addresses, subscriptions and RPC budget. RPC + scoped WebSocket is the baseline here; gRPC starts at FOCUS and has separate limits.
Yes. Use its managed /order + /execute path, where your user signs the supplied transaction. Keep that flow separate from the Router /build path. Supanode can continue serving your own wallet and application-state reads.
The user requests a swap, reviews it and approves it with a wallet. A liquidation keeper watches protocol eligibility and acts under its own capital and signing policy. The keeper needs a separate position and oracle integration.
Use these references for the Jupiter integration, Solana transaction lifecycle and Supanode access conditions.