Trade Sizing Against Pool Depth on Solana

Trade sizing liquidity on Solana comes down to one ratio: the size of your order divided by the reserve of the token you are paying in. On a constant product pool that ratio alone determines your price impact, before any fee is applied. If you learn to read depth as a reserve figure rather than as a dollar figure, you can decide your maximum order size in a few seconds, and you can tell the difference between a pair that is merely expensive and a pair that cannot absorb you at all.

What depth actually is on an AMM

On a central limit order book, depth is visible: rows of resting bids and offers, each with a price and a quantity. You can add up the first ten rows and know exactly what a given size costs. An automated market maker has no such rows. It holds two balances and prices every trade from a formula applied to those balances. There is nothing to add up, because there are no discrete orders to sum.

What replaces the order book is the reserve pair and the curve. The pool holds some quantity of token X and some quantity of token Y. A swap moves the pool along the curve: you add to one reserve and remove from the other, and the price you receive is the average price along the segment you traversed. The further you travel, the worse the average. Depth, in this world, means how far you can travel before the average gets bad.

This is why depth cannot be read from a single number such as total value locked. Two pools with identical stated liquidity can behave completely differently for your order if one holds that value on a constant product curve spread across all prices and the other concentrates it inside a narrow band. The useful question is never how much liquidity exists in total. It is how much of it stands between your order and a price you would not accept.

Constant product versus concentrated liquidity

A constant product pool obeys the relation x * y = k, where x and y are the two reserves and k is held constant across a swap. The spot price is simply the ratio y / x. Because the product is fixed, removing token Y forces token X to rise, and the curve gets steeper the further you push. Depth is always present at every price, but it thins out continuously as you move away from the current ratio.

Reading a constant product pool is therefore straightforward. Find the reserve of the token you are paying in. That single number, together with your order size, tells you the impact. You do not need to know the other reserve, the token price, or the total value locked, because those quantities cancel out of the impact expression. It is one of the few places in trading where a genuinely useful answer needs exactly one input.

Concentrated liquidity pools break that convenience deliberately. Liquidity providers choose a price range, and their capital only participates while the pool price sits inside that range. Inside an active range the pool behaves like a much deeper constant product pool, which is the whole point: the same capital produces far better prices for normal sized trades. Outside the range, that capital contributes nothing at all.

The practical consequence is that depth in a concentrated pool is local and can end abruptly. An order that stays inside the active range may cost almost nothing in impact. An order that pushes the price out of that range crosses into whatever the next tick of liquidity happens to be, which may be far thinner or effectively absent. The pool does not warn you. The quote simply becomes much worse at a size you could not have predicted from the headline number.

• For a constant product pool, read the input-side reserve and treat everything else as noise.
• For a concentrated pool, ask how much liquidity sits inside the active range, not how much the pool holds overall.
• Test a concentrated pool by quoting two sizes, one small and one at your intended size, and comparing the implied rate per unit.
• If the rate per unit degrades sharply between those two quotes, you are leaving the dense part of the range.

Size as a percentage of reserves, not in dollars

The most useful habit in sizing is to stop thinking in currency and start thinking in reserve percentage. A trade of a given notional value is small in one pool and catastrophic in another. The same trade expressed as a share of the input reserve carries its own answer with it, and that answer is portable across every constant product pool you will ever touch.

Ignoring fees for a moment, if you send an amount dx into a pool holding reserve x of that token, the average execution price is worse than the pre-trade spot price by a factor that depends only on the ratio between them.

The relation inverts cleanly, which is what makes it usable in practice. If you decide in advance that you will accept a given impact, the reserve percentage you may spend is impact / (1 - impact). Half a percent of impact allows an order of about 0.5025 percent of the reserve. One percent allows about 1.0101 percent. Two percent allows about 2.0408 percent. For anything in this range, the shortcut is that your reserve percentage and your impact percentage are nearly the same number.

That near-identity is the rule worth memorising. If your order is one percent of the input reserve, expect roughly one percent of average price impact. If it is five percent of the reserve, expect roughly five percent. The approximation drifts once you go beyond about ten percent of reserves, and it drifts in the direction of being optimistic, so treat any size that large as a warning rather than a calculation.

