Verifying DEX Liquidity Depth - Crypto Research Notes

1. Why DEX Pricing Mechanisms Deserve Their Own Line of Inquiry: The Division of Labor with Oracle Research

An earlier piece in this series on oracles and price data centered on a single question: how does a protocol obtain a price from outside itself? A lending market or a derivatives protocol calculating collateral ratios or liquidation thresholds needs a number it does not generate on its own — it only reads it. That is what oracles are for: off-chain price feeds, on-chain aggregation contracts, update frequency, staleness thresholds, cross-source verification. The whole apparatus exists to answer one question — whose number can be trusted? But that chain of reasoning always leaves one link unexamined: where did the price being collected by the oracle and read by the protocol actually come from in the first place? A large part of the answer is the DEX (decentralized exchange) itself. A DEX doesn't just relay a price — it produces one. Its market-making curve, the distribution of its liquidity, and the execution path of every single swap jointly determine what a given trading pair 'should' cost at a given moment. This is a question that runs parallel to oracle research but points in the opposite direction: oracle research asks where a price came from and whether it can be trusted; DEX pricing research asks how that price was actually computed, and whether the computation itself leaves room to be manipulated.

To be more concrete about the division of labor: the oracle article dealt with risk in the information-transmission layer — a price feed updating with a lag, an aggregator relying on a single data source, a price update being deliberately delayed at a critical moment. This article deals with risk in the price-generation layer — how far a pool's quoted depth diverges from the volume it can actually absorb, how far a swap of ordinary size can push a pool's quote away from the external reference price, and whether the rules governing an automated market-making curve leave a structural opening for a third party to insert a low-cost transaction ahead of someone else's and profit from it. The two questions are frequently connected end to end — plenty of oracle designs use a DEX's time-weighted average price (TWAP) as one of their inputs, which means a researcher who doesn't understand the fragilities in a DEX's own pricing mechanism will struggle to judge whether an oracle design built on top of DEX prices is actually sound. But treating the two as one and the same blurs the research: oracle research is concerned with cross-source verification, update cadence, and circuit-breaker thresholds; DEX pricing research is concerned with pool structure, depth distribution, price-impact curves, and the abstract patterns behind front-running and sandwich attacks. These are two different checklists, and they need to be worked through separately.

There's a more direct reason to treat DEX pricing as its own subject: a DEX is one of the few places in crypto where the entire pricing process happens in full public view. From the moment a swap is submitted to the moment it settles, the change in pool reserves, the execution price, and the size of the slippage are all — in principle — auditable transaction by transaction, on chain. That gives a researcher something to verify independently, without taking anyone's self-reported numbers on faith; you don't need to trust what any party publishes, you only need to be able to read the reserve curve itself. But 'verifiable' is not the same as 'easy to verify.' Most users only ever see a price that has already been computed for them by a front end. The real depth distribution behind that pool, how sensitive the quote is to a large order, and whether a given trade was sandwiched by other transactions before and after it — all of that only becomes visible once a researcher actually pulls apart the on-chain data. That combination — fully public data, non-trivial to interpret — is exactly why DEX pricing mechanisms merit their own research track.

One methodological boundary is worth stating up front. This article works through four layers: the abstract logic of AMM pricing and the categories of liquidity-pool design; how to independently verify a pool's true depth; independent methods for calculating price impact and slippage; and the abstract mechanism categories behind MEV and sandwich attacks. Every example used to illustrate a mechanism — pool sizes, curve parameters, slippage ratios, block-ordering arrangements — is an abstract category or a constructed, fictional figure used purely to explain the underlying principle. These will be flagged explicitly in the text and do not correspond to any real, identifiable DEX product, protocol, team, or historical event, nor do they constitute a conclusive judgment about any specific project. The discussion of MEV and sandwich attacks in the fifth section is written from the standpoint of a researcher trying to recognize and guard against risk — the goal is to understand why this kind of manipulation can happen and what observable traces it leaves behind, not to provide a step-by-step guide for carrying it out. The article as a whole is a discussion of research methodology only. It is not investment advice, nor is it operational advice.

Oracle research: focuses on the transmission and verification of price information — cross-source comparison, update frequency, staleness thresholds, circuit-breaker design
DEX pricing research: focuses on how the price itself is generated — market-making curve design, the distribution of reserves within a pool, price impact and slippage, and the room for manipulation within the execution path
Where they meet: many oracle designs use a DEX's time-weighted average price as one input, so findings from the two lines of research tend to corroborate each other, even though their checklists and methods differ
Scope of this article: the logic of AMM pricing, verifying true depth, calculating price impact and slippage, and the abstract mechanism categories behind MEV and sandwich attacks — from a researcher's vantage point, not an operational guide

2. The Abstract Logic of AMM Pricing and Categories of Liquidity Pool Design

To verify whether the quote a trading pair produces at a given moment is reasonable, the first step isn't to check whether it has been manipulated — it's to understand what rule produced that quote in the first place. Unlike a traditional exchange, where the trade price emerges from an order book matching buyers and sellers, a quote on an automated market maker (AMM) DEX isn't proposed by any counterparty at all. It's computed in real time by a mathematical function written into the contract — public and identical for every trader — based on the current quantities of each asset the pool holds. This is commonly called a constant function market maker formula. Understanding this formula-driven pricing, rather than pricing set by a quoting party, is the shared prerequisite for everything that follows: verifying liquidity depth, calculating price impact, and identifying MEV mechanics. It's also the key methodological divergence from our earlier article on oracle price feeds. That piece examined how an external-world price gets carried on-chain; here we examine how the on-chain price itself is computed in real time by a deterministic formula.

