DEV Community: Casatrick | Polymrket Bot Dev

Polymarket Protocol Versions: V1, V2, V3 and What Trading Bots Need to Know

Casatrick | Polymrket Bot Dev — Wed, 07 Oct 2026 05:21:39 +0000

Polymarket version numbers are getting harder to talk about casually.

You can see:

V1
V2
V3
PolyV2

and assume there is one protocol that simply moved from version 1 to version 2 and then version 3.

That is not how the current stack is organized.

There are different versions for different parts of the system:

Exchange
Order signing
Position protocol
Market metadata
Data APIs
SDK packages

That distinction matters when you maintain a trading bot.

A package upgrade might be trivial.

A protocol change can affect:

Contracts
Collateral
Order structure
EIP-712 signing
Asset identifiers
Execution
Settlement
State reconciliation

The April 2026 Polymarket exchange upgrade was a coordinated change to the smart contracts, order-book system, and collateral layer. Polymarket describes the upgrade as moving to CTF Exchange V2 and pUSD, with changes to order structure, matching, fees, and order management.

Since then, the protocol surface has continued to evolve.

The current official clients now distinguish token-backed V1/V2 flows from PolyV2 position-backed V3 flows.

For someone maintaining a Polymarket trading system, that means protocol compatibility needs to be treated as part of the infrastructure.

There is no single Polymarket "version"

This is the first thing worth getting straight.

A useful mental model is:

Polymarket
    │
    ├── Exchange protocol
    │
    ├── Order signing
    │
    ├── Position protocol
    │
    ├── Market metadata
    │
    ├── Data services
    │
    └── SDK packages

Those layers can evolve independently.

For example, the current official Rust CLOB client documents:

V1
V2
V3

as protocol variants for order construction.

Its README describes V1 as the legacy CTF-token path, V2 as the current CTF-token exchange path, and V3 as the Exchange V3 path used for Polymarket V2 positions.

That is very different from saying:

API version = 3

There is no reason to add /v3 to every Polymarket endpoint just because Exchange V3 exists.

The versions belong to different layers.

CLOB / Exchange V2 is a real protocol change

The April 28, 2026 upgrade was not just a new SDK release.

Polymarket changed the exchange stack itself.

The official migration announcement describes three coordinated changes:

New smart contracts
        +
Rewritten order book
        +
New collateral token

The new exchange contracts are CTF Exchange V2, and the new collateral token is pUSD, replacing USDC.e as the trading collateral layer.

The contract repository describes CTF Exchange V2 as the core smart-contract system for trading Conditional Token Framework assets. It currently lists the deployed Polygon contracts for the collateral token, collateral adapters, standard exchange, and negative-risk exchange.

This matters because an integration that only changes its Python or TypeScript dependency is not necessarily migrated.

The underlying assumptions may also have changed.

The order structure changed

One of the clearest examples is the signed order itself.

The current Rust client defines separate order structures for V1 and V2.

The V1 structure contains fields such as:

taker
nonce
feeRateBps
expiration

The V2 order structure instead uses fields including:

timestamp
metadata
builder

with expiration carried separately in the payload.

The EIP-712 domain version also changes:

V1 → "1"
V2 → "2"
V3 → "3"

That is not cosmetic.

The exchange contract and signed typed-data structure have to agree.

A bot that manually constructs EIP-712 messages therefore needs to know which protocol it is signing for.

Contract addresses are part of the migration

A protocol migration also changes the contracts that the trading system ultimately interacts with.

The current CTF Exchange V2 repository lists these Polygon contracts:

CTFExchangeV2
0xE111180000d2663C0091e4f400237545B87B996B

NegRiskCtfExchangeV2
0xe2222d279d744050d28e00520010520000310F59

CollateralToken proxy
0xC011a7E12a19f7B1f670d46F03B03f3342E82DFB

CtfCollateralAdapter
0xADa100874d00e3331D00F2007a9c336a65009718

NegRiskCtfCollateralAdapter
0xAdA200001000ef00D07553cEE7006808F895c6F1

These are documented by the official V2 exchange repository.

For a trading bot, hardcoded contract addresses are therefore part of the compatibility surface.

So are:

verifying contracts
allowances
collateral handling
settlement assumptions

A migration audit should look for all of them.

pUSD is part of the protocol change

The collateral model also changed.

Polymarket's April 2026 upgrade introduced pUSD, an ERC-20 collateral token on Polygon backed 1:1 by USDC. The exchange documentation describes pUSD as the new technical collateral layer while trading settles in native USDC.

That creates another compatibility boundary:

Old

USDC.e
   ↓
CTF / Exchange


New

USDC / pUSD
   ↓
Collateral layer
   ↓
CTF / Exchange

A bot that checks balances, approves contracts, wraps collateral, or manages inventory directly onchain needs to understand that layer.

This becomes especially important for systems that are not simply using the web interface but are managing their own wallet flow.

Fees also moved closer to protocol state

Another important change is fee handling.

Polymarket's current fee documentation says fees are applied at match time, not included as a fee field in the order itself. The current formula is based on share count, fee rate, and share price.

That means a trading system should avoid treating:

fee = property of order creation

as a universal assumption.

Instead, it should think more like:

Order
   ↓
Match
   ↓
Protocol determines fee
   ↓
Execution result

This matters for analytics as well.

If you're measuring:

Gross PnL
Fees
Net PnL

the accounting layer needs to correspond to the actual execution model.

It also matters for strategy selection because Polymarket currently charges taker fees on several market categories while makers are not charged fees and can receive rebates.

Then there is PolyV2

This is where version naming gets even more confusing.

The current Polymarket clients support PolyV2 position identifiers.

These are not simply another name for normal CTF token IDs.

The official Python SDK changelog shows the progression:

0.8.0
→ expose market protocol versions

0.9.0
→ support Poly V2 identifiers and trading

0.10.0
→ migrate data reads to Data API v2

These are SDK changes, but they reflect underlying protocol concepts that the application has to understand.

The official Python models explicitly expose market protocol versions as:

v1
v2

and distinguish those values from the package version itself.

PolyV2 orders use Exchange V3

This is probably the easiest place for a developer to make the wrong assumption.

The current official Rust CLOB client documents:

CTF token
    ↓
V2 exchange flow


Polymarket V2 position
    ↓
V3 exchange flow

Position-backed orders bypass the normal protocol lookup and use Exchange V3, with EIP-712 domain version "3".

The TypeScript CLOB V2 release also added support for positionID and explicitly says that it selects Exchange V3 signing for limit and market orders.

So a trading system should not simply ask:

"What version of Polymarket am I using?"

It should ask:

What asset am I trading?

What protocol does that asset use?

Which exchange signs that order?

Which contract verifies it?

What collateral path applies?

How is the resulting execution reported?

That is a much better compatibility model.

Execution changed too

Protocol upgrades don't stop at signing.

The execution path itself has also changed.

The official Rust CLOB changelog records a July 2026 change for an asynchronous execution pipeline in which matched orders can return tradeIDs while transaction hashes are resolved later. The client added internal transaction-hash resolution for this flow.

That changes how a bot should model execution.

Instead of:

ORDER
  ↓
FILLED
  ↓
TRANSACTION HASH

you may need:

ORDER
  ↓
MATCHED
  ↓
TRADE ID
  ↓
TRANSACTION RESOLUTION
  ↓
CONFIRMATION
  ↓
SETTLEMENT

That is directly related to the execution-verification architecture I've been working on.

A match tells you something important.

It does not necessarily represent the final state of the entire execution lifecycle.

Why this matters for reconciliation

This is where protocol knowledge becomes operational engineering.

Suppose your local system records:

Order:
MATCHED

but the transaction is still unresolved.

Or:

Local position:
+100

while the remote position is:

+40

Or the market changes protocol representation while your application still has older assumptions in memory.

The recovery problem is the same:

Local assumptions
       ↓
Current protocol state
       ↓
Compare
       ↓
Reconcile
       ↓
Verify

Protocol-awareness therefore belongs inside the state and execution layers.

It is not something you check once during installation.

What a protocol-aware trading bot should track

I would keep protocol information explicit in the system.

For example:

Market
   ↓
Protocol version
   ↓
Asset identifier
   ↓
Exchange path
   ↓
Signing version
   ↓
Contract
   ↓
Collateral
   ↓
Execution state
   ↓
Settlement state

That can be represented as internal metadata rather than scattered assumptions.

For example:

asset_type
protocol_version
position_id
token_id
exchange_version
chain_id
verifying_contract
collateral_type

The exact schema will depend on the implementation.

The important part is not hiding these distinctions.

Don't build version logic around package versions

A common mistake is:

SDK v0.10
→ therefore protocol v2

That is not a safe relationship.

The official Python SDK is currently on its own semantic versioning track, with the package at 0.12.0 in the repository metadata, while its changelog separately records support for market protocol versions, PolyV2 identifiers, and Data API v2.

Likewise, the dedicated CLOB V2 TypeScript package has its own release numbers such as 1.2.0.

These numbers describe software releases.

They do not define the onchain protocol.

What I would check before deploying a Polymarket bot

For an existing system, I would treat this as a compatibility audit.

[ ] Exchange contract addresses
[ ] EIP-712 domain version
[ ] Signed order fields
[ ] Asset identifiers
[ ] Protocol version metadata
[ ] Collateral path
[ ] Token / position approvals
[ ] Fee handling
[ ] Order submission
[ ] Execution events
[ ] Trade IDs
[ ] Transaction resolution
[ ] Settlement tracking
[ ] Position reconciliation
[ ] WebSocket recovery
[ ] Restart recovery

If any of these are hardcoded assumptions, the system is carrying protocol risk.

This is also why migrations should be tested end to end

I would not consider a migration complete because:

npm install

or:

pip install

succeeds.

The useful test is closer to:

Market discovery
      ↓
Protocol detection
      ↓
Asset identification
      ↓
Order construction
      ↓
Signature
      ↓
Submission
      ↓
Match / fill
      ↓
Transaction
      ↓
Settlement
      ↓
Position
      ↓
PnL / fee accounting

That tests the actual system boundary.

It also gives you a much better way to catch protocol mismatches before they become trading incidents.

My current architecture

This is the direction I'm taking with my own Polymarket infrastructure work:

                 POLYMARKET
                      │
                      ▼
              Protocol / Market
                      │
                      ▼
               Market Adapter
                      │
                      ▼
                  Strategy
                      │
                      ▼
                    Risk
                      │
                      ▼
                  Execution
                      │
                      ▼
              Execution Verifier
                      │
                      ▼
               Reconciliation
                      │
                      ▼
                Control Plane
                      │
             ┌────────┴────────┐
             ↓                 ↓
        Monitoring          Recovery

The point is to keep protocol-specific assumptions close to the integration boundary.

The rest of the system can then work with clearer internal concepts:

Order
Fill
Position
Exposure
Risk
Execution status
System health

That makes future migrations easier to reason about.

The bigger lesson

Polymarket protocol changes are not really a problem for the SDK alone.

They're an integration problem.

A protocol upgrade can affect:

Contracts
Signing
Collateral
Orders
Execution
Settlement
Accounting
State

And those changes eventually show up as operational problems:

orders stop submitting
fills become harder to interpret
positions drift
retries become unsafe
accounting changes
reconciliation breaks

That is why I think protocol compatibility should be treated as part of trading infrastructure.

Not as a dependency upgrade.

Final takeaway

When someone says:

“Polymarket V2”

I would now ask:

V2 which layer?

Because today you may be dealing with:

CTF Exchange V2
CLOB V2
PolyV2 positions
Exchange V3
Data API V2
SDK versions

Those are related, but they are not interchangeable labels.

For a trading bot, the useful model is:

Protocol
   ↓
Asset
   ↓
Exchange
   ↓
Signing
   ↓
Execution
   ↓
Settlement
   ↓
Position
   ↓
Risk

That is the level at which compatibility actually matters.

And for an existing trading system, the practical question is not whether the latest SDK installs.

It is whether the complete path still agrees:

contracts
→ signing
→ order
→ match
→ execution
→ settlement
→ position
→ risk

That is what I would test before trusting the bot with capital.

Polymarket Trading Bot Order States: Handling Pending, Failed, and Unknown Orders

Casatrick | Polymrket Bot Dev — Tue, 06 Oct 2026 05:48:17 +0000

One of the harder parts of an automated trading system is not submitting an order.

It is knowing what actually happened after the order was submitted.

A bot can receive an incomplete response.

An order can remain unresolved.

A fill can arrive later.

A connection can disappear between two events.

The application can restart before it finishes processing the result.

That creates a dangerous situation if the bot treats every order response as final.

For a Polymarket trading bot, I prefer to model order execution as an explicit state machine rather than a single boolean such as:

order = successful

A simplified internal lifecycle looks more like:

INTENDED
   ↓
SUBMITTED
   ↓
ACCEPTED
   ↓
MATCHED
   ↓
FILLED

with other paths such as:

REJECTED
CANCELLED
FAILED
RETRYING
UNKNOWN
INCONSISTENT

The exact state model can vary by implementation.

The important part is that unknown should be a real state.

Why a single order status is not enough

A simple trading bot often does something like:

submit order
    ↓
get response
    ↓
if success:
    mark filled

That works only when every step behaves exactly as expected.

A more realistic execution flow looks like:

Strategy
   ↓
Order intent
   ↓
Submission
   ↓
Exchange response
   ↓
Matching
   ↓
Fill
   ↓
Transaction
   ↓
Confirmation
   ↓
Position

There are several different facts here.

The strategy intended to place an order.

The system submitted something.

The venue accepted or rejected it.

The order may or may not have matched.

A fill may or may not have occurred.

The resulting execution may still need to be tracked further.

Collapsing all of that into one status makes recovery much harder.

An internal order state machine

I usually find it easier to reason about execution with explicit states.

For example:

INTENDED
   ↓
SUBMITTED
   ↓
ACCEPTED
   ↓
MATCHED
   ↓
FILLED

Possible failure paths:

SUBMITTED → REJECTED
SUBMITTED → FAILED
ACCEPTED  → CANCELLED
MATCHED   → PARTIAL

And when the system cannot establish what happened:

SUBMITTED
    ↓
UNKNOWN

The state machine is not meant to describe every possible platform implementation.

It is an internal representation that lets the rest of the trading system make decisions based on what is actually known.

Pending does not mean failed

Suppose the strategy submits an order and does not immediately receive a final outcome.

The wrong response is often:

No final response
      ↓
Assume failed
      ↓
Submit again

That can create duplicate exposure.

The order may still be alive.

It may have been accepted but the application has not observed the next event yet.

It may already have matched.

The system simply does not know yet.

So I prefer:

SUBMITTED
    ↓
PENDING
    ↓
WAIT / VERIFY

rather than immediately converting uncertainty into failure.

The dangerous UNKNOWN state

This is the state I think deserves the most attention.

Imagine:

Order submitted
       ↓
Network interruption
       ↓
Response lost

The bot now has:

Local state:
UNKNOWN

That does not mean:

Order failed

It also does not mean:

Order succeeded

It means:

The application does not currently know.

That distinction matters.

If the bot immediately retries, the first order could still exist.

You could end up with:

Original order
      +
Retry order
      =
More exposure than intended

Unknown state therefore needs its own recovery path.

Unknown should block unsafe assumptions

A useful rule is:

Don't convert uncertainty into a successful or failed state just because the strategy needs an answer.

Instead:

UNKNOWN
   ↓
PAUSED / NO RETRY
   ↓
RECONCILE
   ↓
VERIFY

Only after the system establishes enough information should it decide whether the order should be considered complete, failed, cancelled, or retried.

This is one reason execution verification and reconciliation belong close to the trading system rather than being treated as dashboard features.

Retrying an order is not as simple as submitting it again

A common implementation is:

if order failed:
    retry()

The difficult part is determining whether the order actually failed.

Consider:

Order 123
   ↓
Submitted
   ↓
Response timeout

The application might classify that as:

FAILED

But the real state could be:

ACCEPTED

or:

MATCHED

or:

FILLED

The network failure tells you that the application didn't get a response.

It does not necessarily tell you what happened to the order.

So the retry decision should depend on verified state, not just the absence of a response.

A safer flow is:

Request timeout
      ↓
Mark UNKNOWN
      ↓
Query / reconcile
      ↓
Did the order exist?
      ↓
What is its current state?
      ↓
Only then decide:
retry / cancel / continue

Partial fills make the state model more important

Suppose the strategy intends:

The actual execution is:

40 filled
60 remaining

That is neither a clean failure nor a clean completion.

The system needs to represent the difference between:

requested quantity = 100
filled quantity    = 40
remaining quantity = 60

The resulting state could be represented internally as:

PARTIALLY_FILLED

The important part is that downstream calculations use the actual fill.

For example:

Order
  ↓
40 Fill
  ↓
Position +40
  ↓
Exposure
  ↓
Risk

not:

Order 100
  ↓
Assume Position +100

This connects directly to position reconciliation.

A trading system cannot maintain reliable risk controls when it confuses order intent with actual execution.

Order state affects position state

The order state machine should not live in isolation.

It feeds other parts of the system.

A useful dependency chain is:

Order
   ↓
Fill
   ↓
Position
   ↓
Exposure
   ↓
Risk

For example:

Order = ACCEPTED

does not automatically mean:

Position increased

And:

Order = INTENDED

definitely does not mean:

Position increased

The position should be based on actual execution.

That sounds obvious, but this distinction becomes important when processing real-time events, partial fills, retries, reconnects, and application restarts.

Execution state and transaction state should stay separate

Another useful separation is between the order execution state and what happens afterward.

For example:

ORDER
  ↓
FILL
  ↓
TRANSACTION
  ↓
CONFIRMATION
  ↓
SETTLEMENT
  ↓
POSITION

I don't want one field called:

status = filled

to represent every stage of that lifecycle.

A system may know that a trade matched while still waiting on a later stage.

That is why my execution-verification work treats these stages separately.

Repository:

https://github.com/casatrickdev/polymarket-execution-verifier

The verifier is designed around checking execution across order, fill, transaction, and settlement states rather than assuming that one event tells the entire story.

