An order can be large enough yet use a price that does not conform to the required increment. It can also use a conforming price while falling below the applicable minimum size. These are separate checks—not interchangeable ways to decide whether an order is valid.
This guide covers Polymarket’s documented international central limit order book (CLOB). It is not guidance for Polymarket US or account-specific support.
What the documented fields tell you
The supplied order-book documentation identifies separate min_order_size and tick_size fields. Read the applicable values for the market you intend to use rather than assuming one numeric default applies everywhere.
The supplied official order-pattern guidance states that prices that do not conform to the applicable tick size are rejected.
That supports a narrow conclusion: price conformity matters. It does not establish that meeting the minimum size and price increment is sufficient for acceptance or execution.
Keep amount, quantity and price separate
Before comparing inputs with constraints, write down what each input represents.
| Item | Question to answer | What not to confuse it with |
|---|---|---|
| Intended amount | What monetary amount am I planning around? | The number of shares |
| Share quantity | How many shares am I proposing? | A monetary budget |
| Chosen price | What price per share am I entering? | The permitted price increment |
| Minimum size | What minimum applies, and in what units? | A universal minimum assumed from another market |
| Tick size | What increment must the price conform to? | The order’s size requirement |
| Proposed adjustment | What would change, and why? | An input change I have already approved |
For a simple hypothetical calculation, 12 shares at $0.42 per share gives a quantity-times-price amount of $5.04. That is arithmetic, not a fee-inclusive quote or a prediction of what will execute. A stated budget of $6 is still a different input from a quantity of 12 shares.
Hypothetical examples: one constraint can pass while another fails
All numbers in this section are invented for teaching. They are not Polymarket defaults or values for a named market.
Assume an illustrative market has a minimum of 10 shares and a price increment of $0.01.
Example A: conforming price, insufficient quantity
A proposed order specifies 8 shares at $0.42.
- The quantity is below the assumed 10-share minimum.
- The price conforms to the assumed $0.01 increment.
- Changing only the price would not address the quantity shortfall.
Increasing the quantity would change the proposed order. It should be treated as a decision to review, not a harmless formatting correction.
Example B: sufficient quantity, nonconforming price
A proposed order specifies 12 shares at $0.425.
- The quantity meets the assumed minimum.
- The price does not conform to the assumed $0.01 increment.
- Increasing the quantity would not address the price-increment problem.
Both $0.42 and $0.43 illustrate prices on that hypothetical increment, but neither should be selected automatically on the reader’s behalf. They are different prices. Review any proposed adjustment explicitly.
Neither example establishes whether an order would be accepted or filled after an adjustment.
Troubleshooting a “Polymarket invalid order price” question
Start with the submitted price and the applicable increment—not by increasing the amount.
- Identify the intended market and order book. Make sure the constraints you are reading belong to the order you are reviewing.
- Record the applicable
tick_size. Compare the actual proposed price with that increment. - Record
min_order_sizeseparately. Confirm its units before comparing it with your quantity or monetary amount. - Keep the original input visible. If an adjustment is proposed, write down the original value, suggested value and reason.
- Review the change before proceeding. A constraint problem does not tell you which alternative price or amount to choose.
- Keep the conclusion limited. Passing these two checks is not an exhaustive validation result or an execution promise.
If the inputs appear to conform but a problem remains, these sources alone do not establish its cause. Do not turn a single rejection or unusual display into a claim of an API defect.
Where TickBetter fits
TickBetter is PRE-ALPHA and currently in development. The proposed design requirement is to explain relevant constraints and make suggested input changes visible for explicit confirmation. This describes intended behavior—not implemented checks, a live validator or available execution functionality.