Overview
CopyForge is a non-custodial copytrading platform built on Polymarket. When you subscribe and connect a trading wallet, a dedicated execution process begins mirroring every trade placed by the traders you follow — in real-time, with no manual intervention required.
The system is designed around three concerns: speed (signals delivered in under 10ms via an in-memory queue), cost efficiency (shared market data means N clients consume the same API bandwidth as 1), and security (your private key never leaves your device unencrypted and is isolated inside its own sandboxed container).
~0ms
signal delivery lag
10s
max trade detection lag
1×
API calls per N clients
AES-256
key encryption at rest
A shared market data layer polls Polymarket once for all tracked traders and writes a local cache. A signal detection process reads that cache, identifies new trades, and pushes signals into per-client queues. Each client's execution worker wakes up the instant a signal arrives and places the order — no polling delay, no shared execution path between clients.
Infrastructure
Every component runs as an isolated container. Shared services run once regardless of how many clients are active. Each client's execution worker runs in its own container with no access to other clients' credentials or state. All containers restart automatically on crash and start on boot without manual intervention.
In-memory store for signal queues, deduplication sets, and execution state. No persistence — ephemeral by design. Capped at 256 MB with LRU eviction. Signals trimmed to the last 500 per client.
Polls Polymarket trade history and open positions for every tracked trader. Writes results to a shared local cache using atomic file replacement. Automatically discovers new traders added by any client.
Reads the market data cache, detects new trades via a deduplication store, aggregates same-market activity into single signals, and pushes to each following client's queue. Seeds all existing trades on first run to prevent re-copying after restart.
One container per trading account. Blocks on the queue until a signal arrives, sizes the order according to the client's configured mode, and places it on Polymarket. Subscribes to a real-time fill stream for instant confirmation.
Shared services (market data, signal engine) mount client configurations read-only and write only to the shared cache layer. Each execution worker mounts only its own credentials — no cross-client file access is possible at the container level. All source volumes are mounted read-only; the only writable mount per client is its own isolated data directory.
When a client completes the setup flow, their configuration and encrypted credentials are written to an isolated directory, a new execution worker is registered in the container orchestration layer, and the container starts immediately. No restart of existing services, no downtime for other clients.
Signal Pipeline
The pipeline is designed for minimum latency at every stage. Market data is cached so detection never waits on network round-trips. Workers wake up the instant a signal is pushed — not on a fixed polling schedule.
The market data service polls Polymarket for trade history and open positions for every followed trader on a fixed interval. Results are written to a shared cache atomically so readers never see a partial update.
The signal engine reads the fresh cache and checks each trade against a persistent deduplication store. Only trades not previously seen are promoted to signals. Same-market trades within the same scan window are aggregated into one.
On first startup, the signal engine marks all currently-visible trades as already-seen. This prevents re-copying existing open positions after a server restart or configuration change.
Each aggregated signal is pushed to a dedicated per-client queue. Clients following the same trader each receive an independent copy. Queues are bounded to prevent unbounded memory growth.
Each execution worker blocks on its queue with a short timeout. The moment a signal arrives, the worker wakes immediately — no polling loop, no waiting for the next cycle. Delivery lag is effectively zero.
The worker sizes the order using the client's configured mode (equal, dynamic, or custom), reserves the required balance, and places a limit or market order on Polymarket. Fill confirmations arrive via an authenticated real-time stream.
When a trader places multiple orders in the same market within one scan window, the signal engine collapses them into a single signal with a combined position size. This reduces redundant order placement and more accurately reflects the trader's intent rather than reacting to each individual fill separately.
Every signal carries an expiry timestamp. If an execution worker is restarting or paused and cannot process a signal within the TTL window, the signal is discarded rather than executed late. This prevents stale orders entering the market at incorrect prices.
Security
Security isn't a feature we added — it's the constraint every architectural decision was made under. Private keys are never stored raw, never logged, and never reachable across client boundaries at any layer of the stack.
Your trading wallet's private key is encrypted in the browser using RSA-OAEP (SHA-256) before it is ever sent over the network. The plaintext key never appears in an HTTP request body.
On the server, the key is decrypted from transit ciphertext and immediately re-encrypted with AES-256-GCM using a server-side secret before being stored. The plaintext key is never persisted to disk or written to any log.
Each execution worker reads its credentials from a mount scoped exclusively to that client. No container can access another client's credentials, even if compromised. Credential files are readable only by the process owner.
All source code is mounted read-only into containers. An execution worker cannot modify strategies, shared libraries, or any other client's configuration. The only writable surface is the client's own isolated data directory.
CopyForge never holds your funds. WalletConnect authenticates your identity. Your trading wallet signs orders directly on-chain. We have no ability to move funds without your private key.
Private keys are never written to stdout, stderr, application logs, or any persistent storage in plaintext. The only moment a key exists in plaintext is in-process memory during initial provisioning, after which it is immediately re-encrypted.
Your key is encrypted client-side before transmission, decrypted server-side only to immediately re-encrypt for storage, and then passed to your execution worker's isolated environment at startup. At no point in this chain does the plaintext key touch a log, a database column, or a file readable by another client's process.
Tech Stack
The stack is intentionally straightforward — each component was chosen because it's the established best-in-class tool for its role. Async Python for I/O-bound execution, Redis for sub-millisecond queuing, Docker for isolation. No custom protocols, no exotic runtimes.
Frontend
Execution Engine
Infrastructure
Polymarket APIs
Production Specs
These values reflect the running production configuration. They are chosen to provide safe, stable operation across all client accounts simultaneously while leaving headroom for burst activity.
10s
market data refresh
25s
cache validity window
300s
signal expiry TTL
24h
dedup window
~0ms
queue delivery lag
500ms
order round-trip
CopyForge uses token bucket rate limiting at 75% of Polymarket's documented thresholds. This headroom absorbs bursts, accommodates adaptive backoff when the exchange signals congestion, and ensures per-client fairness across the shared execution pool.
Total exposure divided evenly across all tracked traders. Rebalances automatically when the trader list changes.
Allocation weighted by each trader's trailing performance score. Higher-performing traders receive proportionally larger size.
Fixed USD size per trader, set at configuration time. Full manual control over per-trader risk.