Polymarket Copy Trading Bot: How to Mirror Profitable Wallets

A copy trading program observes another wallet and decides whether to reproduce its exposure. Public activity is useful evidence of completed trades, but it does not reveal every pending order, hedge or reason behind a position.

What public wallet data shows

The Data API exposes activity, positions and trading information, while market discovery and books come from Gamma and CLOB. The current Data API uses its documented pagination and response envelope. Store a cursor or a durable event identifier so reconnecting does not repeat a previously handled trade.

A public record is an observation after an activity occurs. By the time it reaches the follower, available prices and depth may differ. A copied position can therefore have different costs and outcomes from the original position. The same gap exists in copy trading in other markets, where followers also act after the source has traded.

Choose wallets using more than headline returns

Review the length of the history, realized versus unresolved exposure, concentration and trade sizes. Consider whether activity reflects a hedge, liquidity provision or an event-specific strategy. An apparently profitable isolated wallet may omit positions held elsewhere.

Do not infer repeatable returns from selected winning trades. Evaluate the full period available and retain losing or unresolved events. Avoid a fixed claim about the proportion of winning wallets when it is not established by the current official documentation.

Build a wallet review record

Start with the complete period you can observe rather than a leaderboard screenshot. Record when the wallet was first followed, which markets it traded, the largest open exposure and the number of unresolved events. Separate deposited or transferred assets from trading results wherever the available data allows. A rising wallet balance is not by itself proof of profitable trading.

Create one review record per wallet and update it on a fixed schedule. Include both realized outcomes and positions still awaiting resolution. Do not remove a wallet from the historical test simply because it later performs poorly. Selecting only wallets that survived to the end introduces information that would not have existed when the copy decision was made.

Look for concentration as well as activity. Ten contracts may all depend on one election, sporting event or cryptocurrency threshold. A source can also trade several wallets or hold an offsetting position elsewhere. Those unknowns should remain recorded as unknowns rather than filled with assumptions about the trader's intent.

Review market rules directly when adding a new event family. A wallet's historical trading frequency says little about a contract with a different deadline or resolution source. Keep that review separate from the source ranking, so a highly ranked wallet cannot override a rejected market definition.

Choose an explicit copying policy

There are two different policies to test: copying individual observed trades and adjusting toward a target position. A trade copier reacts to new activity. A position follower compares the source's observed holdings with its own target exposure. Combining them without a clear rule can double count a trade already reflected in the position snapshot.

For a simple first experiment, follow only new activity after a recorded start time. Do not automatically acquire the source's entire pre-existing portfolio. Those positions may have very different entry prices and could be approaching an exit. If existing positions are included, model them as separate decisions at the follower's current achievable price.

Set entry and exit rules before testing. Specify how to handle a source adding to a position, reducing it or changing to the opposing outcome. A reduction in the source position does not necessarily imply that the follower should sell the same number of shares, because the follower may have entered later or filled only part of its target.

Copy-trade execution workflow

• Read new activity and deduplicate it using stable identifiers.
• Map the activity to the current market and outcome asset.
• Inspect executable depth, fee parameters and market status.
• Scale exposure using the follower’s own limits, not the source wallet’s balance.
• Record fills and residual exposure, then reconcile before a retry.

The current SDKs are polymarket-client for Python and @polymarket/client for TypeScript. Public clients support observation; secure clients add authenticated trading. New-account wallet setup uses the Deposit Wallet flow, while legacy wallet types remain supported.

The raw call behind wallet observation is the Data API v2 activity route, GET https://data-api.polymarket.com/v2/activity?user=<wallet>, which returns rows in a data array and a pagination.next_cursor for the next page. Data API v1 routes retire on 24 October 2026 (Polymarket docs, checked on 10 Oct 2026). Trade rows carry transaction_hash, asset_id, side, shares and price, which together make a workable deduplication key.

This short Python sketch uses only calls from Polymarket's SDK docs. It records paper decisions and places a limit order only when LIVE is set to True:

import asyncio, os
from polymarket import AsyncPublicClient, AsyncSecureClient

SOURCE = "0x..."   # the wallet you follow
LIVE = False       # paper mode until you change this
seen = set()       # keep this in a database in practice

async def copy(trade, size="10"):  # size from your own rules
    if not LIVE:
        print("PAPER", trade.side, size, trade.asset_id, "limit", trade.price)
        return
    async with await AsyncSecureClient.create(
        private_key=os.environ["POLYMARKET_PRIVATE_KEY"],
    ) as client:
        await client.place_limit_order(
            asset_id=trade.asset_id, side=trade.side,
            price=str(trade.price), size=size,
        )