What happens when you double the size

Traders usually assume that cost scales with size in a straight line: twice the order, twice the cost. That is true of a flat percentage fee. It is not true of price impact, and the difference is the single most important piece of arithmetic in this article.

Start from the impact expression. Doubling r roughly doubles the impact rate, since r / (1 + r) is close to linear for small values. But the impact rate is a percentage applied to a notional that has also doubled. The value you actually give up is the rate multiplied by the size, so it grows with the square of the reserve percentage.

Run the numbers. At one percent of reserves the squared term is 0.0001. At two percent it is 0.0004. Dividing by the small correction factor changes little. The result is that doubling the order size increases the tokens you forfeit to impact by a factor of roughly four, not two. Tripling it increases them by roughly nine. This is why a trader who splits a large order into three clips and gets each one filled against restored depth can pay a small fraction of the impact cost of the single large order.

It also explains an asymmetry that surprises people. Cutting a large order in half does not save half the impact cost. It saves about three quarters of it. The savings from restraint are front-loaded, which means the first reduction in size is by far the most valuable one you will make, and further reductions past a certain point buy you very little.

The middle column is a percentage; the right hand column is indexed so that a one percent order equals 1.00. Read across the bottom row: an order eight times larger costs roughly sixty times as much in forfeited tokens. Nothing about the interface makes that visible, because the interface shows you a rate, and the rate looks tolerable long after the total has stopped being tolerable.

Sizing bands and the impact they imply

Rules of thumb are only useful if they are stated in the units that actually determine the outcome. Stated in reserve percentages, the following bands hold for constant product pools regardless of which tokens are involved or what they are worth. Every figure below is illustrative arithmetic derived from the impact expression, not an observation of any market.

1. Under 0.5 percent of reserves. Impact is under half a percent and is usually smaller than the pool fee itself. Size is not your problem here; fees and timing are. Execute in one clip and stop optimising.
2. 0.5 to 1 percent of reserves. Impact lands between roughly half a percent and one percent. Still a single clip for most purposes, but worth checking whether a second venue exists before you sign.
3. 1 to 3 percent of reserves. Impact runs to about three percent and the squared cost term is starting to bite. Split across venues if any alternative liquidity exists. If it does not, ask whether the trade still makes sense at this cost.
4. 3 to 8 percent of reserves. Impact reaches the mid single digits and the forfeited value grows steeply. Split by default, over routes if possible and over time if not. Expect the last clip to be materially worse than the first.
5. Above 8 percent of reserves. You are no longer taking a price, you are setting one. Impact compounds, the pool becomes an arbitrage target the moment you finish, and the quoted rate understates what you will feel on the way out. Treat this as a signal to reduce size or abandon the pair.

Notice that these bands say nothing about the token, the sector, or the size of your account. That is the point. A reserve percentage is a complete description of the sizing problem on a constant product curve, and reasoning in those units keeps you honest about pools that look large in headline terms and behave small when you actually push against them.

An illustrative sizing table by depth band

The table below inverts everything above into the form you actually need at the moment of trading. Pick the row that matches the input-side reserve of the pool, read across, and you have your maximum order for three different impact ceilings. All figures are computed from size = reserve × impact / (1 - impact) and are illustrative arithmetic, expressed in units of the input token.

Two habits make this table portable. First, always read the reserve of the token you are paying in, not the one you are receiving, because the input side is what your order dilutes. Second, scale linearly: a pool with 20,000 units of input reserve permits exactly twice the order of a pool with 10,000, at every impact ceiling in the table. The relationship between reserve and permitted size is proportional even though the relationship between size and cost is not.

Splitting over time versus over routes

Once your order exceeds the band a single pool can absorb, you have two ways to break it up, and they solve different problems. Confusing them is the most common sizing mistake after ignoring reserve percentages entirely.

Splitting over routes means sending parts of one order to several pools simultaneously. It works when the liquidity you need already exists but is scattered across venues right now. Each pool absorbs a smaller reserve percentage, so each contributes a smaller impact, and because impact cost is quadratic the sum of several small impacts is far below one large one. The mechanics of why that sum comes out lower are covered in detail in our note on route splitting and price impact.

