How unequal pool weights affect swap prices

In a weighted AMM, token weights help determine the price relationship. The raw reserve ratio is not sufficient when weights differ. A reserve must be interpreted relative to its assigned weight.

An 80/20 hypothetical

Imagine a two-token pool with 800 A, 200 B, an 80% weight for A and a 20% weight for B. Before fees, the marginal B-per-A rate is (B reserve / B weight) / (A reserve / A weight).

Here, both normalized reserves equal 1,000, so the rate is one B per A. Reading only 200 ÷ 800 would suggest 0.25 B per A and miss the weight adjustment entirely.

Balancer's weighted-math documentation describes the invariant and weight-normalized spot prices. The example above uses invented balances to make the units visible.

A finite swap still moves along a curve

The one-to-one marginal rate does not mean an unlimited amount can exchange at that rate. For a two-token weighted model, output depends on the reserve changes and the ratio of the input and output weights. Trading fees further affect the effective input.

Consequently, a router needs both pool balances and the configured weights to quote a trade correctly. Reusing constant-product output arithmetic for every weighted pool would produce the wrong result except in the appropriate equal-weight case.

Weights are part of market structure

A weight is not a promise that the token's outside market value remains fixed. Trades and external market conditions can still alter the pool state. Some pool families also permit parameters to change under specific rules, so the quote must use the relevant configuration.

For a swapper, the practical lesson is to compare the complete executable output for the desired amount. A weighted pool can compete with other venue types, but its reserve display needs its model context. The pool's asset quantities, weights, fee rule and execution direction together describe the pricing problem.