Inside SHADOW | How FlowSniper Mirrors Wallets

A code-grounded look at the copy-trade mode that watches up to twenty-five wallets, mirrors their entries and exits, and is honest about what it can and can’t see.

By FlowSniper Actual Estimated read: 9 minutes

The pitch you’ve heard before

Most copy-trade products fall into one of two buckets. They either pretend to have insight they don’t have (a “smart algorithm” that’s actually just a leaderboard) or they hide gnarly mechanics behind a slick UI and leave you to discover the limitations during a drawdown.

Shadow is FlowSniper’s version of copy-trade. It mirrors trades from up to twenty-five wallets that you’ve targeted. The mechanics are simple, the limitations are real, and we’d rather tell you about both up front than have you find out the hard way.

This article is a code-grounded walkthrough. What’s actually running. What it sees, what it doesn’t, and how the design choices shape what you’ll experience operating it.

What Shadow does

Every sweep cycle, Shadow runs a tight loop for each wallet you’re watching:

1. Pull the wallet’s current alpha holdings from on-chain.
2. Determine what’s different from the last snapshot.
3. If a new netuid appears, Shadow opens one too.
4. If a target wallet sold some alpha, Shadow sold. (Shadow sells proportionally as well.)
5. If a target wallet exits a subnet, Shadow does too.

That’s the entire trade-detection model. There’s no event-stream listener, no privileged feed, no insider data. Shadow reads the same public chain state that anyone can read.

That seems like a limitation, and it is. It’s also the right architecture. Event streams require trust in an indexer, and indexers can lie or fail. Chain reads are slower, but they’re the truth. The trade-off is latency: Shadow sees what you did roughly three to five minutes after you did it, which is fine for swing-style follow trades and bad for trying to mirror a high-frequency scalper.

If you’re trying to copy someone who’s in and out of a subnet inside a single epoch, Shadow probably isn’t your tool. If you’re trying to copy a thoughtful accumulator who picks subnets and holds, Shadow is exactly your tool.

The diff problem

Here’s the part that took the longest to get right.

Alpha holdings don’t only change when their owner trades. Validator emissions add small amounts of alpha to staked positions automatically every epoch. So if Shadow saw “wallet X had 4.5 alpha last sweep, now has 4.51 alpha,” the bot cannot tell whether that’s the wallet owner buying 0.01 more (mirror it) or whether validator emissions credited 0.01 (ignore it).

Shadow handles this asymmetrically:

• The new netuid appearing in the snapshot is unambiguous. Mirror as a new entry.
• Significant alpha decrease beyond a threshold is unambiguous. Mirror as a sell.
• Small alpha increases are ambiguous. Ignore.
• Alpha going to zero is unambiguous. Close.

The cost of this asymmetry is real. Shadow won’t pick up dollar-cost-averaging from your target. If they slowly add to a position over weeks, Shadow holds whatever it entered with and doesn’t follow the adds.

The alternative is event-level chain reads to distinguish DCAs from emissions, which adds complexity and latency for a feature most users don’t need. If you do need it, you can manually re-enter a Shadow position to refresh sizing, or promote the position to Designate and manage it directly.

We’d rather miss inbound DCAs than spam your wallet with phantom buys every time emissions land.

Trust, but verify

There’s a distinction worth making explicit: “wallet is empty” and “we don’t know what’s in the wallet” are two different states. A naive design treats them as one. A correct design treats them as two.

Shadow’s chain-fetch helper returns both the data and a success flag:

async def _fetch_target_stakes(self, ss58):
    try:
        stakes = await self.r.get_stakes(ss58)
        return stakes, True
    except Exception:
        return {}, False

When the fetch returns ok=FalseShadow treats that wallet as unreadable for the entire sweep. No entries, no exits, no inferred state changes. Just "we don't know, try next cycle again." On the next successful sweep, Shadow diffs against the last known-good snapshot, not the broken one.

This matters because RPC nodes occasionally return empty data when they’re under load. A system that treated empty as “wallet sold everything” would fire phantom exits across every Shadow position attached to that wallet. We’d rather skip a cycle than guess wrong.

Sizing: fixed or proportional

When Shadow detects a target wallet entering a new position, it has to decide how much TAO to put in. Two modes are supported.

Fixed mode uses the same TAO size for every Shadow entry, regardless of how much the target spent. If it shadow_sizing_tao is 0.05, every new Shadow position is 0.05τ. Simple, predictable, and ignores whether the target is sizing big or small.

Proportional mode scales Shadow’s size to a percentage of the target’s apparent position value. If the target has roughly 5τ in a subnet and shadow_sizing_pct is 10%, Shadow opens a 0.5τ position.

Both modes respect a hard per-subnet cap. Even on proportional mode, if your target opens an enormous position, Shadow won’t follow them off a cliff. It caps at shadow_max_position_tao no matter what.

The right choice depends on your target. If you’re following a wallet that sizes by conviction (some 0.5τ positions, some 5τ positions), proportional mirrors that conviction. If you’re following a wallet that throws the same chunk at every opportunity, fixed is simpler and works fine.

Up to twenty-five wallets

Shadow polls each watched wallet in sequence every sweep and tracks the per-wallet snapshot separately. This matters for two reasons.

Provenance. Every Shadow position records which wallet originated it. The dashboard and engagement log show “from Keith” or “from 5GuRLE…” so you always know which target’s call you’re riding. When you have multiple Shadow positions across multiple wallets, the attribution is preserved end-to-end.

Independent state. If wallet A has an RPC fetch failure but wallet B succeeds, Shadow processes B normally and skips A. The wallets don’t share fate.

