"What is the minimum deposit for a trading bot?" has two correct answers that differ by an order of magnitude, and most tools only tell you the smaller one.
On 18 September 2026 we asked a live OKX account for the order constraints of twelve instruments and combined them with our own sizing formula. For an ETH perpetual grid, the venue will accept an order from a $53 deposit. The same grid does not behave as configured until about $522.
Both numbers are right. They answer different questions.
What we measured
Three fields per instrument, asked from the venue rather than remembered: limits.cost.min (smallest order it accepts), limits.amount.min and precision.amount (the lot step). The size of the smallest order in a ladder comes from our own sizing owner, not recomputed — a second definition of sizing would drift from the form on the first edit.
Twelve instruments (six symbols, spot and perpetual) × four sizing shapes. Live venue, not testnet.
Finding 1: on a perpetual, the lot step IS the whole minimum
| instrument | min order | lot step | step as % of the minimum |
|---|---|---|---|
| ETH/USDT spot | $0.26 | $0.0026 | 1.0 % |
| BTC/USDT spot | $0.81 | $0.0008 | 0.1 % |
| OP/USDT spot | $1.14 | — | 0.0 % |
| ETH/USDT perp | $2.61 | $2.6060 | 100.0 % |
| BTC/USDT perp | $8.09 | $8.0905 | 100.0 % |
| OP/USDT perp | $0.11 | $0.1136 | 100.0 % |
All six perpetuals: 100.0 %. All six spot markets: between 0.0 % and 1.0 %.
This is not a quirk of one symbol. A perpetual is quoted in contracts, and one contract is the minimum order. So the only order sizes that exist are 1 contract, 2 contracts, 3 contracts. On spot the step is a rounding detail; on a perpetual it is the unit of the entire ladder.
Finding 2: there are two floors, and tools quote the lower one
Mechanical floor — the deposit at which the smallest rung clears the venue minimum. Below it nothing happens at all: the order is rejected, the cycle never starts.
Workable floor — the deposit at which the ladder you configured is the ladder that actually gets placed. We set it where the smallest order is at least ten lot steps, so quantisation error is at most 10 %.
| grid, 10 orders | mechanical | workable | ratio |
|---|---|---|---|
| ETH perp | $53 | $522 | 9.8× |
| BTC perp | $162 | $1619 | 10.0× |
| LINK perp | $25 | $245 | 9.8× |
| DOGE perp | $18 | $175 | 9.7× |
| SUI perp | $17 | $161 | 9.5× |
| ETH spot | $6 | $6 | 1.0× |
| BTC spot | $17 | $17 | 1.0× |
On spot the two floors are identical. On perpetuals they differ by about ten times, and the gap comes entirely from the indivisible contract.
Finding 3: spot and perpetual are not the same product for sizing
Same venue, same day, same nominal strategy, same symbol: an ETH grid works from $6 on spot and from about $522 on the perpetual. Eighty-seven times apart.
Nothing about the strategy changed. The instrument did.
Why this quietly breaks a ladder — measured
A grid is configured with a first-order fraction and a martingale step: each rung is a little larger than the last. That is the whole point — the average entry improves as price falls.
Put that ladder near the mechanical floor of a perpetual and the rung sizes come out as 1.17, 1.29, 1.43, 1.58, 1.74, 1.92 contracts. The lot step is one contract. Every rung is placed as 1.
That is not a thought experiment. It is a live system on our own fleet — BNB/USDT, read out of the order books on 19 September 2026: six rungs planned to total 9.13 contracts, six single contracts actually resting. A third less capital in the market than the form displayed — and no error anywhere. Of 31 systems under polling, 26 had enough rungs to judge, and four had their geometry erased this way.
Two causes that look identical
A flat ladder comes from one of two mechanisms, and they are not fixed by the same thing:
- •Truncation to the lot step. The planned size is above the venue minimum, but the exchange truncates to the step — 1.17 becomes 1. This is what we measured, in all four cases.
- •Bump to the venue minimum. The planned size is *below* the smallest order the venue accepts, so it is raised to the minimum.
On screen both produce the same row of identical orders. Only the second is helped by "increase your deposit". We assumed the second and measured the first — worth knowing which one you have before paying for the wrong fix.
One detail decided the diagnosis. Our own test harness rounded order size to the nearest step, while the exchange library truncates. On that harness this exact defect would have looked healthy: 1.17 rounds to 1, but 1.58 and 1.74 round to 2, producing a growing ladder. That the venue truncates was not settled by documentation — it was settled by the live books, where all six rungs were single contracts.
What can and cannot be fixed
The fix is to stop quantising each rung on its own and place the difference of running totals: rung N is floor(planned total through N) − already placed. BNB becomes 1, 1, 1, 2, 2, 2 — six orders totalling 9 against a plan of 9.13. LTC, at a 0.1 step, lands exactly on plan.
Note what that does and does not promise. The ladder is not monotonic, and it cannot be: on a coarse step you cannot preserve both the total and a strictly growing sequence — the fractional part has to go somewhere. BTC at a 0.01 step comes out as 0.01, 0.01, 0.01, 0.02, 0.01, 0.02. The only way to make every neighbour larger than the last is to round up, which means placing more than the deposit can fund. The honest statement is: the tail of the ladder is heavier than the head, and the total matches the plan to within one lot step.
And the rule has an edge. When the planned rung is *smaller than the lot step itself*, the differences come out as zeros, and you can no longer keep both the order count and the geometry — something has to give. The engine keeps the order count and raises such a rung to the venue minimum, so the far safety orders do not silently vanish.
Which means the finding above stands for small deposits: below the workable floor, your weighted ladder really is a stack of identical orders. Quantisation arithmetic extracts everything the lot step can express — it cannot overrule the step.
The failure is silent in both directions: no rejection to warn you, and no visible difference on the screen. It is invisible to a backtest too, which works in continuous sizes unless it is told otherwise.
How to check this yourself
Three lines against your own venue, before you fund anything:
const m = exchange.markets['ETH/USDT:USDT'];
console.log(m.limits.cost.min); // smallest order the venue accepts
console.log(m.precision.amount); // the lot step
console.log(m.contractSize); // how much one contract is worthThen the only question that matters: how many lot steps is my smallest rung? If the answer is one or two, your ladder is a stack of identical orders whatever the form shows you. Ten is a reasonable bar; below five the quantisation error is comparable to the edge you are trying to capture.
Limits of this measurement
- •One venue, one day, twelve instruments. OKX on 18 September 2026. Minimums differ by venue, by instrument and over time — this is a method, not a table to copy.
- •The "ten steps" bar is our choice, not a law. It is where quantisation error falls to 10 %. A different tolerance moves every workable number proportionally.
- •Prices move the floors. These are notional minimums, so a symbol that doubles in price moves its own floor.
- •Leverage is not in these numbers. Our sizing expresses the smallest order as a fraction of the deposit, so the table above does not answer what leverage does to the floor. We have not measured that here, and we are not going to guess at it.
- •This is not investment advice, and none of the above is a recommendation to trade.
What this says about our own product
Our platform refuses outright when the smallest order is below $1 and warns below $5. Those are common-sense lower bounds, not a measurement of any venue — and the measurement above shows the venue floor sitting higher than both on most perpetuals.
We are saying it plainly because it is the honest reading of our own instrument: the venue is the arbiter of what it will accept, and a product that answers this question from its own constants is answering a different question than the user asked.