A Short Checklist for Kalshi Bots

Paper trading is useful when it catches mistakes that would have been expensive live. For Kalshi-style bots, the mistakes are usually not glamorous. They are order fields, side logic, size, fees, and error handling.

1. Check the shape of the order

Every order should have the expected ticker, action, side, and count. If the API rejects the request, the bot should learn something. It should not keep knocking on the same locked door.

2. Try to invert yourself

YES/NO logic is easy to get backwards, especially when an agent turns market text into a trade. Test both sides on purpose. Then inspect the resulting positions as if you expected them to be wrong.

3. Make size hurt

Do not only test tiny orders. Increase size until slippage matters. A realistic simulator should walk visible order book depth and compute an average execution price. If there is not enough depth, the bot should get a clear rejection.

4. Count fees where they happen

Fees should appear in balances, trade records, and performance metrics. If they live in a separate spreadsheet you rarely open, they are not part of the test.

5. Hit the limits deliberately

Bots should slow down, alert, or stop when they hit quota pressure. A rate limit is not just an HTTP status. It is a test of whether the agent can stop doing the wrong thing.

6. Keep the receipt

Keep order history, fills, trades, ledger entries, and portfolio snapshots. You will need the trail when two versions disagree and both seem plausible.

7. Graduate reluctantly

Passing a sandbox does not mean a bot is safe. It means the most obvious execution bugs did not show up yet. That is still worth a lot. The goal is not certainty. It is fewer stupid losses.