What happens after a restart?

Imagine the application crashes here:

SUBMITTED
   ↓
?

The process restarts several seconds later.

The local database might contain:

Order ID: 123
State: SUBMITTED

The application should not simply continue from there as though nothing happened.

A safer startup process is:

Load local state
      ↓
Find unresolved orders
      ↓
Query / reconcile current state
      ↓
Update local state
      ↓
Recalculate position
      ↓
Recalculate exposure
      ↓
Check risk
      ↓
Resume trading

That makes unresolved orders part of startup recovery.

This is closely related to position reconciliation: the system needs to re-establish a trustworthy state before creating additional risk.

WebSocket events should update state, not define reality

Real-time events are useful for keeping local state current.

But I don't want the local state machine to assume:

event received = complete truth forever

Consider:

Order submitted
      ↓
Fill event
      ↓
WebSocket disconnect
      ↓
More execution activity
      ↓
Reconnect

Some events may have been missed.

The application now needs a way to establish current state again.

So I think about real-time processing and reconciliation as two complementary mechanisms:

Real-time events
      ↓
Fast local updates

Reconciliation
      ↓
Recovery and verification

The first keeps the system responsive.

The second gives it a way to recover from uncertainty.

Duplicate events are another problem

The opposite problem can also happen.

Instead of missing an event, the application might process the same logical event more than once.

For example:

Fill event
   ↓
Position +40

Same event processed again
   ↓
Position +80

That creates incorrect state even though the connection was never lost.

This is why event handling should be designed with idempotency and deduplication in mind.

The system needs to know which execution events have already been applied.

That state belongs in the execution layer rather than being left to the strategy.

Order state should be observable

A useful trading dashboard should not simply show:

Orders: 14

It should make unresolved conditions visible.

For example:

SUBMITTED       3
ACCEPTED        2
PARTIAL         1
FILLED         14
REJECTED        1
CANCELLED       2
UNKNOWN         1

The exact numbers are only examples.

The point is that the operator should be able to see where execution is getting stuck.

An UNKNOWN order should be much more visible than a successful order that needs no action.

Unknown orders should have a timeout policy

A system can also define how long an order is allowed to remain unresolved.

Conceptually:

UNKNOWN
   ↓
recheck
   ↓
still unknown
   ↓
alert
   ↓
continue reconciliation

The timeout should not automatically mean:

cancel and retry

because the system still needs to understand whether the original order exists and what exposure it may have created.

A useful policy might distinguish between:

UNKNOWN for 1 second

and:

UNKNOWN for 5 minutes

The longer uncertainty persists, the more aggressively the control plane may need to intervene.

Risk controls should understand execution uncertainty

Risk management often focuses on:

Position limits
Exposure limits
Daily loss

But execution uncertainty can itself become a reason to block trading.

For example:

Open position:
+40

Unresolved order:
+60

Known exposure:
40

Potential exposure:
100

Depending on the strategy, treating the unresolved order as irrelevant could lead to incorrect decisions.

This doesn't necessarily mean counting every unknown order as filled.

It means the system should know that uncertainty exists and apply an appropriate policy.

That is an important distinction.

A control plane can make these decisions explicit

This is where order management connects to the broader trading control plane.

The strategy should not have to understand every operational failure mode.

Instead:

                 TRADING BOT
                      │
       ┌──────────────┼──────────────┐
       ↓              ↓              ↓
   Strategy       Execution        Risk
                      │
                      ↓
                Order State
                      │
          ┌───────────┴───────────┐
          ↓                       ↓
   Verification            Reconciliation
          │                       │
          └───────────┬───────────┘
                      ↓
                 CONTROL PLANE
                      │
              Pause / Resume
              Alert / Recover

The control plane can decide whether the system is allowed to continue trading.

For example:

UNKNOWN ORDER
     ↓
Trading blocked
     ↓
Reconcile
     ↓
Execution verified
     ↓
Risk checked
     ↓
Trading allowed

That keeps operational safety separate from strategy logic.

An example failure flow

Consider this sequence:

1. Strategy decides to buy 100

2. Order is submitted

3. Network response times out

4. Local state becomes UNKNOWN

5. Strategy wants to retry

6. Control Plane blocks retry

7. Execution state is reconciled

8. Original order is found

9. 40 units were filled

10. Position is updated to +40

11. Risk is recalculated

12. Remaining quantity is handled explicitly

Without the state machine, the system might have simply retried the order at step 5.

That is exactly the kind of situation where a small implementation detail can turn into an unnecessary position.

Testing order-state handling

I would test explicit failure scenarios rather than only the happy path.

Order accepted
    → continue

Order rejected
    → record rejection

Order cancelled
    → record cancellation

Partial fill
    → update actual quantity

Response timeout
    → UNKNOWN

WebSocket disconnect
    → preserve unresolved state

Application restart
    → reconcile unresolved orders

Duplicate event
    → do not double-apply

Order state mismatch
    → pause and reconcile

Unknown state persists
    → alert and block unsafe actions

These cases are much closer to the real operational problem than simply testing:

submit()
returns success

What I want the execution layer to answer

At any point, the system should be able to answer questions like:

What did the strategy intend?

Was the order submitted?

Was it accepted?

Did it match?

How much actually filled?

What remains unresolved?

Did we receive the relevant events?

Does local state agree with remote state?

What position resulted?

Is the resulting exposure within risk limits?

Is it safe to place another order?

Those questions are more useful than a single status field.

They also provide much better information when investigating an incident.

Connecting this to execution verification

This is the reason I keep execution verification separate from the strategy.

The strategy should care about:

Should I trade?

The execution system should care about:

What happened to the order?

The reconciliation layer should care about:

Does local state match reality?

The risk system should care about:

Is the resulting state still acceptable?

And the control plane should care about:

Should the system currently be allowed to trade?

Those are related questions, but they are not the same question.

The architecture I'm building around this

My current Polymarket infrastructure projects reflect that separation.

Polymarket Trading Bot

https://github.com/casatrickdev/polymarket-trading-bot

The broader bot handles strategy, execution, risk, monitoring and backtesting.

Polymarket Execution Verifier

https://github.com/casatrickdev/polymarket-execution-verifier

The verifier focuses on execution state across order, fill, transaction and later settlement stages.

Polymarket Trading Control Plane

https://github.com/casatrickdev/polymarket-trading-control-plane

The control plane focuses on state, health, risk, reconciliation, alerts and operational recovery.

The goal is not to make the system more complicated for its own sake.

It's to keep different kinds of uncertainty from being hidden inside one order handler.

Final takeaway

A trading bot should not think in terms of:

order succeeded

It should know where the order is in its lifecycle.

Something like:

INTENDED
   ↓
SUBMITTED
   ↓
ACCEPTED
   ↓
MATCHED
   ↓
FILLED

with explicit paths for:

REJECTED
CANCELLED
FAILED
PARTIAL
UNKNOWN
INCONSISTENT

The particularly important state is:

UNKNOWN

because unknown does not mean failed.

It means the system does not yet know what happened.

That should trigger verification or reconciliation, not an automatic assumption.

For an automated Polymarket trading system, that distinction matters because the next order is going to be based on whatever state the system believes right now.

The execution layer needs to make that belief explicit.

And when it cannot establish the truth, the safest state is sometimes simply:

UNKNOWN
   ↓
STOP
   ↓
VERIFY
   ↓
RESUME

That is a much better foundation for a trading system that needs to keep operating reliably.

What It Actually Takes to Run a Polymarket Trading Bot 24/7

Casatrick | Polymrket Bot Dev — Mon, 05 Oct 2026 07:11:50 +0000

Getting a Polymarket trading bot to place orders is one problem.

Keeping it running correctly for days or weeks is a different problem.

A bot can work perfectly in a local test and still fail in production because of:

WebSocket disconnects
stale market data
partial fills
position mismatches
execution uncertainty
process restarts
memory or resource problems
failed API requests
unreconciled state
risk limits being reached

The strategy may be fine.

The problem is everything around the strategy.

For me, a production-oriented Polymarket system looks more like:

Market Data
    ↓
Strategy
    ↓
Risk
    ↓
Execution
    ↓
Verification
    ↓
Reconciliation
    ↓
Monitoring
    ↓
Recovery

Running 24/7 means every one of those layers needs a plan for what happens when something goes wrong.

A running process is not the same as a healthy bot

The easiest health check is:

process = running

That doesn't tell you much.

The process can be alive while:

WebSocket = connected but stale
Position = wrong
Execution = unknown
Risk = unverified
Market data = outdated

So I prefer to separate:

Process Health

from:

Trading System Health

A process can be running while the trading system is paused.

That's a useful state.

Start with explicit system states

A control plane can make the operational state visible:

HEALTHY
DEGRADED
PAUSED
RECOVERING
FAILED

For example:

WebSocket disconnect
        ↓
HEALTHY
        ↓
DEGRADED
        ↓
PAUSED

After recovery:

PAUSED
   ↓
RECONNECT
   ↓
RECONCILE
   ↓
VERIFY
   ↓
RISK CHECK
   ↓
HEALTHY

This is very different from:

socket connected
↓
start trading

A connection is only one part of the system.

WebSocket connections need supervision

A trading bot depending on real-time data should assume that connections will eventually fail.

A basic connection lifecycle is:

CONNECTED
    ↓
DISCONNECTED
    ↓
RECONNECTING
    ↓
CONNECTED

But there is another question:

Is the data actually fresh?

A connection can report CONNECTED while no useful events have arrived recently.

So I would track:

last_event_time
last_connection_time
reconnect_count
last_disconnect
data_age

For example:

WebSocket:
CONNECTED

Last event:
9.4 seconds ago

Maximum allowed age:
2 seconds

That should not be considered healthy.

Reconnect doesn't mean recovered

This is one of the most important operational distinctions.

Suppose:

Event A
   ↓
Event B
   ↓
DISCONNECT
   ↓
Events C, D
   ↓
RECONNECT

The application may never have seen C and D.

So:

RECONNECTED

does not automatically mean:

STATE VERIFIED

The recovery process should be closer to:

Disconnect
   ↓
Pause
   ↓
Reconnect
   ↓
Rebuild / fetch state
   ↓
Reconcile
   ↓
Verify
   ↓
Check risk
   ↓
Resume

I've written more about this in Polymarket WebSocket recovery.

Process restarts are normal

A production system should expect restarts.

The question isn't:

“Can the process start?”

It is:

“What state should the process trust after starting?”

A safer startup sequence is:

Application starts
        ↓
Load persisted state
        ↓
Connect to external sources
        ↓
Read authoritative state
        ↓
Compare
        ↓
Repair discrepancies
        ↓
Verify risk
        ↓
Allow trading

The important part is that:

application_started

and:

trading_allowed

are separate states.

Persist state that matters

If the bot restarts, in-memory state disappears.

That means some information needs to survive the process:

orders
fills
positions
execution state
risk state
recovery state
timestamps
last known events

You don't necessarily need to persist every piece of data forever.

But you need enough information to reconstruct the trading state after a restart.

For example:

Last known position
Last known exposure
Active orders
Unresolved executions
Last reconciliation

Without this, every restart becomes a guessing exercise.

The bot needs a single source of truth for operational state

Different components can know different things.

The strategy may know:

BUY

The execution layer may know:

FILLED

The verifier may know:

TX_PENDING

The reconciliation layer may know:

POSITION_MISMATCH

The risk layer may know:

BLOCK

These aren't contradictory.

They're different views of the same system.

A control plane can combine them:

Execution = TX_PENDING
Position   = MISMATCH
Risk       = UNVERIFIED
        ↓
Trading Permission = BLOCK

That is much more useful than one global boolean.

Risk has to keep running

Risk checks cannot happen only once when the process starts.

The system can change after every execution.

A useful loop is:

Signal
   ↓
Pre-Trade Risk
   ↓
Execution
   ↓
Verification
   ↓
Position Update
   ↓
Exposure Recalculation
   ↓
Risk Recheck

This means the risk system can react to:

position changes
exposure changes
daily loss
execution failures
stale data
state mismatches

For more on that side of the system, see Polymarket Trading Bot Risk Controls.

Execution verification needs to survive restarts

Suppose the bot submitted an order and then stopped.

When it starts again, it shouldn't assume:

old local state = final execution state

The execution may have progressed while the application was unavailable.

It could be:

FILLED
TX_PENDING
CONFIRMED
SETTLED

or still unknown.

That's why I treat execution verification as a separate layer:

Order
   ↓
Fill
   ↓
Transaction
   ↓
Confirmation
   ↓
Settlement
   ↓
Position

The verifier can re-establish the execution state after a restart instead of relying entirely on stale in-memory state.

See the Polymarket Execution Verifier project.

Partial fills are an operational problem too

A 100-unit order doesn't necessarily become:

100 filled

It might become:

40 filled
60 remaining

The bot needs to keep track of:

requested quantity
matched quantity
remaining quantity
current order state
position

A restart makes this more important.

After restarting, the system needs to establish whether the remaining 60:

still exists
was filled
was cancelled
is unknown

Otherwise local position and external state can diverge.

Position state needs reconciliation

Suppose the bot restarts and thinks:

Position = +100

The account says:

Position = +40

The bot is running.

The connection is working.

The strategy is producing signals.

But the system shouldn't immediately continue trading.

The correct sequence is:

Position mismatch
        ↓
PAUSE
        ↓
Reconcile
        ↓
Verify
        ↓
Recalculate exposure
        ↓
Risk check
        ↓
Resume

That's the basic reason I treat reconciliation as infrastructure rather than a cleanup task.

Monitoring should watch conditions, not just uptime

A basic uptime monitor can tell you:

Bot process: UP

That's useful, but not sufficient.

I'd rather monitor:

Process
WebSocket
Market Data
Execution
Position
Risk
Recovery

For example:

SYSTEM HEALTH

Process        OK
WebSocket      OK
Market Data    OK
Execution      OK
Position       VERIFIED
Risk           OK
Recovery       IDLE

And during an incident:

SYSTEM HEALTH

Process        OK
WebSocket      RECOVERING
Market Data    STALE
Execution      UNKNOWN
Position       UNVERIFIED
Risk           BLOCKED
Recovery       ACTIVE

Now the operator knows what is wrong.

Alerts should correspond to real actions

An alert is useful when someone or something can act on it.

Examples:

MARKET_DATA_STALE
WEBSOCKET_DISCONNECTED
POSITION_MISMATCH
EXECUTION_UNKNOWN
RISK_LIMIT_BREACHED
RECOVERY_STARTED
RECOVERY_FAILED

The system can then decide:

alert only

or:

pause trading

or:

start recovery

or:

require operator intervention

I don't want alerts that are just noise.

Metrics become more useful after the bot has been running

Once the basic operating model works, start measuring execution behavior.

Useful metrics include:

order latency
fill latency
fill ratio
partial-fill rate
rejection rate
unknown execution count
position mismatch count
reconciliation duration
recovery duration

The important part is not collecting hundreds of numbers.

It's identifying changes.

For example:

Fill latency ↑
Rejections ↑
Unknown states ↑
Recovery time ↑

That combination is much more interesting than any one number by itself.

That's the focus of the execution analytics work in this cluster.

Incident recovery needs history

If something goes wrong at 03:00, I don't want the only answer to be:

Bot restarted at 03:02

I want to know:

What happened?
When did it start?
What was the last verified state?
Which orders were active?
What fills were observed?
What became unknown?
What did reconciliation find?
What risk state existed?
Why was trading resumed?

A useful incident timeline might look like:

03:01:08  Order submitted
03:01:09  Fill observed
03:01:10  WebSocket disconnected
03:01:11  Trading paused
03:01:18  Process stopped
03:02:03  Process restarted
03:02:04  Recovery started
03:02:05  Reconciliation started
03:02:07  Position verified
03:02:08  Risk check passed
03:02:09  Trading resumed

That is much more useful than a simple uptime record.

I've written about this in Polymarket Trading Bot Incident Recovery.

Resource limits matter too

24/7 operation isn't only about trading state.

The process itself uses:

CPU
Memory
Disk
Network
Connections
File descriptors

A system that slowly accumulates memory or logs can eventually fail even if the trading logic is correct.

So production monitoring should include basic process-level signals:

memory usage
CPU usage
disk usage
restart count
connection count
error rate

The exact limits depend on the deployment environment.

The important part is noticing the trend before the process becomes unstable.

Logging should support investigation

A trading system needs logs that are useful during failures.

For example:

execution_id
order_id
trade_id
market_id
event_type
state
timestamp
reason

Avoid logs like:

something failed

Prefer:

EXECUTION_STATE_CHANGED
execution_id=abc123
from=FILLED
to=TX_PENDING
reason=transaction_not_available

This makes later analysis much easier.

Sensitive credentials should never appear in logs.

Deployment is part of the system

A 24/7 bot needs a predictable runtime environment.

That means thinking about:

process supervision
automatic restart
environment configuration
secrets
network access
logging
storage
health checks
resource limits

The exact deployment can vary.

VPS, container, cloud VM, or another environment can all work.

The engineering requirement is the same:

The bot should fail in a controlled way rather than silently disappearing.

Automatic restart isn't enough

A supervisor can restart a process.

For example:

process dies
   ↓
supervisor restarts

Good.

But that doesn't guarantee safe trading.

The trading system still needs:

restart
   ↓
load state
   ↓
reconcile
   ↓
verify
   ↓
risk check
   ↓
resume

Otherwise the supervisor may simply restart the same incorrect state over and over.

A simple 24/7 architecture

Putting these ideas together:

                    POLYMARKET
                        |
                        v
                 Market Data / API
                        |
                        v
                   Trading Bot
                        |
              +---------+---------+
              |                   |
              v                   v
           Strategy              Risk
              |                   |
              +---------+---------+
                        |
                        v
                    Execution
                        |
                        v
                Execution Verifier
                        |
                        v
                Position Reconcile
                        |
                        v
                 Control Plane
                        |
          +-------------+-------------+
          |             |             |
          v             v             v
      Monitoring      Alerts       Recovery
          |
          v
       Metrics