This section starts with the simplest case — the two-asset constant product model — to lay out the basic mechanics. A pool locks up a quantity x of asset A and a quantity y of asset B, and absent any deposits or withdrawals, the product x×y stays equal to a constant k, with the marginal price approximately y/x. A hypothetical example, used purely to illustrate the method (all figures are fictional): a pool with x = 1,000,000 and y = 1,000,000 (k = 1 trillion, marginal price 1:1). If a trader deposits 100,000 units of asset A in one transaction, x' becomes 1,100,000, and y' has to fall to roughly 909,000 to keep k constant — producing an effective execution price of about 0.91, noticeably worse than the pre-trade 1:1 quote. That gap is the price impact created by the trade's own size, and has nothing to do with external market conditions. Two properties of this model carry through the rest of the analysis: price impact tracks trade size relative to the pool's reserves, not the absolute dollar amount; and the price curve is hyperbolic, with its slope steepening sharply as trade size grows — the mathematical basis for the price-impact formulas that follow.

In practice, several abstract categories of pool design make different trade-offs in how the constant function is built, and verification should start by identifying which category a given pool belongs to. Stable-asset optimized curve models are built for asset pairs whose prices should, in theory, track the same peg; their curves are far flatter than the constant product model near the peg, giving smaller price impact — but once the asset ratio gets pushed into a severely imbalanced region, the slope steepens abruptly and price impact can end up more severe than the plain constant-product case, an asymmetry that's easy to miss. Concentrated liquidity models let liquidity providers supply capital only within a chosen price range, so the depth a pool quotes at any given moment is the sum of every range position that covers the current price — and that depth can be highly uneven. Reading total value locked alone tells you almost nothing about the real depth near the current price. Weighted multi-asset pool models generalize the two-asset product to a weighted product across several assets (a hypothetical example: 50%/30%/20%); for a given trade size, lower-weighted assets tend to show steeper price-impact curves.

The constant function itself only determines the theoretical output amount. The actual execution price also layers on the pool's configured fee tier (hypothetical tiers: 0.05%, 0.3%, 1%), with only the amount left after the fee feeding into the constant-function calculation. When verifying a quote, keep the theoretical output amount separate from the amount actually received — if the gap between them deviates noticeably from the nominal fee rate times trade size, that points to an undisclosed extra deduction somewhere in the flow. Beyond that, fee tiers, the granularity of concentrated-liquidity ranges, and curve-shape parameters can often be adjusted through governance or by an admin address. If changed quietly, these adjustments can alter the quote and slippage on the exact same trade even while the pool's asset quantities stay unchanged — a permissioned risk similar to the data-source address swaps covered in the oracle price feed article. When verifying historical quotes, check whether any such parameter change occurred within the research window, so it doesn't get mistaken for an effect of the trade itself or of external market movement.

3. How to Independently Verify a Liquidity Pool's True Depth

When a researcher opens a DEX front end and sees a trading pair annotated with something like "TVL: $5.12M" or "Liquidity: Sufficient," that text needs to be treated with the same posture this series has applied consistently elsewhere: it is a claim the interface is making to the researcher, not a fact the researcher has independently confirmed. This logic is structurally identical to the point made repeatedly in Smart Contract Security and Audit Report Research Fundamentals — that a passed audit does not mean the contract is free of vulnerabilities — and in Oracle and Price Feed Research Fundamentals — that using a "secure oracle" does not mean the price source has actually been verified. The TVL figure shown on a front end has its accounting methodology, its formula, and even the timestamp of the snapshot itself determined unilaterally by the project's front-end code or a third-party data aggregator. Unless a researcher traces the number back to raw on-chain state, there is no way to know whether it genuinely reflects the liquidity currently available for execution. More importantly, "this pool holds a large amount of capital" and "a trade of a given size can be executed with only minimal price impact" are related but not equivalent statements — a high headline number can easily sit on top of quite shallow executable depth, and unpacking that distinction is the focus of this section.

Independently verifying a pool's true depth breaks down into four sequential steps. First, bypass the front-end display layer and read the raw reserve data directly from the on-chain contract, establishing a baseline fact that doesn't depend on any third party's presentation logic. Second, identify the specific pool design the liquidity uses, to determine what share of the headline TVL is actually positioned near the current price and contributes to trades happening right now. Third, check the distribution of liquidity-provider addresses, to assess whether that depth could be withdrawn in bulk by a small number of addresses within a short window. Fourth, simulate a series of quote requests at increasing trade sizes to derive an empirical price-impact curve directly, rather than relying on any single number to stand in for what is inherently a multidimensional concept. The four subsections below walk through the concrete mechanics of each step in turn.

Verification step one: read raw reserve / virtual-reserve data on-chain and cross-check it against the TVL figure shown on the front end
Verification step two: identify the pool's design category to determine what share of the headline TVL is genuinely usable near the current price point
Verification step three: check LP token holding concentration to assess whether depth could be withdrawn instantly by a small number of addresses
Verification step four: simulate quotes at increasing trade sizes to plot the pool's empirical price-impact curve at a given block height

3.1 Locating the Pool Contract and Reading Its Raw Reserve Data

