FlowSniper — Field Manual

FlowSniper is a retail-grade, four-mode autonomous trading suite for Bittensor's dTAO subnet ecosystem. One bot runs four parallel strategies: Sniper hunts short-term momentum, Sentinel builds and rebalances a long-hold subnet portfolio, Designate lets you mark targets manually and have the bot manage them, and Shadow mirrors trades from wallets you track. Profits from any mode can auto-compound back into the Sentinel portfolio. Every mode has its own capital budget, its own live/dry toggle, and its own prerequisite gate before real TAO moves.

This Field Manual is the complete operator reference. If something in the bot doesn't match what you read here, the bot is right — update instincts, then come back and check the docs.

What Is FlowSniper

FlowSniper is a self-hosted Python bot. You run it on a small Linux VPS, point it at a Bittensor wallet, and it operates 24/7. Every 3 minutes (default) it sweeps all 128 subnets, scores them across 16 on-chain signals, and decides what each active mode should do — enter, hold, trim, exit, rebalance, or sit on its hands.

The interface is a terminal menu called the Command Center. Numbers select menu items. B or 0 goes back. Q quits. Dashboards refresh live. Everything the bot does is logged, journaled, and inspectable.

Table of Contents

What's New in v1.2

Highlights of changes since v1.1. Four thrusts: transparency (Selection Engine surfaces the full Sentinel decision pipeline), control (per-tier filter overrides, position cap override, RPC multi-fallback, tiered webhook alerts), visibility (SIGINT live log feed on the main menu, License Dashboard), and performance + correctness (sweep times roughly five times faster on operators using a local Subtensor node, stable license fingerprint that survives routine operations).

SIGINT — live bot logs across all modes, one keypress away

• New main-menu item: [10] SIGINT. Streaming bot logs spanning Sniper, Sentinel, Designate, and Shadow in a single feed. Previously buried inside the Sniper submenu, which made it look mode-specific despite always covering all four modes.
• Operator vocabulary — SIGINT pairs naturally with SITREP and THREAT BOARD on the Intelligence section of the main menu, all three answering different questions: SITREP for portfolio state, THREAT BOARD for signal scores, SIGINT for real-time bot reasoning.
• Use it for watching the scoring engine think through a sweep, debugging an unexpected entry or exit, or just confirming the bot is alive and processing.

License Dashboard — full visibility into your subscription

• New menu screen: [16] ADMIN → [22] License. Shows tier, status, key suffix (redacted), Discord handle, activation date, expiration (or “lifetime” for Vanguard), next renewal price, last vault check, and server reachability.
• Lifetime keys render with explicit “No renewal required” framing — no countdown timer, no warning lines, no upsell.
• Renewal warnings for subscription tiers are tiered: a friendly reminder at T-14 days, firmer notice at T-7, a final alert at T-1. Each fires at most once per cycle.

Tiered webhook alerts — the right signal at the right time

• Configurable per event type in [11] NOTIFICATIONS. Trade entries, exits, dropouts, license alerts, and system warnings each have their own toggle.
• License events — if your subscription nears renewal, Discord notifies you so you can re-up before any service interruption. Lifetime keys never trigger license alerts.
• Designed for low noise — the goal is “you only see what matters,” not a wall of pings.

Faster sweeps via direct RPC routing

• Five times faster on a local Subtensor node — for operators running their own node, sweep times dropped from 8–13 minutes down to under 3 minutes. Every chain query in the bot now uses your configured RPC profile (primary plus failovers).
• No setting changes required — if you've already configured a primary endpoint in [15] GLOBAL PARAMETERS → RPC endpoints, the speedup is automatic.
• Operators on public endpoints still see a modest speedup since connections are no longer split between the configured primary and the SDK's network default.

Stable license fingerprint — updates survive routine operations

• Fingerprint inputs are now CPU model, machine-id, and platform — the identifiers that genuinely identify a physical machine. Hostname renames, network reconfiguration, kernel updates, and bot installer runs no longer shift the fingerprint.
• Installer auto-rebind — when updating an existing installation, the installer detects fingerprint mismatches caused by the new algorithm and rebinds automatically. No manual rebind required for the v1.2 update.
• Legitimate rebind triggers — replacing the VPS or reinstalling the OS still requires a key rebind via the Armory, which is the intended behavior.

Bulk-exit improvements

• Portfolio Preview [E] exits all non-target positions in one cycle — user-requested bulk exits bypass the per-cycle exit rate limit. The rate limit still applies to algorithmic exits as a safety net against runaway signals.
• More reliable alpha unstaking — alpha amounts are floored to the chain's precision rather than rounded, eliminating a class of edge-case exit rejections on dust positions.

Filter override preview, fixed

• Live preview now works as documented — [2] SENTINEL → [9] Risk Profile → [F] → [P] Preview universe impact reliably runs the universe builder twice and shows admitted/excluded subnets plus per-filter exclusion counts.

Selection Engine — full transparency into Sentinel's picks

• New menu item: [2] SENTINEL → [7] Selection Engine. Live walkthrough of the full decision pipeline, recomputed every time you open the screen.
• Universe build — total scanned, qualifying count, per-filter exclusion breakdown with binding-constraint indicator (the filter blocking the most subnets).
• Scoring & ranking — held positions plus “below cut” (qualified but ranked lower than your holdings target). Each row shows pool size and computed score.
• Weight allocation — raw score-proportional weights vs. final weights with cap-redistribution attribution. Capped positions explicitly flagged.
• Why-not lookup — [L] from the engine view. Type a netuid (12), prefixed name (SN12), or substring (score). Returns the rejecting filter, hypothetical score if admitted, and projected rank against the live universe.
• Suggestions — when universe is below holdings target, the screen lists the top filters to loosen with the projected admission count for each.

Per-tier filter overrides — tune Sentinel without abandoning the tier

• New menu action: [2] SENTINEL → [9] Risk Profile → [F] Tier filter overrides. Each of the three tiers maintains its own independent overrides — switching tiers preserves the customizations for the tier you switched away from.
• Eight overrideable filters: pool minimum, market cap minimum, mcap/pool ratio max, 14-day flow minimum, 7-day flow minimum, age minimum, pool volatility max, deregistration rank floor.
• Live preview [P] — runs the universe builder twice (current vs. proposed) and shows admitted/excluded subnets plus per-filter exclusion counts.
• Held-position warning — if your filter changes would exclude positions you currently hold, the save confirmation surfaces them by name and notes that Sentinel will begin unwinding via the standard dropout process (not a panic-sell).
• Save flow — standard Y/N when preview succeeded, type-to-confirm save if preview failed (no silent saves blind to impact).

