Fixing Polymarket's "invalid amounts" error on the CLOB (py-clob-client)

BlueWhale-Quant-Lab — Mon, 01 Jun 2026 14:05:03 +0000

Fixing Polymarket's "invalid amounts" error on the CLOB (py-clob-client)

If you've posted an order to Polymarket's CLOB with py-clob-client and gotten
back a flat invalid amounts — even though your size looks fine and you
rounded it to two decimals — here's what's actually going on, and a one-line fix.

The undocumented rule

A CLOB order carries two integer amounts (scaled by 1e6). Both must be whole
multiples of 10000:

makerAmount = price * size * 1_000_000     # multiple of 10000
takerAmount =         size * 1_000_000     # multiple of 10000

round(size, 2) isn't enough. Concrete example:

price = 0.82, size = 6.25
makerAmount = 0.82 * 6.25 * 1e6 = 5_125_000
5_125_000 % 10000 = 5000   ->  invalid amounts

The catch: the valid step for size depends on the price.

The fix

import math

def size_step_units(price):           # in 1/10000-share units
    p_int = int(round(price * 10000))
    maker_step = 1_000_000 // math.gcd(p_int, 1_000_000)
    return maker_step * 100 // math.gcd(maker_step, 100)

def round_for_fok(price, size):
    p = max(0.01, min(0.99, round(price, 2)))
    step = size_step_units(p)
    units = (int(round(size * 10000)) // step) * step or step
    return p, round(units / 10000, 4)

round_for_fok(0.82, 6.25) → (0.82, 6.0), and now both amounts are valid. I
packaged this (plus a $1 / 5-share minimum-order check) as a tiny MIT tool:
https://github.com/BlueWhale-Quant-Lab/polymarket-clob-order-amount-tick-size

Two more traps on the daily markets

invalid tick size — the daily ("...on June 1") markets use a 0.001 tick, not 0.01. Hard-coding tick_size="0.01" gets them rejected.
The 10-share minimum step — at prices like 0.999, the smallest valid size step is 10 shares, so a sub-10-share order at that price is impossible. You either round up or move the price.

And if you rest GTC orders, flooring the size loses shares to the fee skim and
can leave your two legs unbalanced (No > Yes); you want nearest-rounding with a
±tick price search instead. Those are in the PRO build
here,
but the free tool above fixes the common invalid amounts case for everyone.

(This is order-amount math — not order placement, signing, or any profit claim.)

How to get a Polymarket event slug (and the CLOB token IDs) for Up/Down markets

BlueWhale-Quant-Lab — Mon, 01 Jun 2026 13:37:41 +0000

How to get a Polymarket event slug (and the CLOB token IDs) for Up/Down markets

If you've tried to automate anything around Polymarket's crypto "Up or Down"
markets, you've probably hit this wall: the Gamma API will happily return an
event if you already know its slug —

GET https://gamma-api.polymarket.com/events?slug=btc-updown-5m-1780319100

— but nothing documents how to build that slug in the first place. Searching
"polymarket event slug", "polymarket get market by slug", or "polymarket clob
token id" turns up almost nothing. Here's the format, and a small open-source
tool that does it for you.

Why the slug matters

On Polymarket the slug is the key that unlocks everything else:

slug ──/events?slug=──▶ event ──▶ markets[0].clobTokenIds ──▶ order book / price

No slug, no market id, no CLOB token id, no condition id. So building the slug
deterministically is step one of any read or trade automation.

The easy case: 5-minute and 15-minute markets

These two timeframes use a plain UTC timestamp:

{asset}-updown-{tf}-{unix_timestamp}

btc-updown-5m-1780319100
eth-updown-15m-1780318800

t_start is just a UTC floor:

def get_t_start(tf, now):
    dur = {"5m": 300, "15m": 900}[tf]
    return (int(now) // dur) * dur

That's it — no timezone, no daylight saving. There's a tiny MIT-licensed tool
that builds these and (optionally) calls Gamma to hand you the token IDs:

python polymarket_slug.py btc 5m --resolve
# slug   : btc-updown-5m-1780319100
# title  : Bitcoin Up or Down - June 1, 9:05AM-9:10AM ET
# tokens : ['632187004239...', '502984638552...']

Repo: https://github.com/BlueWhale-Quant-Lab/polymarket-updown-event-slug-generator

The hard case: 1h / 4h / 1d

The hourly, 4-hour, and daily markets are where naive code silently 404s:

The boundaries are Eastern Time. Hard-code a UTC-5 offset and every slug breaks for ~8 months of the year once US daylight saving (EDT, UTC-4) kicks in.
The 1d market runs noon-ET → noon-ET — not a UTC day, not an ET-midnight day. "...on March 5" = Mar 4 noon ET → Mar 5 noon ET, and the slug carries the settlement date: bitcoin-up-or-down-on-march-5-2026.
The 1h format drifted. Polymarket has shipped it both with and without the year (bitcoin-up-or-down-june-1-9am-et vs ...-june-1-2026-9am-et), so robust code has to try both and validate.
Watch for zombie slugs: across a year boundary the same date can resolve to last year's CLOSED market (depth 0). Filter closed/inactive.

The free tool sticks to the two deterministic timeframes on purpose. If you need
1h/4h/1d done correctly (DST-safe, format-change-proof, with the noon-ET boundary
and dynamic tickSize handled), there's a complete version here:
Polymarket Up/Down slug generator — PRO.

Wrap-up

The slug is a small thing that blocks a lot of Polymarket automation simply
because the format isn't written down anywhere. For 5m/15m it's a one-line UTC
floor; for 1h/4h/1d it's an Eastern-Time minefield. Grab the open-source generator
and save yourself the reverse-engineering:
https://github.com/BlueWhale-Quant-Lab/polymarket-updown-event-slug-generator

(Note: this is about building a data primitive and reading public market data —
not placing orders or predicting prices.)

DEV Community: BlueWhale-Quant-Lab

Fixing Polymarket's "invalid amounts" error on the CLOB (py-clob-client)

Fixing Polymarket's "invalid amounts" error on the CLOB (py-clob-client)

The undocumented rule

The fix

Two more traps on the daily markets

How to get a Polymarket event slug (and the CLOB token IDs) for Up/Down markets

How to get a Polymarket event slug (and the CLOB token IDs) for Up/Down markets

Why the slug matters

The easy case: 5-minute and 15-minute markets

The hard case: 1h / 4h / 1d

Wrap-up