Splitting over time means sending clips sequentially and waiting between them. It works for a completely different reason: it does not find extra liquidity, it waits for liquidity to come back. Between your clips, other flow arrives and arbitrageurs pull the pool price back toward the wider market. If they do, your second clip meets a partly restored curve and pays impact as though it were a fresh order. If they do not, you are simply paying impact from a worse starting point each time, and time splitting has made things marginally worse rather than better.

The decision rule follows from that difference. Ask whether the missing depth exists somewhere else at this instant. If yes, split over routes, because the depth is available now and waiting gains nothing. If no, ask whether the pair sees enough independent flow that the price will be restored within your patience window. If yes, split over time. If neither is true, no amount of splitting saves you and the honest answer is that the position is too large for this pair.

Executing a time split by hand means quoting, signing, waiting, re-quoting and repeating for every clip, while the parameters that matter drift underneath you. That repetitive clip-by-clip work is what a professional Solana volume bot is built to absorb, holding the interval and the clip size while it sends the pieces to Solana venues, rather than leaving you to place each one manually and hope the ninth looks like the first.

Recognising a pair that is too thin for your size

Some pairs cannot take your order at any sensible cost, and the sooner you can tell, the less you pay to find out. Thinness is not a property of the pair alone; it is a relationship between the pair and the size you want. A pool that is perfectly adequate for one unit is unusable for one hundred.

• Your intended order exceeds a few percent of the input-side reserve, so you are setting price rather than taking it.
• Only one venue holds meaningful liquidity, which removes route splitting as an option entirely.
• The quoted rate degrades sharply between a small test size and your intended size, indicating a concentrated range that ends near where you are trading.
• The quote moves materially between two refreshes seconds apart, meaning the pool is being moved by flow far smaller than yours.
• The impact you are quoted is larger than the edge you believe you have, which makes the trade unprofitable before it starts.
• You cannot describe how you would exit the position at a comparable cost, because entry impact is only half the round trip.

The last point is the one most often skipped. Entering a thin pair commits you to exiting it, and the exit faces the same curve from the other side, usually with less patience and worse timing. If you would not accept the exit cost today, the entry is already a mistake regardless of what happens to the price. Size the round trip, not the entry.

The wider cost picture, of which impact is only one line, sits in our execution cost and quality section, alongside the measurement discipline that tells you whether a change to your sizing actually improved anything.

How sizing interacts with slippage tolerance

Sizing and slippage tolerance are frequently confused because both are expressed as percentages and both appear near the confirm button. They are not the same control and they do not compensate for each other.

Price impact from your own order is already inside the quote you are shown. The interface has walked the curve for your size and told you the resulting rate. Raising your slippage tolerance does not reduce that impact by a single basis point, because tolerance is not a discount on the quote. It is the maximum additional adverse movement you will accept between the moment the quote was constructed and the moment your transaction is executed on chain.

Where the two interact is through the pool. A thin pool moves further for any given amount of unrelated flow, so the price you were quoted has a shorter useful life. That argues for a slightly wider tolerance on a thin pair, purely to survive the interval between quoting and landing at a slot cadence of roughly four hundred milliseconds. It never argues for using tolerance to accommodate an order that is too large, because a wider tolerance in a thin pool simply widens the band in which someone else can profitably move the price against you before your transaction settles.

The correct sequence is therefore fixed. Size first, against the reserve percentage, until the quoted impact is one you would accept. Only then set tolerance, against the pool's volatility and your urgency, using the decision framework in our guide to setting slippage tolerance. Doing it in the other order produces the classic failure mode: an oversized trade wrapped in a tolerance wide enough to hide how much it cost. For the underlying transaction mechanics that define the interval tolerance has to cover, the Solana transaction documentation is the primary reference.

Get sizing right and most of the other levers become minor. Get it wrong and no amount of routing sophistication, priority pricing or tolerance tuning will recover the difference, because the cost you created by being too large was fixed the moment you chose the number.

Frequently asked questions