/copy-trade

name: copy-trade
description: This skill should be used when the user asks to "copy trades from" a wallet, "mirror a wallet", "follow this address", set up "copy trading", "track and replicate a trader", or mirror another account's swaps bounded by guardrails. Watches a target wallet and mirrors its trades, filtered by chain, asset match, position size, and the follower's own portfolio state.
allowed-tools: Read, Write, Edit, Glob, Grep, Bash(npm:*), Bash(npx:*), Bash(curl:*), WebFetch, AskUserQuestion
model: sonnet
license: MIT
metadata:
  author: uniswap
  version: '0.2.0'
prerequisites:
  - swap-integration
  - viem-integration

Copy Trade

Watch a target ("leader") wallet on the target chain and mirror its swaps into the follower's wallet, bounded by guardrails. This is a thin strategy layer: it decides what to mirror and whether to mirror it, then delegates the actual swap to `swap-integration` and `viem-integration`. The skill never builds quote, approval, swap, or signing logic itself.

> **Runtime Compatibility:** This skill uses `AskUserQuestion` for execution-mode and confirmation prompts. If `AskUserQuestion` is not available in your runtime, collect the same parameters and confirmations through natural language conversation instead.

Overview

The host scheduler invokes this skill on a cadence (about every 5 minutes). Each invocation is a single, self-contained, deterministic run:

1. Read the stored cursor (last processed block). 2. Read the leader wallet's new on-chain actions since the cursor. 3. For each new action, apply guardrails. 4. For actions that pass, delegate the mirror swap to `swap-integration`. 5. Advance the cursor and record which leader actions were mirrored.

Treat this as a state machine, not free-form reasoning. Read state, diff against the chain, decide per action, act, advance the cursor. Do not infer intent beyond what the on-chain events say, and never re-derive a decision a prior run already recorded.

Prerequisites

This skill delegates all infrastructure. It never reimplements quoting, approval, signing, or swap construction.

• **swap-integration** (uniswap-trading): the only execution path. Every mirror swap goes through its Trading API flow (`check_approval` then `quote` then `swap`, then sign and broadcast). Do not reimplement any of it.
• **viem-integration** (uniswap-viem): accounts, clients, signing, transaction broadcast, and reading the leader wallet's activity. Read the leader's transactions and receipts since the cursor block to detect swaps (see Step 2).

Read these plugin references before acting and treat them as ground truth:

• selected target-chain template: chainId, chain name, contract addresses, tradable token source, RPC / read path, indexing availability, funding constraints, and template-specific caveats. For the reference Robinhood Chain template, see `../../references/robinhood-chain.md`.
• `../../references/execution-model.md`: the Trading API requirement, execution modes, restrictions, and disclaimer rules.
• `../../references/strategy-state.md`: the shared state file and scheduler pattern.

Template inputs

The selected target-chain template must provide:

• chain id, chain name, native gas token, and RPC / read path.
• deployed Uniswap router, Permit2, PoolManager, and v2/v3/v4 pool factory / reader addresses needed to decode leader activity.
• whether a public indexer exists; if not, the skill polls RPC and scans bounded block ranges.
• tradable token resolution rules, including any token list or allowlist source.
• funding constraints, transfer-restriction caveats, and market-hours guidance.

Workflow (deterministic state machine)

Step 1: Read state cursor

Load the JSON state file (shape in `strategy-state.md`). For copy-trade the relevant fields are the last processed cursor (block or log position) and the set of leader intents already mirrored (keyed at the transaction level by `leaderTxHash`, plus a sub-index when one tx yields more than one independent intent; see Step 2). If no state file exists, this is the first run: initialize the cursor to the current head block and mirror nothing on this pass (avoid replaying the leader's full history unless the operator explicitly opts in).

This first-run-at-head behavior is skill-specific, not template-specific. It prevents accidental history replay on any target chain.

Step 2: Read leader actions since the cursor

Detect the leader's swaps by scanning the leader's own transactions, not by topic-filtering pool events on the leader address. The pool `Swap` events do not carry the leader EOA: v2 indexes `sender`/`to` and v3 indexes `recipient` (all of which are the router when the trade routes through UniversalRouter / SwapRouter02, not the leader), and v4 `Swap` indexes only `PoolId` and `sender` (the PoolManager's caller, again the router). A `getLogs` filter keyed on the leader address therefore returns nothing for router-routed trades. Instead:

1. Iterate blocks in the range `(cursor, head]` and select transactions where `tx.from` equals the leader. (Use viem's block/transaction reads via `viem-integration`; scan in bounded ranges to respect RPC limits.) 2. For each such transaction, fetch its receipt and decode the `Swap` logs it contains. A single leader transaction may emit one or more `Swap` logs (a multi-hop route emits one log per leg; a batch/multicall emits one log per independent swap). The protocol version is identified by the emitting contract: a v4 `Swap` is emitted by the `PoolManager`; v2/v3 `Swap` logs are emitted by individual pool contracts. 3. Resolve each pool to its token pair before deciding direction. v2/v3 `Swap` logs do not name the tokens -- read `token0()` / `token1()` on the emitting pool (or decode the v4 `PoolKey` from the `PoolId`) to learn the pair. The token addresses come from these reads plus the selected target-chain template; never invent them. Pool `Swap` logs always reference `WETH` (the ERC-20), n