Unified SDK gaps for production migration: threshold-safe taker FAK semantics and missing user stream events

[kevinwtl]

Summary

We are evaluating the official Python client (polymarket-client==0.1.0b7) for migrating a live trading system from the legacy CLOB client. The main production migration blocker on our side is threshold-safe taker FAK semantics.

I also include one user-stream observation below as a request for guidance, but I no longer want to overstate that point publicly as a confirmed SDK gap because it may still be a usage or subscription-shape issue on our side.

1. Market-order FAK does not expose explicit worst-price / threshold semantics

Current legacy path uses an explicit threshold-safe market order equivalent to:

MarketOrderArgsV2(
    token_id=...,
    amount=...,
    side=BUY,
    price=threshold_price,
    order_type=FAK,
)

In the unified SDK, AsyncSecureClient.create_market_order / place_market_order expose:

• amount
• shares
• max_spend
• order_type (FAK / FOK)

but no explicit price, threshold_price, or limit_price.

We inspected the SDK source and found that market orders resolve an estimated market price internally, and max_spend only adjusts BUY amount for fees/total spend after that price is chosen. That does not appear to be equivalent to a signed worst-price guard.

Questions:

• Is there currently any supported way in py-sdk to express threshold-safe taker FAK semantics equivalent to the legacy client's explicit price cap?
• If not, is explicit price / threshold_price / limit_price support planned for market FAK orders?

2. Secondary observation: unified user stream guidance

In one controlled live smoke test, we observed legacy CLOB user WS events for live taker orders while the unified user stream produced 0 events for the same test window.

However, I want to be careful here: we have not concluded yet that this is necessarily an SDK defect. It may still be a usage issue, subscription-shape issue, or a misunderstanding on our side.

So the narrower question is:

• Is there any recommended or required subscription pattern for authenticated user events beyond UserSpec() or UserSpec(markets=[condition_id]) when validating live taker fills?

Why this matters

The main migration blocker is the first item:

• without threshold-safe taker semantics, migrated market FAK orders weaken execution safety

The second item is currently just a request for implementation guidance while we continue testing.

Happy to provide more concrete reproduction details if useful.

[cesarenaldi]

Appreciate the careful writeup here.

I checked both points against main. I think we’ve already addressed both, but the fixes have not been released to PyPI yet, so they would not be present in polymarket-client==0.1.0b7.

For the market-order threshold case, #105 added protected market orders. The equivalent to the legacy threshold price is now:

await client.place_market_order(
    token_id=token_id,
    side="BUY",
    amount=amount,
    max_price=threshold_price,
    order_type="FAK",
)

For sells, use min_price:

await client.place_market_order(
    token_id=token_id,
    side="SELL",
    shares=shares,
    min_price=threshold_price,
    order_type="FAK",
)

When those are provided, the SDK uses that price for the signed order instead of estimating from the book.

For the user stream point, #103 changed UserSpec() so broad user subscriptions omit the markets filter instead of sending markets: []. That should cover the same issue as #102.

We’ll publish these in the next beta. Once that’s out, I’d be interested to hear if it lines up with your migration tests.

[cesarenaldi]

@kevinwtl this is now available in https://pypi.org/project/polymarket-client/0.1.0b8/. Can you please verify and let me know?

[kevinwtl]

Thanks, confirmed on our side.

[kevinwtl]

Closing this now. Thanks again.