Market orders: taker amount rounded to tick precision (5-6 decimals) but API caps it at 4 — orders rejected

[furcabet]

Package: @polymarket/clob-client-v2@1.0.8 (latest)
Affected code: getMarketOrderRawAmounts in src/order-builder/helpers (both BUY and SELL branches)

Summary

For market orders, getMarketOrderRawAmounts rounds the taker amount using the tick-size precision from ROUNDING_CONFIG (amount: 5 for tick 0.001, amount: 6 for 0.0001). But the CLOB API only accepts market-order amounts with maker ≤ 2 decimals and taker ≤ 4 decimals, so whenever the rounded taker ends up with a non-zero 5th/6th decimal the order is rejected server-side:

invalid amounts, the market buy orders maker amount supports a max accuracy of 2 decimals, taker amount a max of 4 decimals

The client itself produces the invalid payload, so there is nothing an SDK consumer can do about it short of patching the package (the rounding happens inside createMarketOrder/buildMarketOrderCreationArgs right before signing).

Reproduction

// node >= 18, after `npm i @polymarket/clob-client-v2@1.0.8`
const { buildMarketOrderCreationArgs } = await import(
  './node_modules/@polymarket/clob-client-v2/dist/order-builder/helpers/buildMarketOrderCreationArgs.js'
)
const { ROUNDING_CONFIG } = await import(
  './node_modules/@polymarket/clob-client-v2/dist/order-builder/helpers/roundingConfig.js'
)

// BUY $5 at 0.998 on a 0.001-tick market
const buy = await buildMarketOrderCreationArgs(
  '0x0000000000000000000000000000000000000001',
  '0x0000000000000000000000000000000000000001',
  0,
  { tokenID: '1', amount: 5, price: 0.998, side: 'BUY' },
  ROUNDING_CONFIG['0.001']
)
console.log(buy.takerAmount) // 5010020 = 5.01002 shares -> 5 decimals, rejected

// SELL 7.77 shares at 0.998
const sell = await buildMarketOrderCreationArgs(
  '0x0000000000000000000000000000000000000001',
  '0x0000000000000000000000000000000000000001',
  0,
  { tokenID: '1', amount: 7.77, price: 0.998, side: 'SELL' },
  ROUNDING_CONFIG['0.001']
)
console.log(sell.takerAmount) // 7754460 = 7.75446 USDC -> 5 decimals, rejected

Math: 5 / 0.998 = 5.010020… → roundDown(…, 5) = 5.01002 (5 decimals). Any price with 3+ significant decimals routinely produces this; it only slips through when the 5th decimal happens to be zero.

The 2/4-decimals cap appears to be specific to market orders (the server error says "the market buy orders …"): limit orders built by getOrderRawAmounts use the same tick precision (5–6 decimals) and are accepted fine.

Suggested fix

Cap the taker amount at 4 decimals (round down, so the order stays marketable and never asks for more than the fair amount) in both branches of getMarketOrderRawAmounts:

if (decimalPlaces(rawTakerAmt) > 4) rawTakerAmt = roundDown(rawTakerAmt, 4);

We are running exactly this as a local patch on top of 1.0.8 and rejections disappeared. Happy to open a PR if useful.

[lushan888]

I can fix this. The issue is in getMarketOrderRawAmounts — after the rounding logic, taker amounts can exceed 4 decimals. Fix: cap rawTakerAmt at 4 decimals before parseUnits.

Wallet (Base): 0xaa9e4971e0973065513b18dEF9eC06Eb1F39D7A2

[osr21]

Confirmed + workaround

Hit this in PolyWatch when placing market orders on fine-tick markets. The bug is in getMarketOrderRawAmounts — the taker is rounded to tick precision (5–6 decimal places for 0.001/0.0001 tick markets) but the CLOB API enforces taker ≤ 4 decimal places.

Workaround: Truncate the taker amount to 4 decimal places before building the order:

function truncate4(n: number): number {
  return Math.floor(n * 10_000) / 10_000;
}

// Before createMarketOrder, clamp the size:
const safeSize = truncate4(desiredSize);
const order = await client.createMarketOrder({
  tokenID,
  amount: safeSize,
  side,
  worstPrice,
});

Note: Math.floor (truncation) rather than Math.round prevents the truncated value from rounding up and potentially exceeding the desired exposure.

Root fix location (for the team): src/order-builder/helpers.ts in the BUY and SELL branches of getMarketOrderRawAmounts — change the taker rounding from ROUNDING_CONFIG[tickSize].amount to Math.min(ROUNDING_CONFIG[tickSize].amount, 4), or add a dedicated TAKER_MAX_DECIMALS = 4 constant.

