Report liquidity as a capacity range instead of one headline number

Report capacity as the amount compatible with a stated execution constraint. A small set of limits gives a more useful picture than one headline number because different users may require different tolerances.

Build a capacity table

For a hypothetical fee-free constant-product pool with input reserve of 100,000, define the constraint as average output-rate shortfall relative to the initial local price. Using a ≤ b × x / (1 − b):

These are conditional model capacities. The table does not say which limit the user should accept.

Define the cost boundary

The model comes from the constant-product invariant and excludes fees. If the requested constraint concerns all-in economic cost, separate network payments and pool fees must also enter the calculation.

A final marginal-price limit requires a different capacity table. A nominal-parity stablecoin limit can differ from a current-market-reference limit. Put the definition beside the numbers.

Use quote brackets when no closed formula applies

For an actual route, collect quotes at increasing sizes and determine which satisfy each threshold. If only 500 and 1,000 have been tested, report a capacity interval rather than an exact maximum between them.

Preserve network, token direction, state and fee treatment. Repeat the table in the reverse direction when exit capacity matters. Do not add capacities across pools without considering shared routes and the changed states created by combined execution.

The strength of a capacity table is its explicit condition. It replaces “this pool has enough liquidity” with a statement that can be checked against the intended transaction.