The system is no longer just:

strategy → order

It is an operational loop.

What should happen when the system gets unhealthy?

The reaction should depend on the problem.

For example:

Market data stale
        ↓
Pause

or:

Position mismatch
        ↓
Reconcile
        ↓
Verify

or:

Risk limit breached
        ↓
Block
        ↓
Operator / recovery process

or:

WebSocket disconnect
        ↓
      Pause
        ↓
   Reconnect
        ↓
    Recover
        ↓
     Resume

The important part is that the response is defined before the incident happens.

24/7 operation is mostly about boundaries

The longer a bot runs, the more important system boundaries become.

You need to know where:

strategy
execution
verification
state
risk
monitoring
recovery

begin and end.

A strategy failure shouldn't necessarily become a process failure.

A WebSocket failure shouldn't automatically become a strategy failure.

A position mismatch shouldn't become silent extra exposure.

An execution uncertainty shouldn't become fake success.

A restart shouldn't automatically mean trading is safe.

Those boundaries are what make continuous operation manageable.

A practical 24/7 checklist

Before calling a Polymarket bot production-oriented, I'd want:

[ ] Process supervision
[ ] Persistent state
[ ] WebSocket reconnect handling
[ ] Market-data freshness checks
[ ] Execution verification
[ ] Position reconciliation
[ ] Risk controls
[ ] Pause / resume
[ ] Recovery workflow
[ ] Structured logs
[ ] Metrics
[ ] Alerts
[ ] Resource monitoring
[ ] Restart recovery
[ ] Incident history
[ ] CI / tests

The exact implementation will vary.

The important thing is that every box has an actual behavior behind it.

The broader system I'm building

This is where the different Polymarket projects start fitting together:

Polymarket Trading Bot
        ↓
    Execution
        ↓
Execution Verifier
        ↓
Position Reconciliation
        ↓
  Risk Controls
        ↓
Trading Control Plane
        ↓
Monitoring / Analytics
        ↓
Incident Recovery

The bot is the part that trades.

The rest is what allows it to operate continuously.

That distinction is becoming more important as I work on the infrastructure around it.

Final takeaway

Running a Polymarket bot for a few hours isn't the same engineering problem as running one continuously.

For 24/7 operation, the system needs to handle:

disconnects
restarts
partial fills
state mismatches
execution uncertainty
risk breaches
stale data
resource problems
incidents
recovery

The basic operating loop becomes:

Run
 ↓
Observe
 ↓
Verify
 ↓
Reconcile
 ↓
Control
 ↓
Recover when needed
 ↓
Continue

The goal isn't to build a bot that never fails.

That's not realistic.

The goal is to build a system that fails visibly, recovers deliberately, and never assumes that a running process means trading is safe.

Polymarket Trading Bot Execution Analytics: What Should You Measure After the Trade?

Casatrick | Polymrket Bot Dev — Sat, 03 Oct 2026 06:41:59 +0000

A Polymarket trading bot can be running normally and still have problems you won't notice from the P&L.

Orders may be taking longer to execute.

Partial fills may be increasing.

Rejections may be happening more often.

Execution state may be staying unresolved longer than expected.

Position reconciliation may be running too frequently.

A recovery that normally takes a few seconds may suddenly take a minute.

None of that is obvious from:

Bot: RUNNING
P&L: +$...

For an automated trading system, I want to know not only whether it traded, but how the execution layer is behaving.

That is where execution analytics becomes useful.

The idea is simple:

Execution
   ↓
Metrics
   ↓
Health / Anomalies
   ↓
Risk / Control
   ↓
Action

I'm treating this as another layer around the Polymarket trading infrastructure I'm building.

What should you measure?

There isn't one universal list.

The useful metrics depend on the strategy and the execution model.

But for a production-oriented Polymarket bot, I would start with:

order latency
fill latency
fill ratio
partial-fill rate
rejection rate
execution failures
unknown execution states
position mismatches
reconciliation frequency
recovery duration

The important part is not collecting dozens of metrics.

It's being able to connect a metric to an operational decision.

For example:

rejection rate ↑
       ↓
execution health ↓
       ↓
investigate / pause

That's much more useful than a dashboard full of numbers nobody acts on.

Order latency

The first useful measurement is how long an order takes to move through the execution path.

For example:

strategy decision
      ↓
order created
      ↓
order submitted

Measure:

decision → order created
order created → submitted

You can then start looking at the distribution rather than a single average.

For example:

p50:  120 ms
p95:  480 ms
p99:  910 ms

The exact numbers aren't important here.

The point is that averages can hide slow executions.

A bot that normally processes most orders quickly but occasionally takes much longer can have a very different operational profile from one with consistently stable latency.

Fill latency

Order submission is not the same thing as execution.

So the next measurement is:

order submitted
      ↓
fill observed

Track the elapsed time.

For example:

Order A → 140 ms
Order B → 165 ms
Order C → 3.8 s

That third observation deserves attention even if the order eventually completed successfully.

Over time, fill latency can be tracked by:

market
side
order type
strategy
time window

This makes it possible to find patterns instead of treating every slow execution as an isolated event.

Fill ratio

Suppose the strategy requested 100 units.

The execution produced 75.

That's:

requested = 100
matched   = 75

The fill ratio is:

75 / 100 = 75%

This is more informative than simply recording:

FILLED

because requested quantity and actual execution are different things.

A system that starts seeing lower fill ratios may need a different execution policy, more inventory planning, or simply a closer look at the market conditions.

The metric by itself doesn't tell you what to do.

It tells you where to look.

Partial-fill rate

Fill ratio and partial-fill rate answer different questions.

Fill ratio asks:

How much of the requested quantity was actually executed?

Partial-fill rate asks:

How often are orders ending up partially executed?

For example:

100 orders
30 had partial execution

That gives:

partial-fill rate = 30%

This is useful because partial fills can create downstream work:

partial fill
   ↓
remaining quantity
   ↓
position update
   ↓
exposure update
   ↓
possible reconciliation

This connects directly to my earlier Polymarket partial fills work, where requested quantity and actual execution have to remain separate.

The interesting metric isn't simply “how many orders were partial.”

It's what those partial fills cause elsewhere in the system.

Rejection rate

Another straightforward metric is:

rejected orders
----------------
submitted orders

For example:

1,000 submitted
25 rejected

A 2.5% rejection rate means something very different from a system where almost every order succeeds.

More importantly, track changes over time.

For example:

Monday    0.8%
Tuesday   0.9%
Wednesday 1.1%
Thursday  4.7%

The Thursday number is where I'd start investigating.

Possible causes need to be established from the actual execution data rather than guessed from the metric alone.

Execution failures

Not every execution issue is a rejection.

You can also have failures around:

submission
tracking
confirmation
state updates
reconciliation
recovery

So I would separate execution failures into useful categories rather than using one giant counter.

For example:

ORDER_SUBMISSION_FAILURE
FILL_PROCESSING_FAILURE
TRANSACTION_VERIFICATION_FAILURE
POSITION_RECONCILIATION_FAILURE
RECOVERY_FAILURE

That makes the metric much more actionable.

If recovery failures are increasing while order submission remains healthy, you have a very different problem from a system where order submission itself is failing.

Unknown execution states

This is one of the metrics I care about most.

A trading system will sometimes encounter states it can't verify immediately.

For example:

FILLED
   ↓
TX_PENDING

or:

execution = UNKNOWN

The important metric is not just the count.

Track how long executions remain unresolved.

For example:

UNKNOWN executions: 7

oldest unresolved:
18.4 seconds

Now the control plane has something meaningful to evaluate.

You can define a policy around unresolved execution state rather than treating UNKNOWN as an invisible edge case.

This connects directly to the Polymarket Execution Verifier.

Position mismatches

Execution analytics shouldn't stop at the execution layer.

Suppose the system believes:

position = 100

while the external state is:

position = 40

Now you have:

position mismatch = -60

Track:

mismatch count
mismatch duration
markets affected
largest difference
time to resolution

This is directly related to my earlier Polymarket position reconciliation work.

I haven't put a guessed URL into that link because the exact published page URL should come from the live DEV page rather than being invented.

The important analytics question is:

How often does the system disagree with the account, and how long does it take to become consistent again?

Reconciliation frequency

Reconciliation itself is something worth measuring.

For example:

automatic reconciliations
manual reconciliations
reconciliations after reconnect
reconciliations after restart
reconciliations caused by mismatch

Then:

reconciliation count
+
reconciliation duration
+
reconciliation result

gives you a much better picture of system stability.

If reconciliation starts running constantly, that can be a signal that another part of the system needs attention.

Again, the metric doesn't explain the cause.

It tells you where to investigate.

Recovery duration

Suppose a WebSocket disconnect occurs.

The system goes through:

disconnect
   ↓
pause
   ↓
reconnect
   ↓
reconcile
   ↓
verify
   ↓
risk check
   ↓
resume

Measure the total time.

For example:

Recovery #1 → 2.4 s
Recovery #2 → 3.1 s
Recovery #3 → 18.7 s

That third recovery may deserve investigation.

You can also break the duration into stages:

disconnect → reconnect
reconnect → reconciliation
reconciliation → verification
verification → risk check
risk check → resume

Now you can see where the recovery process is actually spending time.

This builds on the Polymarket WebSocket recovery work from earlier in the cluster.

Metrics need context

A single number is rarely enough.

Suppose you see:

fill ratio = 72%

Is that good?

You can't answer that without context.

Compare:

Market A: 72%
Market B: 41%

or:

normal: 74%
today: 72%

or:

strategy A: 91%
strategy B: 53%

Analytics become useful when they're attached to:

market
strategy
side
time
execution type
system state

This is why I prefer structured event data over a dashboard that only stores aggregate counters.

Metrics should come from state transitions

The easiest way to produce useful execution analytics is to make state transitions observable.

For example:

ORDER_CREATED
      ↓
ORDER_SUBMITTED
      ↓
FILL_OBSERVED
      ↓
TX_PENDING
      ↓
CONFIRMED
      ↓
SETTLED
      ↓
POSITION_VERIFIED

Every transition can have:

timestamp
execution_id
order_id
trade_id
market_id
state

Then metrics can be derived from the events.

For example:

ORDER_SUBMITTED → FILL_OBSERVED

gives fill latency.

And:

DISCONNECT → TRADING_RESUMED

gives recovery duration.

This is a much cleaner design than adding unrelated counters throughout the codebase.

An execution timeline is more useful than a single number

Imagine this execution:

10:41:08.120  order submitted
10:41:08.340  fill observed
10:41:08.342  transaction pending
10:41:08.910  transaction confirmed
10:41:09.020  position updated
10:41:09.040  position verified

Now you can calculate:

order → fill
220 ms

fill → confirmation
570 ms

confirmation → position verified
130 ms

total
920 ms

That lets you see where the time is going.

The same timeline can also help when something goes wrong.

For example:

order submitted
fill observed
WebSocket disconnect
process restart
reconciliation
position mismatch
repair
resume

Now the analytics become part of incident investigation.

Analytics and risk should be connected

The same metrics can feed Polymarket trading bot risk controls when an operational threshold is crossed.

Metrics become much more useful when the control plane can act on them.

For example:

execution latency ↑
rejection rate ↑
unknown state duration ↑
        ↓
Execution Health = DEGRADED

Or:

position mismatch count ↑
        ↓
Reconciliation Health = DEGRADED
        ↓
Trading Permission = BLOCK

Or:

recovery duration ↑
        ↓
System Health = DEGRADED

The exact thresholds should be configurable.

The important part is the architecture:

Metrics
   ↓
Health
   ↓
Risk
   ↓
Control

That turns analytics into an operational input instead of a report that nobody reads.

This is part of the broader Polymarket trading bot architecture I've been building.

Don't optimize for dashboards

It's easy to build a beautiful dashboard with:

Orders
Fills
Latency
Volume
P&L

and still not know whether the system is healthy.

The dashboard should answer operational questions.

For example:

Are executions taking longer than normal?

Are partial fills increasing?

Are unresolved executions accumulating?

Are positions frequently drifting from external state?

Is reconciliation taking longer?

Are recovery incidents becoming more frequent?

Those are questions that can lead to engineering action.

A useful execution-health view

I would want something roughly like:

EXECUTION HEALTH

Orders                 1,248
Fill ratio               86%
Partial fills             94
Rejections                11
Unknown executions         3

p50 fill latency         180 ms
p95 fill latency         620 ms

Position mismatches        2
Active recoveries          0

The actual UI doesn't need to look exactly like this.

The important thing is that the metrics represent the system's current operational state.

Anomaly detection can come later

You don't need machine learning to start.

Simple thresholds are enough.

For example:

p95 latency > threshold

or:

unknown executions > threshold

or:

recovery duration > threshold

or:

position mismatches > threshold

Then:

Normal
   ↓
Threshold crossed
   ↓
DEGRADED
   ↓
Investigate

Start with deterministic rules.

You can add more sophisticated anomaly detection later if there is enough historical data to justify it.

Store the raw events

One useful design decision is to preserve enough raw event information to reconstruct metrics later.

For an execution, you might store:

execution_id
order_id
trade_id
market_id

event_type
event_timestamp
observed_timestamp

requested_quantity
matched_quantity

state
reason

Then metrics can be recalculated.

That's better than only storing:

average_fill_latency = 240ms

because once you throw away the underlying observations, it becomes difficult to investigate why the number changed.

Metrics should support incident analysis

Suppose today's recovery time is much worse than yesterday's.

A good system should let you drill down:

Recovery Duration ↑
      ↓
Reconciliation Duration ↑
      ↓
Position Mismatch Count ↑
      ↓
Market X
      ↓
Specific execution / event sequence

Now analytics and incident recovery are connected.

That is the direction I want the infrastructure to take.

That makes analytics useful for Polymarket trading bot incident recovery as well as day-to-day monitoring.

The broader stack

This fits into the rest of my Polymarket work:

Polymarket Trading Bot
        ↓
Execution
        ↓
Execution Verifier
        ↓
Position Reconciliation
        ↓
Risk Controls
        ↓
Trading Control Plane
        ↓
Execution Analytics

Each layer produces information for the next.

The bot produces execution events.

The verifier establishes execution state.

Reconciliation establishes state consistency.

Risk evaluates the resulting exposure and system conditions.

The control plane decides whether trading continues.

Analytics measures how all of those pieces are behaving over time.

What I would measure first

I wouldn't start with 50 metrics.

I'd start with a small set:

1. Order latency
2. Fill latency
3. Fill ratio
4. Partial-fill rate
5. Rejection rate
6. Unknown execution count
7. Unknown execution duration
8. Position mismatch count
9. Reconciliation duration
10. Recovery duration

Those ten already give you visibility into a large part of the execution lifecycle.

Then add metrics when there is a real operational question they can answer.

Final takeaway

A trading bot being profitable doesn't tell you whether the execution system is healthy.

A bot can be making money while:

latency is increasing
partial fills are increasing
rejections are increasing
execution state is staying unknown
positions are drifting
recovery is getting slower

That's why I'm interested in measuring what happens after the strategy produces a trade.

The model is:

Execution
   ↓
Events
   ↓
Metrics
   ↓
Health
   ↓
Risk / Control
   ↓
Action

The goal isn't to build a dashboard full of numbers.

It's to make the trading system measurable enough that you can answer:

What is happening to execution right now, and does it require the system to change its behavior?

That's the level of observability I want around an automated Polymarket trading system.

Polymarket Trading Bot Incident Recovery: How to Reconstruct What Happened

Casatrick | Polymrket Bot Dev — Fri, 02 Oct 2026 05:57:34 +0000

A Polymarket trading bot stops.

Maybe a WebSocket connection dropped.

Maybe an order behaved unexpectedly.

Maybe the position no longer matches local state.

Maybe the process restarted.

The immediate reaction is usually:

restart the bot

But restarting only gets the process running again.

It doesn't answer the more important questions:

What happened before the incident?

What state did the bot believe it was in?

What actually happened to the orders and fills?

Which events were missed?

What is the current position?

Is the system safe to trade again?

That's the part I'm interested in.

For a production-oriented trading system, incident recovery isn't just restarting a process. It's reconstructing enough state to understand what happened and verify that the system can safely continue.

A restart is not a recovery

A simple recovery flow might be:

Process crashed
    ↓
Restart
    ↓
Trading resumes

That assumes the state before the crash was correct.

It also assumes nothing important happened while the process was unavailable.

Neither assumption is safe.

A better flow is:

Incident
    ↓
Pause Trading
    ↓
Recover State
    ↓
Reconcile
    ↓
Verify
    ↓
Check Risk
    ↓
Resume

The restart is only one step.

The first problem is figuring out what happened

Imagine the bot was running normally.

Then something goes wrong.

When the process comes back, you may have:

Last known local state
+
Persisted state
+
Orders
+
Fills
+
Market events
+
Position data
+
Risk state

These don't necessarily line up.

You might discover:

Local position:   +100
Remote position:   +40

Or:

Order:
FILLED

Transaction:
UNKNOWN

Or:

Connection:
RECONNECTED

State:
UNVERIFIED

The incident isn't resolved just because the process is running again.

Start with the last known good state

A useful recovery process needs a reference point.

For example:

Last Known Good State
        ↓
Incident
        ↓
Events around incident
        ↓
Current external state

The system should be able to answer:

When was the last verified state?

What orders were active?

What had already filled?

What positions were expected?

What was the exposure?

What was the risk state?

Without that history, recovery becomes guesswork.

Why event history matters

Suppose the system saw:

Order A
Fill A
Fill B

Then the process crashed.

When it restarts, the local database may only contain part of the state.

The recovery system needs to establish:

What was known before the incident?
What happened during the gap?
What is true now?

That means keeping enough structured information to reconstruct state.

Not every raw event has to be stored forever.

But important state transitions should be traceable.

The trading bot can be alive while its state is wrong

This is similar to the problem I covered in Polymarket WebSocket reconnects.

Imagine:

Process:
RUNNING

WebSocket:
CONNECTED

Strategy:
ACTIVE

Looks healthy.

But:

Position:
UNVERIFIED

Now the system has a much more serious problem.

The process is healthy.

The trading state is not.

This distinction is important during incident recovery because the recovery process needs to establish system state, not just process state.

Reconstructing an incident

A useful incident-recovery pipeline looks like:

Incident Detected
      ↓
Freeze New Risk
      ↓
Capture Current State
      ↓
Load Last Known State
      ↓
Inspect Orders / Fills
      ↓
Inspect Execution State
      ↓
Read Remote Position
      ↓
  Compare
      ↓
Identify Mismatches
      ↓
    Repair
      ↓
   Verify
      ↓
Risk Check
      ↓
   Resume

The exact implementation will vary.

The principle is the important part:

don't resume trading before you understand the state you are resuming from.

Freeze new risk first

The first operational action should normally be to stop adding new exposure.

For example:

Incident
   ↓
TRADING PAUSED

Existing state can still be inspected.

Orders can be reconciled.

Positions can be checked.

But the system shouldn't keep creating additional risk while it is trying to figure out what happened.

This is one of the reasons risk controls and incident recovery belong together.

Reconcile orders first

The system needs to understand the order state around the incident.

For example:

Order 1 → Filled
Order 2 → Open
Order 3 → Cancelled
Order 4 → Unknown

An order that is UNKNOWN needs different handling from one that is clearly cancelled.

Likewise, an open order may still create future exposure.

So recovery needs to establish:

Known orders
+
Known fills
+
Unknown orders
+
Expected remaining quantities

before rebuilding the rest of the state.

Then reconstruct execution state

This connects directly to the Polymarket Execution Verifier.

An incident can leave an execution somewhere in the middle of its lifecycle:

SUBMITTED
    ↓
MATCHED
    ↓
FILLED
    ↓
TX_PENDING

The process stops.

When it comes back, the application shouldn't assume the final state.

It should recover the execution information and determine whether the trade is:

VERIFIED
UNKNOWN
INCONSISTENT
FAILED

The important part is that recovery uses evidence rather than assumptions.

Partial fills make recovery harder

Suppose the bot intended:

and before the incident it knew:

40 filled
60 remaining

Then the process goes down.

After restarting, several things could be true.

The remaining 60 may still be open.

They may have filled.

They may have been cancelled.

The application may not know yet.

So:

100 requested
40 previously known

does not automatically mean:

40 final

The recovery process has to reconcile the current order and fill state.

This is one reason partial fills and incident recovery are closely related but distinct problems.

Position reconstruction comes next

After resolving orders and executions, the system needs to establish the current position.

For example:

Expected:
+100

Observed:
+40

That's a mismatch.

The system should not simply overwrite one number with the other and continue.

It needs to know why the difference exists.

Possible causes include:

Missed fill
Partial execution
Missed WebSocket event
Unexpected order state
Stale local state
Restart during execution

The goal is to move from:

UNKNOWN / INCONSISTENT

to:

VERIFIED

Incident recovery is different from reconciliation

These two concepts are connected, but I don't think they should be treated as the same thing.

Reconciliation

Asks:

Does my local state match the external state?

Local
  ↓
Remote
  ↓
Compare
  ↓
Repair

Incident recovery

Asks:

What happened, what state was lost or made uncertain, and what do I need to verify before the system can operate again?

Incident
  ↓
Reconstruct
  ↓
Reconcile
  ↓
Verify
  ↓
Recover

Reconciliation is part of recovery.

Recovery is the larger process.

Recovery needs a timeline

One of the most useful things an incident system can provide is a timeline.

For example:

10:41:08  Order submitted
10:41:09  Fill observed
10:41:10  WebSocket disconnected
10:41:11  Execution state uncertain
10:41:18  Process stopped
10:42:03  Process restarted
10:42:04  Trading paused
10:42:05  Reconciliation started
10:42:06  Position mismatch detected
10:42:07  Remote state fetched
10:42:08  Position verified
10:42:09  Risk checks passed
10:42:10  Trading resumed

Now the operator can understand what happened.

Without this, the incident may look like:

Bot crashed
Bot restarted

That's not enough information.

The control plane should record the recovery state

This is where the Polymarket Trading Control Plane fits into the larger architecture.

The system can move through explicit states:

HEALTHY
    ↓
DEGRADED
    ↓
PAUSED
    ↓
RECOVERING
    ↓
 HEALTHY

The important part is that RECOVERING is an actual system state.

It tells the rest of the system:

The process is running, but normal trading has not been restored yet.

That is much clearer than a generic “online” status.

Recovery should have clear stages

A useful model is:

1. Detect
2. Pause
3. Capture
4. Reconstruct
5. Reconcile
6. Verify
7. Check Risk
8. Resume

Each stage should produce observable state.

For example:

RECOVERY_STARTED
RECONCILIATION_STARTED
STATE_MISMATCH
RECONCILIATION_COMPLETED
RISK_CHECK_COMPLETED
RECOVERY_COMPLETED
TRADING_RESUMED

That turns recovery from a collection of retry loops into an operational process.

What happens when reconstruction fails?

Sometimes the system won't be able to establish a clean state immediately.

For example:

Local:
+100

Remote:
UNKNOWN

Or:

Execution:
UNKNOWN

Position:
UNKNOWN

The system should not invent an answer.

It should remain controlled:

RECOVERING
    ↓
PAUSED

and retry or request further reconciliation.

This is another reason I prefer explicit UNKNOWN states.

Unknown state is uncomfortable.

Pretending unknown state is healthy is worse.

Recovery after application restart

A restart deserves the same treatment.

The process starts:

Application
    ↓
Load persisted state

But that state may be stale.

So:

Load Local State
       ↓
   Connect
       ↓
Read Remote State
       ↓
   Compare
       ↓
    Repair
       ↓
    Verify
       ↓
Risk Check
       ↓
Allow Trading

Starting the application and starting trading are therefore separate operations.

Recovery after a WebSocket gap

The same applies when a connection drops.

Suppose:

Event A
Event B
   ↓
DISCONNECT
   ↓
Events C, D
   ↓
RECONNECT

The process may not have seen C and D.

The recovery path has to establish the current state rather than assuming the missing events can be ignored.

That's why the sequence is:

Disconnect
   ↓
Pause
   ↓
Reconnect
   ↓
Reconcile
   ↓
Verify
   ↓
Risk Check
   ↓
Resume

The connection returning is only one part of the recovery.

Recovery should be idempotent

This is important for automated systems.

Suppose the recovery worker gets triggered twice.

You don't want:

Recovery #1
Recovery #2

to produce conflicting state changes.

The operations should be safe to repeat:

RECONCILE
RECONCILE
RECONCILE

without double-counting fills or creating duplicate records.

Likewise:

PAUSE
PAUSE

should remain simply:

PAUSED

The recovery process should be designed around idempotent operations wherever possible.

Incident history is useful after the system is healthy

Recovery isn't only about getting back online.

The incident record can help answer:

What failed?

How long was trading paused?

Which state became inconsistent?

How was it repaired?

Did risk limits change?

What prevented the system from resuming immediately?

Over time, that becomes useful for identifying recurring problems.

For example:

WebSocket incidents
Execution failures
Position mismatches
Stale-data incidents
Recovery failures

You can start seeing patterns instead of isolated outages.

What I want to see from an incident record

Something like:

Incident ID:
INC-2026-0012

Started:
10:41:10

Trigger:
WEBSOCKET_DISCONNECTED

System State:
PAUSED

Affected Execution:
abc123

Position:
MISMATCH

Recovery:
COMPLETED

Duration:
62 seconds

Final Risk State:
HEALTHY

Trading:
RESUMED

The exact implementation doesn't need to look like this.

But the system should retain enough information to explain the recovery.

Don't hide recovery inside logs

Logs are useful.

But recovery state should also be part of the application's domain model.

Instead of only:

ERROR websocket disconnected

the system should know:

system_state = PAUSED
recovery_state = RECONCILING
trading_permission = BLOCK

Now dashboards, alerts, APIs, and automation can use the same source of truth.

That's one of the main reasons I'm separating the Control Plane from the trading strategy.

What should make trading resume?

This is the final gate.

I don't want:

process restarted
    ↓
resume

I want something closer to:

Incident resolved
+
Orders reconciled
+
Executions verified
+
Positions verified
+
Exposure recalculated
+
Risk healthy
+
Market data fresh
=
Trading allowed

If one of those critical conditions remains unknown:

PAUSED

until the state is established.

The broader architecture

The incident-recovery layer fits into the stack I've been building:

Polymarket Trading Bot
        ↓
    Strategy
        ↓
      Risk
        ↓
    Execution
        ↓
Execution Verifier
        ↓
Position Reconciliation
        ↓
Trading Control Plane
        ↓
Incident Recovery

The responsibilities stay separate.

The strategy generates decisions.

Risk controls those decisions.

Execution carries them out.

The verifier determines what happened.

Reconciliation checks whether state matches reality.

The control plane coordinates health and trading permission.

Incident recovery reconstructs and restores the system after something goes wrong.

A practical recovery checklist

Before allowing a bot to resume after an incident:

[ ] Incident trigger identified
[ ] New trading paused
[ ] Last known state recovered
[ ] Orders reconciled
[ ] Fills reconciled
[ ] Execution state verified
[ ] Position verified
[ ] Exposure recalculated
[ ] Risk checked
[ ] Market data confirmed fresh
[ ] No critical UNKNOWN state remains
[ ] Recovery completed
[ ] Trading permission = ALLOW

The exact policy will depend on the system.

But the important part is having an explicit gate.

Final takeaway

A failed trading bot is not necessarily the hard part.

The harder problem is restarting it without knowing what happened before the restart.

A process can start successfully while:

orders are uncertain
fills are incomplete
positions are wrong
exposure is stale
risk is unknown

That's why I think incident recovery should be treated as part of the trading system itself.

The recovery path I want is:

INCIDENT
   ↓
PAUSE
   ↓
RECONSTRUCT
   ↓
RECONCILE
   ↓
VERIFY
   ↓
CHECK RISK
   ↓
RESUME

The goal isn't simply to get the bot running again.

It's to get the system back to a state where it knows what happened, knows what is true now, and has a reason to trust the next trade.

Polymarket Trading Bot Risk Controls: When Should a Bot Stop Trading?

Casatrick | Polymrket Bot Dev — Thu, 01 Oct 2026 06:47:01 +0000

A Polymarket trading bot can have a good strategy, fresh market data, and a working execution engine - and still be unsafe to let it trade.

The difficult part isn't only deciding:

“Should I buy?”

There is another question underneath it:

“Is the system currently in a state where it should be allowed to trade at all?”

That is where risk controls become infrastructure.

A production-oriented Polymarket trading bot needs more than a strategy and an order API.

It needs explicit rules for when to continue, when to reduce activity, and when to stop.

I've been building my Polymarket trading infrastructure around that idea:

Market Data
     ↓
Strategy
     ↓
Risk Checks
     ↓
Execution
     ↓
Verification
     ↓
Position / Exposure
     ↓
Monitoring
     ↓
Recovery

The important part is that the risk layer sits between the strategy and execution - and can also react to problems discovered after execution.

A good signal doesn't guarantee a safe trade

Imagine your strategy generates:

BUY

The signal looks good.

Market data is available.

The execution engine is working.

Normally you might immediately submit the order.

But what if:

Current position = already near limit

Or:

Market data = stale

Or:

Previous execution = still unverified

Or:

Position reconciliation = failed

Or:

Daily loss limit = already breached

The strategy may still be correct.

The system should still refuse the trade.

That's the difference between strategy logic and trading-system control.

Risk should be a gate, not a suggestion

I prefer thinking about risk as a gate:

Signal
  ↓
Risk Gate
  |
  +---- BLOCK
  |
  +---- ALLOW
          ↓
       Execute

The strategy produces an intent.

The risk layer decides whether that intent is permitted under the current system state.

This makes risk reusable across different strategies.

For example:

Momentum
Arbitrage
Market Making
Copy Trading

can all feed the same risk engine.

You don't want every strategy implementing its own completely different exposure and safety rules.

What should a Polymarket bot check before trading?

There isn't one universal configuration.

The exact limits depend on the account, strategy, capital, market, and operating policy.

But a useful production-oriented system can evaluate several categories.

Position limits

The simplest check is:

How large can this position become?

For example:

Current position: 80
New order:        30
Maximum:          100

The correct decision is not:

80 < 100

You need to consider the resulting position:

80 + 30 = 110

Therefore:

BLOCK

Risk checks should evaluate post-trade state, not just current state.

Market exposure

A position limit isn't always enough.

A token or market can become a large portion of the overall portfolio even when an individual order looks small.

So the system can maintain:

Market Exposure
+
Portfolio Exposure

For example:

Market A:   $8,000
Market B:   $5,000
Market C:   $3,000

Total:     $16,000

A new trade might be acceptable at the market level but unacceptable at the portfolio level.

That is why I prefer two layers:

Per-Market Risk
       +
Portfolio Risk

Total exposure

The same principle applies at the system level.

Suppose the bot operates across several Polymarket markets.

Each individual position may be inside its own limit:

Market A → OK
Market B → OK
Market C → OK

But the aggregate exposure could still be too large.

The risk engine therefore needs a global view:

Positions
   ↓
Exposure
   ↓
Portfolio Risk

This becomes particularly important when multiple strategies or execution workers share the same account.

Daily loss limits

Another simple but useful control is a daily loss boundary.

Conceptually:

Daily P&L
   ↓
Compare with configured threshold
   ↓
Within limit → continue
Over limit   → pause

The exact accounting method needs to be defined carefully.

The important thing is that the limit is implemented as a system policy, not as a number hidden inside one strategy.

Once the threshold is reached:

RISK LIMIT BREACHED
        ↓
TRADING PAUSED

The strategy doesn't get to override that simply because it sees another attractive signal.

Execution failures should affect risk

Risk isn't only about P&L.

Repeated execution failures can indicate that something is wrong with the system.

For example:

Order 1 → failed
Order 2 → failed
Order 3 → failed
Order 4 → failed

At some point the control plane should ask:

Why am I still allowing new orders?

A simple operational rule can be:

Execution Failures
       ↓
Failure Threshold
       ↓
Pause
       ↓
Investigate / Recover

This connects the execution layer with the risk layer.

Stale market data is a risk condition

This is one of the easiest conditions to overlook.

A strategy might believe it has current market information because the WebSocket connection still exists.

But:

connected = true

doesn't necessarily mean:

data = fresh

You need a freshness measurement.

For example:

Last market event: 500 ms ago
Maximum allowed age: 2 seconds

That's healthy.

But:

Last market event: 12 seconds ago
Maximum allowed age: 2 seconds

should produce:

MARKET_DATA_STALE

The response might be:

pause

or:

reduce permissions

depending on policy.

The important part is that stale data becomes an explicit system condition rather than being silently ignored.

A WebSocket reconnect is not a clean bill of health

This connects directly to the recovery work I've been doing around Polymarket WebSocket recovery.

Imagine:

Event A
Event B
DISCONNECT
Event C
Event D
RECONNECT

After reconnecting, the socket is healthy again.

Your local trading state may not be.

There could be missing events.

That means:

CONNECTED

should not automatically produce:

TRADING_ALLOWED

A safer sequence is:

DISCONNECT
   ↓
PAUSE
   ↓
RECONNECT
   ↓
REBUILD STATE
   ↓
RECONCILE
   ↓
VERIFY
   ↓
CHECK RISK
   ↓
RESUME

Risk controls are therefore connected directly to recovery.

Position mismatch should block new exposure

This is where the risk engine needs to consume reconciliation results.

Suppose the system believes:

Expected position: 100

but the external account shows:

Observed position: 40

The system has a mismatch.

My earlier work on Polymarket position reconciliation treats this as a state problem rather than something the strategy should silently fix.

Until the mismatch is understood, the risk engine may need to produce:

POSITION_UNVERIFIED

and:

TRADING_BLOCKED

That prevents the system from adding more exposure based on incorrect local state.

Execution uncertainty should propagate into risk

The same applies to execution verification.

Suppose an order reaches:

FILLED

but the rest of the execution lifecycle is not yet verified.

The system might have:

Execution = UNKNOWN
Position   = UNKNOWN
Risk       = UNKNOWN

In that situation, the safest operational response is generally not:

continue trading

It is:

PAUSE
↓
VERIFY
↓
RECONCILE
↓
RECHECK RISK

That's one reason I built a separate Polymarket Execution Verifier.

Execution verification and risk control answer different questions.

The verifier asks:

What happened?

The risk engine asks:

Given what happened, is further trading permitted?

Risk needs multiple layers

I think about risk as a stack:

Order Risk
     ↓
Position Risk
     ↓
Market Exposure
     ↓
Portfolio Exposure
     ↓
System Risk

And another stack operates alongside it:

Market Data Health
     ↓
Execution Health
     ↓
Reconciliation Health
     ↓
Recovery State

The final trading decision can combine both:

SIGNAL
  ↓
RISK
  +
SYSTEM HEALTH
  ↓
ALLOW / BLOCK

This is much stronger than checking one maximum position value.

Risk decisions should be explainable

A good risk engine shouldn't just return:

false

It should return the reason.

For example:

Decision: BLOCK

Reason:
MAX_TOTAL_EXPOSURE_BREACHED

Current:
$51,200

Limit:
$50,000

Or:

Decision: BLOCK

Reason:
MARKET_DATA_STALE

Current age:
8.4s

Maximum:
2.0s

Or:

Decision: BLOCK

Reason:
POSITION_UNVERIFIED

Expected:
100

Observed:
40

That makes risk decisions observable and much easier to debug.

Risk state should be visible to the control plane

This is where the separate Polymarket Trading Control Plane fits into the architecture.

The control plane can consume:

Health
Risk
Execution
Position
Reconciliation
Recovery

and convert them into a system state.

For example:

HEALTHY
   ↓
Risk breach
   ↓
PAUSED

Or:

DISCONNECTED
   ↓
RECOVERING
   ↓
RECONCILING
   ↓
RISK CHECK
   ↓
HEALTHY