The first step in verification is locating the actual on-chain pool contract address behind a given trading pair — which usually means querying the corresponding DEX's factory contract for the pool address generated from the two token addresses, rather than trusting whatever address happens to be embedded in a front-end pair page. The same token pair on the same protocol can correspond to several parallel pools differing in fee tier or curve parameters, and the one the front end shows by default may not be the one the researcher actually intends to verify. Once the pool address is located, the next step is to call the contract's exposed read-only functions directly through a block explorer's "read contract" interface and pull the recorded reserve values. For a pool priced under the constant-product formula, this typically means two separate token reserve amounts; for pools using other curve formulas, such as stablecoin-swap pools, what gets returned may be a set of "virtual balance" parameters that cannot be read as usable depth on their own — recovering the actual price-quantity relationship requires combining them with the curve formula itself, which is handled together with the quote-simulation method in subsection four.

Once the raw reserve values have been read, one detail that is easy to overlook but that directly affects whether the conclusion is correct is token decimal handling: if the two tokens have different decimal precision (say, one uses 18 decimals and the other 6), comparing the raw integer values without converting first will produce a completely wrong reserve ratio and a wrong implied price. Researchers should confirm the decimals parameter declared by each token contract before doing any math, convert the raw reserve values into actual token amounts, and then combine that with an independent price reference — for instance, one of the price sources discussed in the previous section, or a quote from another high-liquidity venue — to compute the pool's nominal dollar value based on its current reserves. That self-calculated figure should then be compared against the TVL number shown on the front end. If there is a material discrepancy — for example, the self-calculated value comes in well below the displayed figure — that discrepancy is itself a concrete signal worth recording and investigating further. It may point to the front end including a stale historical snapshot that has since been withdrawn, a cache that hasn't refreshed, or an accounting methodology that lumps in capital from a different pool under the same display entry. The right response is to trace the specific source of the discrepancy, not to jump to the blanket conclusion that "the numbers don't match, so this platform is broken."

3.2 Headline TVL vs. Executable Depth: The Price-Range Problem in Concentrated Liquidity

In pools that use concentrated liquidity design — where a liquidity provider can choose to deposit capital into only a specific price range they select, rather than spreading it across the entire curve from zero to infinity as in a traditional constant-product pool — headline TVL and the depth actually available near the current price point can diverge substantially. Unpacking this mechanical trap is the focus of this subsection. The mechanism is straightforward: once a liquidity provider sets their capital into a range like "40% to 300% of the current price," that capital is indeed counted toward the pool's total value locked at the contract level, but as long as the trading price never actually moves into that range, the capital plays no part in any trade happening near the current price. Its effect is closer to a limit order parked far from the market than to spot depth available on demand. This means a researcher cannot infer how large a swap the pool can absorb near the current price with limited price impact purely from a headline TVL figure — the actual distribution of liquidity across price ranges needs to be examined directly.