Per-position cap override — concentration control

• New menu action: [2] SENTINEL → [9] Risk Profile → [C] Adjust position cap. Override the tier’s default max_position_pct (Conservative 25, Balanced 20, Aggressive 18).
• Range: 5% floor, 50% ceiling. +/- single-keypress adjustment in 1% steps.
• Math floor warning — if your cap times your holdings target drops below 100%, the editor warns that the bot will silently clamp upward and suggests raising the cap or lowering holdings.
• Reset via [D] clears the override and restores the tier default.

RPC multi-fallback — resilience against endpoint outages

• New submenu: [15] GLOBAL PARAMETERS → RPC endpoints. Configure a primary endpoint plus up to two failovers.
• Built-in options: latent-lite (default primary), finney (default failover). Custom WebSocket URLs supported — the bot validates URL format on entry and offers an immediate connectivity test.
• [T] Test all — spawns a 10-second connectivity probe against every configured endpoint and reports pass/fail.
• Bot behavior: at startup, the bot constructs the fallback list and passes it to bittensor.Subtensor. If the primary fails mid-cycle, the SDK rolls forward through failovers automatically.

Auto-Compound rebuild — per-mode independent + threshold pooling

• Per-mode percentages — Sniper, Sentinel, Designate, and Shadow each have an independent contribution percentage. 0% = off, >0% = on at that rate. (Previous design had cross-mode coupling that quietly dropped Shadow.)
• Threshold pooling — configurable compound_redeploy_threshold. Below threshold, the pool accumulates without redeploying. Once threshold met, pool unlocks and feeds the next Sentinel entry. Re-locks when balance drops below the chain min-buy floor (0.01τ).
• Per-mode contribution display shows all-time deposits per source mode (computed from the compound log).
• Legacy field migration on first menu visit converts old single-toggle cross_mode_compound_* profile fields into the new per-mode shape.

Critical correctness fixes

• Sentinel dropout slow-unwind alpha leak — the slow-unwind code was emitting side="EXIT" for what is logically a partial exit. Downstream _rec_exit took the full-deletion branch after only a partial unstake on chain. Result: positions appeared as “stragglers” on chain with the bot blind to them. Fixed at the source. Existing stragglers heal via Field Recovery.
• Yield-accrual auto-claim — validator yield on managed positions was accumulating on chain but the bot’s reconciliation explicitly left it untracked (treating any chain-greater-than-DB delta as “external stake we can’t claim”). For single-claimant positions with bounded growth (excess ≤ 100% of current tracking), the excess is now claimed automatically. Wallet display catches up to chain, PnL recognizes yield as profit at exit, auto-compound deposits sized correctly.
• Field Recovery missed Shadow positions — the recovery scan didn’t include the position_state_shadow table, so Shadow holdings appeared as stragglers needing recovery despite being properly tracked. Fixed.
• Allocation history reader — was iterating the snapshot dict expecting {nuid: position} shape, but the writer stored {"holdings": [...], "total_basis_tao": X, "count": N}. The view rendered nothing. Fixed; allocation history now properly displays the top 5 by allocation per snapshot.

Quality-of-life

• Holdings “Why” column — [2] SENTINEL → [1] Holdings now shows score plus interpretive label per held position (145.8 · top quartile, flow-bonus). Replaces the previous LastDCA column. LastDCA info still available via [3] Allocation History.
• Sentinel main menu renumbered — Selection Engine added as [7] under Intelligence. Configuration block shifts: Parameters [7]→[8], Risk Profile [8]→[9], Auto-Compound [9]→[10], Portfolio Preview [10]→[11], Fortify [11]→[12], Budget [12]→[13].
• VERSION single source of truth — the bot reads its version string from the VERSION file at install time, eliminating the dual-source-of-truth bug where FLOWSNIPER_VERSION in the source and VERSION on disk could drift apart.
• Sentinel Parameters cleanup — removed Risk Tier and Target Holdings duplicates that already lived on the Risk Profile screen.

Requirements

Hardware / VPS

• CPU: 2 vCPU. The bot is I/O-bound, but four concurrent modes plus the menu interface need real cores.
• RAM: 8 GB. Once all four modes (Sniper, Sentinel, Designate, Shadow) warm up, the bot's working set is around 5 GB. Smaller VPSes will thrash in swap and cycle times will balloon from 5 minutes to 60+ minutes — at which point trading decisions are based on stale data. Technical floor is 4 GB; the installer warns and requires confirmation between 4–8 GB. See VPS Specifications for details.
• Disk: 20 GB SSD. The SQLite database grows ~50 MB/month with all four modes active.
• Network: Stable internet. The bot talks to Subtensor RPC nodes and (optionally) the Taostats API.
• OS: Ubuntu 22.04 LTS only. FlowSniper ships compiled bytecode locked to Python 3.10, which is the version 22.04 ships by default. Ubuntu 24.04 ships Python 3.12 and the bot will refuse to start. The installer enforces this and will exit with a clear error on any other OS.

Software

• Python 3.10 (the version Ubuntu 22.04 ships by default — do not upgrade or downgrade; the bot is bytecode-locked to 3.10).
• bittensor and requests Python packages — installed automatically by the installer.
• A funded Bittensor wallet (coldkey + hotkey). You can use the same wallet for all modes or separate wallets per mode.
• (Optional) A free Taostats API key for same-day Sentinel activation.
• (Optional) A Discord webhook URL for notifications.

License

FlowSniper is a paid license — Operator or Vanguard. Your key is tied to your account and transferable through the Armory. Request clearance if you don't have one.

• Operator — 14 days free with no payment up front. To keep running after the trial, renew for $29/mo in TAO via Discord /renew. Discord membership required for renewals.
• Vanguard — lifetime key. One-time TAO payment. No renewals.

Installation

FlowSniper ships as a single-command install. The curl one-liner from your Armory handles everything — system dependencies, Python environment, bot files, systemd service. Most operators are running within two minutes.

The install command

Find your personalized install command on your Armory download page. It looks like:

curl -fsSL <your-install-url> | bash

Run it on a fresh Ubuntu 22.04 LTS VPS with at least 8 GB RAM. The installer:

• Installs Python 3 and all system dependencies.
• Creates ~/flowsniper with a Python virtual environment.
• Installs the bittensor and requests packages.
• Drops flowsniper.py and flowsniper_menu.py in place.
• Sets up a systemd service (flowsniper.service) for 24/7 operation.
• Launches the first-boot setup wizard so you can configure wallet, budgets, and chain endpoint.

