Turn observed wallet swaps into new trades with your own policy, limits and signing.
Successful transaction at your selected commitment.
Fresh route, own limits, own signature. Confirm the result.
A transaction can contain transfers, account setup and several nested program calls. Classify the whole supported action before you create a trade.
Solana copy trading starts with an observed wallet action. Your application identifies the swap, applies its own limits and signs a new transaction.
Supanode supplies streams, RPC reads and transaction delivery. You build the decoder, trading policy and bot.
Start with one supported program version and one clearly attributed swap. Verify the wallet's authority, input and output mints, successful status and token-account ownership.
This example follows a wallet that authorizes a single supported swap. Unknown aggregators, multiple actions and unclear attribution are skipped until you add a tested adapter.
See Raydium CP-Swap's input/output modelOne swap can settle through several inner token transfers. Group them under the recognized action; treating every transfer as a fresh swap can trigger several unwanted trades.
Solana's parsed JSON can still contain partially decoded instructions. A wallet-address filter also does not cover every transfer involving its token accounts when the owner address is absent from the transaction account list.
The source swap is an input to your decision. Your size and current liquidity determine a separate route.
Sample data
Synthetic trade amounts and labels.
Quote your own trade at the current price and check its result separately.
Your chosen input
Set by your policy and available balance.Your new quote
Current route for your own size.Your minimum output
Illustrative 100 bps tolerance on 198 B.198 × (1 - 100 / 10,000) = 196.02 BScaling the source trade would suggest 200 B. Your fresh quote is 198 B. Slippage applies to this new quote; it does not restore the source price.
Simulation can expose a failure before submission. A successful simulation does not guarantee the transaction will execute.
action = decode_supported_swap(source_tx)
if action.failed_or_ambiguous:
audit_and_skip()
key = (network, wallet, source_signature)
intent = reserve_once(key)
if not intent.is_new:
stop_duplicate()
route = fresh_route(own_size, allowed_mints)
check_policy_route_and_simulation(route)
own_tx = build_and_sign(route, own_wallet)
persist_before_send(intent, own_tx)
submit(own_tx)
reconcile(own_tx.signature)For a limited watchlist, WS logs plus RPC transaction reads provide a clear starting architecture. gRPC transactions are an alternative when full payload delivery fits your workload.
Scroll the table sideways for the full comparison.
| Data path | Supanode provides | You implement |
|---|---|---|
| WebSocket + RPC | Mention-filtered logs with signature and status. RPC reads the confirmed transaction. | Backend WS client that supports auth headers, hydration queue, supported decoder, policy, persistent state and signer. |
| Yellowstone gRPC + RPC | Transaction payloads filtered by specified addresses. RPC supports state checks and confirmation. | Yellowstone client, supported swap decoding and local policy to classify address-matched transactions. |
| RPC polling | Available transaction-signature history and transaction lookups. | Pagination, polling delay and rate control. Plan recovery within the 2-day Solana RPC replay window and the available method budget. |
Start this example with WS + RPC or gRPC. A raw-shred path needs your own receiver, reconstruction pipeline and swap decoder.
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.
Each getTransaction costs 10 RPC RPS units. Other reads and subscription commands share the budget; retries and backfill add load.
10 × hydrated candidates/s + other weighted RPC + subscription commands ≤ plan RPC budgetUse the equation to estimate RPC demand. Measure live activity and recovery traffic before choosing a tier.
RPC method weights and limits / gRPC subscription and address limitsForward signed transactions through parallel delivery channels, including staked TPU connections with SWQoS. Use your RPC for reads, simulation, network confirmation and execution status.
Submit your own signed transaction through RPC, or use optional TPU Sender. Account for any priority fees.
HTTP API-key access and separately authorized QUIK transport have different setup.
Request an API key or a free trial up to 24h through Supanode on Telegram. Our team confirms trial availability and setup.
Budget for one selected Bundle, network fees, optional tips, external router/API access and your own server and storage. A Bundle covers the RPC, WS and gRPC services included in its tier.
Paid Bundle plans start in the portal with a Solana wallet. Request a free trial up to 24 hours from our team; availability and setup are confirmed separately. Paid Sender access follows its separate key and tip model.
The example uses confirmed source transactions. If you act earlier, define how the client handles rollbacks and validates the source action.
Observe commitment, source slot, first-seen time, queue delay and route age separately. A notification's arrival time is not the source execution time; transaction blockTime may be absent.
Persist the event identity and trading intent. A repeated source signature or commitment upgrade updates the existing record.
(network, followed_wallet, source_signature)The policy version belongs in the record. Changing it must not accidentally turn an old event into a second purchase.
Restore the live subscription and buffer arriving events while you investigate the gap.
Page available RPC signatures toward the saved checkpoint with overlap. Hydrate candidates within your rate budget.
Merge live and recovered signatures. Old recovered events are audit-only by default; fresh ones still pass the age gate.
If the checkpoint cannot be reached, mark an unresolved gap and pause automatic following until resync or an operator decision.
Solana RPC provides 2 days of replay; gRPC provides 100 slots. Budget recovery reads and validate the interval you recover. A new balance snapshot cannot prove that every missed trade was recovered.
Reserve the intent atomically and save your own signed bytes and signature before sending. If a send times out or the process restarts, check that signature before building another transaction.
Check the old transaction's status and expiry first. A replacement needs a fresh route and another policy check. Re-signing creates a new transaction and can create a second trade if the original already landed.
Implement source selection, supported swap decoding, allowlists and position sizing. Add transaction construction, signing and persistent state to track and recover each attempt.
No. Check successful status and decode a supported action with clear wallet attribution. Transfers, failed attempts and unknown program versions are not sufficient. The bounded example skips ambiguous routes and multiple actions. Extending support requires a tested adapter and an explicit policy.
The follower makes a new trade with a new size, route and signature. Check a fresh quote and set minimum output for that transaction; liquidity, price and ordering can change after the source trade.
Start with WS + RPC for a limited watchlist. Use gRPC for transaction payloads within its plan and address limits, and add Sender as an optional delivery path. Choose capacity from observed activity, processing needs and recovery demand.
Run the watcher on your backend with a WS client that supplies the authentication header. Keep service tokens and signing keys on the server.
Solana RPC provides 2 days of replay; gRPC provides 100 slots. Match the gap to the available window and rate budget, validate recovered records and mark unresolved intervals explicitly. Keep your own durable records for a complete audit trail.
Implement and test the supported decoder against the deployed program version. Validate API integration, endpoint behavior, duplicate handling and transaction reconciliation with your own workload. The sample amounts illustrate the arithmetic.
Use these protocol definitions and product references to build and test your application.