async def poll():
    async with AsyncPublicClient() as client:
        pages = client.list_activity(user=SOURCE, activity_types=["TRADE"], page_size=50)
        page = await pages.first_page()
        for t in page.items:
            key = (t.transaction_hash, t.asset_id, t.side, t.shares, t.price)
            if key not in seen:
                seen.add(key)
                await copy(t)

asyncio.run(poll())

Timing, fees and position sizing

Measure the delay from the observed trade to the proposed follower order. Reject a copy when its achievable price is outside the chosen tolerance. Neither a low-latency host nor a faster polling interval recreates an already completed fill. Our guide on why speed matters for copy bots shows where that delay builds up.

Read market-specific fees and size constraints before submission. Keep an event-level exposure cap, a maximum daily loss for the strategy and a rule for stopping after incomplete reconciliation. A source wallet increasing its position is not a reason to exceed those limits.

Worked follower-sizing example

Suppose a source wallet buys 1,000 YES shares at $0.40. A hypothetical follower policy proposes one tenth of the source quantity, subject to a separate $50 event budget. By the time the follower observes the trade, the best achievable average price for 100 shares is $0.46. That purchase would cost $46 before fees, rather than the $40 implied by copying the source's historical price.

If the contract ultimately pays YES, the follower's gross gain is $54 before costs. If it pays NO, the follower loses the $46 purchase cost before fees. These figures illustrate why the follower has different economics, even when the copied direction and share quantity are correct. They are not a forecast about the wallet's future results.

Now suppose only 60 shares are available within the follower's price tolerance. Record those 60 shares and leave the remaining proposed quantity unfilled. Do not increase the limit just to reproduce the source's size. The maximum event budget and acceptable price are constraints on the follower, independent of how confident the source appears.

If the source later sells half its holdings, a proportional target could reduce the follower to half its own copied exposure. That is a policy choice that must be tested, not an instruction to sell 500 shares from a follower holding only 60. Track source quantities, follower targets and actual follower fills in separate fields.

Deduplication and recovery checkpoints

Store a durable record of processed activity identifiers and pagination progress. Before advancing a checkpoint, commit the corresponding observation and paper decision. If a restart repeats the last page, the same identifier should produce a duplicate observation record rather than another simulated purchase.

Periodically compare the reconstructed follower position with the latest account view. This catches a missed sell, an uncertain order response or an unexpected position change. Pause new entries if that comparison fails. A monitor should keep gathering evidence during the pause so recovery can determine what changed.

The step-by-step Polymarket bot setup covers the current SDK, paper ledger and deployment steps. Copy-specific components still need to distinguish source activity from follower fills. Keep the wallet-observation service free of signing secrets where practical, and make the execution component apply the follower's own limits.

Evaluate copying after delays and costs

Replay the time the observation reached the follower, then choose a later book for simulated execution. Report the number of observed trades, accepted decisions, price rejections and incomplete fills. A test that drops expensive or unfillable copies can overstate the usefulness of the selection policy.

Compare several fixed delay assumptions without selecting the best one after seeing the results. Include fees at the simulated prices and group results by event, not only by trade. Related entries into one outcome are one concentrated risk even when the source submitted them as separate transactions.

An algo VPS can host the monitor independently of a home computer. Measure actual observation and processing delays before choosing more resources. Hosting does not reveal private source orders, restore an earlier fill price or convert an unresolved wallet result into a repeatable strategy.

Paper-test copying and recovery

Replay the recorded observation time, then price the follower at a later executable book. Include missed updates, duplicate events, partial fills and the source closing only part of a position. Record why a proposed copy was rejected as well as why one was simulated.

For the broader framework, see automated trading on Polymarket. Check the official geographic restrictions before enabling live orders; remote hosting does not alter physical-location eligibility.

Running a Polymarket copy bot

Paper-test the copying rules first, including what the bot does when the followed wallet trades again before your last order fills. Size positions from your own bankroll, not the wallet you copy, and skip trades that arrive after the price has moved past your limit. A Polymarket VPS from QuantVPS runs from Dublin, the closest non-georestricted region to Polymarket's London servers, under 1ms to Polymarket's order book.

FAQs

Does copying a profitable wallet produce the same result?

No. Entry time, size, fees and other exposure can differ. Public records also do not explain every part of the original trader’s strategy.

Can a read-only copy monitor be tested without a wallet key?

Yes. Public-data observation and a paper ledger are separate from authenticated execution. Keep signing credentials out of the monitor and its logs.

Should a new follower copy existing holdings immediately?

Treat that as a separate policy from following new activity. Existing positions have historical entry prices and may be near an exit. Evaluate any proposed entry at the follower’s current price, with its own event budget and resolution review.

How can a copy monitor avoid processing the same trade twice?

Persist stable activity identifiers and commit the observation before advancing its checkpoint. On reconnect, treat repeated identifiers as already processed. Reconcile follower positions separately because observing a source trade does not establish a follower fill.