Opening the menu after install

Anytime you want the interactive menu, SSH into your VPS and run:

cd ~/flowsniper
source venv/bin/activate
python flowsniper_menu.py

The bot itself keeps running as a systemd service regardless of whether you have the menu open — the menu is just the operator's view into what the bot is already doing.

Service control (without leaving the menu)

From the Command Center, [12] SERVICE CONTROL exposes start / stop / restart / status / tail-logs without ever touching systemctl directly. You rarely need the command line after install.

First Boot & Dry Run

On first run FlowSniper asks for the basics, stores them in the profile, and drops you at the Command Center. Every mode is enabled by default and every mode is in dry run. That is correct. Do not flip anything live yet.

The first 24 hours — what to actually do

1. Let it run for ten sweep cycles (about 30 minutes at the default 3-min cadence). This is Sniper's prereq to even be eligible for live.
2. While that runs, open SITREP and watch a few cycles go by. You should see subnets appearing on the Threat Board with conviction scores.
3. If you intend to run Sentinel, set your Taostats API key now (see the Taostats section). Without it, Sentinel needs ~14 days of organic history before it activates. With it, Sentinel is ready in roughly 26 minutes.
4. Open each mode's submenu and walk the options. Everything is safe to poke at in dry run — you cannot accidentally move TAO.
5. Configure your budgets (see Per-Mode Budgets). The default split is 30/30/20/20 but you should match it to your strategy.
6. Add a Discord webhook (Notifications menu) if you want alerts. Defaults turn on automatically when a webhook is added.

The Command Center

The main menu you see when you run python flowsniper_menu.py. Every mode's PnL, position count, and live/dry state is visible at a glance. Bootstrap progress appears inline while Sentinel is building history.

Status strings mean exactly what they say:

• ● LIVE — that mode is trading with real TAO right now.
• ○ PENDING — you asked for live; prereqs aren't met yet; bot will auto-flip.
• ○ dry run — safe default; simulating only.
• off — you disabled that mode entirely via the Modes menu.

If any mode is in PENDING, a yellow banner appears. If all modes are dry, a red DRY RUN banner appears. If any mode is live, no banner is shown — real trades are happening.

The Four Modes — Overview & Comparison

Every mode is a different answer to the question "what should this bot do with my capital?" You can run any combination — all four at once, just one, or any mix. Each mode independently has its own enable flag, wallet, budget cap, and live/dry toggle.

How they work together

The modes aren't isolated silos. Positions can flow between them, and profits from one can fund another.

• Shadow → Designate: Promote any Shadow position to Designate with one keystroke. The mirror is preserved (target exit still triggers yours), but Designate's risk rules now also apply. Whichever triggers first wins.
• Sentinel → Designate: Promote any Sentinel position to Designate to take it out of Sentinel's universe-driven management and put it under Designate's manual risk rules. Common use: halting an in-progress dropout unwind on a position you have personal conviction on.
• Sniper/Designate → Sentinel (cross-mode compound): Realized profits from Sniper and Designate can route into Sentinel's compound pool, which then spends that TAO buying whatever the current universe ranking says on the next DCA step.
• Sentinel's own auto-compound: When Sentinel trims a position above its target weight and realizes profit, that profit can reinvest back into Sentinel separately (independent percentage toggle).

Sniper ACTIVE · MOMENTUM

Sniper is the original FlowSniper behavior: an active momentum trader that scans all 128 subnets every cycle and enters when conviction crosses threshold. It's the most hands-off of the active modes — you tune parameters once, then the bot hunts, sizes, enters, manages, and exits on its own.

What Sniper does on every sweep

1. Pulls the latest on-chain state for every subnet.
2. Scores each subnet across 16 signal dimensions (see Signal Architecture).
3. Produces a composite conviction score that blends setup, trigger, and decay components.
4. Filters by liquidity, impact cost, drawdown, regime, cooldowns, and per-hour trade limits.
5. Opens new positions if conviction sustained across cycles. Closes positions on stop, trail, profit target, or decay.

Sniper menu

Parameters you'll care about

The full parameter set is wider (sixteen signal weights, conviction compositing, setup/trigger/decay subcomponents). Most operators tune the table above and leave the signal internals to Auto-Tune.

The partial exit ladder

When a Sniper position runs in profit, it doesn't all sit there hoping for more. A partial ladder trims slices at configurable profit levels — e.g. sell 25% at +40%, another 25% at +75%, leave the rest on a trailing stop. You can edit the ladder JSON directly in Parameters → Partial Ladder.

Sentinel PORTFOLIO · LONG HOLD

Sentinel builds and holds a subnet portfolio. It's a rules-based universe screener with value-averaged deployment, drift rebalancing, and optional auto-compound. Where Sniper hunts, Sentinel allocates.

How Sentinel thinks

1. Screen the universe. Every subnet gets ranked by a blended score that cares about momentum, liquidity depth, reserve growth, and staking flow — a slower, structural version of Sniper's scoring.
2. Pick the top N. Your risk tier chooses how many holdings to target (see table below).
3. Value-average in. Instead of dumping your entire Sentinel budget in one cycle, Sentinel ramps deployment over a tier-default window (Conservative 10d, Balanced 5d, Aggressive 3d).
4. Rebalance by drift. When a holding's weight drifts far enough above or below its target, Sentinel trims winners or adds to laggards.
5. Compound if enabled. Realized profit from trims routes into a compound pool and gets redeployed on the next DCA step.

Risk tiers

Universe dropouts — what happens when a held subnet falls out

If a subnet you hold via Sentinel falls out of the qualified universe (its quality screen starts failing), Sentinel automatically unwinds the position over time. The unwind rate depends on why it dropped out, modeled on industry practice for fund holdings.

Fast unwind applies to liquidity-driven dropouts. Industry index funds typically remove on liquidity grounds within 5–10 trading days — the principle being that thin liquidity means market impact gets worse the longer you wait.

Slow unwind applies to quality/valuation dropouts. Active fund practice is 1–3 month unwind on outflow-driven removals — the position can recover, and rushing the exit costs more than waiting.

Sentinel menu

The bootstrap question

Sentinel needs history to rank subnets. Two paths:

• Cold start (no Taostats key): The bot builds history organically from its own sweeps. Sentinel activates after roughly 14 days of data. Free, no setup, slow.
• Bootstrap (with Taostats key): On first run the bot backfills 30 days of history from the Taostats API in about 26 minutes at the free-tier rate limit (5 calls/min). Sentinel activates the same day. Free, one-step setup, fast.

