Polymarket Bot Tutorial · Chapter 31 of 32

Going live with your Polymarket bot: 25-50 USD first deposit, take-profit and stop-loss rules, alert thresholds (Telegram/email), reconciliation cadence, and the first-week scaling plan.

What this chapter covers

The transition from paper to live is where most builders accidentally lose their first deposit. This chapter is the pre-flight checklist plus the first-week discipline that catches bugs before they become losses.

  • Pre-flight checklist
  • First deposit: 25-50 USD
  • TP/SL rules from production
  • Monitoring: Telegram, email, dashboards
  • Reconcile cadence: every fire_exits cycle
  • First week: stay close, stay small
  • Scaling: when to deposit more

Pre-flight checklist

The exact list, in order, before flipping the bot from paper to live.

  1. 30 closed paper trades. Written success criteria met or exceeded.
  2. Diary format identical between paper and live. Same JSONL schema.
  3. VPS deployed. Bot is the only process; systemd unit configured.
  4. HALT file mechanism tested. touch /opt/pmt/HALT stops the bot within 30 seconds.
  5. Telegram alerts configured. A test alert sends successfully.
  6. Daily-loss kill switch tested. Simulate a 10% drawdown; verify halt fires.
  7. On-chain reconciliation tested. Manually mismatch the diary; verify halt fires.
  8. Deposit address is the proxy wallet - the smart-contract wallet Polymarket trades from on your behalf (POLY_FUNDER_ADDRESS) - not your personal account, the externally-owned account or EOA. Verified via SDK wallet show.
  9. pUSD allowance set on both the standard exchange and the NegRisk exchange (pUSD is the collateral since the April 2026 migration).
  10. Initial deposit amount agreed in writing: $25-50 for smoke test.

If any item is incomplete, do not go live. Each one has cost a builder real money in past production stories.

First deposit: 25-50 USD

The smoke-test deposit is intentionally small. The goal is to verify the live path works, not to make money.

What you're testing: does the bot's order placement match Polymarket's view of the trade. Does the diary record correctly. Does the take-profit GTC actually post. Does the bot recover from a transient API error. Does the daily-loss halt trigger if you simulate one.

Expected outcome: 5-15 small trades that approximately mirror the paper diary. Treat any divergence as a bug, not a feature of "live being noisier than paper."

If you blow this $25-50 on a real strategy loss, the strategy needs more paper runs. If you blow it on bugs, fix the bugs before scaling.

Take-profit and stop-loss rules from production

Two quick definitions first, since this section leans on them. A take-profit (TP) is a pre-set sell order that locks in a gain once price rises to your target; a stop-loss (SL) is a sell that cuts the position once price falls past a limit, so one bad trade cannot run away. The two order types below are GTC (Good-Til-Cancelled, a resting order that waits in the book until it fills or you cancel) and FOK (Fill-Or-Kill, which fills the whole order instantly or cancels it entirely). One more term you will see, mark, is not an order type at all - it just means the current mid-price you measure the position against. Below are production defaults from our trader, which have held up across thousands of trades.

  • Buy: FOK at 1c above the best ask. Skip the trade if the ask is above 0.85 - this is "the 0.99 trap", where a near-certain market priced at 0.90+ offers tiny upside but a brutal drop if it flips, so the risk/reward is upside-down.
  • Take-profit: GTC sell at entry + 4-6c, posted immediately after buy fill + 5s settlement wait.
  • Stop-loss via mark: monitor mid; if mid drops to entry - 8c, FOK sell at best bid (no resting; mid blow-through happens fast).
  • Time exit: if position is not closed within X hours and PnL is between -2c and +2c, FOK exit at market.

