Going live safely

Going live means a strategy stops filling against your own candle data and starts sending real orders to an exchange. That is a different category of risk, and Forven treats it as one. This page is the operator's checklist for the moment before real capital: what must be true, what the strict paper→live gate verifies, and the controls that keep watching once a strategy is deployed.

This page is for operators. It assumes you have already run a strategy through the gauntlet and proven it in paper — the stage the public site calls "candidate." It does not re-teach those stages; it covers the transition between them and the safeguards on the far side.

Forven is a research tool. Results are not predictive, no setting creates an edge, and nothing here is financial advice. The controls below limit downside — they do not guarantee against loss.

Beta reality: the paper-lock

Before anything else, know that beta builds hard-lock execution to paper. With FORVEN_ENV=beta, get_execution_mode() returns paper no matter what config.json says — the lock is applied where the mode is read, so a stale live value can never take effect. Mainnet is also default-deny behind FORVEN_ALLOW_MAINNET (must be 1).

So in beta you cannot reach live capital. Read this page now anyway: the gate, the wallet model, and the decay kill-switch are the same machinery you will rely on the day live is unlocked, and knowing them cold is part of the discipline. See execution modes for the full paper-vs-live distinction.

The strict paper→live gate

Forven promotes a strategy through a four-stage lifecycle — Ideation → Test → Paper → Live — and each transition has a validation gate. The paper→live gate is the strict one; it is the last automated check before real orders.

To be eligible, a strategy in paper must have:

• A completed walk-forward backtest. The policy gate verify_backtest_exists_for_stage_transition blocks promotion if walk-forward results are missing. Out-of-sample survival is the evidence that matters here, not in-sample shine.
• Enough paper history. A track of 30+ paper trades over 72h+ (illustrative policy thresholds) so the result is more than noise.
• A Sharpe ratio above the policy threshold. Cumulative paper Sharpe and drawdown are reviewed against the gate's floor.
• No pending recovery. The system refuses to promote while position reconciliation is mid-flight.

The risk-manager agent reviews paper PnL, drawdown, and signal quality; promotion to live is operator-approved only. The brain never sends a strategy to real capital on its own. See promotion gates for the full gate definitions and operator overrides.

Paper PnL is not a proxy for live PnL. Paper trades fill at local OHLCV mid-prices (paper_stage_local_execution_only=true), carry no exchange order ID, and are never reconciled against the exchange. A clean paper record proves the signal logic and risk plumbing; it does not promise live fills at those prices.

Steps: the pre-flight checklist

Work through this in order. Each step is a thing to confirm, not a thing to rush.

1. Re-read the walk-forward result. Open the strategy in the lab and confirm the gauntlet's walk-forward analysis actually passed out-of-sample — not just that a backtest exists. Trust OOS metrics over in-sample.
2. Review the paper session. Confirm the strategy has the required paper history (30+ trades over 72h+, illustrative) and that cumulative Sharpe and drawdown clear the gate. Check the close-reason breakdown for signs the edge is luck, not logic.
3. Inspect signal quality. Look at the entries and exits on the signal chart. Slippage, payoff, and the by-regime breakdown should look like the strategy you tested, not a drifted version of it.
4. Set your risk limits deliberately. In Settings → Trading, set max_drawdown_pct, max_daily_loss_pct, max_risk_per_trade_pct, and the live wallet cap max_concurrent_positions. These now apply to real money. See risk controls for how they interact.
5. Configure and test the exchange connection. Provide HyperLiquid credentials (env FORVEN_HL_*, the ~/.forven/hyperliquid.json file, or encrypted settings) and verify the account reads back. Start on testnet (FORVEN_HL_USE_TESTNET=true) and confirm account.network shows testnet. See HyperLiquid integration.
6. Confirm the network gate. Mainnet is default-deny. Only set FORVEN_ALLOW_MAINNET=1 when you genuinely intend real capital and have done everything above.
7. Switch execution mode last. In Settings → Execution Mode, switch from paper to live (beta refuses this). This writes execution_mode and calls set_execution_mode('live'); the next scanner run picks it up.
8. Promote the strategy. With the gate satisfied, promote paper→live. The system writes a strategy_event (from_state='paper', to_state='live') and the scanner begins routing its signals to real orders.

# Verify the strict gate sees the strategy as live-eligible (read-only)
Invoke-RestMethod -Uri "http://127.0.0.1:8003/api/lifecycle/strategies"