Consider a purely illustrative, entirely fictional example to convey the scale of this gap: suppose an abstract "Token X / Token Y" pool shows a headline TVL of $12 million (this figure is invented purely to illustrate the methodology and does not correspond to any real pool's real data). A researcher pulls the pool's liquidity distribution by price range using a block explorer or a dedicated liquidity-distribution query tool, and finds that roughly $10.2 million of that liquidity has been placed by providers more than 40% away from the current price, with only about $1.8 million actually covering the narrow band around the current trading price. Running the numbers further, a straightforward $500,000 swap executed directly against this pool could produce price impact in the double-digit percentage range — nowhere near the seemingly negligible impact one might intuitively guess from the $12 million headline figure alone. The core methodological point this fictional example illustrates is that, for pools using price-range designs, "total value locked" should be treated as a composite metric that needs further decomposition, not as a number that can stand on its own as a measure of currently executable depth.

3.3 Checking Liquidity-Provider Concentration and Instant-Withdrawal Risk

Even in an ordinary constant-product pool that doesn't involve price-range design and whose reserves have already been confirmed to be reasonably distributed, the depth itself can still rest on shaky foundations — if the overwhelming majority of a pool's liquidity comes from a handful of addresses, that depth can in principle be pulled out rapidly by those addresses via a single withdrawal transaction at any moment, rendering all the depth measurements a researcher has taken invalid within a single block. The concrete way to check this risk is to query the holding distribution of the pool's LP token (the liquidity-provider receipt token) contract — most block explorers offer a holder list sorted by balance, from which a researcher can calculate the combined share held by the top few addresses. It's worth noting that concentrated holdings do not by themselves imply malice or elevated risk; early-stage pools, or pools for long-tail assets that simply have small trading volume to begin with, commonly have liquidity dominated by a handful of early participants as an ordinary matter of fact. The significance of this finding is that it should be logged as a risk factor to keep tracking, not used on its own to conclude that the pool has a problem.

After identifying which addresses hold concentrated positions, the next verification step is determining whether that capital sits under any kind of time-lock mechanism: if the LP tokens have been transferred into a lock contract with a clearly defined unlock timestamp, and the code has been verified to actually reject withdrawal requests before that timestamp, then at least for the duration of the lock, the possibility of that depth being withdrawn is constrained at the code level. Conversely, if those tokens remain in an ordinary externally owned account with no contract-level constraint whatsoever, then that depth can in principle be withdrawn at any moment, and any verbal claim of being "locked," or any interface label to that effect, needs to be traced back to the actual lock-contract code and its unlock parameters rather than taken at face value from a display label. Consider a fictional example: in some abstract pool, the top three addresses collectively hold 91% of the pool's LP token supply, and the address with the single largest share corresponds to an ordinary externally owned account rather than a lock contract. This finding alone doesn't support any conclusive judgment, but it is enough to flag the pool as one whose "depth stability warrants continued observation," with the researcher periodically rechecking these addresses' holdings in subsequent research notes.

3.4 Simulating Quotes at Increasing Sizes to Plot an Empirical Depth Curve

The previous three subsections verified the authenticity of the reserves, the actual usable share of headline TVL near the current price, and the stability risk of that depth — but to actually answer the question of how much price impact a trade of a specific size will incur, plugging reserve figures into the theoretical formula still isn't sufficient on its own. The theoretical formula assumes idealized curve behavior, whereas actual routing logic, splitting across multiple pools, and the pool's true state at the exact moment of the read can all cause the theoretical estimate to diverge from the real outcome. The fourth step, then — the one that finally produces concrete, actionable numbers — is for the researcher to call the read-only quote interface exposed by the DEX's router or quoter contract directly. This kind of interface typically accepts a hypothetical input amount and returns the expected output amount computed from current on-chain state, without needing to actually broadcast a transaction. For the same trading pair, feed in a series of hypothetical sizes from small to large — say, invented figures like $1,000, $5,000, $20,000, and $100,000 — record the quote result at each size, and use those results to calculate each size's percentage price deviation relative to the quote at a near-negligible baseline size, producing an empirical "trade size vs. price impact" curve.

When running this simulated measurement, it's important to note and record the specific block height or timestamp each query corresponds to, since on-chain pool state changes block by block, and the same hypothetical size can produce different results depending on which block it's read against — only by clearly labeling the measurement time does later re-verification or cross-period comparison become meaningful. It's worth repeating this measurement at different times of day to observe whether the depth curve stays stable or thins out noticeably during particular windows; that kind of fluctuation is itself a research finding worth recording. Researchers should also clearly distinguish between two different objects of study: the depth curve of a single pool, versus the combined depth an aggregator can actually route a given trade size through. Most aggregation tools, when handling larger swap requests, automatically split them across multiple pools or even multiple chain paths to execute. So the price impact an aggregator's interface displays reflects the combined outcome across multiple liquidity sources, not the single-pool depth curve discussed in this section — the two are related but not interchangeable, and conflating them will produce a mistaken estimate of the price impact a given trade would actually encounter.

4. Independently Calculating Price Impact and Slippage

Once pool depth has been verified, the next step is converting that static metric into two dynamic ones — price impact and slippage — since these are what actually determine the real cost of a given swap. The relationship between the three terms needs to be untangled first. Liquidity depth describes a pool's capacity to absorb a trade of a given size without a sharp price shift; it is a measure of capacity. Price impact describes how far the pool's quote moves, relative to the theoretical mid-price before the trade, once a specific trade size has executed; it is a measure of outcome. Slippage is the gap between a trader's actual average execution price and the quote they saw when placing the order — it contains both the deterministic price-impact component and an additional, non-deterministic component caused by other transactions being inserted during the window before the trade gets included on-chain. Researchers often blend these three together, but for any cross-pool comparison or anomaly detection, they need to be pulled apart and calculated separately. Otherwise a purely mechanical cost gets misread as an anomaly, or, in the opposite direction, genuine manipulation gets buried under the label of 'normal slippage.'

Using the standard constant-product model (x·y=k) as a baseline, price impact can be derived entirely independently of whatever number a front end displays. Take a hypothetical pool with reserve x0 = 1,000,000 units of asset A and y0 = 2,000,000 units of asset B (an implied mid-price of 1 A = 2 B), charging a 0.30% trading fee. To calculate the price impact of swapping 10,000 units of A for B, first net out the fee to get the effective input Δx = 10,000 × (1 − 0.003) = 9,970. Plugging this into the constant-product relationship (x0 + Δx)·(y0 − Δy) = x0·y0 and solving gives Δy = y0 − x0·y0/(x0 + Δx) = 2,000,000 − 1,000,000 × 2,000,000/1,009,970 ≈ 19,743. The realized average execution price for this trade is 19,743/10,000 ≈ 1.9743, a deviation of (2.0 − 1.9743)/2.0 ≈ 1.29% from the pre-trade mid-price — this is the 'theoretical price impact' before accounting for fee-deduction rounding error. Researchers should compare this hand-derived figure against the number returned by a small on-chain test transaction or a simulated call they run themselves (for instance, a read-only quote call against the router contract). If the two figures show a persistent, systematic gap beyond what fees and rounding can explain — say, a theoretical value of 1.29% against an on-chain result that consistently runs 0.4 percentage points or more higher — that is a signal the pool may be layering on an additional dynamic fee, losses from a fee-on-transfer token, or a hidden cut baked into the router contract itself. These are signals that call for further qualitative verification, not something to wave away as 'normal slippage variance.'

The key to numerically separating price impact from slippage lies in distinguishing two sources: deterministic cost and time-window exposure. Deterministic cost is the deviation derived in the previous paragraph — anything that can be computed exactly once trade size and the pool's current state are fixed, and any researcher applying the same formula at the same block height should arrive at the same result. Time-window exposure refers to the gap between when a trader submits a transaction and when it actually gets included in a block; during that window the pool's state may have already been altered by other transactions, causing the final average execution price to diverge from the theoretical value probed at order time. The way to separate the two is to log a 'dual anchor': query the pool's reserves read-only once before broadcasting the transaction (anchor one), query again immediately once the transaction is confirmed on-chain (anchor two), and cross-check the block explorer for any other transactions touching the same pool within that same block window, before or after. If the pool's state shifted materially between anchor one and anchor two, and that shift happened to work against the researcher's trade (for example, on a buy, the reserve of the asset being bought was pushed up sharply by someone else within the same block), then that extra slippage is not price impact at all — it belongs in the MEV category discussed in the next section. In practice this separation typically shows up as an inequality: observed slippage = theoretical price impact + intra-block state drift. Only by measuring the drift term separately can a researcher determine whether an unusually large slippage reading reflects a genuinely shallow pool or a transaction that got front-run.

Two further confounding factors are easy to overlook and can throw off an independent price-impact calculation. The first is the order-splitting effect of aggregated routing: many front ends split a large trade across multiple pools, or even multiple paths, simultaneously to reduce price impact. If a researcher applies the constant-product formula to a single pool in isolation, the resulting theoretical price impact will come out well above what was actually observed — and the source of that gap is routing optimization, not price manipulation. The fix is to first confirm, via a simulated router call or a public call trace, whether the trade was in fact split and in what proportions, then apply the price-impact formula separately to each sub-path and reconstruct the weighted result. The second factor is that under concentrated-liquidity designs, the 'effective depth range' shifts as price moves. Unlike a uniformly distributed constant-product pool, if a market maker has concentrated liquidity within a specific price band, once a trade pushes price outside that band the marginal liquidity available can drop sharply — the price-impact curve is no longer a smooth convex function but exhibits step-like jumps. Estimating price impact for this kind of pool cannot rely on a single simplified formula for one price range; it has to be computed piecewise — first over the liquidity available within the current price band, and if the trade size exceeds that band's capacity, repeating the same derivation for the next band, then summing the per-segment price impacts to arrive at an estimate that actually approximates real execution. Both of these factors point to the same conclusion: independently calculating price impact and slippage is not a static exercise solvable by plugging numbers into one formula — it first requires confirming the actual mechanical path a trade took, and only then choosing the calculation method that matches that path, rather than applying the same formula indiscriminately across every case.

5. Abstract Mechanism Categories of MEV and Sandwich Attacks: A Researcher's View

The price impact and slippage math covered in Section 4 answers the question of how far a given swap pushes the price. This section answers a different question: once that price path is known, did other transactions bundled immediately before or after the swap extract value from it? Phenomena of this kind are generally grouped under MEV (Maximal Extractable Value) in the research literature, and the subcategory most directly tied to AMM pricing mechanics is the "sandwich" structure built around the price impact of a single trade. A scope boundary is worth stating up front: the goal of this section is to help a researcher recognize and quantify a pool's or a route's exposure to MEV, as one input into assessing a DEX's research value and risk profile — not to lay out steps for constructing such trades. The execution-layer mechanics that a real sandwich depends on, such as front-run ordering, precise gas bidding, or private arrangements with block builders, are outside the scope of a methodology discussion and will not be elaborated here.

At an abstract level, a typical sandwich consists of three transactions bundled into the same block in a specific order. Suppose a liquidity pool currently holds 1,200,000 units of token A against 600 units of token B (illustrative figures). An ordinary user submits a swap of 20 B for A, which, under the constant-product formula, would move the pool price from roughly 1 B = 2,000 A to about 1 B = 1,935 A — a price impact near 3.3%. If an observer is continuously watching the pending-transaction pool (the mempool) and spots this trade, it can construct a first transaction that buys the same direction ahead of the user with a smaller amount of B, pushing the price up further; the user's original trade then settles at this worse price, receiving less A than it would have undisturbed; a third transaction follows, selling the A acquired earlier back into B and capturing the spread as the price reverts. The net effect of the three legs is that the user's realized slippage, in theory 3.3%, is amplified to something like 5%–7% (an illustrative range), with the difference flowing to whoever inserted the surrounding trades. What matters to a researcher is not how to construct these three legs, but how to identify, from historical on-chain data, transaction clusters with this signature — same block, same pool, opposing-then-reversing direction, and linked addresses — and to tally how often and at what scale they occur, in order to judge whether a given route was, during some period, in a state where this structure was easy to apply.

Beyond the sandwich, several other MEV subcategories are mechanically distinct but similarly organized around AMM pricing, and are worth identifying as separate abstract categories. One is back-running: the transaction itself does not change the price the user pays, but instead exploits the price discrepancy that opens up between this pool and other pools or markets once the user's trade has moved the price, capturing that gap through cross-pool or cross-market arbitrage. This activity does not directly harm the user who triggered it, but it does affect how quickly the pool's price converges back to the external market, making it a useful lens when studying a pool's pricing efficiency. A second is just-in-time (JIT) liquidity, where a liquidity provider, having observed that a large swap is about to settle, temporarily deposits liquidity into the relevant price range to capture the fee income from that one trade, then withdraws within the same block or a very short window afterward. This pattern is easier to observe in concentrated-liquidity pools, since the price-range mechanism makes it technically feasible to target a specific band with precision. A third is generalized front-running, which is not limited to swaps and can also target liquidations or the arbitrage window that opens after an oracle update; wherever its trigger condition is tied to a change in AMM quoted prices, it overlaps with the mechanism categories discussed in this section.

Methodologically, a pool's or a route's MEV exposure can be quantified from three observable signals. The first is transaction-order irregularity: within a block's transaction sequence, does a symmetric buy–user trade–sell pattern recur, with the buying and selling addresses having appeared together repeatedly in the past. The second is the round-trip magnitude of the intra-block price path: replaying, in order, every transaction touching a given pool within a block and checking whether the pool's price traces a V-shaped or inverted-V path — deviating and then reverting — rather than moving monotonically in one direction. The third is the timing and gas-priority relationship between the inserted transactions and the user's trade, for instance whether the inserted transactions consistently carry a slightly higher priority fee than the user's; that regularity alone is a statistic worth recording, with no need to reconstruct or reproduce the execution technique behind it. Aggregating these three signals over a time window — say, all trades on a hypothetical pool over the past 30 days — produces an approximate "MEV exposure rate," for example, "roughly 4.8% (illustrative figure) of large swaps in the sample period — defined as swaps exceeding 0.5% of one side of the pool's reserves — showed sandwich characteristics." A figure like this can serve as a supplementary dimension for assessing a pool's liquidity quality and price-discovery reliability, sitting alongside the depth and slippage metrics from earlier sections to form an overall research conclusion about a DEX's pricing mechanism. It does not, on its own, amount to a qualitative judgment about any specific protocol, and it does not imply that a researcher needs or ought to act on the finding by executing any trading strategy.

Same-block cluster identification: filter for transaction groups within a single block that touch the same pool, move price in opposing-then-reversing directions, and involve addresses linked across the sequence
Price-path replay: replay a block's transactions in bundled order and check whether the pool's price traces a deviate-then-revert round trip
Priority regularity: compare the gas/priority-fee gap between suspected inserted transactions and the target transaction to see if it follows a systematic pattern rather than coincidence
Cross-pool spread tracking: record how quickly the price spread for the same pair across different pools or markets converges before and after the user's trade, to help distinguish back-running from a sandwich structure

6. Hands-On: Running a Small Cross-Chain Swap Test and Logging First-Hand Data

The previous sections built up knowledge you can work out entirely on paper: how to verify pool depth, how to estimate price impact and slippage with a formula, and which category of mechanism a sandwich attack falls under. But an on-chain environment is dynamic — block ordering, other transactions submitted by other addresses in the same moment, and the latency of cross-chain processing are all variables that no static formula can fully capture. The last piece of the research methodology is to run an actual swap with a small amount you can afford to lose entirely, then place the "predicted values" calculated in Section 4 side by side with the "measured values" that actually occurred on-chain. The point of this step isn't profit or loss — it's converting what has so far been an abstract mechanism into first-hand records carrying timestamps, block heights, and transaction hashes that you can revisit and cross-check later.

A few ground rules are worth settling before you run your own test. First, only use a small amount you can afford to lose in full, and it's worth setting up a dedicated "test-only" address kept separate from your main holdings — this keeps test traces from mixing with the fund flows of your real positions and makes it easier to review this batch of data on its own later. Second, before each operation, write down the expected price impact and expected received range calculated using the Section 4 methodology, then compare it item by item once the test is done — rather than reconstructing it from memory afterward, since memory recall almost always carries confirmation bias and tends to preserve only the runs that "matched expectations." Third, the entire exercise is for research and learning purposes only and does not constitute investment advice; any on-chain transfer becomes irreversible once confirmed, so double- and triple-check the target chain, token standard, and receiving address before you act.

The predicted price impact at quote time (as a percentage, calculated using the Section 4 formula)
The actual amount received, the actual slippage backed out from it, and the gap between the two
The block height the transaction was included in, confirmation time, and the gas or cross-chain fee paid
Whether a same-direction, large-size transaction appears immediately before or after your own transaction within the same block
The measured change in the pool's two asset reserves before and after the swap (tying back to the depth-verification method in Section 3)
The test address used, the transaction hash, and screenshot-style records for later cross-checking

6.1 Getting ready to test: consolidating assets and picking a target chain

A practical obstacle that comes up often is that a researcher's crypto assets are scattered across different chains, while the pool they plan to test happens to sit on a different chain and requires a different token standard. In that case you first need to consolidate your scattered assets and convert them, as needed, into whatever the target chain actually requires, before starting the formal swap test. One common way to handle this is a non-custodial cross-chain swap aggregator. Take AllSwap as an example: it's a type of non-custodial cross-chain crypto exchange aggregator that requires no registration and no KYC, where multiple market makers compete to offer a fixed quote, and if a trade fails to execute for any reason, funds are automatically returned via the original route.

It's worth stressing that a tool like this should only serve genuine, compliant research and usage needs — it's mentioned here purely to illustrate the pre-test step of "consolidating assets onto the target chain," not as a recommendation or investment advice of any kind. Before operating one, verify for yourself that the target chain, token standard, and receiving address line up exactly with the pool you plan to test: confirm which chain the scenario actually calls for, prepare the corresponding token, and check the address and expected amount character by character before transferring. Once asset consolidation is done, everything that follows — picking the pool, getting a quote, executing, and checking the result — is the swap test this section is really about recording.

6.2 Designing a comparable test plan: principal tiers and time windows

A single test gives you too small a sample to tell "random noise" apart from "systematic bias," so it's worth designing a comparable set of runs: keep the same trading pair and the same pool fixed, but repeat the test across several principal tiers and several time windows to assemble a batch of samples you can compare against each other. Take a purely hypothetical example: say a researcher picks a "Pool AB" (the name and figures are entirely fictional) and sets four principal tiers — roughly $50, $300, $1,200, and $5,000 in equivalent value — running a swap on the same pair at each tier. They also run one round during a relatively busy network period and one during a relatively quiet period, for eight sample groups in total, covering both the "principal size" and "network congestion" dimensions.

The point of this design is that varying the principal size lets you check whether price impact scales non-linearly with trade size (which ties back to the curve behavior of constant-product and similar pricing mechanisms covered in Section 2), while comparing time windows helps you observe how network congestion and other traders' activity affect actual slippage and block-packing order. For every test group, record the "predicted value" before execution and the "measured value" immediately after, keeping the gap between the two as short as possible so the market's own movement doesn't get mixed into your price-impact measurement error.

6.3 Checking the on-chain receipt for signs of a possible sandwich

Once you have the transaction hash, you can look up in a block explorer which block your transaction landed in and what other transactions sit immediately next to it. As covered in Section 5, the abstract signature of a sandwich attack is: within the same block, a same-direction transaction appears first that pushes the price up (or down), then your own transaction executes, followed immediately by an opposite-direction transaction that pushes the price back. You can check for this pattern directly: whether that "push in the same direction — your trade — reverse the position" three-transaction sequence shows up in the block, whether the addresses initiating the first and last transactions are the same or otherwise appear related, and how far your actual execution price deviates from the theoretical, undisturbed price.

It's worth being clear that this check is for risk identification and research logging only — it's about judging whether a given transaction sits inside a suspected sandwich structure, not about reproducing or explaining how to construct one. Recognizing the pattern and carrying it out are two entirely different things, and this section only deals with the former. In most cases the price impact of a small transaction is minimal and the odds of being specifically targeted are low, so clear signs of this kind don't turn up often in small-scale tests — and that absence is itself an observation worth recording.

6.4 Organizing the data, reading it correctly, and knowing the limits

Once each sample group is organized into a table along the fields above, focus on two kinds of gaps. First, whether the difference between "predicted slippage" and "measured slippage" widens as the principal amount grows — this tells you how closely the formula you used to estimate price impact actually tracks the real pool's behavior. Second, whether "measured time to arrival and fees" differ across network congestion periods — this reflects friction costs in the cross-chain and execution layer itself, not a flaw in the pricing mechanism. Keeping these two kinds of gaps separate stops you from misattributing network-latency effects to pricing mechanics or MEV.

One last note on the limits of this exercise: patterns drawn from a small-sample test only tell you roughly what a given pool looked like during a given window — they can't be generalized into a universal conclusion, and still less used as a basis for trading decisions. If any single run turns up an unusually large slippage gap or a suspected sandwich pattern, treat it as a lead that needs further cross-verification rather than rushing to a conclusion. The process and any fictional figures described in this section are research-methodology examples only and do not constitute investment advice — always use a small amount you can afford to lose in full, and proceed cautiously with a full understanding of the risks involved.

7. Common Misconceptions in DEX Liquidity Research

When researching DEX liquidity systematically, a handful of recurring biases surface again and again. Their root cause is rarely a lack of data access — it's a misreading of what the AMM mechanism actually represents at an abstract level: mistaking a "headline size metric" for "usable depth within a specific price range," or treating "the slippage estimate shown in a front-end" as equivalent to "the price slippage actually realized on-chain." What these misconceptions share is that no single one of them is outright wrong in isolation — but judged apart from the specific price range, time window, and execution path involved, each one systematically overstates or understates a trading pair's true liquidity condition. Below is a working list of the misconceptions that come up most often in practice, each with a mechanism-level explanation of why it arises, so researchers can check their own verification checklists against it.

These misconceptions deserve their own section because they tend to surface at the exact reasoning step where a research conclusion gets decided — for instance, a judgment that sounds entirely reasonable on its face, like "this pool holds $20 million in TVL, so liquidity is ample and price discovery should be reliable," can fall apart the moment it's tested against an actual price-impact calculation. Catching these errors doesn't require additional tooling — it just requires asking, before drawing a conclusion, whether a given number reflects a book-value stock, in-range depth, or a snapshot at one particular moment; and whether a discrepancy has actually been broken down to its most granular, independent components rather than lumped under a single catch-all cause.

Distinguish between a "book-value stock metric" (TVL) and "conditional depth within a specific price range" — don't let the former stand in for the latter as evidence of adequate liquidity
Distinguish between "previewed front-end slippage" and "actual on-chain execution slippage" — record data based on the realized fill price shown in the transaction receipt
When assessing related risks, check both the slippage tolerance setting and the economics of execution cost together, not just the magnitude of price impact on its own
Break down any shortfall in the amount received into its independent components — execution slippage, service fees, and destination-chain fee deductions — rather than merging them into one figure

7.1 Misconception One: TVL Equals Depth

Total Value Locked (TVL) is a stock metric — it reflects the total dollar value of assets locked across the entire price range — whereas liquidity depth is a conditional metric tied to a specific price range. The two are not interchangeable. In pools built on a concentrated-liquidity design, market makers can choose to park capital within a narrow band just above and below the current price. Hypothetical example: a trading pair ABC/USDT shows total TVL of $12 million (figure is illustrative), but if roughly 80% of that capital is concentrated within a narrow band of ±2% around the current price, then once a large sell order pushes the price out of that band, the depth remaining to absorb further selling pressure could drop to under $2 million almost overnight. The price-impact curve would show a cliff-like jump rather than the smooth curve the TVL figure implies. Citing the TVL total alone, without breaking down how it's distributed across price ranges, can produce a depth assessment that bears no resemblance to how the pool actually behaves under stress.

7.2 Misconception Two: Quoted Slippage Equals Realized Execution Slippage

The "estimated slippage" a front-end shows before a trade is submitted is typically a simulation an aggregator runs against on-chain state at the moment the user is viewing the page — but the actual fill happens only after the transaction is packed into a block. There's a window between the two, which might be a few hundred milliseconds or, under network congestion, stretch to tens of seconds. Hypothetical example: an interface shows an estimated price impact of 0.15% with a slippage tolerance set at 0.5%; after actual on-chain execution, two large swaps land ahead of it within that window, pushing the real price impact to 0.43% — still within tolerance, so the trade executes successfully, but nearly three times the previewed figure. If a research record treats the front-end quote as the final word without checking the actual fill price against the input price in the transaction receipt, it will systematically misjudge that pool's execution quality.

7.3 Misconception Three: Low Price Impact Means No MEV Risk

The profitability of a sandwich-style attack depends on whether an attacker can insert one transaction before and one after a target trade and extract value from the slippage tolerance the victim left on the table — this has no consistent positive or negative correlation with how "deep" the pool itself is. It depends far more on how loosely the slippage tolerance is set and on whether the cost of constructing both bracketing transactions is covered by the potential profit. A very deep pool can still leave room for exploitation if the user's slippage tolerance is set loosely (3% to 5% is common under some front-ends' "auto" or "relaxed" modes); conversely, a shallower pool may not actually be a profitable target if the packing cost is too high relative to the pool's size. So the inference "this pool's price impact is small, so it should carry no related risk" overlooks the two decisive variables — slippage tolerance and execution cost — and is methodologically incomplete.