Related: the same issue affects the Rust v2 client (#87 equivalent in rs-clob-client-v2).

[osr21]

Confirming this is still reproducible on @polymarket/clob-client-v2@1.0.8.

The precision mismatch table:

| Tick size | `ROUNDING_CONFIG.amount` (current) | API max decimals | Result |
|-----------|--------------------------------------|-----------------|--------|
| `0.01`  | 2                                    | 4               | ✅ OK  |
| `0.001` | 5                                    | 4               | ❌ Rejected |
| `0.0001`| 6                                    | 4               | ❌ Rejected |

The fix in PR #88 is correct. An additional defensive guard worth adding is clamping at the call site in `getMarketOrderRawAmounts`:

```ts
const MAX_TAKER_DECIMALS = 4; // CLOB API hard limit

// BUY branch
const takerAmount = parseFloat(
roundDown(worstCaseFill, Math.min(tickPrecision, MAX_TAKER_DECIMALS))
);

// SELL branch  
const takerAmount = parseFloat(
roundDown(worstCaseFill, Math.min(tickPrecision, MAX_TAKER_DECIMALS))
);
```

This guards against future `ROUNDING_CONFIG` changes re-introducing the regression without requiring a coordinated update to both `ROUNDING_CONFIG` and the calculation site.

Also worth documenting in the README: the CLOB API enforces a hard 4-decimal cap on taker amounts for market orders, independent of tick size. This is not obvious from the API docs and is the root cause of confusing 400 rejections with no error body explaining the precision issue.

[CrisisAlpha]

Confirming the diagnosis from a production integration, and adding one adjacent footgun.

The venue rule is global for market orders: maker ≤ 2 decimals, taker ≤ 4 decimals (the 400 quotes it verbatim), while ROUNDING_CONFIG scales amount precision with tick size (5–6 decimals on fine ticks) — so fine-tick market orders sign a taker the API can never accept. Capping the taker at 4 decimals before parseUnits, as proposed above, matches what we ship.

What we do in production, which also sidesteps a second class of rejects:

• route FOK/FAK BUYs through createMarketOrder with amount = USD to spend, floored to cents (Math.floor(x*100)/100) — the "maker amount supports a max accuracy of 2 decimals" reject is exactly what you get if a computed price × size lands sub-cent;
• pass an explicit price cap — bonus: it skips calculateMarketPrice's orderbook fetch, so order building stays fully offline.

The adjacent footgun once fills start working: a market BUY spends fixed USD and receives a variable number of shares. Our first live fill recorded the requested size (8 shares) while the venue filled amount / avg-price = 9.4488 shares — reconciliation drift on day one. Read size_matched from the POST response, or treat GET /data/order/<id> as authoritative; don't persist the requested size.

[osr21]

Good additions. A few extensions.

SELL side is the mirror — different field, same floor rule:

@CrisisAlpha covers BUY reconciliation; SELLs have the symmetric problem. For a market SELL: maker = shares (≤ 4dp), taker = USDC received (≤ 2dp). The 4dp reject on SELLs therefore hits the maker (shares), not the taker — but the deeper issue is the same rounding overflow. Floor the USDC received before signing:

const usdc = Math.floor(shares * price * 100) / 100;  // taker on SELL, must be ≤ 2dp

Reconciliation drift applies on SELLs too: USDC actually received = size_matched × fill_price, which diverges from shares × quoted_price whenever the fill sweeps multiple price levels.

A ratio-consistent approach that avoids the magic constant:

The 4dp cap is the right symptom fix, but the CLOB also validates the ratio makerAmount / takerAmount must be an exact multiple of tick size. If you only cap the taker without re-aligning the maker, the ratio can still land off-tick and produce a different reject. An approach that fixes both at once:

// 1. Snap price to tick (2dp for most markets)
const tickPrice = Math.round(price * 100) / 100;
// 2. Floor shares to 2dp (never round up — keeps order under budget)
const shares = Math.floor((usdAmount / tickPrice) * 100) / 100;
// 3. Derive USDC from shares × snapped price — ratio is now exact
const usdc = shares * tickPrice; // guaranteed ≤ 2dp, ratio = tickPrice exactly

This works regardless of how ROUNDING_CONFIG changes in future versions because it anchors precision to the price, not to a tick-specific decimal count.

FOK sweep price caps:

Concrete values that sweep the full book without a calculateMarketPrice network call: 0.99 for BUY FOK, 0.01 for SELL FOK. Both are already multiples of 0.01 so no additional rounding is needed.

GTC partial fills — POST response size_matched is point-in-time only:

@CrisisAlpha's note applies to FOK/FAK fills that settle immediately. For GTC orders: the POST response size_matched reflects only the portion matched on arrival; subsequent maker-fills accumulate separately. GET /data/order/{orderId} → size_matched is the only authoritative cumulative figure. If you run GTCs on thin markets and sum the POST response across multiple orders, you will undercount fills.

[osr21]

Fix: clamp taker amount to 4 decimal places before signing

The CLOB API enforces a 4-decimal-place cap on takerAmount in the wire format, but the SDK currently computes it with 5–6 decimal places from tick precision, causing the rejection.

Where it breaks

In the order builder, takerAmount for a market BUY is:

const takerAmount = roundDown(size / price, roundConfig.size);  // may produce 5+ decimals

Fix: add a secondary clamp to 4 decimals

// After computing takerAmount, clamp to the API's 4-decimal limit:
const clampedTakerAmount = Math.floor(takerAmount * 10000) / 10000;

Alternatively, use the existing roundDown helper with precision: 4 as a second pass:

const takerAmount = roundDown(
  roundDown(size / price, roundConfig.size),  // tick precision
  4                                            // API wire format cap
);

This is consistent with how the CLOB's own price/size normalizer works — it truncates at 4 significant decimal places before validating the order hash. The Python client has the same bug (see polymarket/py-clob-client-v2#99).