The strategy doesn't need to understand every operational state.

The control plane handles that responsibility.

Kill switch vs pause

These shouldn't necessarily mean the same thing.

A normal pause might be:

TRADING PAUSED

because:

market data is stale
reconciliation is pending
an execution failed
exposure is temporarily too high

The system can potentially recover and resume after verification.

A kill switch is stronger:

KILL SWITCH

It represents an emergency operational control that blocks trading until explicitly cleared.

The important property is that neither should be buried inside strategy code.

They belong to the control layer.

When should the bot actually stop trading?

This is the question I would build the entire risk architecture around.

Not:

“Can the strategy generate another signal?”

But:

“What conditions should make another trade unacceptable?”

For example:

Position limit breached
        OR
Portfolio exposure too high
        OR
Daily loss threshold breached
        OR
Market data stale
        OR
Execution state unknown
        OR
Position mismatch
        OR
Critical execution failures
        OR
Recovery incomplete
        ↓
TRADING BLOCKED

This is effectively a trading permission engine.

Trading permission as a state machine

Instead of a boolean like:

can_trade = true

the system can have explicit permissions:

ALLOW
BLOCK
REQUIRES_RECONCILIATION
REQUIRES_RECOVERY

For example:

Healthy
   ↓
ALLOW

but:

Position mismatch
   ↓
REQUIRES_RECONCILIATION

and:

Critical risk breach
   ↓
BLOCK

and:

WebSocket recovery
   ↓
REQUIRES_RECOVERY

This gives the rest of the system something concrete to act on.

A practical pre-trade pipeline

The architecture can therefore become:

Strategy Signal
      |
      v
Market Data Check
      |
      v
Execution State Check
      |
      v
Position Check
      |
      v
Exposure Check
      |
      v
Risk Limits
      |
      v
Trading Permission
      |
      +---- BLOCK
      |
      +---- ALLOW
              |
              v
           Execute

The key is that the order does not reach execution until the relevant checks have passed.

But pre-trade checks aren't enough

Something can change immediately after the order is submitted.

So risk has to continue after execution.

A simplified lifecycle is:

Pre-Trade
   ↓
Execute
   ↓
Verify Execution
   ↓
Reconcile Position
   ↓
Recalculate Exposure
   ↓
Recheck Risk

That creates a feedback loop:

TRADE
  ↓
NEW STATE
  ↓
RISK
  ↓
NEXT DECISION

The system isn't evaluating risk once.

It's continuously evaluating the state that future decisions depend on.

How this connects to the broader Polymarket stack

This is the direction I’m building toward:

Polymarket Trading Bot
        |
        v
     Strategy
        |
        v
      Risk
        |
        v
    Execution
        |
        v
Execution Verifier
        |
        v
Position Reconciliation
        |
        v
Trading Control Plane
        |
        +---- Monitoring
        +---- Alerts
        +---- Recovery
        +---- Pause / Resume

Each layer has a different job.

The strategy generates decisions.

The risk engine determines whether those decisions are permitted.

Execution submits them.

The execution verifier establishes what actually happened.

Reconciliation checks the resulting state.

The control plane determines whether the overall system is healthy enough to continue.

A simple risk checklist

Before allowing a new Polymarket trade, the system should be able to answer:

[ ] Is market data fresh?
[ ] Is the connection healthy?
[ ] Is the current execution state verified?
[ ] Is the current position known?
[ ] Is reconciliation complete?
[ ] Is the resulting position inside its limit?
[ ] Is market exposure inside its limit?
[ ] Is total exposure inside its limit?
[ ] Is daily loss inside its limit?
[ ] Are execution failures below the configured threshold?
[ ] Is the system fully recovered?
[ ] Is trading permission ALLOW?

If one of the critical answers is unknown, the system should know that it is unknown.

That's much better than silently assuming everything is fine.

The real goal isn't to stop trading

Risk controls aren't there because trading should always be conservative.

They're there because the system needs a clear answer to:

When should trading stop?

Without explicit rules, the bot can continue trading through:

stale data
bad state
wrong positions
execution uncertainty
risk breaches
recovery

At that point, the strategy isn't really controlling the system anymore.

The system is just continuing because nobody told it to stop.

Final takeaway

A Polymarket trading bot doesn't only need a strategy that knows when to trade.

It needs infrastructure that knows when not to trade.

The model I'm working toward is:

Signal
   ↓
Risk Check
   ↓
Execution
   ↓
Verification
   ↓
Reconciliation
   ↓
Risk Recheck
   ↓
Continue / Pause

And the final permission should come from actual system state:

Market data healthy
+
Execution verified
+
Position reconciled
+
Exposure within limits
+
Risk within limits
+
Recovery complete
=
TRADING ALLOWED

Otherwise:

PAUSE
↓
RECONCILE
↓
VERIFY
↓
RECOVER
↓
RECHECK RISK
↓
RESUME

That's the difference between a bot that can place orders and a trading system that knows when it should stop.

Polymarket Execution Verification: When “Filled” Doesn’t Mean Settled

Casatrick | Polymrket Bot Dev — Wed, 30 Sep 2026 05:44:27 +0000

A Polymarket trading bot can receive a successful execution response and still not know enough to safely continue trading.

That sounds like a small implementation detail.

It isn't.

In a production trading system, there is a big difference between:

"I sent the order."

"I received a fill."

"The fill has a transaction."

"The transaction is confirmed."

"The execution is settled."

"My position matches reality."

Those are different states.

If your bot treats them as one state called FILLED, eventually you get a system that believes it owns one position while the account says something else.

This is why execution verification deserves its own layer.

I built a small Polymarket execution-verification project around this idea:

Don't let a trading system assume an execution is complete before the relevant state has been verified.

GitHub: Polymarket Execution Verifier

The problem with treating `FILLED` as the end

Imagine the strategy decides to buy 100 shares.

The bot submits:

BUY 100

Then it receives an execution update:

FILLED

A naive implementation does:

filled = true
position += 100
continue trading

That is dangerous.

The bot has made several assumptions at once:

the requested quantity was actually matched
the execution event was complete
the settlement transaction is known
the transaction was successfully processed
the external position reflects the expected result
no relevant event was missed

Those assumptions can fail independently.

A safer trading system treats execution as a state transition rather than a boolean.

Order → Fill → Transaction → Confirmation → Settlement → Position

The execution lifecycle I use is:

INTENDED
   ↓
SUBMITTED
   ↓
ACCEPTED
   ↓
MATCHED
   ↓
FILLED
   ↓
TX_PENDING
   ↓
CONFIRMED
   ↓
SETTLED
   ↓
POSITION VERIFIED

There are also failure and uncertainty states:

REJECTED
CANCELLED
FAILED
RETRYING
UNKNOWN
INCONSISTENT

The important part is that FILLED is not necessarily the final state your risk engine should trust.

Polymarket's current CLOB tooling also distinguishes trade completion from simply observing a fill: the current client logic considers a trade resolved when it reaches a terminal outcome, such as having a settlement transaction hash or having failed. The client can also expose transaction hashes when available and trade IDs that can be followed while a hash is not yet available.

That distinction is exactly what an execution verifier should make explicit.

Why execution state becomes uncertain

There are several ways a trading bot can end up with incomplete execution information.

1. The order was matched, but transaction information is not available yet

A matching event tells you something important happened.

It does not necessarily mean every downstream piece of information is already available to your application.

For example:

Order
  ↓
Matched
  ↓
Fill observed
  ↓
Transaction information unavailable

The correct state is not:

DONE

It is closer to:

TX_PENDING

or:

UNKNOWN

depending on what the system actually knows.

Your execution layer should preserve that uncertainty instead of hiding it.

2. Partial execution

Suppose you intended:

100 shares

but only 40 were matched.

Your bot now has:

Requested: 100
Matched:    40
Remaining:  60

That remaining quantity cannot simply disappear from your accounting.

The execution system needs to know whether the remaining 60:

are still active
were cancelled
expired
failed
were never accepted
require another verification step

This is why requested quantity and executed quantity should always be separate fields.

For example:

{
  "requested_size": 100,
  "matched_size": 40,
  "remaining_size": 60,
  "execution_state": "PARTIAL"
}

The exact data model can vary, but the principle should remain the same.

3. The transaction is confirmed, but the position still isn't verified

This is one of the most important boundaries.

Consider:

FILLED
   ↓
TX CONFIRMED

A developer may immediately update the internal position:

local_position += executed_size

But the trading system still has another question:

Does the external account state actually match what I expected?

For example:

Expected position: 125.5

Observed position: 100.0

The transaction succeeded.

The internal state is still wrong.

This is where execution verification connects directly to position reconciliation.

A trading bot should not confuse:

transaction verified

with:

position verified

Those are different checks.

4. A WebSocket event can be missed

Real-time trading systems depend heavily on event streams.

That creates another failure mode.

Imagine:

Event 101 received
Event 102 received
[connection drops]
Event 103 happens
Event 104 happens
connection restored

Your application reconnects.

But reconnecting the socket does not magically reconstruct the events that were missed.

You now have:

local state != external state

The correct recovery sequence is:

DISCONNECT
   ↓
PAUSE
   ↓
RECONNECT
   ↓
REBUILD STATE
   ↓
RECONCILE
   ↓
VERIFY
   ↓
RESUME

This is why execution verification cannot be implemented as a single API callback.

It belongs inside a larger state-management system.

Execution verification should be explicit

Instead of:

if order.filled {
    update_position();
    continue_trading();
}

use an explicit state machine.

For example:

enum ExecutionState {
    Intended,
    Submitted,
    Accepted,
    Matched,
    Filled,
    TxPending,
    Confirmed,
    Settled,
    PositionVerified,

    Rejected,
    Cancelled,
    Failed,
    Retrying,
    Unknown,
    Inconsistent,
}

Now the rest of the system can react to the state.

For example:

FILLED
    ↓
Does transaction information exist?
    ↓
No
    ↓
TX_PENDING

Then:

TX_PENDING
    ↓
Transaction confirmed?
    ↓
Yes
    ↓
CONFIRMED

Then:

CONFIRMED
    ↓
Position matches expected state?
    ↓
No
    ↓
INCONSISTENT

This is much safer than a single filled=true flag.

The verifier should separate facts from assumptions

A useful execution record might contain:

strategy_decision_id
internal_execution_id

polymarket_order_id
trade_id

market_id
token_id
side

requested_quantity
matched_quantity

order_timestamp
fill_timestamp

transaction_hash
confirmation_timestamp

execution_state
position_state

verification_timestamp

The important property is that each value represents something actually observed.

For example:

requested_quantity = 100
matched_quantity   = 40

is different from assuming:

matched_quantity = requested_quantity

Likewise:

execution_state = CONFIRMED

should not automatically imply:

position_state = VERIFIED

Good trading infrastructure makes those boundaries visible.

What should happen when verification fails?

This is where execution verification becomes a risk-control problem.

Suppose the verifier reaches:

INCONSISTENT

The strategy layer should not simply continue because it still has a signal.

The control flow should look more like:

Execution uncertain
       ↓
Pause affected trading
       ↓
Query authoritative state
       ↓
Reconcile orders / fills / positions
       ↓
Verify risk
       ↓
    Healthy?
   ↙       ↘
 YES       NO
 ↓          ↓
RESUME     PAUSE

The trading decision is therefore not just:

Should I buy?

It also becomes:

Is the system in a state where buying is safe?

That is a very different engineering problem.

A useful execution verifier architecture

The project I am working on separates verification into layers:

                 Strategy
                    │
                    ▼
              Execution Request
                    │
                    ▼
              Order Submission
                    │
                    ▼
            ┌──────────────────┐
            │   Execution      │
            │    Verifier      │
            └──────────────────┘
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
      Order        Fill       Transaction
        │           │           │
        └───────────┼───────────┘
                    ▼
               Settlement
                    │
                    ▼
            Position Verification
                    │
                    ▼
                 Risk Layer
                    │
                    ▼
             Resume / Pause

This gives the system a clear boundary:

the strategy produces an intention; the infrastructure determines whether reality matches that intention.

Execution verification vs position reconciliation

These two concepts are closely related, but they solve different problems.

Execution verification

Question:

Did the intended trade actually reach a verified terminal execution state?

It follows:

Order
→ Fill
→ Transaction
→ Confirmation
→ Settlement

Position reconciliation

Question:

Does the account's actual position match the position my system believes it has?

It follows:

Expected State
      ↓
External State
      ↓
Compare
      ↓
Match / Mismatch

You need both.

For example:

Execution: VERIFIED
Position:  MISMATCH

is completely possible.

Likewise:

Execution: UNKNOWN
Position:  temporarily unchanged

is also possible.

The system should retain both pieces of information.

Why this matters for automated trading

A strategy can be statistically correct and still lose control of the system.

The failure may happen after the signal.

For example:

Signal
  ↓
Order
  ↓
Partial Fill
  ↓
WebSocket Gap
  ↓
Incorrect Local State
  ↓
Incorrect Position
  ↓
Incorrect Risk Calculation
  ↓
New Order

The original strategy wasn't necessarily the problem.

The execution state was.

This is why production trading infrastructure needs more than:

market data
+
strategy
+
order placement

It needs:

market data
+
strategy
+
execution
+
verification
+
reconciliation
+
risk
+
recovery
+
observability

When should the bot resume trading?

This is the final question.

Suppose the bot reconnects after losing its market-data connection.

Should it immediately resume?

No state machine should answer that with:

socket_connected == true

A safer condition is closer to:

connection healthy
AND
market data fresh
AND
orders reconciled
AND
fills reconciled
AND
positions verified
AND
exposure verified
AND
risk limits healthy

Only then should the system move back toward:

TRADING

This is also where an execution verifier connects to a broader trading control plane.

The verifier answers:

What actually happened?

The reconciliation layer answers:

Does my state match reality?

The risk layer answers:

Is continuing safe according to configured limits?

The control plane coordinates the result.

Building the execution verifier

My current project focuses on making these execution states explicit instead of burying them inside strategy code.

Repository:

github.com/casatrickdev/polymarket-execution-verifier

The project is intentionally focused on one problem:

Verify Polymarket execution
across
order → fill → transaction → confirmation → settlement → position

That makes it easier to integrate with the rest of a production trading stack.

The broader architecture connects this with:

a Polymarket trading bot
position reconciliation
trading monitoring
risk controls
recovery logic
operational control

Projects:

Polymarket Trading Bot

Polymarket Trading Control Plane

Practical execution-verification checklist

Before allowing a trading bot to treat an execution as complete, I want to be able to answer:

[ ] Was the order accepted?
[ ] Was it matched?
[ ] How much actually filled?
[ ] Is the remaining quantity known?
[ ] Is the relevant transaction known?
[ ] Has the transaction reached the expected terminal state?
[ ] Is settlement verified?
[ ] Does the external position match expected state?
[ ] Is exposure correct?
[ ] Are risk limits still valid?
[ ] Is there any unresolved execution uncertainty?

If one of those answers is unknown, the system should know that it is unknown.

That sounds obvious.

In production, it is one of the differences between a bot that places trades and a trading system that can actually be trusted.

Final takeaway

A Polymarket trading bot should not think:

FILLED = DONE

A better mental model is:

INTENDED
   ↓
SUBMITTED
   ↓
MATCHED
   ↓
FILLED
   ↓
TRANSACTION VERIFIED
   ↓
SETTLED
   ↓
POSITION VERIFIED
   ↓
RISK VERIFIED
   ↓
SAFE TO CONTINUE

The important question is not only whether an order was filled.

It is:

Can the system prove that its current trading state matches reality?

That is the reason for building an execution-verification layer.

Project

Polymarket Execution Verifier

Verify execution across:

ORDER
FILL
TRANSACTION
CONFIRMATION
SETTLEMENT
POSITION

GitHub: https://github.com/casatrickdev/polymarket-execution-verifier

Polymarket WebSocket Reconnects: Rebuilding Trading State Safely

Casatrick | Polymrket Bot Dev — Tue, 29 Sep 2026 05:53:03 +0000

Your Polymarket trading bot is connected to the WebSocket.

Then the connection drops.

A few seconds later, it reconnects.

Everything looks normal again.

But should the bot immediately start trading?

I don't think so.

A successful WebSocket reconnect only tells you that the connection has returned. It does not prove that the trading system has recovered the events it may have missed or that its local orders, fills, positions, and risk state are still correct.

The recovery problem is:

Disconnect
   ↓
Unknown state
   ↓
Reconnect
   ↓
Reconcile
   ↓
Verify
   ↓
Resume

This is one of the problems I'm exploring with the Polymarket Trading Control Plane.

The project is an operational layer around automated Polymarket trading systems, focused on state, health, risk, reconciliation, and recovery.

A WebSocket reconnect is not a recovery

It's tempting to write something like:

WebSocket disconnected
       ↓
Reconnect
       ↓
Trading resumes

That's fine for a simple data consumer.

For an automated trading system, there is a missing step.

What happened while the connection was unavailable?

Maybe an order changed state.

Maybe a fill occurred.

Maybe a position changed.

Maybe the application missed an event.

Maybe several events arrived in a different sequence.

The system cannot assume that reconnecting restores its internal state automatically.

A more defensive model is:

WebSocket disconnect
        ↓
Trading = PAUSED
        ↓
Reconnect
        ↓
Rebuild / reconcile state
        ↓
Verify orders
        ↓
Verify fills
        ↓
Verify positions
        ↓
Verify risk
        ↓
Trading = RESUMED

That distinction is central to the Control Plane architecture.

What can happen during a disconnect?

Consider a simple sequence:

Event A
   ↓
WebSocket disconnect
   ↓
Events B, C, D
   ↓
WebSocket reconnect

The local application may only know about A.

If B, C, and D affected trading state, local state is now incomplete.

For a trading bot, that can affect:

open orders
fills
positions
exposure
PnL
risk decisions

The process may still be running.

The problem is that it may no longer know the current state.

The dangerous part is that nothing has to crash

A crash is obvious.

A state discrepancy is not.

For example:

Process:       RUNNING
WebSocket:     CONNECTED
API:           OK
Strategy:      ACTIVE

