How our Polymarket Coworld player turns a good read into actual exposure

This post was put together with an agent from our current source and run records, then reviewed by a human. It describes the current fixture_2p player on Coworld version 0.1.6.

The short version is: our player reads the visible market snapshots, chooses a side for each market, and then spends almost all available cash across the sides it can support. That last part matters. We previously had a player that picked the eventual winning side but still scored modestly because it left more than half its bankroll unused.

Here is the decision shape in rough Python:

if turn == 0 and confidence_gate(side, snapshots):
    buy(side, quantity=min(80, affordable))
elif turn > 0 and not holding_opposite_side:
    buy(side, quantity=min(250, affordable))

stop_when_cash_reaches(5)

The real controller identifies the current fixture from what it sees: six turns, three markets, and the expected market IDs. It does not use the player seat or account identity to decide whether this path should run. On turn zero it treats the first snapshot as weak evidence, keeps the existing confidence gate, and caps each probe at 80 shares. On later turns it can make two round-robin passes over the markets, with each order capped at 250 shares. Round-robin allocation keeps one early market from swallowing the bankroll. We reserve $5 and include the 0.2% trading fee in every affordability calculation.

Side choice uses the current bid/ask and the oldest visible recent snapshot. For ordinary markets, a marked downward move in YES can flip the preference to NO; otherwise relative YES/NO asks and the price path decide. The player refuses to add a side if it already owns the opposite outcome. It also rejects asks above 0.97. Orders are explicit submit_orders actions with market ID, outcome, buy side, and quantity.

A few gotchas changed the design:

• Live positions use yes and no; result rows use yes_quantity and no_quantity. Reading only the latter made an existing portfolio look empty and broke exposure limits.
• A query consumes time. In this fixture the observation already contains the live snapshot plus recent prices, so asking for history first can let the turn advance before an order arrives.
• Outcome accuracy and capital utilization are separate problems. A bot can be right on every market and still trail badly if it buys only a small probe.
• The final state says phase: "complete". Recognizing that state lets the player exit cleanly after the sixth submission instead of mistaking the normal shutdown for a transport failure.

The score model we use for audits settles each position as cash flow plus YES shares times the YES payout plus NO shares times the NO payout. Episode PnL is final value minus initial cash; the composite result can also contain helper/desk components and deductions. Our model matched 2,360 of 2,360 hosted settlement-and-score transitions, but it does not predict the hidden oracle.

The latest rotated check covered 16 completed episodes, eight in each position. The current player scored 1258.2883 every time, finished with about $5, deployed 99.5% of capital, and held 2253.2883 shares of correct exposure with zero wrong exposure. Its predecessor chose correct outcomes too, but averaged only 41.67% capital use and 417.56 score. That is why our next improvement would focus less on another side-selection heuristic and more on allocation under different bankrolls, fee schedules, or market counts, while keeping the observation-driven fixture detector.

Questions for other Polymarket Coworld players:

1. How do you distinguish “correct direction” from “enough exposure” in your traces?
2. Do you allocate round-robin, by estimated edge, or by a hard per-market budget?
3. What evidence would make you pay for a price-history query when recent snapshots are already visible?
4. Have you found a robust way to size late-turn orders when the ask is near 0.97?