Automated Polymarket trading bots that treat a FILLED event as the final word risk acting on unverified state. A production-grade system should model execution as a state machine spanning intended, submitted, matched, filled, transaction-pending, confirmed, settled, and position-verified states, with explicit unknown/inconsistent states for uncertainty. The piece argues for separating execution verification, reconciliation, and risk control from strategy logic, and links to an open-source Polymarket Execution Verifier project implementing this architecture, alongside related work on partial fills, position reconciliation, and WebSocket recovery.
Questions this post answers
Why shouldn't a trading bot treat a FILLED order status as fully settled?
A FILLED event only confirms that a match occurred, not that the transaction confirmed, settlement finalized, or the local position matches the account's actual holdings. A bot requesting 100 units might get matched for only 40, so treating FILLED as done can leave local state at +100 while the real position is +40, corrupting downstream risk and exposure calculations. Developers building trading infrastructure can find deeper design discussions on daily.dev to avoid these state-tracking pitfalls.
How should a trading bot handle unknown order state after a dropped connection?
Rather than assuming UNKNOWN transitions to FAILED or FILLED, a safer model pauses trading, reconciles with the exchange, verifies the actual order state, and only then resumes. This avoids silently acting on an assumption when the order could have been rejected, accepted, partially filled, filled, or cancelled during the disconnect. Anyone designing resilient trading bots can track reconnection and reconciliation patterns like this via daily.dev.
Share this post