Position Sizing in Thin Solana Markets: The Arithmetic

Size from pool depth, not from account balance. The maximum position in a thin Solana pair is the amount whose full exit would move the quoted price by less than a limit you set in advance, computed against the reserves you would be selling into. Everything below is that sentence, worked out, with the cases where it fails.

The wrong denominator

Conventional sizing advice divides risk by account size. Risk one percent of capital per trade, or two, or whatever the number is. That advice comes from markets where your order is negligible relative to the venue, so the price you see is the price you get and the only question is how much of your money is exposed.

Thin on-chain pairs break that assumption completely. The pool is the venue, and your order changes it. A position that is one percent of a large account can be a double-digit percentage of a small pool, at which point the price you receive on exit is largely a function of your own order rather than of anything the market decided.

So the denominator changes. The question stops being what fraction of my capital is this, and becomes what fraction of the available depth is this. The first number tells you how much you could lose if the token went to zero. The second tells you how much you will lose simply by leaving, before the market does anything at all.

Both numbers matter and they constrain from different directions. Account-based sizing caps catastrophic loss. Depth-based sizing caps the transaction cost of participating. In a thin pair the second cap is almost always the binding one, and traders who only apply the first are consistently too large without ever knowing it.

The arithmetic of impact

Take the constant-product design, which is the simplest and remains the most common shape for a young Solana pair. The pool holds two reserves, x and y, and enforces that their product stays constant across a swap before fees. Price is the ratio of the reserves.

If you sell an amount dx into the pool, the new x reserve is x + dx, so the new y reserve must be k / (x + dx) where k = x * y. Your output is y - k / (x + dx). The fraction of value you give up relative to the spot price is driven by dx / (x + dx), and that expression is the entire story: cost depends on your order relative to the reserve you are pushing into, and it grows faster than linearly.

Two useful consequences fall out. First, doubling your size more than doubles your impact, which is why a position twice as large is worse than twice as bad. Second, the reserve in the expression is the one on the side you are selling, so entry impact and exit impact are computed against different balances and can differ substantially, especially after the pair has moved.

A worked sizing example

Illustrative arithmetic

Invented round numbers, describing no real pair. A constant-product pool holds 400 SOL and 4,000,000 tokens, so the spot price is 0.0001 SOL per token and k is 1,600,000,000. Your standing impact limit is two percent on a full exit.

You want to know the largest token position you could sell back into this pool while keeping the effective price within two percent of spot. Selling an amount of tokens dt gives an output of 400 - k / (4,000,000 + dt) SOL. Try 80,000 tokens, two percent of the token reserve: the pool's SOL balance becomes 1,600,000,000 divided by 4,080,000, about 392.16, so you receive roughly 7.84 SOL against a spot value of 8 SOL. That is about two percent of impact before fees, so 80,000 tokens is roughly the limit.

At entry, 8 SOL is your maximum. Now suppose the pair falls and reserves shift so that the pool holds 250 SOL against 6,400,000 tokens. Your 80,000 tokens are now 1.25 percent of the token reserve, so exit impact has fallen even though the position is worth less. Suppose instead that liquidity is withdrawn and the pool holds 100 SOL against 1,000,000 tokens. Your 80,000 tokens are now eight percent of the reserve and exit impact is roughly four times what you planned for.

The lesson is not the specific figures. It is that your exit cost is a moving quantity that other people control, and the only defence is to recompute it rather than to assume the entry calculation still holds.

A shortcut worth internalising: on a constant-product pool, selling a fraction f of the reserve on your side costs approximately f in relative price terms for small f, before fees. Two percent of the reserve is roughly two percent of impact. That approximation degrades badly above about ten percent, where the curve steepens, so use it as a mental check on small sizes and compute properly on large ones.

A sizing ladder

Approximate relationship between order size as a share of the reserve being entered and the resulting price impact on a constant-product pool, before fees, with the practical reading for each band.
Order as share of reserve	Approximate impact	Practical reading	What to check before accepting it
Under 1 percent	Under 1 percent	Your order is a minor participant in the pool	That the depth figure is real and near price, not a concentrated total
1 to 3 percent	Roughly proportional	Ordinary working range for a considered position	Exit-side reserve, not entry-side, and the fee tier on top
3 to 10 percent	Rising faster than size	You are now a material part of the market you are trading	Whether a second pool exists to split across, and what the split costs
Over 10 percent	Steepening sharply	The exit price is mostly determined by your own order	Whether the position is worth taking at all at this size

The bands are approximations of a smooth curve and the boundaries are conventions, not thresholds with any special property. Their value is as a shared vocabulary in a journal: recording that an entry was a three percent order is more informative in review than recording that it was a moderate position.

Concentrated pools change the reading

On a concentrated liquidity design the reserves are not spread across all prices. Providers choose ranges, and only the liquidity in ranges containing the current price participates in your trade. The headline total is therefore an upper bound on what you will meet and frequently a bad one.

Two practical adjustments follow. Where the venue exposes active liquidity near the current price, use that figure as the denominator instead of the total. Where it does not, treat your computed impact as optimistic and reduce size accordingly, recording that you did so and why.

There is a second-order effect worth knowing. A large order on a concentrated pool can cross range boundaries, at which point the depth available changes mid-trade and the marginal price deteriorates in steps rather than smoothly. The documentation for the designs in question, such as the Orca Whirlpools documentation, sets out the tick and range mechanics that produce this behaviour.

Splitting, and when it stops helping

The obvious response to an order that is too large for one pool is to split it. Splitting works when the pieces meet genuinely separate depth, and does nothing when they do not, so the first question is always whether a second source of liquidity exists rather than how many pieces to cut.

