$npx -y skills add Uniswap/uniswap-ai --skill copy-tradeThis 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, f
| 1 | # Copy Trade |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | > **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. |
| 6 | |
| 7 | ## Overview |
| 8 | |
| 9 | The host scheduler invokes this skill on a cadence (about every 5 minutes). Each invocation is a single, self-contained, deterministic run: |
| 10 | |
| 11 | 1. Read the stored cursor (last processed block). |
| 12 | 2. Read the leader wallet's new on-chain actions since the cursor. |
| 13 | 3. For each new action, apply guardrails. |
| 14 | 4. For actions that pass, delegate the mirror swap to `swap-integration`. |
| 15 | 5. Advance the cursor and record which leader actions were mirrored. |
| 16 | |
| 17 | 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. |
| 18 | |
| 19 | ## Prerequisites |
| 20 | |
| 21 | This skill delegates all infrastructure. It never reimplements quoting, approval, signing, or swap construction. |
| 22 | |
| 23 | - **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. |
| 24 | - **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). |
| 25 | |
| 26 | Read these plugin references before acting and treat them as ground truth: |
| 27 | |
| 28 | - 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`. |
| 29 | - `../../references/execution-model.md`: the Trading API requirement, execution modes, restrictions, and disclaimer rules. |
| 30 | - `../../references/strategy-state.md`: the shared state file and scheduler pattern. |
| 31 | |
| 32 | ## Template inputs |
| 33 | |
| 34 | The selected target-chain template must provide: |
| 35 | |
| 36 | - chain id, chain name, native gas token, and RPC / read path. |
| 37 | - deployed Uniswap router, Permit2, PoolManager, and v2/v3/v4 pool factory / reader addresses needed to decode leader activity. |
| 38 | - whether a public indexer exists; if not, the skill polls RPC and scans bounded block ranges. |
| 39 | - tradable token resolution rules, including any token list or allowlist source. |
| 40 | - funding constraints, transfer-restriction caveats, and market-hours guidance. |
| 41 | |
| 42 | ## Workflow (deterministic state machine) |
| 43 | |
| 44 | ### Step 1: Read state cursor |
| 45 | |
| 46 | 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). |
| 47 | |
| 48 | This first-run-at-head behavior is skill-specific, not template-specific. It prevents accidental history replay on any target chain. |
| 49 | |
| 50 | ### Step 2: Read leader actions since the cursor |
| 51 | |
| 52 | 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: |
| 53 | |
| 54 | 1. Iterate |