If you're planning to run Sentinel seriously, get the Taostats key. See the Taostats section.

Portfolio Preview

Before you flip Sentinel live, go to Sentinel → Portfolio Preview. It shows the portfolio Sentinel would build at your current risk tier, with target weights, projected DCA pace, and the ranked rationale for each pick. This is where you sanity-check before committing capital.

As of v1.0.5, the Portfolio Preview also shows a Deployment Forecast block — projected time to first buy, time to open all target positions, and time to reach full allocation based on your current wallet size, tier, and ramp configuration. See the next section for what those numbers mean.

Deployment pacing and wallet sizing

Sentinel does not open all of its target positions instantly. It uses value-averaging with a deployment ramp and a weekly budget cap, which deliberately spreads spending over days. This prevents buying at local tops and gives the portfolio time to respond to market moves.

Sentinel operates in two phases:

• Build phase — the initial portfolio construction from 0% to ~100% deployed. During this phase, Sentinel boosts its weekly cap by a build multiplier (default 3.5×) so the portfolio reaches full allocation in roughly 10-20 days instead of 35. This is the right behavior for initial deployment: you want exposure soon, not after a market cycle has already passed.
• Rebalance phase — once the portfolio is ≥95% deployed, Sentinel reverts to the tier's default weekly cap. At this point the bot is only handling drift corrections and compound reinvestment, so a gentler pace is appropriate.

Four things control how fast Sentinel builds the portfolio:

• Weekly deployment cap — how much of the Sentinel budget can move in any 7-day window. Tier-dependent: Conservative 10%, Balanced 20%, Aggressive 35%. Split evenly across 7 days as the daily budget.
• Build multiplier — boost factor applied to the weekly cap during initial build. Default 3.5×. Configurable in Sentinel → Parameters → [M] Adjust build multiplier (range 1.0×–5.0×). Reverts to 1.0× automatically once portfolio is 95% deployed.
• Ramp days — how the per-position target grows from 0 to 100% allocation. Defaults: Conservative 10d, Balanced 5d, Aggressive 3d. Override with sentinel_ramp_days in Parameters.
• Minimum buy size — a hard 0.01τ floor on every buy. Below this, transaction fees dominate and a trade loses money before it can profit. Non-negotiable, applies to all wallets and tiers.

How Sentinel handles the 0.01τ floor

The daily budget (weekly cap ÷ 7, with build-phase multiplier applied) determines how Sentinel spends each day. There are three possible modes, chosen automatically based on budget size:

• Parallel — if the daily budget can fund a 0.01τ buy for every target position (daily budget ≥ holdings × 0.01τ), Sentinel splits spending across all positions with active gaps.
• Single-shot — if the daily budget is at least 0.01τ but below the parallel threshold, Sentinel fires one buy per day into the position with the largest gap.
• Accumulating — if the daily budget is below 0.01τ, Sentinel banks each day's share into a pending deployment bucket. When the bucket crosses 0.01τ, a single buy fires. The bucket carries across days — if the bot is offline for a day, the missed share is credited on the next run (capped at 7 days of back-credit).

With the default 3.5× build multiplier, most retail wallets (≥1τ) run in parallel or single-shot mode during build. Only very small wallets (~0.5τ on Balanced) accumulate — and even then, buys fire every 1-2 days during build instead of every 2-3 days without the multiplier.

What this looks like in practice

For a 0.5τ wallet on Balanced tier (8 holdings, 40% Sentinel budget, 5-day ramp, default 3.5× multiplier):

• Portfolio target: 0.196τ. Base weekly cap: 0.039τ (20%). Build-phase cap: 0.137τ (70%). Daily budget during build: 0.0196τ. Per-position full target: 0.025τ each.
• Build-phase mode: single-shot (daily budget above 0.01τ but below 8 × 0.01τ).
• Day 0 onward: First buy fires on the first sweep after activation (roughly one 0.01–0.02τ buy per day, targeting whichever position has the largest gap).
• Days 0–10: Portfolio fills to ~95% deployed. All 8 target positions have entries by roughly day 8.
• Day ~10: Build phase complete. Sentinel logs Sentinel build-phase complete and reverts to 20%/week cap for rebalancing.
• Day 10+: Rebalance mode. Sentinel only trades for drift corrections (holdings outside tier drift threshold) or compound reinvestment. Most days nothing happens, which is expected behavior.

How much TAO should I fund?

Build-phase duration is governed by tier weekly cap × build multiplier, not by wallet size. Larger wallets just have bigger per-buy sizes. Reference points on Balanced tier with 8 holdings, 40% Sentinel budget, default 3.5× multiplier:

Approximate build-phase durations at default 3.5× multiplier:

• Balanced (20%/wk × 3.5): ~10 days to 100% deployed
• Aggressive (35%/wk × 3.5): ~6 days to 100% deployed (effectively chain-limited)
• Conservative (10%/wk × 3.5): ~20 days to 100% deployed

If you want a different build pace, three tuning options:

• Adjust sentinel_build_multiplier — easiest via the [M] key in Sentinel → Risk Profile, which exposes an interactive slider (1.0×–5.0× in 0.5 steps). Default 3.5×; set higher for faster builds, lower (down to 1.0×) for steady tier pace. Setting 1.0× disables the build-phase boost entirely — use this if you want the pre-v1.0.5 behavior (roughly 35-day builds). The same value can be edited in Parameters directly if you prefer the config path.
• Reduce sentinel_target_holdings — fewer positions means each one is a larger share of your budget. Useful if you prefer a concentrated portfolio.
• Switch tier — Aggressive builds fastest, Conservative slowest. Changes tier defaults for other parameters too, not just pace.

The build multiplier affects only the initial deployment. Once the portfolio reaches 95% deployed, Sentinel automatically reverts to the tier cap for rebalancing — so you're not signing up for permanently aggressive spending.

Fortify

Sentinel → Fortify is the portfolio review screen: current holdings, individual PnL, drift from target, time held, and Sentinel's own health checks. Use this as your weekly read.

Designate MANUAL · BOT-MANAGED

Designate is the human-in-the-loop mode. You decide what to buy. The bot decides when to sell. It's perfect for operators who want control over entry selection but don't want to sit at the terminal babysitting exits.

Typical flow

