[Use cases](https://telegram.me/supanode_tgs) / DeFi applications

# Build a Solana DeFi app.

Connect balances, wallet approval and transaction status in your Solana DeFi application.

[\[ TRY RPC + WEBSOCKET \]](https://stg.portal.supanode.xyz/)[See the application flow](https://supanode.xyz/cases/defi#architecture)

One user action SOL to USDC

Wallet

Available balanceRPC snapshot + scoped updates

Preview

Route, amount, slippageJupiter V2 /build

Transaction

Signed, submitted, checkedYour app + wallet + RPC

A returned signature starts confirmation tracking.

[Application state](https://supanode.xyz/cases/defi#state)[Architecture](https://supanode.xyz/cases/defi#architecture)[Swap example](https://supanode.xyz/cases/defi#example)[Recovery](https://supanode.xyz/cases/defi#recovery)[Stack](https://supanode.xyz/cases/defi#stack)[Cost & access](https://supanode.xyz/cases/defi#access)[FAQ](https://supanode.xyz/cases/defi#faq)

[RPC / WebSocket](https://supanode.xyz/services/solana/rpc)[Yellowstone gRPC](https://supanode.xyz/services/solana/grpc)[Authentication](https://supanode.xyz/docs/solana/authentication)[Bundle plans](https://supanode.xyz/pricing/solana#bundles)

## One action. Three kinds of state.

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.

## Give the backend a clear boundary.

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.

### Your frontend

Balance view  
Swap preview  
Pending / confirmed UI

User wallet  
Signs the exact message

Intent / signed bytesApp API / own stream

### Your backend

Credentials & quota budget  
State cache & subscriptions  
Build, simulate & validate  
Intent + signature journal

Supanode RPC / WS

Read and update state.  
Simulate, send, verify.

Jupiter V2 /build

Route and swap instructions.  
Your app assembles the transaction.

Solana programs

Execute signed instructions.  
Apply protocol rules.

Illustrative application architecture. The SDK handles message encoding and account decoding. Your team maintains the integration and policy.

### Keep paid credentials server-side.

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.

## A swap from request to receipt.

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.

1.  ### Read and preview
    
    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.
    
2.  ### Prepare for approval
    
    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.
    
3.  ### Sign and submit
    
    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.
    
4.  ### Verify and refresh
    
    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.

Client state policy - pseudocode

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

Pseudocode for your application policy.

## Recover the view before calling it fresh.

A socket reconnect restores the connection. Your application still needs a new account snapshot and a decision about pending transactions.

1.  ### Fresh
    
    Known accounts  
    Commitment + slot
    
2.  ### Connection lost
    
    Mark cache stale  
    Keep the signature
    
3.  ### Reconcile
    
    Resubscribe  
    Discover + read
    
4.  ### Refresh UI
    
    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.

### Current view

A snapshot restores the balances the UI needs now. Discover newly created token accounts before rebuilding the watchlist.

### Operation history

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

## Start with RPC and scoped subscriptions.

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.

### Supanode RPC / WebSocket

Initial reads, account updates, simulation, submission and confirmation checks. Both are included in the Bundle.

[Explore RPC / WebSocket](https://supanode.xyz/services/solana/rpc)

### Your application

Frontend, wallet adapter, backend API, protocol decoding, cache, quota controls and intent journal.

[Read authentication requirements](https://supanode.xyz/docs/solana/authentication)

### Jupiter integration

Use V2 `/build` for instructions and transaction control. Your app owns assembly and self-managed landing through its RPC.

[Read the Router integration](https://developers.jup.ag/docs/swap/build/index)

### Prefer managed swap execution?

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.

[Compare Jupiter Order & Execute](https://developers.jup.ag/docs/swap/order-and-execute)

Polling can replace push for an early prototype if you show cache age and budget the extra reads. [gRPC](https://supanode.xyz/services/solana/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.

## Budget the whole application.

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.

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)

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.

### Keep these costs separate.

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 TRIAL \]](https://telegram.me/supanode_tgs)[Compare Bundle plans](https://supanode.xyz/pricing/solana#bundles)[Read method limits](https://supanode.xyz/docs/solana/rpc/limits)

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.

## DeFi application questions.

### Do I need to deploy my own smart contract?

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.

### Can I put the Supanode key in the browser?

Keep the Supanode token on your backend. Its WS client supplies the x-token handshake header and sends application data to the browser.

### Is the swap quote an oracle price?

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.

### Does a returned signature mean the swap succeeded?

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.

### Will reconnecting replay every missed update?

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 should I choose gRPC?

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.

### Can Jupiter handle landing instead?

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.

### How is this different from a liquidation bot?

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.

## Build from the primary sources.

Use these references for the Jupiter integration, Solana transaction lifecycle and Supanode access conditions.

-   [Jupiter V2 Router /build](https://developers.jup.ag/docs/swap/build/index) and [compute budget](https://developers.jup.ag/docs/swap/advanced/compute-units)
-   [Jupiter managed Order & Execute](https://developers.jup.ag/docs/swap/order-and-execute)
-   [Solana account reads](https://solana.com/docs/rpc/http/getmultipleaccounts) and [account subscriptions](https://solana.com/docs/rpc/websocket/accountsubscribe)
-   [RPC submission](https://solana.com/docs/rpc/http/sendtransaction), [signature status](https://solana.com/docs/rpc/http/getsignaturestatuses) and [expiration](https://solana.com/developers/cookbook/transactions/confirmation)
-   [Supanode authentication](https://supanode.xyz/docs/solana/authentication), [WS limits](https://supanode.xyz/docs/solana/websocket/limits) and [gRPC restrictions](https://supanode.xyz/docs/solana/grpc/restrictions)
-   [Bundle plans](https://supanode.xyz/docs/solana/pricing/plans) and [trial conditions](https://supanode.xyz/docs/solana/pricing/free-trials)

[Trading bot infrastructure](https://supanode.xyz/cases/trading)[Liquidation infrastructure](https://supanode.xyz/cases/liquidation-bot)[Historical analysis](https://supanode.xyz/cases/analytics)[Talk to Supanode](https://telegram.me/supanode_tgs)

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