How to Build a Copy-Trading Bot with a Trader Data API

A copy-trading bot monitors a successful trader's wallet and automatically replicates their trades in your own account. Building one requires three components: a trader data API that exposes verified on-chain activity, real-time wallet tracking to catch trades as they happen, and execution logic that mirrors positions while managing your own risk parameters.

What Is a Copy-Trading Bot?

Copy-trading bots automate the process of following another trader's moves. Instead of manually watching a wallet and scrambling to place orders, the bot detects when your target trader buys or sells, calculates the appropriate position size for your account, and executes the same trade within seconds.

The key difference between a basic wallet tracker and a true copy-trading bot is execution. A tracker shows you what happened. A bot acts on it. That means integrating with a DEX aggregator or exchange API, handling slippage, and deciding how much capital to allocate per trade.

Copy-trading bots work across multiple chains. A trader might buy a memecoin on Solana at 8am and swap an ERC-20 on Base at 2pm. Your bot needs to track both wallets, recognize both trades, and execute on the correct chain with the correct token addresses.

Choosing a Trader Data API

You need an API that resolves a social handle to wallet addresses, returns trade history, and offers a real-time feed. Self-reported PnL or manually entered trades are useless because they can be gamed. The API must read directly from on-chain data.

Look for these features:

• Multi-chain wallet resolution: One trader, multiple wallets. If the API only gives you a Solana address but the trader also trades on Base, you miss half the signal.
• Verified trade history: Full list of buys and sells with timestamps, token addresses, amounts, and prices. You need this to backtest which traders are worth copying.
• WebSocket feed: REST polling introduces latency. A WebSocket pushes trade events the moment they hit the chain, giving you a few extra seconds to front-run slippage.
• Leaderboard and filtering: You want to browse the live trader leaderboard and filter by 7-day PnL, win rate, or trade count before hardcoding a handle into your bot.

A trader data API like fomoapi.io handles the hard part: linking a Twitter handle to both Solana and EVM wallets, verifying every trade on-chain, and streaming updates. You call /v2/users/{handle} once, get back the wallet addresses, and subscribe to those wallets over WebSocket.

Example request to fetch a trader's wallets:

GET https://api.fomoapi.io/v2/users/traderhandle
Authorization: Bearer YOUR_API_KEY

Response:

{
  "id": "12345",
  "handle": "traderhandle",
  "wallets": {
    "solana": ["ABC123..."],
    "evm": ["0xDEF456..."]
  },
  "stats": {
    "pnl_7d": 45000,
    "win_rate": 0.68,
    "total_trades": 142
  }
}

Now you have both wallets and can query /trades?user=12345 to pull historical trades or connect to wss://api.fomoapi.io/ws to stream new ones.

Finding Traders to Copy

Picking the wrong trader is the fastest way to lose money. A trader with one viral win and ten quiet losses looks impressive on Twitter but will drain your account. You need a ranked list of traders with verified track records, not self-reported screenshots.

Start by filtering the leaderboard:

• Time window: 7-day PnL is more predictive than all-time. Markets change, and a trader who crushed it six months ago might be cold now.
• Trade count: Someone with three trades and 500% PnL got lucky. Look for 50+ trades in the window.
• Win rate: Above 60% is solid. Below 50% means they are taking big bets and hoping for homeruns.
• Sharpe or drawdown: If the API exposes risk-adjusted metrics, use them. A trader with 30% PnL and 10% max drawdown is safer than one with 50% PnL and 40% drawdown.

Once you have a shortlist, pull their full trade history and run a backtest. Calculate what your returns would have been if you copied every trade with your own position sizing rules. This catches traders who made all their PnL on one or two huge wins that you would not have been able to replicate at scale.

Here is a simple scoring table you might use:

Rank traders by weighted score and copy the top three. Diversifying across multiple traders reduces the risk that one goes cold or makes a catastrophic trade.

Tracking Wallet Activity in Real Time

Polling a REST endpoint every few seconds is too slow. By the time you detect a trade, the token has already moved 5% and your entry is worse. A WebSocket feed pushes trade events the instant they are confirmed on-chain, giving you a realistic shot at copying the trade before the price runs.

Connect to the WebSocket and subscribe to the wallets you want to track:

{
  "action": "subscribe",
  "wallets": ["ABC123...", "0xDEF456..."]
}

When the trader buys 10 SOL worth of a token, you receive:

{
  "event": "trade",
  "wallet": "ABC123...",
  "chain": "solana",
  "type": "buy",
  "token_address": "TokenMintAddress",
  "amount_in": 10.0,
  "amount_out": 50000,
  "timestamp": 1704931200
}

Your bot parses this message, calculates your position size, and submits a buy order to a DEX aggregator like Jupiter (Solana) or 1inch (EVM). The entire flow takes 2-5 seconds if your execution layer is optimized.

Latency matters. A trader buying a low-liquidity memecoin can move the price 10-20% instantly. If you are 10 seconds late, you are buying the top of the pump. Use a WebSocket, run your bot in the same region as your execution infrastructure, and keep your position sizing logic simple so you do not waste time on complex calculations.

Executing Mirror Trades

Detecting the trade is half the problem. Executing it without getting rekt by slippage, gas fees, or failed transactions is the other half. You need a DEX aggregator API that finds the best route and a wallet with enough liquidity to handle the trade size.