1. You read something on X, hear a Discord tip, or just have a feeling about SN-37.
2. Open Designate → Mark Target. Enter SN number and size.
3. The bot enters on the next sweep, records the entry, and wraps the position in the full risk package (stop-loss, trailing stop, partials, RIPCORD).
4. Exit fires automatically when any risk rule triggers. Or you hit Designate → Neutralize to force-close whenever.

Designate menu

Per-position parameters

Unlike Sniper (where settings apply to all positions), Designate lets you tune stops and trails per position. You can hold SN-A on a tight 8% stop and SN-B on a looser 20% stop at the same time. Edit under Adjust Parameters.

Adding to an existing position

If you Mark Target on a subnet you already hold in Designate, the bot detects the duplicate and prompts:

SN24 is already a Designate target.
Current size: 0.025τ  ·  Entry: 0.0312

[A]dd to existing position (merge TAO)
[C]ancel

Selecting Add merges the new TAO into the existing position instead of overwriting it. The bot treats the add as a pending deployment that fires on the next sweep using the same entry logic as a fresh mark. Your per-position stop-loss, trailing stop, and partial exits carry over unchanged — only the sizing updates.

This is the right tool for averaging down into a position that's drifted below entry, scaling into conviction over multiple days, or topping up after a partial exit. Designate treats the averaged position as one lot for PnL accounting.

Field Recovery

If you've ever staked to a subnet manually and then forgot about the alpha you're holding, this is the recover-from-chain button. It queries your wallet, finds any stray alpha positions, and gives you the option to adopt them into Designate's management. Useful after wallet migrations.

Shadow COPY-TRADE · MIRROR

Shadow mirrors trades from other wallets. You paste up to 5 wallet addresses, size your trades as fixed-τ or proportional-to-target, and Shadow enters when they enter, exits when they exit. It's a pure copy mode — no risk management, no signals, no opinions. If you want risk rules too, promote the position to Designate.

What Shadow actually watches

Every sweep, Shadow diffs each watched wallet's alpha holdings against the previous snapshot. A holding that jumped is a likely entry; a holding that dropped is a likely exit. But passive stake emissions drift alpha upward over time without the target ever trading — Shadow filters these using shadow_trade_delta_min (default 2%). Only changes above that threshold are treated as real trades.

Baseline on add — what Shadow does NOT copy

When you add a new target wallet, Shadow takes a snapshot of its existing holdings on the first sweep and treats those as the baseline. It does not mirror what the wallet already holds — only changes after that baseline get copied.

So if you add a whale who's sitting on 50 positions, you don't suddenly copy into 50 positions at current prices. You just start watching; when they next enter or exit something, Shadow follows. This is deliberate — copying someone into a portfolio they accumulated over months at better entries would be expensive and usually unprofitable.

The baseline is persisted to shadow_wallet_snapshots in your database, so removing a target and re-adding it will re-anchor the baseline at the current state — you won't backfill missed trades.

Per-wallet PnL attribution

The Shadow → Target Wallets screen shows a per-wallet PnL breakdown:

• Baseline — when you started tracking
• Realized PnL — profit/loss from closed shadow trades attributed to that source wallet
• Unrealized PnL — current mark-to-market on open shadow positions originated from that wallet
• Total — realized + unrealized

Use this to rank your targets. If one whale produces consistent positive realized PnL and another drags, rotate. Attribution is tracked by stamping the source wallet's SS58 into each exit journal entry.

Shadow menu

Sizing models

• Fixed τ: Every shadow entry uses the same fixed TAO amount (e.g. 0.02τ per trade). Simple, predictable, doesn't track position size.
• Proportional (% of target): You mirror the target's sizing. If they put 10τ into SN-5, and your proportional setting is 10%, you put 1τ into SN-5. Scales with their conviction.

There's also shadow_max_position_tao as a hard cap per subnet regardless of sizing math, so a whale can't accidentally pull you into an oversized position.

Promote to Designate

Shadow positions are naked mirrors — if the target never exits, neither do you. If you see a Shadow position in profit and want to protect it with stops, go to Designate → Promote Shadow (appears when Shadow has open positions). The mirror stays intact — the target's exit still triggers yours — but Designate's risk rules now also apply. Whichever triggers first wins.

Fire Control — The Live-Trading Gate

Fire Control is the master switch. Every mode's dry→live flip happens here, under a typed YES confirmation, with per-mode prerequisite checks. This is the single screen that separates simulation from real TAO movement.

The three states

• DRY RUN: default. Mode simulates but moves no capital.
• PENDING: you asked for live but prereqs aren't satisfied. Bot stays dry, auto-flips to live on the next cycle where prereqs clear. You can cancel pending at any time.
• LIVE: real trades execute.

Prerequisites by mode

Flipping a mode live

1. Open Fire Control from the main menu ([5]).
2. Pick the mode number (1=Sniper, 2=Sentinel, 3=Designate, 4=Shadow).
3. Read the warning. Every flip-to-live warns about real-TAO risk.
4. If prereqs aren't met, you get [S]tage PENDING or [C]ancel. If they are met, you're prompted to type YES in all caps.
5. On confirmation, the service stops, profile updates, service restarts. Next sweep trades live.

Bulk controls

• [A] Enable ALL modes live — attempts live on all four. Modes with met prereqs flip LIVE, others stage PENDING. One YES confirms all.
• [D] Disable ALL modes — flips everything back to dry. Open positions keep being managed (stops and trails still fire) but no new entries.

Per-Mode Capital Budgets

Every mode has a capital cap. When a mode is at or above its cap, new entries don't fire until existing positions close and free up room. Existing positions are never grandfathered to another mode — caps are forward-looking only.

Two budget formats

• Percentage: "Sniper gets 30% of my total wallet." Scales automatically as your wallet grows or shrinks.
• Absolute τ: "Sniper never goes above 5τ." Fixed ceiling regardless of wallet size.

Each mode switches between percent and absolute independently. Both values are stored, so flipping modes preserves your settings.

Default split

These add to 110% intentionally — the percentages are caps, not reservations. Modes compete for the same wallet but each can't go above its ceiling. You almost never hit all caps simultaneously.

Where to edit

Every mode's menu has a Budget item (always the last one) that opens the shared budget allocation screen. All four modes are editable from one screen regardless of which submenu you entered from.

Auto-Compound Engine

Realized profits don't have to sit in your wallet. FlowSniper can route them back into Sentinel's compound pool, which then spends that TAO buying top-ranked subnets on the next DCA step. Two independent toggles let you control this.

Sentinel's own compound