Out of the box, the cap is set to five. That’s comfortable for most operators. Each additional wallet adds an RPC call per Shadow sweep and two to four seconds of cycle time, plus a higher chance of position-cap saturation as more wallets feed the queue.

In v1.2, the cap is configurable up to twenty-five. If you’re running a heavier setup (multiple validators, a pool of known-good traders, and a few experimental slots), you can dial it up from the Shadow → Configuration menu. Just know what you’re trading. Past about ten or fifteen wallets, sweep latency starts to become noticeable. Twenty-five is the ceiling, not the recommendation.

Budget and exits

Shadow respects FlowSniper’s mode-budget system. You decide what percentage of your wallet (or fixed τ amount) Shadow is allowed to deploy, and it stops opening new positions when that’s full. Two crucial details.

Entries respect the budget. If Shadow is at the cap, it skips new entries and logs the reason.

Exits ignore the budget. If your target sold and we’re tracking that position, we sell. Full stop. The point of copy-trading is mirroring exits as well as entries. Constraining exit-following because of “budget” would defeat the entire purpose.

Shadow also enforces a position-count cap, tracked mid-loop, so a single sweep where multiple target wallets simultaneously enter new positions can’t exceed the cap. Excess entries get queued for the next sweep instead of opening positions you didn’t ask for.

Promotion to Designate

Shadow positions are pure mirror trades. No stop-loss. No trailing stop. No time-based exits. If your target holds, Shadow holds. Even if the position is bleeding 50%, and you’d rather just be out.

For some users, that’s the point. The whole reason they’re following someone is that they trust the call and don’t want a stop-loss second-guessing it. For others, it’s terrifying.

The bridge is a promotion. Any Shadow position can be promoted to Designate from the menu. When it is:

• The position keeps its source-wallet provenance. You still see “originally from Keith.”
• All four risk-management mechanisms become active: stops, trailing stops, time exits, and conviction-decay exits.
• Whichever fires first wins. If your target sells, Designate exits on the mirror. If your trailing stop hits before they sell, Designate exits on its own logic.

This is one of the things that took the most thought to design correctly. Most copy-trade systems treat “follow them” and “manage risk” as mutually exclusive. You’re either riding their call, or you’re not.

FlowSniper’s design says you can have both. Ride their call, but with a parachute. The parachute might pull you out before they exit, and that’s the whole point.

What Shadow can’t do?

Worth being explicit about the limits.

Shadow can’t see why your target traded. They might be reacting to news, vibes, an indicator they trust, or something they coded themselves. Shadow sees only the chain effect, not the reasoning. If their reasoning was wrong, you’ll find out the same time they do.

Shadow can’t outrun the chain. There’s a delay, typically one sweep cycle (three to five minutes), between when your target’s transaction settles and when Shadow sees it. For positions held days to weeks, this is invisible. For frantic intraday rotation, it’ll cost you.

Shadow doesn’t deduplicate across wallets. If two wallets you’re watching both enter SN42 in the same sweep, Shadow opens two separate Shadow positions on SN42. Provenance separated, sized separately. Some users want this (treats each call as independent evidence). Some find it confusing. We chose visibility over consolidation. If you’d rather consolidate, manually exit one of them.

Shadow can’t distinguish a sell from a wallet-to-wallet alpha transfer. If your target moves their alpha to a different wallet via btcli stake transfer rather than selling, Shadow sees the alpha disappear from the watched wallet and treats it as an exit. Technically incorrect, but from your perspective, you don't have visibility on the destination wallet anyway, so an exit is the safer interpretation.

Who Shadow is for

If your target is a slow accumulator who picks subnets thoughtfully and holds, Shadow is excellent. You’ll mirror their entries and exits with a few-minute delay, and the delay won’t matter because they’re not trading on minutes.

If your target is a fast trader whose edge is timing, Shadow won’t keep up. You’ll get late entries on positions that have already moved and late exits when they were already out at higher levels. Use Sniper or Sentinel for that. Both are decision-making, not mirroring, and they don’t have the latency disadvantage.

If you’re not sure whether the wallet you’re watching is good, Shadow is a cheap way to find out. Pick a wallet, set a small fixed sizing (say 0.02τ per entry), let it run for a month, and look at the engagement log. The data tells you whether their calls were worth following without putting real money on the line.

What it actually feels like to operate

Configure your wallets in the menu. Set sizing. Let it run.

The dashboard shows your Shadow positions inline with your other modes, with each position labeled by source wallet. The engagement log shows entries and exits as they happen, with the originating wallet noted. If something looks unexpected, you can check the log to see what the bot’s view of the target’s wallet was at the time.

Most days, nothing dramatic happens. Some days your target makes a great call, and Shadow makes the same call. Some days, they make a bad call, and you ride it down. The bot doesn’t filter its calls. That’s the point.

If you want filtering, that’s what Sentinel is for. The bot picks the subnets itself based on signal scores, no wallet to follow. If you want the bot to actively trade in and out, that’s Sniper. Shadow is for when you’ve already decided whose judgment you trust, and you just want to be there with them.

The honest summary

Shadow is the simplest mode in the FlowSniper conceptually, and one of the trickier ones to implement well. The mechanics are diff-based, latency-bounded, asymmetric on detection, and explicit about what they can and can’t see.

That’s not as exciting as “AI-powered copy trading,” but it’s what’s actually running.

If you’re already a FlowSniper customer and you’ve been ignoring Shadow because you didn’t trust the concept, this is your invitation to take another look. Pick a wallet you respect. Set a small size. Let the data tell you whether their calls were worth following.

If they were, you’ll know. If they weren’t, you’ll know that too.

Either answer is worth having.

FlowSniper is an autonomous, self-hosted dTAO trading bot. Four modes, one wallet, your VPS, your keys.

flowsniper.ai