The numbers shift per strategy, but the pattern is consistent: take-profit always GTC, stop-loss usually FOK (because GTC stops don't fill when mid blows through), time exits to avoid riding stale signals.

Monitoring: Telegram, email, dashboards

The bot needs to be observable in real time. Three layers.

  • Telegram alerts: every fill, every halt, every error above threshold. Use a dedicated channel or group; don't mix with personal messages.
  • Daily summary email: end of day, total trades, win rate, PnL, list of halts triggered. Read it every morning.
  • Dashboard: optional but useful. A simple HTTP endpoint that reads the diary and renders open positions + recent fills + cumulative PnL.

The pattern: any state change worth knowing about → Telegram. End-of-day summary → email. Real-time exploration → dashboard.

Reconcile cadence: every fire_exits cycle

Reconciliation must run frequently enough that drift is caught before the next trade can compound it. The cadence depends on trade frequency.

  • Strategies with < 10 trades/day: reconcile every hour.
  • Strategies with 10-100 trades/day: reconcile every 15 minutes.
  • HFT strategies (100+ trades/day): reconcile every cycle of the exit-firing loop.

The cost of reconciliation is one chain read per token held. At 20 tokens, that's 20 RPC calls; at a free-tier RPC, well within budget. Don't over-optimize this.

First week: stay close, stay small

Week one of live deployment is the most dangerous. You're discovering live-path bugs the paper run missed. Discipline:

  • Stay close - check the Telegram channel hourly during waking hours.
  • Stay small - position sizes at minimum (5 shares); a bug should cost dollars, not hundreds.
  • Reconcile manually at end of day for the first 3-5 days. Compare diary to Polymarket UI directly.
  • Document every surprise. Even small confusions become bugs eventually.

End of week one: if no bugs and the diary matches reality, scale to normal size. If bugs appeared, fix them, run another smoke-test week.

Scaling: when to deposit more

Triggers for adding capital, each with a different threshold.

  • +50% deposit: 30 live trades, win rate within 5pts of paper rate, no production halts due to bugs.
  • +100-200% deposit: 100+ live trades, consistent profitability across the sample, infrastructure tested through at least one minor outage.
  • +500%+ deposit: only after 6+ months of consistent live profitability. Capital ramps slower than success - you want to be sure the edge is real, not a regime that's about to disappear.

The biggest single risk of premature scaling: a strategy that was profitable in one market regime becomes unprofitable in the next. Bigger size doesn't fix that. Patience does.

Frequently asked questions

How much should my first live deposit be?
25-50 USD. Enough to test real fills, real fees, real reconciliation. Small enough that a total loss does not affect your life. Most disciplined traders we know start at this size even if their bankroll allows much more - the ego cost of a small loss is far less than the ego cost of a big one.
What TP/SL should I set?
Symmetric to your edge. If your strategy expects +5% per winning trade, set take-profit at +5-7% and stop-loss at -3-4%. Asymmetric (small TP, large SL) is gambling, not trading. Our production trader uses TP+6% / SL-4% (FAK exits) on most strategies.
How should I monitor my bot live?
Three channels: (1) Real-time alerts on closed-trade outcomes >$0.30 PnL via Telegram bot. (2) Hourly dashboard view of cash + open positions + MtM. (3) Daily PnL summary by email. Failing any of those three means you are running blind.
What should trigger an emergency stop?
Any of: daily loss > 5% of bankroll, fill rate < 30% (suggests wedged orders), more than 5 consecutive losing trades, market data feed silent for >30 seconds, or any reconciliation mismatch between diary and on-chain. All can be coded as automatic halt-sentinel touches.
When can I scale up my live bankroll?
When you have at least 50 closed live trades, the live win rate matches paper within 10%, and there has been no reconciliation incident in 2+ weeks. Scale by 2x at most per checkpoint - 25 USD -> 50 -> 100 -> 200 -> 500 over months, not days.
Should I run multiple strategies live at once?
Not initially. Get one strategy live for 2-4 weeks, validated. Then add a second. Monitoring two strategies at once during the first weeks is a recipe for missing the bug that kills strategy 1.