7.4 Misconception Four: The Entire Shortfall in Amount Received Is Slippage

In cross-chain or cross-DEX asset transfers, the gap between the expected and actual amount received is often lumped together and labeled "slippage," but that gap usually comes from at least three separable components: execution slippage from price impact within the DEX routing itself; a flat or proportional fee charged by the cross-chain aggregation layer; and the cost of actually completing receipt on the destination chain, which some aggregators deduct upfront from the quoted amount. Hypothetical example: swapping 100 tokens from Chain A to Chain B, with an expected receipt of 98.5 tokens but an actual receipt of 97.2 — a shortfall of 1.3 tokens. Left unbroken down, this tends to get recorded simply as "1.3% slippage," but disaggregating it might show 0.6 tokens attributable to execution slippage, 0.5 to service fees, and 0.2 to destination-chain fee deductions — three components with entirely different mechanisms and predictability. Recording them as one figure obscures which factor is actually driving the shortfall.

8. Conclusion

This article and the series' earlier pieces on oracles and price-feed research form two complementary dissections of the same object: the on-chain price. The oracle article dealt with how protocols pull prices from external sources, and its verification work centered on source diversity, update frequency, and the boundary conditions under which a feed can be manipulated. This article deals with the DEX itself as the price source, examining how its internal pricing mechanism actually works, with verification centered on real depth under constant-product and concentrated-liquidity curve models, the computability of price impact, and the MEV-style artifacts that arise when transaction ordering gets inserted into during price discovery. Neither approach relies on trusting any specific protocol; instead, each supplies an independently reproducible method at a different layer — how external information enters a protocol, and how a protocol generates price internally. The significance of this division of labor is practical: a complete price-credibility investigation usually needs to confirm both that a counterparty's DEX quote hasn't drifted from its own pool's true curve, and that the downstream protocol reading that price hasn't been misled by a single snapshot of pool state. These are two separate but complementary verification workflows, and neither substitutes for the other.

