# Tiny autonomous live gating pattern

Use this pattern when moving a crypto trading bot from convincing paper results to tiny autonomous live trading.

## User-facing operating mode

- Do not require manual approval for every micro-trade once autonomy is explicitly approved.
- Do not spam normal trade-by-trade reports.
- Send a concise daily report at the agreed local time, and immediate alerts only for critical safety events.
- For trading-status questions, answer as a trader/risk manager first; avoid long developer logs unless the user asks for implementation detail.

## Final live gates before any autonomous mainnet order

Require a preflight mode dedicated to the exact launch class, e.g. `tiny-autonomous-live`, separate from generic `live-preview`.

Hard gates:

1. Mainnet read-only reconcile is green.
2. No open positions or open orders before start.
3. Mainnet signed credentials are internally consistent: funded account/subaccount address, agent signer private key, derived agent wallet address, and configured agent-wallet address agree as expected.
4. API health is green.
5. DataQualityGate is green for current market data.
6. Kill-switch is not active.
7. Daily-loss, weekly-loss, and loss-streak gates are active.
8. Reconciler is active and can block new entries.
9. Telegram/critical alert delivery is proven with real message delivery, not only a local dry run.
10. Legacy live/AutoTrader paths are blocked.
11. Secrets/log scan is clean.
12. Testnet strategy smoke proves forced signal -> entry -> reduceOnly stop -> reconcile -> controlled close -> cleanup.
13. Net paper scorecard gates are green, including PnL ex-problem-coin and top-coin concentration.
14. No mainnet order was sent before the explicit final launch condition.

Allowed conditional:

- Hyperliquid `scheduleCancel` can remain `conditional_unavailable_due_to_exchange_volume_limit` if and only if all other gates are green and the failure is exchange volume/availability, not bot logic.

If any hard gate is red, do not start live. Report the red gate and stop.

## Signed credential pitfall

Read-only reconcile can be green while signed mainnet trading is still unsafe. Treat `agent_wallet_private_key_mismatch`, `api_key_private_key_mismatch`, or equivalent account-vs-agent inconsistencies as a hard blocker for autonomous live, even if there are no positions/orders and account balance is visible. Never “work around” this by sending a tiny order.

## Risk limits for tiny autonomous start

Persist launch limits in runtime config and verify them during preflight:

- long-only at start
- max open trades: 3
- max notional per trade: 10–15 USDC
- max total open notional: 45 USDC
- default leverage 1x, hard max 2x
- max daily loss: 2 USDC
- max weekly loss: 5 USDC
- after 2 losing trades in a row: block new entries and require analysis in the daily report
- no Martingale
- no averaging down
- no risk increase without user approval
- no new live strategies without paper/shadow proof
- no new live coins without report/approval

## WLD / problem-coin handling

Do not permanently ban a historically leaky coin if the user wants trader discretion, but make it constrained and visible:

- max one open position
- max 20% of last 30 trades
- require clean setup, spread, depth, volume, funding, and regime
- block if it dominates stats or PnL ex-coin turns negative
- always include coin share and PnL ex-coin in the daily report

## Alerting and reporting pattern

Critical immediate alerts only:

- position without stop
- kill-switch
- daily loss limit reached
- unexpected open position
- reconcile mismatch
- bot/process not recoverable
- sustained API/data degraded mode

Daily report fields:

- equity/free collateral
- net daily PnL
- open positions and orders
- trade count
- best/worst trades
- WLD/problem-coin share and PnL ex-coin
- market regime
- API health and data quality
- reconcile status
- learnings
- proposed changes
- recommendation: continue / pause / reduce risk / paper test needed

## Telegram smoke nuance

If the bot-specific Telegram adapter is not configured but the Hermes platform messaging target is available, a platform-level smoke can prove real delivery for the current Telegram topic. Journal the target, message IDs, alert names, `secrets_sent=false`, and `mainnet_order_sent=false`. Keep bot-adapter configuration as a separate gate if the live runtime depends on that adapter rather than Hermes delivery.