Sentinel → Auto-Compound. When Sentinel trims a position above target weight and realizes profit, a configurable percentage (sentinel_compound_pct) of that realized amount moves into the compound pool. On the next DCA step, Sentinel spends the pool on current-top-ranked subnets.

• Set to 0%: realized profit stays in your wallet.
• Set to 100%: every realized τ reinvests.
• Set somewhere in between (e.g. 50%): half grows the portfolio, half goes to the wallet.

Cross-mode compound

Sentinel → Auto-Compound → Cross-mode (or via Global Parameters). Routes realized profit from Sniper and Designate exits into Sentinel's compound pool. Same percentage mechanic: you pick how much of Sniper/Designate profit to route.

The end-to-end flow looks like this:

Sniper exit   ┐
Designate exit ├──► (× cross_mode_compound_pct) ──► Sentinel compound pool
Sentinel trim ──► (× sentinel_compound_pct)     ──► Sentinel compound pool
                                                                 │
                                                                 ▼
                                          Spent on next Sentinel DCA step
                                          Buys top-ranked subnets

Why this matters

Without compounding, a successful Sniper exit just adds τ to your free balance — dead capital until you decide what to do with it. With compounding on, that same exit grows your long-hold position automatically. Sniper feeds Sentinel; Sentinel grows the base; the base funds future Sniper entries. That's the flywheel.

Taostats API Integration

A free Taostats API key unlocks Sentinel's 30-day history backfill. This is the single highest-impact optional integration for operators who care about Sentinel — without it, Sentinel can't rank subnets until organic sweep history accumulates over two weeks.

Getting a key

1. Sign up at taostats.io/pro.
2. The free tier is enough — FlowSniper's bootstrap respects the 5 calls/min rate limit.
3. Your key format looks like: tao-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:xxxxxxxx.

Setting the key in FlowSniper

1. From the Command Center: [14/15] Global Parameters → Taostats API.
2. Pick [1] Set API key and paste (input is hidden, like a password prompt).
3. The service auto-restarts. Bootstrap starts on the next scan cycle.
4. Progress appears on the main Command Center screen: ▸ Sentinel bootstrap: 47% (60/128 subnets).
5. ~26 minutes later: bootstrap: complete. Sentinel is now eligible for live.

If bootstrap fails

Failures are usually API quota or network blips. The Taostats menu exposes [3] Reset bootstrap (retry backfill) to requeue on the next restart. Also shown inline on the main screen when status is failed.

Discord Notifications

FlowSniper ships granular per-event Discord alerts. Set a webhook once; toggle each event type on or off. Defaults are all OFF until you add a valid webhook — at that point sensible defaults flip ON automatically so you don't have to toggle 10 things manually.

Event types

• Trade entries / exits — individual entry and exit fills across all modes.
• Big moves — positions crossing a ±PnL% threshold (default 25%). Catches runners and blowups.
• Sentinel rebalance — drift-triggered rebalance events.
• Shadow events — target wallet entered/exited something you're now mirroring.
• Designate events — positions you marked opened, closed, or hit risk rules.
• Bot offline — heartbeat missed. You should know about this.
• Wallet balance — alerts if free TAO drops below a floor.
• Liquidity decay — one-cycle liquidity drops on subnets you hold.
• Milestones — first profitable day, N trades done, wallet milestones.
• Weekly digest — scheduled summary. Pick day, hour, and timezone.

Setting it up

1. Get the webhook URL: Discord server → channel settings → Integrations → Webhooks → New Webhook → Copy URL.
2. FlowSniper: Command Center → [11] NOTIFICATIONS → Set webhook.
3. Paste. Test. The bot sends a test message; if it shows up in Discord, you're done.
4. Toggle individual event types in the same menu.

SITREP — Live Dashboard

SITREP is the wide, live-updating dashboard that shows every mode simultaneously. Each mode gets its own panel with current positions, unrealized PnL, realized PnL, latest sweep results, and any warnings. The screen refreshes every 5 seconds while open.

Use SITREP when you want a single screen to stare at during active trading hours. Use the individual mode menus when you want to act on a specific mode.

Threat Board — Live Signal Scores

Every subnet's current conviction score, ranked. The Threat Board tells you what could happen next — which subnets are closest to triggering Sniper entries, which are in decay, which are quiet. It's the same data the scoring engine sees. Columns include conviction, setup score, trigger score, decay score, price momentum, and flow.

Reading it: the top of the board is where Sniper might act. The bottom is where Sniper might exit. Subnets toward the middle are sitting idle.

What's Happening — Recent Activity

A chronological timeline of everything the bot did recently — across all four modes. Each entry shows timestamp, mode, event type (entry/exit/trim/skip/alert), subnet, size, and a one-line reason. This is your single-pane audit log.

Combined View — All Modes At Once

The Combined menu crosses all four modes in a single dataset:

• All Positions: every open position from every mode in one table.
• Combined Trade History: journal entries from every mode, time-sorted.
• Combined Analytics: win rate, payoff ratio, Sharpe, max drawdown — computed across all modes together, so you see suite-level performance.
• Subnet Overlap: shows subnets held in more than one mode at once (e.g. Sentinel is holding SN-5 and Shadow just copied a whale into SN-5).
• Export All Data: dumps the combined journal to CSV.

Modes Menu — Enable & Disable

The Modes menu is where you turn entire modes on and off. This is separate from Fire Control — Modes controls whether a mode exists in your UI at all, Fire Control controls whether an existing mode is simulating or live-trading.

Disabling a mode:

• Hides its submenu from the Command Center.
• Stops generating new signals/rankings for that mode.
• Continues managing existing open positions (stops, trails still fire) — so you don't strand capital.
• Is safe to toggle — nothing destructive happens to your data.

Use Modes if, for example, you never want to see Shadow because you don't copy-trade. Disable it once and the UI cleans up.

Arsenal — Wallet Management

Each mode can use the same wallet, or its own wallet. Arsenal is where you configure which wallet each mode uses.

The wallet model

• Primary wallet (wallet_name + hotkey_name + wallet_path): used by Sniper and any mode without its own wallet configured.
• Per-mode wallets: Sentinel, Designate, and Shadow each have optional wallet fields. If empty, the mode falls back to the primary. If set, the mode uses its own keys.

Why separate wallets

• Accounting: you can see at-a-glance which wallet is which mode's book.
• Isolation: a compromised Shadow target wallet doesn't affect your Sentinel core.
• Tax reporting: some jurisdictions make life easier when you can show per-strategy wallets.

Most operators start with one wallet for everything, then split later if their capital warrants it.

Validator hotkey