Reviewed methodologically, the verification chain built in this article proceeds in layers. The first layer is independent verification of pool depth, which requires researchers to stop settling for the TVL figure shown on a front end and instead read reserves directly, check that token decimals and precision are handled correctly, and watch for asymmetric reserves or signs that liquidity was recently pulled in bulk. The second layer is independent calculation of price impact and slippage, which requires researchers to work through the constant-product formula and the piecewise math within concentrated-liquidity ranges well enough to hand-derive the expected slippage on a hypothetical trade size from a pool's raw parameters — without leaning on any front-end simulator — and then compare that derivation against the actual quote to see whether the gap falls within the fee and a reasonable margin of error. The third layer is recognizing the abstract mechanics of MEV and sandwich attacks: being able to spot the traces of a price briefly pushed up or down by looking at transaction ordering, gas bidding, and how transactions are arranged within a block, rather than reflexively attributing every bit of slippage loss to manipulation. The fourth layer is hands-on testing — actually executing a small real cross-chain or cross-DEX swap and recording first-hand data such as the gap between quoted and received slippage, settlement time, and hidden fees, so the conclusions drawn from the first three layers can be checked against real execution outcomes. These four layers interlock, and skipping any one of them leaves the final judgment resting on an unverified assumption.

It bears repeating that every calculation method, mechanism classification, and hands-on testing procedure offered in this article is meant to help researchers build a repeatable, verifiable framework for understanding how DEX pricing works and where its risks originate. None of it constitutes advice about any specific trade timing, trade route, or asset allocation, and none of it should be read as a playbook for arbitrage, front-running, or evading other traders. AMM curve designs, liquidity-incentive structures, and MEV-related block-building mechanisms are still evolving, and the abstract mechanism categories described here — constant product, concentrated liquidity, the manipulation pathways behind sandwich attacks — are generalizations meant to illustrate method, not a specification; implementation details vary by protocol. Anyone applying this method to a real scenario should rely on data they've read on-chain themselves and on their own test results, not on the illustrative figures used in this piece. Read together with the series' earlier articles on on-chain data analysis, oracle pricing, and bridge security, this piece helps complete a fairly comprehensive research perspective on on-chain price credibility across three layers: how a price is generated, how it is read, and how it travels across chains.

Depth verification: read pool reserves and token decimals directly rather than relying on a front end's aggregated TVL figure
Slippage calculation: work through the constant-product formula and concentrated-liquidity range math by hand as an independent check on quoted prices
Mechanism recognition: identify MEV-style patterns from transaction ordering and in-block arrangement, distinguishing normal slippage from price shifts caused by inserted transactions
Hands-on verification: execute a real swap with a small amount and record first-hand data — quoted slippage, actual amount received, and settlement time
Systemic view: pair this with oracle price research and bridge security research to cover price generation, price reading, and price transfer respectively
Boundaries of method: every conclusion should rest on data you've verified yourself; none of this is investment advice or an operational judgment about any specific protocol or timing