Splitting across venues is the version that reduces impact. Two pools on the same pair are two independent reserves, and an order divided between them pushes each one less far. A router does this automatically where its coverage includes both, which is why a routed quote and a direct quote can differ on a pair that trades in more than one place. The cost is real: each additional leg adds fees, adds compute, adds accounts to the transaction, and adds another way for the whole thing to fail.

Splitting across time in the same pool is the version that is widely believed to help and mostly does not. A constant-product pool does not refill itself. If you sell half now and half in ten minutes, and nobody else traded in between, the second half meets a reserve already depleted by the first, and your total impact is approximately what a single order would have cost. Time-splitting only helps to the extent that other participants restore the reserve while you wait, which is a bet on other people rather than a property of the mechanism.

There is one honest exception. Splitting across time reduces the chance that a single large order is the visible event that triggers other participants to act. That is a behavioural argument rather than a mechanical one, it cannot be verified from the chain, and it should be labelled as such in your notes rather than presented to yourself as arithmetic.

The practical rule is unglamorous: split across venues when a second venue has real depth, price the extra legs before assuming they are free, and treat time-splitting as risk management rather than as impact reduction.

Why the exit side is the binding constraint

Entry is a decision you control. You can decline it, split it, delay it or take it smaller. Exit is a decision you will eventually have to make regardless of conditions, and the conditions at that moment are set by other participants and by liquidity providers who owe you nothing.

This asymmetry is the whole argument for sizing on the exit side. It is also why depth-based sizing is more conservative than it first appears: you are not sizing for current depth, you are sizing for depth that may be materially lower when you need it, which argues for a limit with margin in it.

The mirror image of this question sits on the project side of the same market. Teams ask how much activity a pair needs before it becomes visible on venue and aggregator screens, and the honest form of that question is a sizing question too, which is why how much volume a token needs gets asked as often as how much depth a trader needs. Both are answered by arithmetic against a pool rather than by an ambition.

For a trader the practical implication is that visibility and depth are not the same resource. A pair can be highly visible and thin, and Solana volume automation changes the first without changing the second. Your sizing arithmetic is computed against the second, always, regardless of how busy the pair looks.

The sizing rule set

Rule one: set the impact limit before the pair

Choose the maximum acceptable exit impact as a standing policy, in advance, applying to every trade. Cost: the limit will be wrong for some pairs in both directions. Failure case: you raise it for one specific pair and the exception becomes the rule within a month.

Rule two: compute against exit-side reserves

Every size calculation uses the reserve you would be selling into, read at entry and recorded. Cost: this produces smaller positions than entry-side arithmetic, permanently. Failure case: reserves are adequate at entry and are withdrawn afterwards, which the calculation cannot anticipate.

Rule three: recompute on any depth change

If reserves move materially, recompute and hold the smaller of the permitted size and the current position. Cost: forced partial exits that are sometimes unnecessary. Failure case: you recompute during a fast move and the act of reducing is itself expensive.

Where sizing rules fail

They fail when the depth figure is wrong. Interfaces aggregate, cache and occasionally mislabel. If your denominator is off by a factor of two, every downstream number is off with it, which is why reading reserves from the pool account rather than from a summary card is worth the extra step.

They fail against slow bleed. Depth-based sizing protects against transaction cost, not against a position losing value gradually while remaining perfectly liquid. A separate invalidation is required for that, and it is a different rule with a different trigger.

They fail against correlated exits. Sizing arithmetic assumes you are the only one leaving. If a wave of participants sells simultaneously, the reserve is being consumed by others while you compute, and your realised impact will exceed the calculation. Depth is a snapshot, not a reservation.

And they fail against the temptation to make an exception. The single most common way this framework breaks is a trader who applies it faithfully for a month and then decides that this particular pair is different. The limit is only a limit if it survives the trade you most want to take.

Questions the desk gets asked

How should you size a position in a thin crypto market?

Set an impact limit in advance, then let the pool decide the size. The maximum position is the amount whose full exit would move the quoted price by less than that limit, computed against the reserves on the side you would be selling into. Your account balance sets an upper bound on what you can risk, not what the market can absorb.

What is price impact on a constant-product pool?

It is the difference between the spot price before your trade and the effective price you receive, caused by your own order changing the reserve ratio. For a pool holding reserves x and y under the invariant x times y equals k, selling an amount dx gives an output of y minus k divided by x plus dx. The larger your order relative to x, the worse the effective price.

Is two percent price impact a lot?

It depends entirely on what you are doing and no universal threshold exists. What matters is that you choose a limit before you look at a specific pair, so that the number is a constraint you set while neutral rather than a number you justify while wanting to trade. The limit is a policy, not a market fact.

Why size from the exit side rather than the entry side?

Because entry is optional and exit is not. You choose when to enter and can decline; once positioned, you will have to sell into whatever depth exists at that time, and that depth is set by other people. Sizing on the entry side quietly assumes the pool will still be there, which is the assumption that fails most often.

Does splitting an order reduce price impact?

Splitting across several pools can reduce impact if the pools are genuinely separate sources of depth, at the cost of extra fees, extra compute and more ways for a transaction to fail. Splitting across time in the same pool does not reduce total impact by itself, because the pool does not refill on its own; it only helps if other participants restore the reserve in between.

How does this apply to concentrated liquidity pools?

The same principle applies to a different denominator. On a concentrated design, headline total liquidity overstates what your order will meet, because capital sits in ranges that may be far from the current price. Use active liquidity near price where the venue exposes it, and treat the total as an upper bound that your order will not benefit from.

What if the permitted size is too small to bother with?

That is the pair telling you it is not tradeable at your size, which is a useful result rather than an obstacle. The two honest responses are to trade it smaller or not at all. The dishonest response, and the common one, is to raise the impact limit for this particular pair because you want the trade.