Everything looks healthy.

But:

Position state: UNVERIFIED

That is a very different situation.

This is why I prefer distinguishing:

process health

from:

trading-system health.

The Control Plane currently models explicit operational states such as:

HEALTHY
DEGRADED
PAUSED
RECOVERING
FAILED

rather than treating “process is alive” as the complete health model.

Why pause trading during the reconnect

Suppose the bot has no verified state during the disconnect.

If it keeps trading, its next decision could be based on:

stale positions
stale exposure
stale order state

That creates a bad sequence:

Unknown state
    ↓
Strategy continues
    ↓
New order
    ↓
More exposure

A safer approach is:

```text id="7t9r9d"
Unknown state
↓
No new risk
↓
Recovery
↓
Verified state
↓
Resume




The Control Plane's operational model explicitly includes `PAUSE TRADING`, `RESUME TRADING`, `KILL SWITCH`, and `RECONCILE STATE` as control actions.

---

## Reconnection should transition the system into recovery

I like thinking about reconnect as a state transition rather than a single callback.

For example:



```plaintext
HEALTHY
    ↓
WebSocket disconnect
    ↓
DEGRADED
    ↓
PAUSED
    ↓
RECONNECTING
    ↓
RECOVERING
    ↓
VERIFIED
    ↓
HEALTHY

The exact implementation can vary.

The principle is:

The system should know which phase of recovery it is in.

That makes behavior easier to reason about and easier to observe.

Rebuild state after reconnect

Once the connection returns, the system needs a way to establish its current state.

Conceptually:

Reconnect
    ↓
Read current remote state
    ↓
Compare local state
    ↓
Repair discrepancies
    ↓
Verify

This is different from simply subscribing to the stream again.

The Control Plane is designed around local-versus-remote state comparison for orders and positions, with reconciliation after reconnects, restarts, suspected event gaps, unexpected API responses, and mismatches.

What exactly should be reconciled?

Position is only one part of the problem.

The trading system has multiple related state domains:

Orders
   ↓
Trades / Fills
   ↓
Positions
   ↓
Exposure
   ↓
Risk

That means recovery should not stop at:

“My position looks correct.”

It should eventually establish that the broader trading state is internally consistent.

For example:

Orders:      verified
Fills:       verified
Positions:   verified
Exposure:    verified
Risk:        verified

Only then does the system have a strong basis for resuming normal operation.

The Control Plane explicitly treats these as separate observable state areas.

Missed events are not the only problem

A disconnect can create several types of uncertainty.

Missed event

The application never saw a state transition.

Duplicate event

The application processes the same event more than once.

Delayed event

The event arrives much later than expected.

Out-of-order state

The system observes related events in an unexpected sequence.

Restart during the gap

The application loses in-memory state before recovery.

That means the recovery layer has to be designed for uncertainty, not only connection failure.

Unknown should be an explicit state

One of the most useful states in a trading system is:

UNKNOWN

Imagine the bot submits an order immediately before the connection drops.

The application doesn't know whether the order:

was rejected
was accepted
partially filled
fully filled

The wrong behavior is to guess.

Instead:

UNKNOWN
   ↓
PAUSE
   ↓
RECONCILE
   ↓
DETERMINE ACTUAL STATE
   ↓
CONTINUE

The Control Plane is designed around making uncertain state visible rather than hiding it.

Reconnect after a partial fill

This is where yesterday's Polymarket partial fills work connects directly to today's problem.

Imagine:

Requested: 100
Filled:     40

Then the WebSocket disconnects.

During the gap, the remaining 60 may:

remain open
be cancelled
fill later
change execution state

The bot reconnects.

It should not assume:

Position = +40

without checking.

And it should not assume:

Position = +100

either.

It needs to reconcile.

That's why partial-fill handling and WebSocket recovery are separate but connected problems:

Partial Fill
     ↓
Execution State
     ↓
WebSocket Gap
     ↓
Potential State Drift
     ↓
Reconciliation
     ↓
Verified Position

Reconnect after an application restart

The same problem appears during restart.

Suppose the process exits.

When it comes back, it has only the state that was persisted locally.

That state may not represent everything that happened while the application was down.

A safer startup path is:

Application starts
        ↓
Load local state
        ↓
    Connect
        ↓
Read remote state
        ↓
   Compare
        ↓
    Repair
        ↓
Verify risk
        ↓
Allow trading

Starting the application and starting trading should therefore be two separate decisions.

The recovery sequence I want

The system I'm designing around this problem uses a simple mental model:

1. Detect
2. Pause
3. Reconnect
4. Reconcile
5. Repair
6. Verify
7. Check risk
8. Resume

The purpose is not to make recovery slow.

The purpose is to avoid turning an infrastructure problem into an automated trading problem.

Risk needs to be part of recovery

Suppose the system reconciles positions successfully.

That still doesn't necessarily mean trading should immediately resume.

The system should also check:

current exposure
position limits
loss limits
data freshness
execution-failure count
overall health

The Control Plane's risk model explicitly includes position limits, market exposure, total exposure, daily loss, execution-failure limits, and stale-data conditions.

So the final recovery sequence becomes:

Reconcile
   ↓
Verify
   ↓
Risk Check
   ↓
ALLOW

or:

Reconcile
   ↓
Mismatch / Risk Breach
   ↓
REMAIN PAUSED

What if reconciliation fails?

This is important too.

Suppose the system reconnects but cannot establish a consistent state.

It should not keep trying to trade just because the connection is technically healthy.

Instead:

Reconnect
   ↓
Reconcile
   ↓
Mismatch remains
   ↓
PAUSED
   ↓
Alert operator

The project is designed to make state mismatches and critical conditions observable so they can be handled deliberately.

The control plane architecture

This is the larger architecture I'm building around the trading bot:

                         POLYMARKET
                              │
               ┌──────────────┴──────────────┐
               │                             │
         WebSocket Streams              API / Reads
               │                             │
               ▼                             ▼
       ┌────────────────┐          ┌──────────────────┐
       │ Event Ingestion│          │ State Reconciler │
       └───────┬────────┘          └────────┬─────────┘
               │                            │
               └────────────┬───────────────┘
                            ▼
                    ┌──────────────────┐
                    │    State Store   │
                    │                  │
                    │ Orders           │
                    │ Trades           │
                    │ Positions        │
                    │ Exposure         │
                    │ PnL              │
                    │ Health           │
                    └────────┬─────────┘
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
         Risk Engine    Health Engine   Alert Engine
              │              │              │
              └──────────────┼──────────────┘
                             ▼
                    ┌──────────────────┐
                    │  Control Plane   │
                    │                  │
                    │ Pause            │
                    │ Resume           │
                    │ Kill Switch      │
                    │ Reconcile        │
                    └──────────────────┘

This architecture is intentionally centered on operational state rather than another trading strategy.

Observability during recovery

Recovery shouldn't happen inside a black box.

The system should expose events such as:

WEBSOCKET_DISCONNECTED
RECONCILIATION_STARTED
STATE_MISMATCH
RECONCILIATION_COMPLETED
TRADING_PAUSED
TRADING_RESUMED

The broader event model also includes:

ORDER_FAILURE
PARTIAL_FILL
MARKET_DATA_STALE
RISK_LIMIT_BREACHED
KILL_SWITCH_TRIGGERED

That information can feed:

dashboards
logs
alerts
webhooks
external monitoring

Now an operator can see not only:

“The bot is connected.”

but:

“The bot reconnected, reconciled, verified state, passed risk checks, and resumed.”

That's a much more useful operational signal.

Failure scenarios worth testing

A WebSocket recovery implementation should be tested against more than a clean disconnect.

For example:

Scenario	Expected behavior
WebSocket disconnect	Enter degraded state
Reconnect	Trigger recovery
Missed event	Reconcile
Duplicate event	Avoid double-counting
Delayed event	Validate current state
Partial fill during gap	Reconcile actual fill
Unknown order	Block blind retry
Process restart	Reload and reconcile
Position mismatch	Pause trading
Risk breach	Pause or kill

The Control Plane roadmap explicitly includes these kinds of failure and recovery scenarios.

Reconnect versus recovery

This distinction is the main idea of the project.

Reconnect

Can I connect to the stream again?

Recovery

Can I prove that my trading state is correct again?

Those are not the same question.

A reconnect can take seconds.

State recovery can require:

Event verification
+
State reconciliation
+
Position verification
+
Risk checks

Only after that should normal trading resume.

Why I'm building this

The more I work on automated Polymarket trading, the more interesting the infrastructure around the strategy becomes.

The strategy answers:

What should I trade?

The execution layer answers:

How should I place the order?

The execution verifier answers:

What actually happened?

The control plane answers:

Can I safely continue?

That separation is the direction I'm exploring across these projects.

Related Polymarket projects

Polymarket Trading Bot

Automated trading, execution, risk controls, and backtesting.

https://github.com/casatrickdev/polymarket-trading-bot

Polymarket Execution Verifier

Verifies the execution lifecycle across:

Order
 ↓
Fill
 ↓
Transaction
 ↓
Settlement
 ↓
Position

https://github.com/casatrickdev/polymarket-execution-verifier

Polymarket Trading Control Plane

Monitoring, state, reconciliation, risk, health, alerts, and recovery.

https://github.com/casatrickdev/polymarket-trading-control-plane

Together:

Trading Bot
    ↓
Execution
    ↓
Execution Verification
    ↓
State Reconciliation
    ↓
Control Plane
    ↓
Risk / Recovery

Final takeaway

A WebSocket reconnect can tell you:

“The connection is back.”

It cannot automatically tell you:

“The trading system is healthy again.”

The system may have missed events.

Local state may be stale.

Orders may be uncertain.

Positions may need reconciliation.

Risk may have changed.

So the recovery path I want to build around is:

DISCONNECT
    ↓
PAUSE
    ↓
RECONNECT
    ↓
RECONCILE
    ↓
VERIFY
    ↓
RISK CHECK
    ↓
RESUME

For an automated Polymarket trading bot, reconnecting is a networking problem. Recovering safely is a trading-system problem.

That's the distinction behind the Control Plane.

Polymarket Position Reconciliation: Keeping Trading Bot State in Sync

Casatrick | Polymrket Bot Dev — Mon, 28 Sep 2026 05:51:27 +0000

Your Polymarket trading bot says:

Position: +100

But the account actually holds:

Position: +40

Which one should the trading system trust?

This is a position reconciliation problem.

For an automated Polymarket trading bot, local state can become different from actual account state after:

partial fills
WebSocket disconnects
missed events
application restarts
delayed events
unexpected API responses

My approach is to treat reconciliation as a first-class part of the trading system rather than something added after execution fails.

The basic idea is:

Local State
     ↓
Remote State
     ↓
Compare
     ↓
Repair
     ↓
Verified State

This is one of the core ideas behind the Polymarket Trading Control Plane I'm building.

Why position state can become wrong

A simple trading bot often assumes that every event arrives correctly and that its local state always represents the account.

In reality, there are several places where state can diverge.

For example:

WebSocket disconnect
        ↓
Execution event missed
        ↓
Local state not updated
        ↓
Position becomes stale

The system may still be running.

The process may still be healthy.

The strategy may still be producing signals.

But its understanding of the current position can already be wrong.

The Control Plane is designed around making those conditions visible and controllable.

Local position vs actual position

Consider this simple example:

Local position:
+100

Remote position:
+40

The difference is:

-60

If the strategy uses the local value for its next decision, it is now calculating from incorrect state.

That can affect:

Position sizing
Exposure
Hedging
Risk limits
Available capital
Next orders

So the trading system needs to know not just:

“What does my local state say?”

but:

“Does my local state agree with the account?”

Position reconciliation is not just a database comparison

It is tempting to think of reconciliation as:

SELECT local_position
SELECT remote_position

if different:
    update

The problem is that a trading system has multiple related state domains.

A useful model is:

Orders
   ↓
Trades / Fills
   ↓
Positions
   ↓
Exposure
   ↓
Risk

The Control Plane explicitly keeps these concepts separate.

An order is what the strategy requested.

A fill is what actually executed.

A position is what the account holds.

Exposure is the risk created by that position.

If one of those layers is wrong, the downstream state can also become wrong.

The real problem: events can be missed

Real-time event streams are useful because automated trading systems need low-latency updates.

But an event-driven system cannot assume that every event will always arrive exactly when expected.

Imagine:

Order submitted
      ↓
Partial fill
      ↓
WebSocket disconnect
      ↓
Fill event missed
      ↓
WebSocket reconnect

The connection is back.

But the local position may still be wrong.

The system should not treat:

RECONNECTED

as equivalent to:

STATE VERIFIED

Those are different conditions.

Reconnect is not reconciliation

This distinction is central to the architecture.

A reconnect answers:

“Can I connect again?”

A reconciliation answers:

“Does my local state match the current remote state?”

The recovery flow should therefore look like:

WebSocket disconnect
        ↓
Trading = PAUSED
        ↓
Reconnect
        ↓
Read remote state
        ↓
Compare local state
        ↓
Repair discrepancies
        ↓
Verify position
        ↓
Verify risk
        ↓
Resume trading

The Control Plane's current recovery model explicitly includes reconnects, restarts, suspected event gaps, unexpected API responses, and state mismatches as reconciliation triggers.

A concrete position mismatch

Suppose the local system contains:

Market: BTC Up/Down

Local position:
+100

The remote account reports:

Remote position:
+40

A reconciliation report could become:

POSITION MISMATCH

Market: BTC Up/Down

Local:
+100

Remote:
+40

Difference:
-60

Status:
REQUIRES_RECONCILIATION

At this point, I don't want the strategy to continue creating more positions.

The system first needs to establish a verified state.

That is the purpose of the reconciliation layer.

What should trigger reconciliation?

A trading system doesn't need to reconcile only after something obviously breaks.

Useful triggers include:

WebSocket reconnect
Application restart
Suspected event gap
Unexpected API response
State mismatch

These are already part of the Control Plane's planned reconciliation model.

Conceptually:

Normal operation
      ↓
Real-time events
      ↓
Local state

Failure / uncertainty
      ↓
Reconciliation
      ↓
Verified state

That gives the system both speed and a recovery mechanism.

Reconciliation should compare more than positions

Suppose the position is correct, but an order is still unexpectedly open.

Or the fills are correct, but the local exposure calculation is wrong.

So a reconciliation process should eventually compare multiple dimensions:

Orders
  ↓
Fills
  ↓
Positions
  ↓
Exposure
  ↓
Risk

This is why the Control Plane's state model includes orders, trades, positions, exposure, PnL, and health as separate observable areas.

The goal is not merely:

“Position matches.”

It is:

“The trading state is internally consistent and verified.”

What should happen during a mismatch?

I would not allow the system to continue trading normally while critical state is unresolved.

A simplified control flow is:

Position mismatch
       ↓
Trading = PAUSED
       ↓
Reconcile
       ↓
Repair
       ↓
Verify
       ↓
Risk check
       ↓
Resume

This is consistent with the broader control-plane principle of making critical state visible and controllable before allowing additional risk.

Why pausing matters

Imagine the system believes:

Position = +40

but the real position is:

Position = +100

The strategy might see enough available capacity to add another 40.

The real account would then become:

+140

even though the trading system thought it would become:

+80

A state mismatch therefore isn't only a display problem.

It can become a risk problem.

That's why stale or inconsistent state should be able to block new trading.

Position reconciliation after a partial fill

Partial fills are a good example of why reconciliation matters.

Suppose:

Requested:
100

Filled:
40

Remaining:
60

The strategy intended 100.

The execution layer actually filled 40.

The remote position should reflect the actual fill, not the original intention.

The state flow becomes:

Order
 ↓
40 Fill
 ↓
Position +40
 ↓
Exposure calculation
 ↓
Risk check

If the local system instead assumes:

Position +100

then every downstream control is working from the wrong state.

This is why yesterday's partial-fill work connects directly to today's reconciliation problem.

Reconciliation after an application restart

Another common case is restarting the trading process.

Before the restart:

Local State
Orders:     ...
Positions:  ...
Exposure:   ...

After restarting, the application may only know what was persisted locally.

It should not blindly assume that the persisted state is still current.

A safer startup sequence is:

Application starts
        ↓
Load local state
        ↓
Read remote state
        ↓
Compare
        ↓
Repair discrepancies
        ↓
Verify risk
        ↓
Allow trading

This makes startup a recovery operation rather than simply:

“The process has started, so trading can start.”

Reconciliation after a WebSocket gap

Another example:

WebSocket
   ↓
Event A
   ↓
Disconnect
   ↓
Events B, C, D
   ↓
Reconnect

The application may know about A but not B, C, or D.

The system should have a way to establish the current state after reconnecting.

Conceptually:

Last known state
       ↓
Reconnect
       ↓
Remote state
       ↓
Compare
       ↓
Repair
       ↓
Verified state

This is one reason the project treats real-time events and reconciliation as complementary mechanisms rather than alternatives.

A state machine makes this easier to reason about

One useful way to express the operational state is:

HEALTHY
    ↓
DEGRADED
    ↓
PAUSED
    ↓
RECOVERING
    ↓
HEALTHY

For example:

WebSocket disconnect
        ↓
HEALTHY → DEGRADED
        ↓
Trading → PAUSED
        ↓
Reconnect
        ↓
Reconcile
        ↓
Verify
        ↓
RECOVERING
        ↓
HEALTHY

The Control Plane currently defines explicit health states including HEALTHY, DEGRADED, PAUSED, RECOVERING, and FAILED.

Reconciliation should be observable

A good reconciliation process should not silently modify state.

It should produce observable events.

For example:

RECONCILIATION_STARTED
RECONCILIATION_COMPLETED
STATE_MISMATCH
TRADING_PAUSED
TRADING_RESUMED

The broader Control Plane event model also includes:

ORDER_FAILURE
PARTIAL_FILL
MARKET_DATA_STALE
WEBSOCKET_DISCONNECTED
RISK_LIMIT_BREACHED
KILL_SWITCH_TRIGGERED

These events can feed dashboards, logs, alerts, and webhooks.