For Solana, Jupiter is the standard. For EVM chains, 1inch or 0x work well. Both offer APIs that take a token pair and amount and return a signed transaction ready to broadcast.

Example flow for mirroring a Solana buy:

1. Receive WebSocket event: trader bought Token X with 10 SOL.
2. Calculate your position size: if you are copying at 50% scale, you buy with 5 SOL.
3. Call Jupiter API: POST /quote with inputMint=SOL, outputMint=TokenX, amount=5000000000 (5 SOL in lamports).
4. Get quote back with expected output amount and price impact.
5. If price impact is under your threshold (say 3%), call POST /swap to get the transaction.
6. Sign and broadcast the transaction.
7. Store the trade in your database with entry price, amount, and timestamp.

Set a max slippage tolerance. If the trader is buying a token with 8% price impact and you blindly copy, you are underwater before the trade even settles. A reasonable rule: skip any trade with >5% price impact or >2% slippage.

Gas fees and transaction failures are real on EVM chains. If you are copying a $200 trade and paying $30 in gas, the math does not work. Either increase your minimum trade size or only copy trades above a certain dollar threshold. On Solana, gas is negligible, but transaction failures still happen during network congestion. Retry logic and priority fees help.

Position Sizing and Risk Management

Copying a trader 1:1 is a bad idea unless you have the exact same account size and risk tolerance. If the trader has a $500k account and bets $50k on a single memecoin, copying that with your $10k account means you are all-in on one trade.

Use proportional position sizing:

• Fixed percentage: Allocate 2-5% of your account per trade, regardless of what the trader does. If they go 20% into a token, you go 3%.
• Kelly criterion: If you have enough historical data, calculate optimal bet size based on win rate and average win/loss ratio. This maximizes long-term growth but requires accurate estimates.
• Max position cap: Never put more than 10% of your account in a single token, even if the trader does.

Stop-loss rules are critical. If the trader holds through a 50% drawdown and eventually recovers, good for them. But your risk tolerance might be lower. Set a stop-loss at 15-20% below entry and exit automatically if hit. You can always re-enter later if the trader is still in the position.

Diversify across traders. If you are copying three traders and each gets 30% of your capital, a disaster from one trader only costs you 10-15% of your total account. Putting everything on one trader is a single point of failure.

Handling Multi-Chain Trades

A sophisticated trader operates on multiple chains. They might scalp memecoins on Solana in the morning and swing-trade DeFi tokens on Base in the afternoon. Your bot needs to track both wallets and execute on both chains without manual intervention.

The trader data API should return all wallets in one call. If you explore the API endpoints, you will see that /v2/users/{handle} gives you a wallets object with separate keys for Solana and EVM chains. Subscribe to all of them on the WebSocket.

Execution is where it gets tricky. You need:

• Separate wallets per chain: One funded Solana wallet, one funded EVM wallet (or one per EVM chain if you want to optimize gas).
• Chain-specific DEX integrations: Jupiter for Solana, 1inch or 0x for EVM. Each has its own API and transaction format.
• Token address mapping: The same project might have different token addresses on Solana vs. Base. Make sure you are buying the right token on the right chain.

If the trader buys Token A on Solana and Token B on Base within the same hour, your bot should execute both trades independently. Do not try to consolidate them or wait for one to finish before starting the other. Run them in parallel.

A common mistake is under-funding one of your wallets. If the trader makes three big Solana trades in a row and your Solana wallet only has enough SOL for two, you miss the third trade. Keep a buffer of at least 20% more capital than you expect to deploy per chain.

Testing and Deployment

Do not deploy a copy-trading bot to production without backtesting and paper trading. The cost of a bug is real money, and the cost of a bad trader is even worse.

Backtest process:

1. Pull 30 days of trade history for your target traders using /trades?user={id}.
2. Simulate copying each trade with your position sizing and stop-loss rules.
3. Calculate total return, max drawdown, and win rate.
4. Compare to a baseline (holding SOL or ETH over the same period).

If your backtest shows 15% return with 20% max drawdown and the baseline is 8% return with 5% drawdown, your strategy is not adding enough value to justify the risk. Adjust your trader selection, position sizing, or stop-loss rules and re-run.

Paper trading is live execution without real money. Connect to the WebSocket, detect trades, calculate position sizes, and log what you would have done. Run this for at least a week to catch edge cases like network outages, API rate limits, or unexpected trade types.

Once you deploy, monitor constantly:

• Trade latency: How long between the trader's trade and your execution? Aim for under 5 seconds.
• Slippage: Are you consistently getting worse prices than expected? You might need a better DEX aggregator or lower position sizes.
• Failed transactions: Track retry rates and failure reasons. If 10% of your trades are failing, something is wrong with your execution layer.
• PnL divergence: Is your PnL tracking the trader's? If they are up 10% and you are flat, you are either missing trades or getting terrible fills.

Set up alerts for critical events: wallet balance drops below threshold, API key rate limit hit, WebSocket disconnects for more than 60 seconds, or a single trade loses more than 5% of your account.

Closing Notes

Building a copy-trading bot that actually works requires verified trader data, real-time wallet tracking, and disciplined execution. The hard part is not writing the code. It is finding traders worth copying, sizing positions correctly, and managing risk across multiple chains. A trader data API like fomoapi.io handles the data layer so you can focus on the strategy and execution. If you want to see which traders are performing right now, view API pricing tiers and get access to the full leaderboard and WebSocket feed.