Copy trading sounds trivial until you try to build it: one account opens a position, and a bunch of other accounts should end up holding the same position, scaled to their size, fast enough that the price hasn't run away.
On a centralized exchange this is mostly a database problem — you custody everyone's funds, so "mirroring" a trade is an internal ledger update. On a non-custodial perp DEX like Hyperliquid, you don't hold anyone's money, every order is a signed transaction against an on-chain order book, and the followers' fills happen at whatever the market gives them. That changes the problem from "update a row" to "run a low-latency, fault-tolerant, multi-account execution system that never has withdrawal rights."
We've been building this at Moss (open-source AI trading agents platform on Hyperliquid), and this post is about the parts that were genuinely hard. Code below is illustrative and simplified — the point is the shape of the problem, not a copy-paste implementation.
What "hosted copy trading" has to do
The contract is simple to state:
A lead — for us usually an AI agent, but it could be any account — opens, modifies, and closes perp positions.
Each follower should track the lead's positions, scaled to the follower's own equity, with sane risk limits.
Followers keep full custody the entire time. We can place and cancel their orders; we can never move their funds.
It has to happen in near real time, because the longer the gap between the lead's fill and the follower's fill, the more the follower pays in slippage.
Four of those words do all the damage: custody, scaled, near real time, and (implicitly) reliably. Let's go through them.
The primitive that makes it possible: agent wallets
The first question everyone asks is: if you don't custody funds, how do you trade on someone's behalf?
Hyperliquid has a primitive for exactly this — agent wallets (also called API wallets). A master account can authorize a separate key as an agent. That agent can sign and submit orders for the account, but it cannot withdraw or transfer funds. Withdrawal authority stays with the master key, which only the user holds.
This is the whole reason a hosted, "connect-and-go" copy trading flow can be non-custodial. The user connects their wallet on the website, signs one approval transaction that registers our agent key, and from then on we can mirror trades into their account without ever being able to touch the balance. No depositing funds with us. No giving us their seed phrase. No installing a separate client.
Conceptually:
# User signs this ONCE, from their own wallet, in the browser.
# It authorizes our agent key to place orders — and nothing else.
approve_agent_action = {
"type": "approveAgent",
"agentAddress": moss_agent_address,
"agentName": "moss-copy",
}
# Signed by the USER's wallet, submitted to Hyperliquid.
After that, our side holds only the agent key for that user:
from hyperliquid.exchange import Exchange
# `agent_wallet` can sign orders for the user's account,
# but the chain will reject any withdrawal/transfer it signs.
follower_exchange = Exchange(agent_wallet, base_url, account_address=user_address)
Worth being precise about the trust model here: the agent key can place bad trades if it's compromised, so the key is still sensitive. But the worst case is bad trades, not stolen funds — the withdrawal path is closed by the protocol, not by our promise. That distinction is the entire pitch.
The mirror loop
At the core is an event-driven loop: watch the lead, diff against each follower, close the gap.
We subscribe to the lead's fills over the WebSocket instead of polling, because polling either wastes requests or adds latency, and in copy trading latency is literally a cost.
from hyperliquid.info import Info
info = Info(base_url)
def on_lead_event(msg):
for fill in msg["data"]["fills"]:
# The lead's position in `fill["coin"]` just changed.
# Recompute the target for every follower and reconcile.
reconcile_coin(fill["coin"])
info.subscribe(
{"type": "userFills", "user": lead_address},
on_lead_event,
)
The important design decision is that we don't replay the lead's individual orders. We treat the lead's resulting position as the source of truth and drive each follower toward a scaled version of it. Replaying orders sounds simpler but breaks the moment anything desyncs — a missed event, a partial fill, a follower who poked their account manually. Reconciling against target state is idempotent: run it twice and nothing bad happens.
def reconcile_coin(coin):
lead_pos = get_position(lead_address, coin) # signed size
lead_equity = get_account_equity(lead_address)
for follower in followers_copying(lead_address):
target = compute_target_size(lead_pos, lead_equity, follower)
current = get_position(follower.address, coin)
delta = target - current
if abs(delta) < follower.min_clip(coin):
continue # too small to bother, avoids fee churn
submit_mirror_order(follower, coin, delta)
Everything interesting is hiding in compute_target_size and submit_mirror_order.
Proportional sizing across very different accounts
A lead running $50k and a follower running $300 should not hold the same absolute position. The natural scaling is by equity ratio:
def compute_target_size(lead_pos, lead_equity, follower):
ratio = follower.equity / lead_equity
raw = lead_pos * ratio
# Respect the follower's own risk config — not the lead's.
raw = clamp_to_max_notional(raw, follower)
raw = clamp_to_max_leverage(raw, follower)
# Round to the asset's lot size, or the order is rejected.
return round_to_lot(raw, follower.coin_meta)
Three things bite here:
Risk config belongs to the follower, not the lead. If the lead runs 20x and a follower set a 5x cap, the follower's cap wins. That means a follower can't always perfectly track the lead, and that's correct behavior — you're protecting them, not cloning a stranger's risk appetite.
Lot sizes and minimum order sizes are real constraints. A small follower scaling a small lead position can land below the minimum order size, in which case the honest answer is "you can't take this trade," not "round it up to something bigger than you intended."
Equity moves. A follower's equity changes as positions move, so the "ratio" isn't a constant. We snapshot equity at reconcile time rather than caching it, and we deliberately add hysteresis (the min_clip check above) so small equity wobbles don't generate a storm of tiny rebalancing orders that just bleed fees.
Slippage and partial fills
This is where the non-custodial, on-chain nature stops being an abstract design note and starts costing money.
When you mirror a trade, you are by definition late — the lead filled first, you saw the event, then you acted. If you send a naive market order, you eat whatever the book has moved to. On a CLOB you don't actually get a "market order" with protection for free; you express it as a marketable limit with a slippage bound and accept that it might only partially fill.
def submit_mirror_order(follower, coin, delta):
is_buy = delta > 0
px = marketable_price(coin, is_buy, slippage_bps=follower.max_slippage_bps)
result = follower_exchange(follower).order(
coin,
is_buy,
abs(delta),
px,
{"limit": {"tif": "Ioc"}}, # fill what you can now, cancel the rest
builder={"b": MOSS_BUILDER_ADDRESS, "f": MOSS_BUILDER_FEE},
)
record_fill(follower, coin, result)
Ioc (immediate-or-cancel) means we never leave a resting order dangling at a stale price. But it also means we can come up short — the book didn't have enough size within our slippage band. Now you have a policy question with no universally right answer:
Chase it — re-submit for the unfilled remainder at a slightly worse band. Tracks the lead more tightly, pays more slippage.
Accept the drift — log that this follower is now slightly under the target and let the next reconcile pass pick it up.
We lean toward accepting drift for the long tail and only chasing when the gap is large relative to the follower's target, because chasing aggressively in a fast market is how you turn one bad fill into three. The drift gets cleaned up on the next reconcile anyway, which is the whole reason we drive toward target state instead of replaying orders.
State reconciliation: assume you will miss events
WebSockets disconnect. Events get dropped. A follower opens the app and manually closes a position out from under you. An order you thought filled actually got rejected for a tick-size rounding error you didn't catch. If your system only reacts to lead events, every one of these leaves a follower silently out of sync — and "silently wrong" in a system that touches people's money is the failure mode you least want.
So alongside the event-driven loop we run a slower full reconciliation sweep that doesn't trust any of our own bookkeeping:
def reconcile_sweep():
# Pull GROUND TRUTH from the chain, not our cached state.
lead_state = info.user_state(lead_address)
for follower in all_active_followers():
follower_state = info.user_state(follower.address)
for coin in union_of_open_coins(lead_state, follower_state):
target = compute_target_size_from_state(lead_state, follower, coin)
current = position_of(follower_state, coin)
if abs(target - current) > follower.tolerance(coin):
submit_mirror_order(follower, coin, target - current)
The event loop is the fast path; the sweep is the safety net. The sweep is intentionally boring and idempotent: it reads real positions from user_state, computes what each follower should hold, and nudges anything outside tolerance. If the event loop is healthy, the sweep finds nothing to do. When the event loop misses something, the sweep is what stops a small desync from compounding.
A subtle point: the sweep has to respect the same hysteresis and min-clip rules as the fast path, or the two will fight each other — the loop pushes a follower to target, the sweep rounds it differently and pushes back, and you've built a fee-burning oscillator. Ask me how I know.
Fees, briefly
Two fee mechanics matter and neither should surprise the user:
Performance fee with a high-water mark. Followers pay a performance fee only on new profit above their previous peak equity, so a follower who dips and recovers isn't charged twice for the same gains. You persist the high-water mark per follower per lead and only accrue fees when realized equity sets a new high.
Builder codes. Hyperliquid lets an app attach a builder code to orders and earn a small fee on the volume it routes. That's the
builder={...}field in the order call above. It's how the platform earns from activity without taking a cut of the follower's profit or the lead's performance fee — your incentive is aligned with volume and uptime, not with skimming.
What we'd tell ourselves at the start
Drive toward target state, never replay orders. It's the single decision that made everything else (missed events, partial fills, manual interventions) recoverable instead of catastrophic.
The agent-wallet model is the product, not a detail. "We can trade for you but physically cannot withdraw your funds, enforced by the protocol" is a stronger promise than any amount of trust-us copy, and it's what lets the whole flow live on a website with no extra client to install.
Build the boring reconciliation sweep first. It feels redundant when the happy path works. It is the only thing standing between "one dropped WebSocket message" and "a follower quietly holding the wrong position for an hour."
Hysteresis everywhere. Markets jitter, equity jitters, rounding jitters. Without deadbands, a correct system still bleeds fees by constantly correcting noise.
If you want to poke at how the agents themselves are built — the part that decides what to trade, which is a whole separate set of problems — the strategy side is open source: https://github.com/moss-site/moss-trade-bot-skills.
You can create a trading agent straight from a terminal via the skill, but that's a post for another day.
Happy to go deeper on any one of these in the comments — the slippage/chase policy and the reconciliation deadband tuning are the two I'd most like to compare notes on with anyone who's built something similar.