That makes reconciliation part of the system's operational history rather than a hidden database operation.

What happens when state cannot be verified?

This is an important case.

Sometimes reconciliation cannot immediately determine the correct state.

For example:

Local:
+100

Remote:
unknown

The system should be able to represent uncertainty.

Instead of assuming:

REMOTE = LOCAL

it can move into a controlled state:

UNKNOWN
    ↓
PAUSED
    ↓
RETRY / RECONCILE

The principle is:

Unverified state should not be treated as verified state.

That is especially important for systems that can place additional orders automatically.

The control plane around the trading bot

This is where the broader architecture comes together:

                 POLYMARKET
                      │
                      ▼
               Trading Bot
                      │
                Strategy
                      │
                  Execution
                      │
                      ▼
              Execution State
                      │
                      ▼
             ┌─────────────────┐
             │  CONTROL PLANE  │
             │                 │
             │ State           │
             │ Risk            │
             │ Health          │
             │ Reconciliation  │
             │ Alerts          │
             │ Recovery        │
             └────────┬────────┘
                      │
                      ▼
                Verified State

The Control Plane is not another trading strategy.

It is the operational layer around the trading system.

That is the purpose of the project.

A practical reconciliation checklist

Before allowing a trading bot to resume, the system should eventually be able to answer:

[✓] Market data is fresh
[✓] WebSocket is healthy
[✓] Orders are known
[✓] Fills are known
[✓] Positions match
[✓] Exposure is correct
[✓] Risk limits are satisfied
[✓] No unresolved critical mismatch
[✓] Trading can resume

This turns recovery from a vague concept into a sequence of verifiable conditions.

Testing position reconciliation

I would test reconciliation against explicit failure scenarios:

Scenario	Expected behavior
Position matches	Continue
Position mismatch	Pause and reconcile
Missed event	Detect and reconcile
Duplicate event	Avoid double-counting
Partial fill	Update actual quantity
Unknown order state	Reconcile
WebSocket disconnect	Degrade and recover
Application restart	Reload and reconcile
Stale data	Pause affected trading
Risk breach	Pause or kill

The Control Plane's planned failure scenarios already follow this kind of model.

Why this matters

A trading bot should not be considered healthy just because:

Process = running

A more useful definition is:

Process
   +
Connections
   +
State
   +
Risk
   +
Execution
   +
Verified Position

The system needs to know whether those pieces are consistent.

That is what makes position reconciliation an important part of automated trading infrastructure.

Final takeaway

The question isn't only:

“Is my bot running?”

It is:

“Does my bot know what the account actually looks like?”

A local position can become stale.

A WebSocket can disconnect.

An event can be missed.

An order can partially fill.

An application can restart.

When those things happen, the trading system needs a reliable path back to a verified state.

For me, that path is:

Local State
    ↓
Remote State
    ↓
Compare
    ↓
Repair
    ↓
Verify
    ↓
Risk Check
    ↓
Resume

That is the core idea behind the Polymarket Trading Control Plane I'm building.

Not another strategy.

An operational layer that helps an automated Polymarket trading system know when its state can be trusted—and when it should stop trading until it can.

Polymarket Partial Fills: How Automated Trading Bots Should Handle Them

Casatrick | Polymrket Bot Dev — Sun, 27 Sep 2026 05:10:38 +0000

An automated Polymarket trading bot requests 100.

Only 40 actually fill.

What should happen next?

A simple bot might treat the order as completed.

A production-oriented trading system cannot.

The system now has:

Requested: 100
Filled:     40
Remaining:  60

That changes the position, the exposure, the hedge, the next trade, and potentially the entire risk state.

This is why I think partial fills are a state-management problem, not just an order-management problem.

In this article, I'll walk through how I think about partial fills in an automated Polymarket trading system and why execution verification and reconciliation need to be separate parts of the architecture.

What is a partial fill?

A partial fill occurs when an order is executed for only part of its requested quantity.

For example:

Requested quantity: 100
Executed quantity:   40
Remaining quantity:  60

The strategy wanted 100.

The market gave the system 40.

Those are two different facts.

A trading bot that continues to reason about the original 100 as though it were executed is now operating with incorrect state.

The first rule is therefore:

Requested quantity and executed quantity must be tracked separately.

Why partial fills are dangerous for trading bots

Imagine a strategy generates:

BUY 100

The execution layer submits the order.

The market only fills:

Now the system has to answer:

Is the remaining 60 still resting?
Should the order be cancelled?
Should the remaining quantity be re-priced?
Is the position supposed to be hedged?
How much exposure actually exists?
Does the strategy still want the trade?
What happens if the remaining order never fills?

None of those questions can be answered correctly if the system stores only:

order.quantity = 100

The actual execution state needs to be explicit.

The execution state should be more than FILLED / NOT FILLED

A common simplification is:

SUBMITTED
    ↓
FILLED

Real execution is closer to:

INTENDED
    ↓
SUBMITTED
    ↓
ACCEPTED
    ↓
PARTIALLY_FILLED
    ↓
FILLED

But there are other outcomes:

REJECTED
CANCELLED
FAILED
RETRYING
UNKNOWN

And after execution:

FILLED
    ↓
TRANSACTION
    ↓
CONFIRMED
    ↓
SETTLED

That is why I prefer thinking about execution as a state machine.

INTENDED
   ↓
SUBMITTED
   ↓
ACCEPTED
   ↓
MATCHED
   ↓
PARTIALLY FILLED
   ↓
FILLED
   ↓
TX_PENDING
   ↓
CONFIRMED
   ↓
SETTLED

The exact state model will depend on the trading system, but the important idea is the same:

The trading system should represent what actually happened.

Partial fills change your risk

Consider a hedged trade.

Suppose the strategy expects:

Leg 1: 100
Leg 2: 100

But Leg 1 only fills 40.

The system does not have a 100-unit exposure on Leg 1.

It has 40.

That means a second leg sized for 100 could create an unintended position.

Instead:

Requested Leg 1
       ↓
     100
       ↓
Actual Fill
       ↓
      40
       ↓
Hedge calculation
       ↓
      40

This is why hedge logic should be based on actual execution, not intended execution.

The distinction is simple:

Requested size ≠ Filled size

and:

Filled size → actual exposure

The bot needs to track residual quantity

After a partial fill:

Requested: 100
Filled:     40
Remaining:  60

The remaining quantity should be explicit.

Conceptually:

remaining = requested - filled

But the trading system also needs to know what the remaining quantity means.

It could be:

60 resting on the book

or:

60 cancelled

or:

60 unknown

or:

60 requiring a retry

The quantity alone is not enough.

The state of the remaining quantity matters.

What happens when the second leg doesn't fill?

This is where partial fills become particularly important for arbitrage and hedged strategies.

Suppose the intended trade is:

Leg 1 → 100
Leg 2 → 100

But the result is:

Leg 1 → 100 filled
Leg 2 →   0 filled

The system now owns an unintended exposure.

A naive implementation might simply retry Leg 2.

That can be dangerous if the market moved.

The price may no longer support the original trade.

A more deliberate execution flow is:

Leg 1 executed
      ↓
Measure actual fill
      ↓
Check current market
      ↓
Check risk
      ↓
Attempt hedge
      ↓
Verify hedge
      ↓
Reconcile final position

The system should be able to choose among actions such as:

HEDGE
REPRICE
CANCEL
UNWIND
PAUSE

The correct action depends on the strategy and risk policy.

Partial fills and position reconciliation

This is where execution state meets account state.

Suppose your local system says:

Expected position: +100

But execution records say:

Filled: +40

And the account currently reports:

Actual position: +40

The system is consistent.

Now consider:

Expected position: +100
Filled: +40
Actual position: +25

That is a different problem.

Something else happened between execution and account state.

Now the trading system needs reconciliation.

A useful architecture is:

              ORDER
                ↓
             FILL(S)
                ↓
          Local Position
                ↓
        Position Reconciler
                ↓
          Remote Position
                ↓
             Verified

The point is not to assume that one event tells you the whole story.

Why WebSocket events aren't enough

Real-time events are essential for low-latency systems.

But a trading bot should not assume that every event will arrive exactly once and in perfect order.

Possible problems include:

disconnects
missed events
duplicated events
delayed events
application restart
API inconsistencies

That means the system needs two complementary mechanisms:

Real-time updates
       +
Reconciliation

Real-time events keep the system fast.

Reconciliation helps it recover when reality and local state diverge.

A safer recovery sequence

Imagine a partial-fill event happens during a WebSocket disconnect.

The bot reconnects.

It should not automatically decide:

“Everything is fine. Continue trading.”

A safer flow is:

WebSocket disconnect
        ↓
Trading = PAUSED
        ↓
Reconnect
        ↓
Rebuild / reload local state
        ↓
Reconcile orders
        ↓
Reconcile fills
        ↓
Reconcile positions
        ↓
Verify exposure
        ↓
Verify risk
        ↓
Resume trading

The key distinction is:

Reconnect is a network operation. Recovery is a trading-system operation.

Unknown execution state needs its own path

One of the most dangerous states is:

UNKNOWN

Suppose the application submits an order.

The network fails before the application receives the final response.

Now the system does not know whether the order:

was rejected
was accepted
partially filled
completely filled

Immediately submitting the same order again could create duplicate exposure.

So instead:

UNKNOWN
   ↓
Do not blindly retry
   ↓
Query / reconcile
   ↓
Determine actual state
   ↓
Continue according to policy

This is another reason I prefer an explicit execution-verification layer.

Execution verification

I’ve been building a separate Polymarket Execution Verifier around this problem.

The idea is to verify execution across multiple layers:

Order
  ↓
Fill
  ↓
Transaction
  ↓
Settlement
  ↓
Position

Instead of allowing the trading bot to assume:

ORDER = DONE

the verifier asks:

What actually happened?

Possible results include:

KNOWN
UNKNOWN
FAILED
SETTLED
INCONSISTENT

This makes execution verification an explicit component rather than something hidden inside a strategy.

Partial fills in a control-plane architecture

I think of the broader system like this:

                 POLYMARKET
                      │
                 Market Data
                      │
                      ▼
              ┌───────────────┐
              │ Trading Bot   │
              │               │
              │ Strategy      │
              │ Execution     │
              └───────┬───────┘
                      │
                      ▼
             Execution Verifier
                      │
            ┌─────────┴─────────┐
            ▼                   ▼
        Fill State          TX State
            │                   │
            └─────────┬─────────┘
                      ▼
                 Position
                      │
                      ▼
               Control Plane
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
      Risk         Health      Reconciliation
        │             │             │
        └─────────────┼─────────────┘
                      ▼
                   Recovery

The goal is to separate responsibilities.

Strategy

Decides what it wants to trade.

Execution

Attempts to place the order.

Execution verifier

Determines what actually happened.

Control plane

Determines whether the system should continue operating.

That separation becomes increasingly valuable as the trading system grows.

The most important invariant

For me, the key invariant is:

Actual Position
    =
Verified Executions
    =
Risk Calculation Input

At least, that should be the goal.

If those three things disagree, the system should stop treating its local state as trustworthy.

That leads to a simple operational rule:

When critical state is uncertain, reduce or stop new risk until state is verified.

Testing partial fills

Partial-fill handling should be tested explicitly.

For example:

Scenario	Expected behavior
Full fill	Mark execution complete
Partial fill	Track actual filled quantity
Remaining order open	Track residual quantity
Remaining order cancelled	Recalculate state
Partial hedge	Recalculate exposure
Unknown execution	Reconcile before retry
Duplicate event	Avoid double-counting
WebSocket reconnect	Reconcile
Position mismatch	Block trading
Settlement mismatch	Escalate / reconcile

The happy path is easy.

The failure paths are where the trading system needs engineering.

Building around the strategy

This is why I've become increasingly interested in the infrastructure around automated Polymarket trading.

A strategy can answer:

What should I trade?

But that doesn't answer:

How much actually filled?

or:

What position do I really have?

or:

Is it safe to place another order?

Those questions belong to the execution, state, risk, and control layers.

The architecture becomes:

Strategy
   ↓
Execution
   ↓
Verification
   ↓
State
   ↓
Risk
   ↓
Monitoring
   ↓
Recovery

That is the direction I'm exploring with the Polymarket Trading Bot, Execution Verifier, and Trading Control Plane projects.

Related projects

Polymarket Trading Bot

Automated trading, execution, risk management, and backtesting.

https://github.com/casatrickdev/polymarket-trading-bot

Polymarket Execution Verifier

Verify execution across orders, fills, transactions, settlement, and position state.

https://github.com/casatrickdev/polymarket-execution-verifier

Polymarket Trading Control Plane

Monitoring, state reconciliation, risk controls, health, alerts, and recovery.

https://github.com/casatrickdev/polymarket-trading-control-plane

Together:

Trading Bot
    ↓
Execution
    ↓
Partial Fill Handling
    ↓
Execution Verification
    ↓
State Reconciliation
    ↓
Risk / Monitoring
    ↓
Recovery

Final takeaway

A partial fill looks like a small execution detail.

It isn't.

Once an automated trading system starts managing real positions, a partial fill changes:

actual position
remaining quantity
exposure
hedge requirements
risk
execution state
what the strategy should do next

The key is not to make the system assume that an intended trade became a completed trade.

Instead:

Intent
  ↓
Execution
  ↓
Actual Fill
  ↓
Verified State
  ↓
Position
  ↓
Risk

A trading bot becomes much easier to reason about when it knows the difference between what it wanted, what it executed, and what it actually owns.

That's the problem I'm exploring with execution verification and trading-system infrastructure for Polymarket.

Polymarket Trading Bot: Execution, Risk Management, and Backtesting

Casatrick | Polymrket Bot Dev — Fri, 25 Sep 2026 05:42:26 +0000

Building a Polymarket trading bot is not only about finding a strategy that produces profitable signals.

The harder part starts after the signal.

A real automated trading system has to deal with changing order-book prices, partial fills, execution costs, open exposure, failed trades, stale data, repeated losses, gas availability, and the difference between what the bot thinks happened and what actually happened.

That is the problem I wanted to work on with Polymarket Trading Bot v3.2.

The project is an open-source automated trading system for Polymarket with strategy execution, risk management, execution protection, monitoring, and backtesting.

GitHub:
https://github.com/casatrickdev/polymarket-trading-bot

A Polymarket bot needs more than a trading strategy

A simple trading bot can look like this:

Market Data
    ↓
Strategy
    ↓
Buy / Sell

That is enough for a prototype.

A more complete automated trading system looks closer to:

Market Data
     ↓
Strategy Signal
     ↓
Risk Checks
     ↓
Position Sizing
     ↓
Protected Order
     ↓
Execution
     ↓
Position / Exposure Tracking
     ↓
Monitoring
     ↓
Recovery

The difference is important.

A strategy can be correct while the actual trade still goes wrong.

For example:

the price changes between signal generation and execution
an arbitrage leg fills only partially
fees eliminate the expected edge
exposure becomes larger than intended
a copied trade is already stale
the wallet does not have enough gas
the system continues trading after a sequence of losses

So the bot has to treat execution and risk as part of the trading system, not as optional additions.

What changed in v3.2?

The latest version focuses heavily on execution safety and risk controls.

The release includes fee-aware profit checks, price-protected orders, sequential arbitrage execution, improved hedging, stale-trade filtering, exposure caps, a wallet circuit breaker, backtesting, Polygon gas monitoring, and loss-streak protection.

The result is a system that tries to answer a bigger question than:

“Should I trade?”

It also asks:

“Can I safely execute this trade right now?”

1. Fee-aware Polymarket trading

A price difference is not automatically a profitable trade.

Execution costs matter.

The bot now calculates arbitrage and DipArb opportunities while accounting for:

taker fees
gas costs
minimum net-profit requirements

This means a signal can be rejected even when the gross price relationship looks attractive.

That is an important distinction for automated trading:

Gross Opportunity
       ↓
- Trading Fees
- Gas
       ↓
Net Opportunity
       ↓
Profit Threshold
       ↓
Execute / Skip

The strategy is therefore evaluated against the cost of actually trading rather than only the theoretical price difference.

2. Price-protected orders

One of the easiest ways for an automated trading system to behave unexpectedly is to submit an order without sufficient price protection.

Markets move.

The bot now derives worst-price caps or floors from the live order book before sending market orders.

The idea is straightforward:

Live Order Book
      ↓
Current execution conditions
      ↓
Worst acceptable price
      ↓
Order

Instead of treating the market price as static, the execution layer explicitly accounts for the price at which the system is still willing to trade.

3. Sequential arbitrage execution

Arbitrage introduces another problem.

Suppose the system wants to buy both YES and NO.

A naive implementation might submit both orders at approximately the same time.

That creates a race.

What happens if one order fills and the other does not?

Now the bot has exposure that was not part of the intended position.

In v3.2, the arbitrage legs execute sequentially, with unwind and reconciliation logic around partial fills.

Conceptually:

YES / Leg 1
    ↓
Actual Fill
    ↓
Validate
    ↓
NO / Leg 2
    ↓
Actual Fill
    ↓
Reconcile

The system is no longer treating the two orders as if they were guaranteed to fill together.

4. Handling partial fills

Partial fills are one of those problems that look small in a prototype and become important in an automated system.

The intended position might be:

100 shares

But actual execution could be:

60 filled
40 remaining

That means the system needs to know what it actually owns rather than what it originally requested.

The bot's execution logic therefore works around:

actual fills
incomplete legs
residual exposure
reconciliation
unwind behavior

This is one reason execution state needs to be treated separately from strategy state.

5. DipArb execution protection

The DipArb strategy watches short-duration crypto markets for rapid price movements.

The current implementation includes:

BTC and ETH 15-minute markets
rapid price-move detection
a first-leg entry
an opposite-side hedge
shorter hedge timeout
stop-loss behavior
1:1 hedge requirements based on actual fills

The important engineering point is that the hedge is not based only on the intended order quantity.

It is tied to what actually filled.

That matters because:

Requested quantity ≠ Actual quantity

in a real execution environment.

6. Filtering stale copy-trading signals