# Promotion is operator-approved and gate-validated (WFA, Sharpe, no pending recovery)
Invoke-RestMethod -Method Post -Uri "http://127.0.0.1:8003/api/lifecycle/promote" `
  -ContentType "application/json" `
  -Body '{ "strategy_id": "<your-strategy-id>", "target_stage": "live" }'

What you'll see

After promotion, the strategy's lifecycle stage flips to live on the strategy container's event timeline, and its new trades are tagged execution_type='live' instead of execution_type='paper'. On the risk page the live open_positions count starts incrementing (separately from open_positions_paper), and account.network reflects testnet or mainnet. The strategy container detail page shows the full transition history.

Shared wallet: one pool, global limits

This is the single most important thing to understand before live trading more than one strategy.

Live execution pools every active strategy into ONE shared HyperLiquid wallet. There is no per-strategy wallet on the live side. The consequences:

• max_concurrent_positions is a global cap on the shared pool, not a per-strategy cap. Three live strategies share that budget.
• Per-trade and portfolio risk limits are enforced against the shared account via can_open() at order-submit time.
• Drawdown — and therefore the kill-switch — is measured across the whole pool, not per strategy.

Paper is the opposite: paper sessions are isolated per session, each with its own starting capital and positions, and they never pool with live capital. The risk view reflects this split with two separate counts:

• open_positions — live positions in the shared wallet.
• open_positions_paper — positions across isolated paper sessions.

They do not add together. Plan position limits with the pool in mind: a cap that feels generous for one strategy is shared by all of them.

Phantom recovery: keeping records honest

Because live positions live on the exchange, Forven's local SQLite records can drift from exchange truth — an order fills but the write fails, or a record is created but never captures its order ID. Phantom recovery runs at startup and periodically (about every 30 minutes) to reconcile the two.

Each cycle it reads HyperLiquid open orders and positions, compares them to local OPEN live trades, and fixes mismatches:

• Phantom position — a filled exchange position with no matching trade record. Recovery creates a new trade record. That record is not linked to a strategy and may need manual operator review.
• Pending open reconcile — a trade record with no entry_exchange_order_id. It is marked pending_open_reconcile; its risk-budget slot is freed after _PENDING_OPEN_SLOT_FREE_SECONDS (180s, illustrative). The exchange-verify path closes a genuinely-unfilled trade within that window; if not, it stays open and needs intervention.

The risk page surfaces this as recovery_active, recovery_status, recovery_position_count, recovery_discrepancy_count, a batch ID, and recovery_network. A discrepancy count that does not clear on the next cycle is your cue to look closer. Promotion to live is blocked while recovery is active, by design.

The decay kill-switch: staying live is conditional

Passing the gate is not a permanent license. Once a strategy is live, the risk-manager agent keeps comparing its rolling 72h live Sharpe against its walk-forward baseline. If performance degrades past decay_kill_switch_pct (default 30%, illustrative), the strategy is autonomously demoted out of live and trading halts for it — a quiet auto-retire of an edge that has stopped working.

This is deliberate. A strategy that decays in live conditions is exactly the strategy you want pulled before it does more damage, and the system does not wait for you to notice. The demotion is logged as a strategy_event so the history is auditable.

The decay kill-switch is per-strategy and distinct from the portfolio drawdown kill-switch — the account-wide circuit breaker that trips at max_drawdown_pct (default 10%, illustrative), emergency-closes every live position, and halts all trading until you reset it. Both are described in risk controls; resetting the portfolio kill-switch re-baselines the high-water mark and is destructive to drawdown tracking, so treat a reset as an act of judgment, not a way to silence the alarm.

Caveats

• Beta is paper-locked. You cannot reach live capital in a beta build regardless of config; the steps above are preparation for when live is unlocked.
• The HWM must be known. The portfolio kill-switch only fires when the high-water mark is set. If HWM is zero or unset, drawdown cannot be computed and the switch will not trigger — HWM syncs from the account at startup.
• A failed emergency close needs a human. If a kill-switch sweep cannot close a position after its retries (close_reason='kill_switch_close_fail'), that position stays open for manual review.
• Recovered phantom trades are unlinked. A trade created by phantom recovery is not tied to a strategy and may need operator attention.
• Every number here is an illustrative default, not a recommendation: 30% decay, 10% drawdown, 30+ trades / 72h, 180s recovery window. Tune them to your own risk budget.

Related

• Promotion gates — the full definitions of every lifecycle gate, including the strict paper→live gate.
• Risk controls — the hard limits and both kill-switches in depth.
• HyperLiquid integration — credentials, testnet vs mainnet, and the exchange connection test.
• Execution modes — paper vs live, and the beta paper-lock.