Weighted pool development: where pools with unequal weights break
Weighted pool development begins not with code, but with an honest answer to the question: what will happen to the pool when one asset moves in price several times faster than the others.
A pool with unequal weights holds price through the product of powers — and it is precisely this math that makes it convenient for portfolios with differing volatility, but at the same time turns any sharp imbalance in liquidity into a stress test.
As long as the weights are balanced by arbitrageurs' flows, everything looks stable; as soon as the external price moves and the internal price fails to keep up, arbitrage in the pool begins to systematically drain the cheap asset, and the pool loses exactly the reserve it was assembled for.
The second source of pain is the divergence between price calculation and expectations.
The weights formula produces a smooth curve only when the invariant is strictly observed, but in practice rounding, fees, and the order of operations within a single transaction shift the result.
If price calculation and asset withdrawal live in different parts of the code, the pool starts giving out more than it should, and the difference is covered by liquidity providers — quietly, in portions, until the first large withdrawal.
The third layer is resistance to manipulation in the moment.
A pool with unequal weights without protection against instantaneous operations allows price to be shifted within a single transaction, the arbitrage difference to be captured, and the weight to be returned back, leaving the loss in the reserve.
This is not a flaw in the formula, but a consequence of the fact that price calculation, fees, and limits on weight changes are not linked to each other.
We analyze the pool as a system: the invariant, the order of operations, the boundaries of weight changes, behavior under external arbitrage. Below is how this is closed at the architecture level and exactly where the failure points lie.
What a correctly designed weighted pool provides
The key effect of a weighted pool is resilience to liquidity imbalances.
Unlike an equal-weight pool, where withdrawing a large position sharply shifts the price, here the weight of each asset is set in advance and determines exactly how the curve distributes the impact of a trade.
The higher the weight of an asset, the less it moves, all else being equal — the pool dampens one-sided surges in supply and demand rather than amplifying them.
This leads to a second consequence — a predictable exchange price. The conversion formula is known in advance, so the trade price does not depend on who trades and in what order: it is determined solely by the current balances and weights.
For arbitrageurs and market makers, this removes uncertainty, and for liquidity providers, it eliminates surprises in returns.
Slippage here is manageable rather than "whatever happens." Properly chosen weights and reserve depth determine how far the price moves for a given trade size: a large order executes with a smaller deviation, while small ones barely affect the quote.
This directly affects the returns of providers — fees accumulate more steadily because the flow of trades does not push the pool in one direction.
Manageable provider returns are not about promising percentages, but about risk control: a clear share of each asset, the absence of hidden imbalances, and predictable pool behavior under volatility.
Such a pool weathers market shifts without manual reweighting and remains attractive for liquidity over the long horizon.
Pool Operation Modes: Fixed, Dynamic, and Hybrid Weights
The weight mode is not a cosmetic setting, but a contract between the pool and its liquidity providers. It determines how the exchange price is calculated, whether the composition of the basket can be changed after launch, and which scenarios remain permissible at all. Below are the three modes that are realistically chosen between when designing a weighted pool.
| Mode | When it fits | Limitations |
|---|---|---|
| Fixed weights | A basket with a stable structure: for example, 80/20 on a pair of assets, where the proportion is part of the investment thesis | Weights are immutable after initialization; rebalancing only through swaps or external liquidity operations |
| Dynamic weights | Tasks where the composition must follow the market: indices, strategies with planned rotation of shares | A data source and a recalculation rule are required; when a weight changes, the exchange price changes, and liquidity providers must understand the mechanics in advance |
| Hybrid weights | A pool with a base structure and a limited window of change: a corridor within which weights move | More complex auditing and boundary testing; an explicit policy is required for who initiates the shift and when |
How the mode affects swapping
With fixed weights, the swap formula is predictable: the more a trade pushes the balance away from the target proportion, the more expensive each subsequent unit becomes.
This provides simple protection against draining one side of the pool and a clear slippage curve that is easy to explain to the user.
Dynamic weights add a second control loop: the price depends both on the current balance and on the specified target weight.
If the recalculation rule is formulated vaguely, a liquidity provider cannot assess the risk in advance — that is why such modes are designed together with a transparent update procedure.
What this means for liquidity management
The hybrid mode is a compromise: the base proportion protects the pool from sharp imbalances, while the corridor allows adaptation without a full rebuild of the basket.
The price of flexibility is more boundary checks and mandatory test coverage for scenarios where a weight hits its limit.
We design the mode for the task: first we determine which swap and rebalancing scenarios are needed, then we choose the weights and the rules for changing them. Describe your task — we will come back with an estimate and a plan.
How we design and implement a weighted pool: stages of work
Designing a weighted pool begins not with code, but with analyzing the pool's economics: which assets are included, how shares are distributed, who will perform swaps and why.
The weight scheme and pricing logic depend on this — a mistake at this step cannot be fixed with settings after launch.
- Audit of the task and assets. We fix the composition of the basket, the target proportions, and the swap scenarios: arbitrage, rebalancing, liquidity for a specific product. The output is an agreed-upon pool model and a list of constraints.
- Designing the weight scheme. We determine the asset weights and their allowable bounds so that the pool does not become skewed under one-sided demand. We calculate how a weight change affects the swap price and the income of liquidity providers.
- Configuring swaps and fees. We define the rate calculation formula, the size and distribution of the fee, and limits on the volume of a single operation. We verify that swaps remain predictable during sharp movements.
- Testing resilience under skews. We run scenarios: a large one-sided swap, withdrawal of a large share of liquidity, a series of arbitrage trades. We look at where the pool loses balance and how quickly it recovers.
- Security and access control. We configure roles, a pause during anomalies, and limits on parameter changes. Key actions — only through confirmed roles.
- Testing and launch. We test the contracts on a testnet with real scenarios, then deploy to the mainnet with a limited amount of liquidity.
- Handover of documentation. We provide the weight scheme, swap parameters, management instructions, and an action plan for deviations.
Each stage ends with an artifact that can be verified before moving on. Describe your task — we will get back to you with an estimate and a work plan.
What the client receives: configurations, diagrams, regulations
Weighted pool development ends not with the contract launch, but with the handover of a package your team can use to operate the pool without us.
Below is exactly what gets documented in the documentation and configurations, so that parameters don't have to be reconstructed from chat history.
- Pool configurations: files with the asset composition, initial weights, swap fee, limits on a single asset's share, and pool token emission parameters.
- Weight diagrams: tables of target and boundary weights for each asset, rebalancing rules, and the triggers under which weights change automatically.
- Access policies: administrator, operator, and pause roles, the permission matrix for changing weights, fees, and the asset list, and the multisig procedure for critical operations.
- Interaction diagrams: flow diagrams of funds between the pool, external venues, and the treasury, and the points where withdrawal delays are possible.
- Maintenance regulations: the schedule of routine checks, the response procedure for weight deviations, pool shutdown scenarios, and a step-by-step rollback to the previous state.
- Monitoring instructions: which metrics to collect, alert thresholds for liquidity and asset share, and who receives the signal.
- Deployment documentation: description of environments, the procedure for rolling out contract updates, and checks after each change.
Each artifact is tied to a specific action: the configuration shows what to change when adding an asset, the access policy shows who confirms it and how, and the regulation shows what to do on a deviation.
We agree on the weight diagrams and access policies with you before launch, not after the first operations.
Describe your task — we'll come back with an estimate and a plan, including the composition of this package for your pool.
Case study: how a pool with unequal weights stopped losing liquidity
What it was before
The pool with unequal weights was initially assembled using a standard scheme: the weights were set once at initialization and were not recalculated afterward. As long as the ratio of assets on the market stayed close to the original, everything worked as intended.
As soon as one asset declined relative to another, the pool's invariant began to drift away from the target — and every large user action started moving the price more than had been factored into the calculation.
Slippage on medium-sized trades increased severalfold, and arbitrageurs began clearing out the imbalance earlier than liquidity providers did. From their perspective, it looked like this: yield is falling, risk is rising, and the cause is not visible from the interface.
The first to leave were those who held the majority share in the pool — and the pool lost depth exactly where it was needed for large trades.
What was changed
We rewrote the weight logic: instead of a fixed ratio — dynamic adjustment with a rate limiter, so the pool does not jerk on every trade.
We added an invariant check before executing an operation: if an action pushes the pool beyond the allowable imbalance boundary, the transaction is rejected with a clear reason, rather than going through with price deterioration for all other participants.
Separately, we closed off a class of failures during sharp imbalance — previously, in that situation, some operations went through at an incorrect price.
What it became
Slippage on comparable volumes decreased, and the share of operations rejected by the invariant stayed within the expected range — meaning the protection does not interfere with normal trading.
Liquidity providers stopped exiting the pool during imbalance: previously this was the main cause of outflow, now depth is maintained, and the share of active capital in the pool has grown.
The class of failures that led to incorrect execution no longer reproduces — this was confirmed by runs on historical data and on the test network.
We cross-checked some of the architecture decisions against the open model Balancer — we took not the code, but the approach to weight mathematics and safety boundaries.
How is a weighted pool different from an equal-weight pool?
In an equal-weight pool, the shares of all assets are the same, so it works well as a currency pair: you can exchange one asset for another with minimal slippage as long as the reserves are balanced.
But as soon as one asset starts being actively withdrawn, its share drops, and every subsequent trade goes through at an increasingly unfavorable price. An equal-weight pool essentially serves a single pair and handles one-sided demand poorly.
A weighted pool assigns each asset its own weight — for example, 80/20 or 60/20/20. The exchange price is calculated using a formula where the weight determines how strongly the asset's value changes when its share in the pool changes.
The higher the weight, the more gently the price rises during withdrawals and the more resilient the pool is to imbalances: an asset with an 80% weight can be withdrawn many times more than an asset with a 20% weight before the price starts to drift. This is the key difference — weights define not only the structure but also the resilience profile.
In practice, this gives rise to different use scenarios. An equal-weight pool is chosen when you need the most predictable exchange price between two assets of similar liquidity.
A weighted pool is used when assets with different volatility or different demand coexist in the pool — for example, a primary settlement asset and a project's auxiliary token.
The weights can be changed via a governance contract, adjusting the pool's structure to match changed demand.
The exchange price deserves separate consideration. In a weighted pool, it depends on the combination of weights, so for large trades the final slippage can be either lower or higher than in an equal-weight pool — it all comes down to the current imbalance of reserves.
That is why, before launch, we model the pool's behavior on historical data and select weights to match real liquidity flows rather than abstract symmetry.
Technical concerns about weighted pool development
Technical concerns about a custom weighted pool usually boil down to four: compatibility with existing infrastructure, liquidity migration, math audit, and behavior under load. Below are direct answers without marketing.
How compatible is a custom weighted pool with already running contracts and interfaces?
The pool implements the standard swap and liquidity pool interface, so routers, aggregators, and wallets see it as a regular source of liquidity.
Weights are set at initialization and can be fixed or managed — this only affects the price recalculation logic, not the external interface. If integration with your internal services is needed, we add an adapter layer so the calling code doesn't have to change.
How do you migrate liquidity from an existing pool without downtime?
Migration happens in two steps: first we deploy the new pool and fill it with test liquidity, then we move providers' positions — either through withdrawal and re-deposit, or through a migration contract that accepts LP tokens of the old pool and issues new ones.
The second path preserves users' positions and reduces the risk of them leaving for competitors. We lock in the sequence and rollback points in the plan before launch.
What exactly does a weighted pool audit check?
The audit covers the weight math and the pool invariant, edge cases with extreme weights, protection against price manipulation, and the correctness of fee calculation. Admin rights are checked separately: who can change weights, pause swaps, withdraw funds. The result is a report with a classification of findings and fixes, not a formal signature.
How does the pool behave under high loads?
The bottleneck is not the number of transactions, but the gas cost of recalculation with a large number of assets. We keep the number of tokens within reasonable limits, cache intermediate values, and move heavy computations out of the hot path.
During sharp price movements the invariant protects the pool from depletion, but arbitrageurs are the first to take the profit — this is expected behavior, not a bug.
If your question isn't here — describe the task, and we'll come back with an estimate and a plan.
Let's discuss your weighted pool development task
To make the estimate realistic rather than an "market average", we need to understand your task at the level of the pool mechanics: which assets and weights, whether weight dynamics are needed, how access to liquidity is structured, and who acts as the provider.
The more specific the inputs, the more accurate the plan and the fewer revisions during implementation.
What's worth preparing for the first conversation:
- pool composition: the list of assets, target weights, and allowable deviation bounds;
- usage scenario: exchange, yield accrual, treasury function, or a combination of these;
- management requirements: who changes the weights and how, whether roles and restrictions on actions are needed;
- expected load: how many operations at peak and what response time is considered acceptable;
- network and compatibility: where we deploy and which services the pool must integrate with;
- existing work: contracts, schemas, documentation — if anything exists, we'll review and reuse it;
- constraints: regulatory, access-related, and timeline constraints for going live.
Next, we review the inputs, clarify ambiguous points, and come back with an estimate and a plan: stages, scope of work, what will be needed on your side, and in what sequence.
Describe the task in whatever form is convenient — we'll come back with a calculation and a proposed timeline.