FlowSniper uses a default validator hotkey for staking operations. You can override it in Arsenal if you prefer delegating to a specific validator. This setting is global.

Global Parameters

Settings that apply across all modes. This menu is where the "infrastructure" of the bot lives.

Chain endpoints

The bot talks to a Bittensor RPC node to read chain state. Two providers are built in:

• latent-lite — fast, light, default.
• finney — official Opentensor endpoint.

Whichever you pick as primary, the other becomes automatic failover if the primary is unreachable. Switch in Global Parameters → Subtensor.

Scan cadence

The default poll interval is 300 seconds (5 minutes) but adaptive polling means the effective rate varies:

• Fast (90s) — when open positions are near stops or trails.
• Normal (300s) — default.
• Idle (600s) — when no positions are open and nothing on the Threat Board is close to entry.

Override any of these in Global Parameters.

Other global settings

• Taostats API — covered in its own section above.
• Auto-tune schedule — frequency and enable flag.
• Operator mode — unlocks the Comms menu (Twitter-ready content generator) for license holders who create social content.
• Liquidity decay alert — pool drop % that triggers a Discord alert if notifications are on.

Service Control

From the Command Center, [12] Service Control manages the systemd service without leaving the menu. Options:

• Start / Stop / Restart the service.
• Status — current systemd state.
• Tail logs — live-streaming bot log output. Great for seeing every sweep in real time.
• Reconcile only — runs a one-shot reconciliation against chain state without triggering new entries. Useful after restoring from backup or switching wallets.

Auto-Tune

Auto-Tune periodically re-fits Sniper's signal weights using your own trade history, searches for better parameter combinations against your recent data, and stages the proposed updates for review before committing.

Default schedule when enabled: every 168 hours (one week). Configurable in Global Parameters or via Recon & Calibration → [2] Set frequency. When it runs, the bot:

1. Collects the last N closed trades and their entry signal snapshots.
2. Runs a grid/gradient search over signal weights, thresholds, and stop parameters.
3. Computes expected P&L under each candidate configuration.
4. Picks the best configuration by risk-adjusted return.
5. Stages the new values and shows them to you via the menu. You approve before they go live.

Menu surface

From the Command Center, navigate to [1] SNIPER → [9] Recon & Calibration. Available actions:

• [3] Recalibrate now — fires a full live tune in the background. Survives SSH disconnect; you can safely close your terminal.
• [4] Dry run (preview) — same flow but no DB writes. Useful for first-time exploration.
• [5] Rollback last tune — reverts the most recent applied parameter changes from the rollback snapshot.
• [6] Tune history — recent tune runs with deltas.
• [7] Subnet blacklist — exclude underperforming subnets from future scans.
• [8] Full backtest / [9] Quick backtest — run the underlying search alone, output to backtest_results.json.
• [10] Backtest + apply best — run a backtest, then auto-apply the winning params with a confirmation prompt.
• [V] View last result — render the most recent backtest report in-menu without re-running. Only shown if a result file exists.
• [A] Apply last result — push winning params from the most recent backtest into your live profile, with a top-10 diff preview and rollback snapshot. Only shown if a result file exists.

Background tune monitoring

When you fire a long-running action, the menu prints a banner with the PID, log path, and exact tail -f / kill commands so you can monitor progress from another shell. While a tune is mid-flight, the Command Center main screen renders a status line below the position summary:

>> Auto-tune: running backtest (slow step)  ·  elapsed 47m

The line only appears when a tune is actually running and disappears once it completes. Phases progress through auditing performance → proposing changes → running backtest → validating → applying. Backtest is the long phase — expect 5–60+ minutes depending on your trade history depth.

Lock files and concurrency

Auto-tune uses /tmp/flowsniper-tune.lock to prevent overlapping runs. Backtests use /tmp/flowsniper-backtest.lock. Both are removed automatically on normal exit. If a tune crashes hard (e.g. SIGKILL or out-of-memory), the lock may stick — clean up with rm /tmp/flowsniper-tune.lock and the next scheduled tune will fire normally.

Backtester

The built-in backtester replays your recent sweep history against the current signal/threshold configuration and reports how it would have performed. Live from Recon & Calibration → [8] Full or [9] Quick. Useful before approving an Auto-Tune proposal, or any time you manually change Sniper parameters. Like Auto-Tune, the backtester runs as a detached subprocess — fire it and walk away.

Backtest results write to backtest_results.json in your install directory. The Recon & Calibration menu surfaces [V] to view the most recent report and [A] to apply its winning params without re-running the search.

Signal Architecture

Every scan cycle, each subnet is scored across 16 signal dimensions. Weights are editable from Sniper Parameters (and auto-tuneable). Core families:

Price & momentum

• w_price_momentum — alpha token price trend.
• w_price_accel — momentum acceleration (second derivative).
• w_vwap_momentum — volume-weighted price trend.

Capital flow

• w_tao_flow — subnet_volume / EMA staking flow.
• w_reserve_change — TAO reserve growth (net staking inflows).
• w_buy_pressure — subnet volume rate vs historical average.
• w_large_buy — single-cycle reserve spike detection.
• w_chain_buy — chain buyback gap (moving price vs spot).

Technical indicators

• w_rsi — relative strength index.
• w_macd — MACD trend confirmation.
• w_bb_squeeze — Bollinger band squeeze / breakout.

Volume & liquidity

• w_volume_proxy — alpha pool activity.
• w_emission — TAO emissions to this subnet.

Composite scores

Individual dimensions feed into three composite scores:

• Setup score — "is this subnet a candidate at all?"
• Trigger score — "is now the time to act?"
• Decay score — "has the setup broken? Should we exit?"

These three compose into the conviction metric which drives entry and exit decisions.

Monitoring Your Bot

Three tools for ongoing oversight:

• SITREP — real-time dashboard. Leave it open during active hours.
• Discord webhook — delivers notifications without a terminal. Entries, exits, big moves, offline alerts.
• SIGINT — streaming bot logs across all modes. Use when you're troubleshooting or just want to watch the scoring engine think.

For multi-day trends, use the Combined → Combined Analytics view. It computes win rate, payoff, max drawdown, Sharpe, and per-signal correlation across all modes.

Updating FlowSniper

Updates are simple: re-run the same install command from your Armory. The installer detects an existing install, pulls the latest version, preserves your database and config, and restarts the service. Takes under a minute.

# Re-run your install command (the same one you used originally).
# It's on your Armory download page.
curl -fsSL <your-install-url> | bash

What the installer does on an update:

