Abstract
0x1 operates a Rust-native mirror trading engine built to replicate leader fills onto a heterogeneous population of follower accounts with sub-second latency, bounded slippage, and per-account risk isolation. This document specifies the architecture of that engine and contrasts it with the serial-execution and unbounded-slippage patterns that characterize conventional copy-trading stacks. The design choices below — per-mirror-trader concurrent pipelines, parallel fanout, orderbook-aware pre-checks, and non-custodial EIP-712 signing — are the mechanisms by which 0x1 compresses the leader-to-follower replication envelope and preserves the PnL shape a follower signed up for.1. Problem Statement: Legacy Copy Trading
Most incumbent copy-trading implementations inherit an architecture that was not designed for high-frequency derivatives venues. The resulting execution pathologies fall into four recurring categories.1.1 Serial order placement
Legacy systems iterate followers in a single-threaded loop. When a leader fills, the system enumeratesN followers and submits orders one after another, blocking on each HTTP round trip and exchange acknowledgement before advancing to the next. In steady state the k-th follower observes a fill time of approximately:
For N = 500 followers, a 30 ms round trip, and a 10 ms matching delay, the last follower fills 20 seconds after the leader — an eternity on a perpetuals venue.
1.2 Unbounded slippage
Because orders are sized from the leader’s notional and submitted market-on-fill, later followers repeatedly walk their own book. Each fill consumes liquidity at progressively worse prices, and the system has no feedback loop that halts the fanout when realized slippage exceeds the follower’s tolerance. The same leader trade produces a PnL distribution across followers that is heavily left-skewed.1.3 Polling-based signal detection
Many systems detect leader activity by polling the exchange REST API every few seconds rather than subscribing to the user-data stream. The leader’s fill therefore enters the replication pipeline with an already-stale timestamp, compounding the queueing delay above.1.4 Shared-fate failure modes
A single malformed order, rate-limit block, or HTTP timeout in the serial loop stalls every follower behind it. There is no bulkhead isolating one leader’s pipeline from another’s, and no per-follower circuit breaker to prevent a bad moment for one account from cascading.2. 0x1 Engine: Design Goals
The 0x1 engine targets four invariants:| Invariant | Definition |
|---|---|
| Low replication latency | Median follower fill lands within one second of the leader fill. |
| Bounded slippage | No follower fills outside their configured slippage tolerance. |
| Proportional sizing | Follower position delta is a fixed fraction of the leader’s margin delta, not a mirrored absolute size. |
| Fault isolation | A failure in one leader pipeline, or one follower account, never blocks any other. |
3. Architecture
3.1 Runtime
The hot path is implemented in Rust on top of the Tokio asynchronous runtime. Each leader is served by an independent supervisor task, and each follower subscription is a lightweight task scheduled cooperatively on the Tokio executor. The engine holds zero synchronous locks on the critical path — all state handoffs use bounded MPSC channels, and backpressure is explicit.3.2 Per-mirror-trader concurrent pipelines
Every followed mirror trader runs three concurrent streams that share nothing except the outbound signal channel: Because the orderbook and user-account streams are independent WebSocket subscriptions, leader fills are observed in the push path rather than a poll cycle. The signal generator produces a typedMirrorIntent the moment Aster publishes the fill, not after the next REST tick.
3.3 Parallel fanout
The fanout step is implemented asFuturesUnordered over all eligible followers. Each follower is a distinct Tokio task that owns its own signer and its own outbound HTTP connection to Aster. The k-th follower no longer waits on the (k-1)-th — every signature, risk check, and order submission happens concurrently.
In the serial model the last follower’s latency grows linearly in N. In the 0x1 model it grows logarithmically in N (scheduler + connection-pool bounded) and is dominated by a single RTT:
3.4 Orderbook-aware pre-check
Before a follower task submits, the risk guard re-reads the live orderbook snapshot and computes the expected fill against the follower’s configured slippage tolerance. Orders that would breach the tolerance are skipped, not sent — and the skip is written to the follower’s activity log with a structured reason code. The legacy failure mode where 500 followers sequentially walk their own book cannot occur, because the order is never dispatched once the expected mark breaches the bound.3.5 Proportional sizing
Follower size is a function of the follower’s configured allocation and the leader’s margin delta: clamped by the follower’s leverage cap and Aster’s minimum order size. The engine does not mirror absolute notional; it mirrors the shape of the leader’s risk commitment onto the follower’s balance sheet.3.6 Non-custodial signing
The engine never sees a raw follower private key on the hot path. Each follower provisions an agent key that signs EIP-712 ECDSA payloads scoped to the trading account; agent keys are encrypted at rest and rotated on demand. The follower retains custody of both their Aster balance and the master key that authorizes the agent.4. Comparative Analysis
- Fanout latency
- Slippage profile
- Fault isolation
- Custody
| Property | Legacy serial | 0x1 engine |
|---|---|---|
| k-th follower fill | ||
| Last follower @ N=500 | ≈ 20 s | ≈ 1 s |
| Signal detection | REST polling | WebSocket push |
5. Operational Envelope
Leader goes silent
Leader goes silent
The supervisor does not synthesize exits. Open follower positions remain open until the leader closes them or the follower closes them manually from the dashboard. The engine never assumes intent from absence.
Follower margin exhausted
Follower margin exhausted
The risk guard returns a
MarginBreach skip before any order is signed. No leveraged top-up is issued on the follower’s behalf. The activity log records the breach with the attempted size and the configured cap.Exchange rate limit
Exchange rate limit
Each follower connection carries its own token-bucket rate limiter. When a follower hits its bucket, only that follower’s tasks backpressure; other followers and other leaders are unaffected.
Partial fill on leader
Partial fill on leader
The signal generator emits incremental
MirrorIntent messages for each partial. Follower sizing is recomputed against the new leader margin delta on every emission.6. Conclusion
Legacy copy-trading stacks are the product of batch-oriented, REST-polled, single-threaded assumptions that do not compose with modern perpetual venues. The 0x1 engine replaces that stack with a push-driven, per-mirror-trader concurrent, orderbook-aware design whose cost per additional follower is a task handle rather than an RTT. The result is a replication surface where the follower’s realized PnL distribution tracks the leader’s with bounded, explicit divergence — and where a bad moment for one account never becomes a crisis for the next.The engine is non-custodial. All follower balances remain on Aster; all signing uses follower-scoped agent keys the follower can revoke at any time.