Pool-Ratio Deposits Match Liquidity to a Pool’s Reserves

Pool-ratio deposit sizing sets the amounts of two tokens for a liquidity deposit according to the pool’s current reserve ratio. Instead of choosing each amount independently, a provider starts with one token balance and calculates how much of the other token the pool can use alongside it. That can make more of a deposit productive, but it does not fix the price at which the tokens enter or remove the risks of providing liquidity.

For a simple two-token pool, the ratio comes from the tokens held in its reserves. If a pool holds 100 units of token A for every 200 units of token B, a deposit of 10 units of A calls for 20 units of B. The ratio is about token quantities, not dollar values: the tokens’ prices determine what those quantities are worth. A guide to choosing a Blackhole Swap pool covers the separate question of which pool may suit a trade or liquidity position. Sizing answers what amounts fit a chosen pool, not whether that pool is a good choice.

How do you calculate a pool-ratio deposit?

Calculate the required second-token amount by multiplying the amount of the first token by the pool’s reserve of the second token, then dividing by the pool’s reserve of the first token. In symbols: required B = deposited A × reserve B ÷ reserve A. If you instead know how much B you can provide, reverse the calculation to find the matching amount of A.

This gives a target, not necessarily the final amount the contract accepts. Token balances may be displayed with different decimal precision, so the calculation must use the underlying token units or correctly normalized amounts. The interface typically handles that conversion, but the wallet still needs to hold both tokens and allow any required spending approvals.

Many interfaces use the smaller of the two available balances to determine a matched deposit. Suppose your wallet holds 10 A and 30 B, while the pool ratio calls for 2 B per A. Using all 10 A needs 20 B, leaving 10 B unused. Using all 30 B would need 15 A, which you do not have. The usable deposit is therefore 10 A and 20 B, with the remaining B still in your wallet.

• Check the pool’s current reserve ratio and the two wallet balances.
• Calculate the matching amount, accounting for token decimals.
• Review the interface’s quoted deposit amounts and any minimum-amount or slippage settings.
• After the transaction, check the liquidity position received and the unused token balance.

Why should the deposit follow the current ratio?

In a conventional constant-product pool, the reserves set the pool’s current marginal price: the relative amount of one token available against the other determines what a small trade would exchange. A proportional deposit adds both assets in line with those reserves, so it increases the provider’s share without deliberately shifting that ratio through the deposit itself.

That differs from depositing a single asset or adding two assets in a ratio far from the pool’s. Some interfaces or protocols can use a swap to convert part of a single-token deposit into the other asset; that adds a trade, with its own fee and price impact. A mismatched two-token deposit may also require a conversion, or the pool’s accounting may leave part of one balance unused. The precise handling depends on the protocol.

Pool-ratio sizing also differs from simply depositing equal quantities or equal dollar values. Equal quantities make sense only if the reserve ratio happens to be one-to-one. For many pools, the matching token quantities differ substantially; their values at the current market price may be closer, but the reserve ratio is the input to the deposit calculation. Neither approach guarantees a particular value later, because token prices and pool reserves can move.

What can change the ratio, and what are the trade-offs?

Swaps change a pool’s reserves, so a ratio observed while preparing a transaction can move before it executes. Arbitrage trades may also move the pool toward prices available elsewhere. The deposit’s calculation therefore depends on a point-in-time view; a transaction may accept slightly different amounts, revert, or leave some balance unused depending on the protocol and its limits.

Pool design matters too. A broad-range constant-product pool generally lets providers add liquidity against its reserves across the curve. A concentrated-liquidity position uses a selected price range, so the assets required can depend on the position’s range and current price, not just a single whole-pool reserve ratio. Stable-asset pools may use a different pricing curve, and a pool with a different design or fee structure may behave differently from a basic constant-product example.

For most providers, the practical advantage is simpler capital matching: start from the pool’s stated ratio, let the interface calculate the counterpart amount, and avoid assuming both balances will be used in full. The trade-off is that a correct ratio only describes the deposit mechanics. It does not assess whether the pool has useful trading activity, whether its price is current, or whether the resulting exposure suits the provider.

Before confirming, check that the selected pool and token pair are correct, that the quoted amounts are close to the current ratio, and that any slippage setting is acceptable. Then watch the actual amounts deposited, the remaining wallet balances, changes in the pool ratio, and whether the position stays within range if it uses concentrated liquidity. Those signals show whether the sizing matched the pool and whether the position remains aligned with the provider’s plan.