• Backs up your existing flowsniper.db automatically before touching anything.
• Replaces flowsniper.py and flowsniper_menu.py with the new versions.
• Runs schema migrations if any are needed.
• Restarts the flowsniper service so the new code loads.

Your profile, wallet config, trade history, open positions, Sentinel bootstrap state — all preserved. You do not need to stop the service, back up manually, or re-enter your settings.

If an update ever goes wrong

The installer keeps your last database backup in the working directory (named flowsniper.db.backup.YYYYMMDD). If something breaks after an update, stop the service, restore the backup, and reach out on Discord — we'll help you roll back cleanly.

Key Management & The Armory

Your FlowSniper license is tied to your account. Keys are transferable through the Armory — the secondary market for existing license holders. Lifetime keys (Vanguard tier) are extremely rare and only available via exclusive drops and the Armory.

To transfer, sell, or retrieve a key, join the Discord and DM FlowSniper Actual directly — all Armory transactions are manually verified.

Troubleshooting

"bittensor not installed"

pip install -U bittensor requests in your virtual environment. If you're not in the venv, activate it first.

The bot connects to chain but no signals appear

Normal for the first few sweeps while history builds. Wait 10–15 minutes. If still empty after an hour, check Service Control → Tail logs for RPC errors and consider switching subtensor endpoint in Global Parameters.

Sentinel bootstrap stuck or failed

Most often a Taostats rate limit or transient API error. Open Global Parameters → Taostats API → [3] Reset bootstrap and restart the service. If it fails repeatedly, check your key is active at taostats.io/pro.

Fire Control won't let me flip Sniper live

Check the prerequisite message. It's almost always "need more dry-run sweeps" — just wait. Or stage it as PENDING and the bot will flip it for you when conditions clear.

A Shadow position never appeared even though my target traded

Most common cause: the target's holding change was below shadow_trade_delta_min (default 2%) — Shadow treated it as passive emission drift, not a real trade. If you're tracking a target with very small trade sizes, lower the threshold in Shadow Sizing.

My Designate position got force-closed and I don't know why

Designate → Engagement Log shows the exit reason for every closed position. Usually it's trailing-stop trigger or the subnet hit your configured take-profit. Adjust parameters for future entries via Designate → Adjust Parameters.

The bot is running but the Command Center shows "offline"

The Command Center checks systemd status. If the service is running manually (not as systemd), the status will look offline even though the bot is working. Prefer running as a systemd service for accurate status reads.

How to Get Help

If something isn't working, here's where to go — in roughly the order you should try.

1. Check the log

Start here for almost any "bot isn't doing what I expect" issue. From the Command Center: SERVICE CONTROL → View Logs. Or from the shell: journalctl -u flowsniper -n 200 --no-pager. The log shows exactly what Sniper / Sentinel / Designate / Shadow did on every sweep, including the reasons for skipping a trade or failing to find a signal. Most "why didn't this do X?" questions are answered in the last 50 lines.

2. Check Troubleshooting above

The Troubleshooting section covers the most common issues: chain connection, bootstrap stall, Sentinel deployment, Shadow mirror detection, Fire Control prerequisites. Skim those first — your issue is likely there.

3. Discord — the best path for live support

• #support — general questions about bot behavior, config, strategy. Response usually within a few hours. Paste log excerpts, not screenshots of log excerpts; easier to read.
• #operator-chat — other operators sharing setups, subnet observations, and configs. Often your fastest answer since other Vanguards/Operators hit the same issues before you.
• #live-signals — pinned bot alerts; not a support channel, but useful context for understanding what the bot is reacting to.
• Direct DM to @FlowSniper Actual — for sensitive issues (key binding, transfer disputes, anything you'd rather not discuss in public). Don't DM for general config questions; use #support so others benefit from the answer.

4. Key & license issues

For anything license-related — "my key deactivated," "I need to rebind to a new VPS," "I want to sell my key" — use the Discord slash commands rather than DMing:

• /status — check your key's state, tier, expiry, last heartbeat
• /rebind — move your key to a new machine (one rebind per 30-day cooldown)
• /upgrade — convert your active trial to a full Operator key (pay $29 in TAO, your key keeps the same string, no reinstall)
• /renew — extend your active Operator key by 30 days (pay $29 in TAO; Vanguard is lifetime and doesn't renew)
• /sell — list your key on the Armory marketplace

All payments are in TAO. No fiat, no credit cards. You must be in our Discord to renew or upgrade — the renewal flow doesn't exist outside of it.

5. Bug reports

If you've found something that looks like an actual bug — wrong number, unexpected crash, data that doesn't reconcile — post in #support with:

• What you did
• What you expected
• What actually happened
• A log excerpt covering the moment (from journalctl -u flowsniper)
• Your current version (from Command Center header)

This format gets a fast, useful answer. "My bot is broken" does not.

How FlowSniper Protects Your Capital

The whole suite is built around the premise that losses happen, and the bot must survive them. Protection is layered.

1. Dry run by default. No mode is ever live on install. You opt in explicitly, per-mode, with typed confirmation, after prereqs clear.
2. Per-mode capital caps. A runaway Sniper can't bleed your Sentinel holdings. Each mode's cap is hard.
3. Position sizing from conviction. Weaker signals buy smaller positions. The bot never goes all-in on a single subnet.
4. Hard stop-loss. Every position has an exit price set at entry. Breach = exit. Every time.
5. Trailing stop. Winners are protected; exits chase price up, never down.
6. Partial profit ladder. Profits lock in automatically at configurable thresholds. You never round-trip a winner to zero.
7. RIPCORD. Decay score breach triggers unconditional exit — no argument, no hesitation.
8. Daily loss ceiling. Hit the daily-loss cap, Sniper freezes new entries until the day rolls over.
9. Per-hour trade limits. Overheated markets can't cascade your wallet.
10. Cooldowns. Same-subnet re-entry is gated by trade_cooldown_seconds. No ping-ponging.

These layers are independent. You don't need all of them to trigger for capital to be safe — any one of them can stop a bad outcome.

Glossary

VPS Specifications

FlowSniper has one supported configuration. There is no min/recommended split — the values below are what the installer enforces and what the bot needs to run cleanly. Anything smaller will be refused at install time.

Common providers that work well at this size: Hetzner Cloud (CX22 or larger), Digital Ocean (Basic 8 GB), Vultr (Cloud Compute 8 GB), Contabo (VPS S or larger), OVH. Avoid shared hosting — you need systemd and a persistent shell.

Disclaimer & Terms of Use