◆ FOR COPY-TRADING BOTS

Solana infrastructure for copy-trading bots.

A copy-trading bot needs a clean loop: watch selected wallets, decide what is safe to follow, build its own transaction, send it, and reconcile the result.

Get Started →See the numbers →

◆ THE WORKLOAD

What decides the outcome.

A production copy-trading bot does more than repeat a transaction. It watches an allowlist of leader wallets, identifies relevant swaps or position changes, checks token, venue, size, slippage, and exposure rules, then builds and signs a new follower transaction. After submission it must track confirmation and update local state without executing the same leader action twice.

A filtered transaction stream removes the need to poll every watched wallet and reduces the unrelated payload your parser must handle.
Processed updates arrive earlier but can be dropped on a fork. Treat detection, submission, and confirmed reconciliation as separate states instead of assuming the first notification is final.
The follower transaction needs its own quote, slippage limit, priority fee, size rule, and idempotency key. Copying bytes from the leader is neither reliable nor a risk policy.
For this workload, a stable filtered stream and a measured send path matter before the fastest possible shred feed. Benchmark that upgrade only after the basic loop is correct.

◆ THE STACK

The path, mapped.

Yellowstone gRPC

Subscribe to transactions that mention watched wallets or programs, then update filters as the watchlist changes.

Explore Yellowstone gRPC →

Solana RPC

Fetch quotes and account state, simulate the follower transaction, and reconcile signatures at the commitment level your policy requires.

Explore Solana RPC →

Transaction sender

Submit the locally signed follower transaction through the available relay paths and keep landing telemetry separate from strategy logic.

Explore Transaction sender →

Primary implementation references.

◆ FAQ

Straight answers.

Which wallet activity should a copy-trading bot subscribe to?

Start with transactions that mention the leader wallets and the programs or venues your strategy supports. Keep the watchlist and program allowlist explicit. The stream finds candidates; your parser still has to classify the action and reject anything outside the bot's policy.

Should a copy-trading bot act on processed or confirmed data?

Processed is earlier and can be useful for detection, but it can be rolled back. A common design separates the early signal from durable accounting: detect at processed when the risk policy allows it, then reconcile the leader and follower signatures at confirmed or finalized commitment before treating the action as settled.

Does a copy-trading bot need decoded shreds?

Not for the first production version. A filtered Yellowstone transaction stream, RPC for simulation and state, and a measured sender cover the core loop. Consider an earlier data source only when workload benchmarks show that stream timing is the limiting factor.

Bring the watchlist size, supported venues, and follower policy. We will map the filters, RPC calls, and send path without forcing the bot into an HFT stack.

Get Started →See pricing →