Copy trading creates another timing problem.

A profitable-looking wallet transaction may already be several seconds old by the time the bot sees it.

v3.2 skips stale whale prints and re-quotes the entry against the current market, with spread, premium, and liquidity checks.

The flow becomes:

Observed Wallet Trade
        ↓
Freshness Check
        ↓
Current Order Book
        ↓
Spread / Liquidity Checks
        ↓
Entry Decision

This prevents the system from blindly treating an old trade as a current market opportunity.

7. Six-layer risk management

The trading strategy is only one part of capital protection.

The bot now uses six layers of risk controls:

Protection	Default
Daily loss limit	5%
Monthly loss limit	15%
Maximum drawdown	25%
Total-loss halt	40%
Loss-streak pause	6 losses
Total exposure cap	30%

These controls are intended to operate at different levels.

For example:

Trade
  ↓
Position Limit
  ↓
Market Exposure
  ↓
Loss Streak
  ↓
Daily Loss
  ↓
Drawdown
  ↓
Total Loss

This creates several opportunities to stop trading before one failure becomes a much larger problem.

8. Dynamic position sizing

Position size is also connected to recent performance.

The default system starts at 2% of configured capital and changes position size according to consecutive wins or losses, subject to the configured cap.

The basic concept is:

Winning streak
     ↓
Potentially larger size

Losing streak
     ↓
Smaller size

There is also a minimum position-size floor so the system does not continuously create tiny orders that are difficult to manage.

9. Exposure limits

Another distinction between a simple bot and a larger trading system is portfolio state.

It is not enough to know:

“I have a new signal.”

The system also needs to know:

“How much capital is already exposed?”

v3.2 tracks total open exposure and per-market exposure and blocks new positions once configured limits are reached.

For example:

Capital
   ↓
Open Position A
Open Position B
Open Position C
   ↓
Total Exposure
   ↓
Risk Check
   ↓
Allow / Reject New Trade

This prevents individual signals from being evaluated independently when they are actually part of the same portfolio.

10. Trading dashboard

The bot includes a dashboard for monitoring the trading system in real time.

The dashboard exposes:

live or dry-run mode
USDC and Polygon balances
session PnL
strategy state
risk limits
drawdown
open exposure
win/loss streak
halted or paused state

It also includes controls such as:

strategy toggles
emergency stop
panic sell
live / dry-run switching

For automated trading, visibility is part of the system.

A bot that trades without an operator being able to understand its state is difficult to debug when something goes wrong.

11. Backtesting the execution layer

The repository also includes a JSONL order-book replay backtesting harness with fee and gas modeling.

Run:

npm run backtest

The purpose is not simply to ask:

“Would this strategy have made money?”

It is also useful for examining how execution logic behaves against recorded market conditions.

That makes it possible to test things such as:

execution assumptions
order-book conditions
fees
gas
strategy behavior
position sizing

A backtest that ignores execution costs can produce results that are very different from what happens in a live market.

12. Gas and operational protection

Trading logic can also fail because of infrastructure.

The bot monitors Polygon gas balance and can pause trading when the balance falls below the configured minimum.

There is also a wallet circuit breaker for copy trading.

After repeated failures, a wallet can be disabled for a cooldown period.

These controls are examples of a broader principle:

Operational failures are trading risks too.

The four strategies

The current bot includes four trading modes.

Arbitrage

Looks for opportunities where the combined YES and NO prices satisfy the configured arbitrage condition.

DipArb

Looks for rapid moves in short-duration BTC and ETH markets and attempts a hedged entry.

Smart Money

Filters selected Polymarket traders using performance and consistency requirements before copying trades.

Direct Trading

Provides manual execution tools including FOK orders and quick trading controls.

The complete strategy configuration is available in the repository.

Getting started

Clone the repository:

git clone https://github.com/casatrickdev/polymarket-trading-bot
cd Polymarket-trading-bot

Install dependencies:

npm install

Build the dashboard:

cd dashboard
npm install
npm run build
cd ..

Create your environment file from .env.example.

For initial testing, use:

DRY_RUN=true

Then start the bot:

npx tsx bot-with-dashboard.ts

The project documentation contains the full configuration and setup instructions.

Why I built it this way

There is a common tendency when building trading bots to spend most of the engineering effort on the strategy.

The strategy is the interesting part.

But once the system is actually running, many of the difficult problems move somewhere else:

Did the order really fill?
How much actually filled?
Is the position state correct?
Is the current market data fresh?
How much capital is exposed?
Did the transaction complete?
Should the system continue trading after repeated failures?

These are infrastructure problems.

That is why this project is increasingly focused on the layer around the strategy:

Strategy
   +
Execution
   +
Risk
   +
State
   +
Monitoring
   +
Recovery

For me, that is what makes a Polymarket trading bot an actual trading system rather than just a script that sends orders.

Open source

The complete project is available on GitHub:

https://github.com/casatrickdev/polymarket-trading-bot

The repository includes the bot, dashboard, configuration examples, documentation, and backtesting tooling.

Final thoughts

A Polymarket bot does not become reliable simply because its strategy works.

The system also needs to control execution, manage exposure, respond to failures, track actual fills, and know when it should stop trading.

That is the direction of v3.2:

less “just place the trade,” more “know exactly what is happening around the trade.”

⚠️ Trading involves risk. This software does not guarantee profits. Always test carefully and never trade more than you can afford to lose.

Building a Polymarket Trading Control Plane: State, Risk, and Recovery

Casatrick | Polymrket Bot Dev — Wed, 23 Sep 2026 06:17:13 +0000

A Polymarket trading bot can be connected, receiving market data, submitting orders, and still be unsafe to operate.

The problem isn't always the strategy.

It can be the system around the strategy.

A production trading system needs to know:

what orders are actually open
what has actually filled
what positions are actually held
whether market data is still fresh
whether local state matches remote state
whether risk limits are still satisfied
whether the system should be allowed to place another order

That leads to a different way of thinking about a trading bot.

Instead of:

market data
    ↓
strategy
    ↓
  order

I want the architecture to look more like:

market data
    ↓
event processing
    ↓
  state
    ↓
  risk
    ↓
execution
    ↓
reconciliation
    ↓
monitoring
    ↓
recovery

I'm building a small Polymarket Trading Control Plane around that idea.

The goal is not another trading strategy.

The goal is to build the operational layer that allows a strategy to run with a much clearer understanding of its own state.

Why build a control plane?

When you're prototyping a trading bot, it's easy to keep everything in one process.

Something like:

while True:
    market = get_market_data()
    signal = strategy(market)

    if signal:
        place_order(signal)

This is fine for exploring an idea.

But once the system has real orders and positions, the questions become different.

What happens when the WebSocket disconnects?

What happens when an order partially fills?

What happens when the process restarts?

What happens when a response is delayed?

What happens when local state says one thing and the remote state says another?

These are operational problems, not strategy problems.

And they become more important as the amount of automation increases.

GitHub: Polymarket Trading Control Plane

The first principle: local state is not reality

Suppose a strategy submits:

BUY 100

The local application records:

order_id = 123
status   = OPEN
size     = 100
filled   = 0

Then 40 contracts fill.

The real state is now:

status    = PARTIALLY_FILLED
filled    = 40
remaining = 60

Now imagine the process misses that update.

The process may still believe:

filled = 0
remaining = 100

Nothing has necessarily crashed.

The program is still running.

The strategy is still calculating.

The system just has the wrong state.

That is much more dangerous than a visible exception because the system can continue making decisions from incorrect information.

WebSockets are useful, but they are not your entire state model

Polymarket's current Rust CLOB client supports WebSocket streams for orderbooks, prices, and authenticated user order/trade events. The current V2 client also exposes Data and Gamma API integrations and other CLOB functionality.

That's exactly what a low-latency trading system needs.

But I don't want my architecture to assume:

WebSocket connected
=
state is correct

Those are two different conditions.

I think about the system as having two paths.

                 POLYMARKET
                     │
          ┌──────────┴──────────┐
          │                     │
      WebSocket              API / Reads
          │                     │
          ▼                     ▼
   Event Processor        Reconciliation
          │                     │
          └──────────┬──────────┘
                     ▼
                Local State

The first path is optimized for speed.

The second path is responsible for validating and repairing state.

State should be explicit

One of the first design decisions in the control plane is to separate the major concepts.

I don't want one giant BotState object that mixes everything together.

Instead:

Orders
   ↓
Trades / Fills
   ↓
Positions
   ↓
Exposure
   ↓
Risk

Each layer answers a different question.

Orders

What did the system request?

order_id
market
side
price
requested_size
status

Fills

What actually executed?

trade_id
order_id
executed_size
execution_price
timestamp

Positions

What do we currently hold?

market
size
average_entry
realized_pnl
unrealized_pnl

Exposure

What risk is currently on the book?

market_exposure
total_exposure
concentration

Risk

Should the system be allowed to place another order?

allowed
paused
degraded
killed

Keeping these concepts separate makes the system easier to reason about.

Model order lifecycles explicitly

Another common mistake is treating an order as simply:

OPEN

or:

CLOSED

Real execution is more complicated.

A simplified lifecycle can look like:

INTENDED
   ↓
SUBMITTED
   ↓
ACCEPTED
   ↓
MATCHED
   ↓
FILLED

With other possible paths:

SUBMITTED → REJECTED
SUBMITTED → CANCELLED
MATCHED   → RETRYING

The exact lifecycle depends on the interface and execution path, but the architecture should allow for intermediate states.

This is particularly relevant with Polymarket's evolving asynchronous execution model. The current V2 Rust client changelog notes that matched orders can carry tradeIDs rather than immediately returning transaction hashes, and the client can resolve those hashes afterward.

That is an important architectural lesson:

An accepted order isn't necessarily the end of the execution lifecycle.

Event processing should be idempotent

Real-time systems eventually see duplicates, reconnects, retries, and restarts.

So event processing needs to be safe to repeat.

A simplified version:

def process_event(event):
    if already_processed(event.id):
        return

    apply_transition(event)
    mark_processed(event.id)

The production implementation can use a stronger persistence and transaction model, but the principle remains:

Processing the same event twice should not create two executions.

This becomes even more important if the application needs to replay events after a restart.

Reconciliation is the recovery mechanism

The main job of reconciliation is simple:

Compare what the application believes with what the remote system currently reports.

For example:

LOCAL

Order 123
filled = 0

REMOTE

Order 123
filled = 40

The reconciler identifies:

difference = 40

and creates an explicit discrepancy:

STATE_MISMATCH

order_id: 123
local_filled: 0
remote_filled: 40
action: repair

I don't want this to be a hidden correction somewhere inside the strategy.

It should be its own subsystem.

Reconciliation after a reconnect

A reconnect shouldn't automatically mean:

connected
→ resume trading

I'd rather use:

disconnect
    ↓
reconnect
    ↓
load persisted state
    ↓
read current remote state
    ↓
compare
    ↓
repair
    ↓
verify risk
    ↓
resume

That extra step is where a lot of production safety comes from.

The same pattern applies after a process restart.

process starts
    ↓
load state
    ↓
synchronize
    ↓
reconcile
    ↓
validate
    ↓
trade

Recovery becomes part of normal operation instead of an emergency patch.

The control plane should be able to stop trading

One of the most useful ideas in this project is that trading permission should be separate from the strategy.

For example:

Strategy says:
BUY

doesn't necessarily mean:

System says:
ALLOW

The flow becomes:

Strategy signal
      ↓
Risk check
      ↓
Health check
      ↓
State check
      ↓
Execution permission

If the system detects a critical issue:

state mismatch
market data stale
risk limit exceeded
execution failures

the answer can be:

TRADING_PAUSED

This is much safer than forcing every strategy to implement its own emergency behavior.

A simple risk model

The first version doesn't need a complicated risk engine.

A few explicit limits already create a useful safety layer.

For example:

max_position_size: 500
max_market_exposure: 1000
max_total_exposure: 5000
max_daily_loss: 250
max_consecutive_failures: 5
max_market_data_age_ms: 5000

Then the decision engine can be:

              RISK CHECK
                  │
       ┌──────────┼──────────┐
       │          │          │
 position     exposure     data age
   limit        limit        limit
       │          │          │
       └──────────┼──────────┘
                  │
          ┌───────┴────────┐
          │                │
        SAFE             UNSAFE
          │                │
       ALLOW             PAUSE

The important part is that the rules exist independently from the trading strategy.

That makes them reusable.

Kill switch

Every automated trading system should have a simple way to stop placing new orders.

The control plane should expose something like:

PAUSE
RESUME
KILL
RECONCILE

A kill switch might be triggered by:

operator action
daily loss threshold
abnormal exposure
persistent state mismatch
repeated execution failure
severe market-data staleness

Conceptually:

               KILL SWITCH
                    │
                    ▼
             STOP NEW ORDERS
                    │
                    ▼
             FREEZE STRATEGY
                    │
                    ▼
              ALERT OPERATOR

The exact behavior around existing positions should be configurable.

The important thing is that a runaway strategy shouldn't require the developer to manually terminate the process.

Health is more than uptime

A process being alive doesn't mean a trading system is healthy.

I want health to include things like:

WebSocket connection
Market-data freshness
Order-stream freshness
API availability
Event processing latency
Last reconciliation
Position consistency
Risk state

A useful state might look like:

SYSTEM: DEGRADED

Market data:          OK
Order stream:         OK
API connectivity:     OK
Position state:       MISMATCH
Last reconciliation:  38s ago
Risk state:           WARNING
Trading:              PAUSED

That's much more actionable than:

process = running

Observability should follow the trading lifecycle

The system should eventually be able to answer:

What happened to this order?

A good execution timeline might look like:

10:00:01.120  strategy signal
10:00:01.132  risk approved
10:00:01.145  order submitted
10:00:01.180  order accepted
10:00:01.240  partial fill 40
10:00:01.242  position updated
10:00:01.245  websocket disconnected
10:00:03.101  websocket reconnected
10:00:03.120  reconciliation started
10:00:03.141  state mismatch detected
10:00:03.150  state repaired
10:00:03.170  trading resumed

This is incredibly useful for debugging.

It's also useful for research.

And eventually it can become useful for post-trade analysis.

Why replay matters

There's another reason to persist events.

Once the system stores important state transitions, you can replay them.

historical events
        ↓
event replay
        ↓
rebuild state
        ↓
inspect behavior

That gives the same infrastructure several uses:

debugging
recovery
backtesting
incident analysis
strategy research
simulation

A trading system that can replay its own decisions is much easier to understand than one that only stores the final PnL.

A small architecture

The first version of the project is intentionally small.

polymarket-trading-control-plane/

crates/
├── ingest/
├── events/
├── state/
├── reconcile/
├── risk/
├── health/
├── alerts/
└── control/

examples/
├── monitor/
├── reconcile/
└── simulated_failure/

tests/
├── state/
├── reconciliation/
├── risk/
└── recovery/

The core flow:

                 POLYMARKET
                     │
          ┌──────────┴──────────┐
          │                     │
      WebSocket               APIs
          │                     │
          ▼                     ▼
   Event Ingestion       Reconciliation
          │                     │
          └──────────┬──────────┘
                     ▼
                 State Store
                     │
           ┌─────────┼─────────┐
           ▼         ▼         ▼
         Risk      Health    Alerts
           │         │         │
           └─────────┼─────────┘
                     ▼
               Control Plane
                     │
                     ▼
                Strategy /
                Execution

This isn't intended to become a full trading platform on day one.

The objective is to make a few critical problems explicit and testable.

Failure scenarios I want to test

A useful test suite should simulate more than successful trades.

For example:

WebSocket disconnect

disconnect
→ reconnect
→ reconcile
→ resume

Partial fill

order size = 100
fill = 40
remaining = 60

Duplicate event

event 1001
event 1001

result:
one state transition

Missed event

1001
1002
1004

detect gap
→ reconcile

Process restart

persisted state
→ process restart
→ reload
→ reconcile
→ continue

Risk breach

exposure > limit
→ trading paused

Stale market data

last update > threshold
→ affected strategy disabled

These scenarios are more valuable to me than simply showing that an order can be submitted successfully.

Where this fits in a trading system

The control plane isn't the strategy.

It's the layer that protects the strategy.

That means different strategies can sit above the same infrastructure:

             STRATEGIES

     momentum   arbitrage   market making
          \        |        /
           \       |       /
            ▼      ▼      ▼
        ┌───────────────────┐
        │   CONTROL PLANE   │
        │                   │
        │ state             │
        │ reconciliation    │
        │ risk              │
        │ health            │
        │ recovery          │
        └─────────┬─────────┘
                  │
                  ▼
             EXECUTION
                  │
                  ▼
              POLYMARKET

That's the direction I find more interesting.

The strategy can change.

The operational infrastructure can remain.

Why I'm building this

I've spent a lot of time looking at the strategy side of automated Polymarket trading.

But the more realistic the system becomes, the more obvious the engineering problems around the strategy become.

A profitable signal doesn't solve:

stale state
partial fills
reconnects
inconsistent positions
risk breaches
operational failures

Those need their own architecture.

And that's the part I want to explore here.

The bigger lesson

The most dangerous trading-system failure isn't always a crash.

A crashed process is obvious.

A process that keeps running while believing the wrong thing is much harder to detect.

That's why I think a serious Polymarket trading system needs more than:

signal
→ order
→ profit

It needs:

market data
→ events
→ state
→ reconciliation
→ risk
→ execution
→ monitoring
→ recovery

The strategy answers:

What should I do?

The control plane answers:

Can I safely do it right now?

And the reconciliation layer answers the question underneath both:

Do I actually know what state the system is in?

That's the problem this project is designed to solve.

What's next

The next step is to make the event stream replayable.

Once important order, fill, position, risk, and reconciliation events can be stored and replayed, the same infrastructure can support:

debugging
historical analysis
recovery
simulation
backtesting
strategy research

That's when the control plane becomes more than a monitoring tool.

It becomes part of the trading system itself.

This project focuses on trading-system infrastructure, reliability, and operational controls. Proprietary trading strategies and implementation details are intentionally omitted.