Polygonswap liquidity pools determine prices from changing token reserves

Pooled Assets and Pool Shares

Pool reserves supply the assets available for exchanges, while liquidity provider (LP) tokens represent a provider's share of those pooled assets. A provider contributes the pair's underlying tokens; the LP token records the resulting pool position. These objects have different units. A reserve balance counts units of one component token, while an LP balance counts units of the pool-share token. Confusing them makes it difficult to interpret either a trading quote or an ownership percentage.

A swap changes the pool's inventory. It does not require a new liquidity contribution for each exchange.

LP-token farming can add protocol rewards to eligible pool-share positions. Those rewards form a separate incentive mechanism and do not directly define the reserve-based price of a swap.

Reserve Ratios and Price Units

Reserve ratios express one token's quantity relative to the other token's quantity, so every quoted rate needs a direction. With both reserves expressed in whole-token units, dividing output reserves by input reserves produces output-token units per input-token unit. Reversing the division changes the units and the interpretation. A ratio without the token direction cannot tell the reader what an input amount would buy. Reserve quantities and a rate also describe different objects: one measures inventory, and the other relates the two assets.

A reserve ratio alone does not calculate the complete output of a finite swap. The pricing function governs the changing rate, while fee treatment and rounding rules determine the quoted token amount.

Why Does a Larger Swap Move the Price?

A larger swap generally shifts reserve proportions more, so it moves the price further when liquidity is otherwise unchanged. Price impact is the change in execution pricing caused by the swap's own interaction with available liquidity. A swap adds its input asset to the pool and removes its output asset, changing their relative balances. The pricing rule therefore responds during the exchange. The swap's average execution rate can differ from the pool's marginal price immediately before trading. Multiplying the initial rate by the entire input amount ignores this changing state and can overstate output when the swap moves the price against its own direction.

Depth Relative to the Proposed Trade

Liquidity depth describes how much trading the pool can absorb around the relevant price, relative to the proposed exchange. Other things equal, greater available liquidity at a given price reduces price impact for the same trade size. The relevant comparison holds the token pair and trade direction constant. A large token count alone cannot rank unrelated pools, because their assets and unit values can differ. Nor does an aggregate platform balance establish the liquidity available to a particular pair. The reserves serving that exchange determine the relevant constraint.

Price Impact and Pending-Transaction Slippage

Slippage describes a change between expected and executed pricing as market conditions change while a transaction is pending. Price impact describes the swap's own effect on pricing. Other trades can change reserves before a pending swap executes, so these mechanisms can operate together. A recent quote remains tied to the pool state used to produce it.

AMM integrations can enforce a minimum-output condition for an exact-input swap. Where implemented, that condition makes execution revert if output falls below the required amount. A maximum-input condition, when supported, bounds spending for an exact-output swap. These limits address different trade instructions; neither increases liquidity depth. Their availability depends on the deployed contracts and interface.

Elapsed time creates an opportunity for intervening trades; it does not specify how far the price will move.

A Quote Followed Through Settlement

A settled exchange rate requires confirmed token movements; all amounts and outcomes in this example are hypothetical.

A trader requests a quote for 73 input-token units and receives an estimate of 59.13 output-token units. The intended pool is on Polygon. A comparison with later execution requires the same pool, component tokens, direction and input amount; changing these would compare a different exchange.

View full-size image

The estimate remains provisional while execution is pending. Assume execution succeeds under the transaction's actual conditions and credits 57.67 output-token units to the intended recipient. The successful on-chain transaction and matching recipient balance increase establish the settled amount. A submission identifier alone does not establish receipt.

Spent input (input-token units): 73. Received output (output-token units): 57.67. The formula settled_rate = received_output / spent_input gives 57.67 / 73 = 0.79 output-token units per input-token unit. The earlier quote implied 0.81 on the same basis. Separating price impact from fees and intervening reserve changes requires those additional inputs.

Trading Fees and Provider Revenue

Trading fees link provider income to the activity that uses a pool's reserves. The amount that a provider receives depends on fee-generating volume, the applicable fee allocation and the provider's pool share. A quoted fee percentage alone does not determine income over a period. Fee revenue also needs a time window and a unit of account, especially when reporting value across different assets.

A swap quote may already account for its pool fee. Subtracting that same fee again would understate expected output.

Changing Inventory and Provider Returns

Liquidity provision exposes a pool share to the changing composition and market value of the underlying reserves. Trading can alter the quantities represented by that position, even while the provider retains the same LP-token balance. Fee income therefore does not describe the position's complete return. A meaningful valuation uses component quantities and consistent market prices at the same point in time. Mixing an old token price with a current reserve balance distorts the comparison.

Impermanent loss is the shortfall caused by AMM rebalancing compared with holding the original token quantities, before fee income. Fees may offset that shortfall; the word impermanent does not establish that the original price relationship will return.

The Limit of Available Output Reserves

Available output reserves limit what a funded pool can exchange, regardless of its ability to calculate prices. An automated pricing rule cannot manufacture the asset that a trade requests. As usable output liquidity becomes scarce, a reserve-based quote can deteriorate sharply; a positive token balance alone does not establish adequate depth. A permitted token-pair pool still needs usable funding. Permissionless creation describes who can establish a pool, while its balances determine its trading capacity. A displayed pool name therefore says little about the amount available for a particular exchange.

Pool Prices and Executable Alternatives

An AMM pool price can differ from prices elsewhere because each pool has its own inventory and trading state. Arbitrage links markets when traders can buy more cheaply in one venue and sell at a higher net price elsewhere. Those trades can shift reserve ratios toward outside prices. Fees and execution costs affect whether the difference supports such a trade, so alignment need not be exact or immediate.

Comparing an available pool quote with an alternative exchange requires the same asset identities, input amount and receiving units. The comparison also needs each route's fees and network costs on a consistent basis. A reserve ratio reports the pool's balance relationship; an executable quote elsewhere offers a rate for a specific exchange.