DISCLAIMER

This whitepaper is intended solely for informational purposes. The ideas are theoretical and have not yet been implemented. The contents do not include any promises, offers, guarantees, representations or warranties, and include speculative, forward-looking statements about potential Delphi Labs projects. 

This paper is subject to change and is not guaranteed to be up to date. The paper was initially published on 10th of October 2022.

1. Vision

By enabling liquidity that’s decentralized, composable and available 24/7, automated market makers (AMMs) are the lifeblood of any decentralized finance (DeFi) ecosystem. As new chains and Layer 2 scaling solutions rapidly proliferate, they compete to bootstrap that liquidity to attract new users and devs. Ironically, their success fragments liquidity across chains.

This fragmentation is inevitable as leading AMMs are generally confined to one of two approaches:

1. Deploying standalone AMM instances, which do not communicate with each other across chains (e.g. Uniswap, Sushi, Curve). This leads to liquidity fragmentation and poor UX as traders receive suboptimal execution and LPs must manually move capital to optimise utilisation
2. Deploying a unified app-chain, which holds all liquidity (e.g. Thorchain, Osmosis). This makes it impossible to achieve synchronous composability with other dApps on native chains (specifically, they can only access liquidity via cross-chain contract calls, which is a sub-optimal UX)

In this paper, we present and explore a third approach with a novel mechanism designed to mitigate the effects of liquidity fragmentation: Shared Liquidity AMM (SLAMM). Using a coordinating appchain “Hub”, virtual liquidity pools and “satellite” deployments on other chains, SLAMMs can theoretically optimize liquidity across isolated, cross-chain pools. 

With this approach, LPs could theoretically “deposit once, LP everywhere” and passively collect fee income across chains. This would offer a better user experience (UX) and superior trade execution for end users as well as smoother returns for LPs.

The sections below explore how SLAMMs can shift liquidity between Cosmos app-chains. However, this model is by no means limited to any specific ecosystem as explored in the final section. After a general description of the mechanism, we will present a blueprint for how an existing decentralized exchange (DEX) might upgrade its logic in order to benefit from shared liquidity as well as possible improvements on the current SLAMM logic, which bear further research.

2. Background

One approach to cross-chain liquidity fragmentation is to offer the sum-total of all liquidity to each chain, regardless of the “real” liquidity available on any particular chain. This approach was described by StarkNet and Loopring (see dAMM (distributed AMM)). In this model, liquidity is initially deposited in an L1, and further divided and distributed to multiple L2s. The L2s price trades using “virtual” liquidity, behaving as though they each contain the total liquidity that was deposited into the L1. This decoupling of real reserves and virtual pricing state allows each L2 to operate independently, without the need for costly and time consuming synchronization after every transaction.

While this model does result in better pricing for traders on the L2 satellites, it has one major drawback: divergence loss (aka impermanent loss) is amplified, and grows linearly with the number of satellites sharing liquidity. This result arises from the fact that since the L2s aren’t communicating synchronously, the same liquidity can be ‘taken’ by traders on multiple chains simultaneously, resulting in increasingly imbalanced ‘real’ reserves (see Appendix 1).

Another solution to fragmentation is the “liquidity black hole” approach: attract a critical mass of traders and LPs to a single venue so that natural consolidation occurs. While this does have its benefits, it sacrifices composability; in particular, synchronous composability is not possible unless other DeFi primitives live in the same execution environment. Cross-chain contract calls to communicate with other apps are possible, but they require asynchronous mechanisms that significantly degrade the trader’s user experience and introduce significant complexity and risk.

3. SLAMM Mechanism

SLAMM aims to improve trading execution and LP returns by sharing liquidity across multiple chains, while mitigating the drawbacks of earlier approaches. SLAMM was designed with the following objectives in mind:

1. Trades made on a SLAMM satellite should be synchronously composable with other DeFi primitives
   
   AMMs are a core dependency that many DeFi protocols must integrate with. Synchronous composability significantly reduces the complexity of those interactions and improves user experience.
2. LPs should not take on additional unnecessary inventory or price risk
   
   Solutions such as dAMM substantially increase LPs exposure to divergence loss (or in the case of stablecoins, inventory risk). While LPs do benefit from exposure to order flow from multiple chains, the additional risk is hard to predict or quantify, particularly if the number of satellites increases or decreases.
3. Traders and LPs should only need to interact with satellites
   
   While the hub is a key piece of infrastructure, most traders and LPs should not need to worry about interacting with a new chain, acquiring new software, or managing new private keys. SLAMM seeks to minimize additional user experience complexity by pushing most user interactions to the satellites, on chains that users are already familiar with.

Components

SLAMM consists of a single central “hub” and many satellite deployments, with each satellite on a different chain. The hub may be implemented either as a smart contract on a host chain or as an app-chain on its own. Considerations for hub and satellite locations include:

• Liveness and security of the hub and each satellite
• Robust cross-chain messaging availability between hub and each satellite
• Cross-chain asset bridging between satellites

LPs deposit their assets directly into satellites. The hub allocates this liquidity among the satellites in a way that minimizes price impact for traders and optimally exposes it to their order flow (see Liquidity Allocation below). In general, the hub should seek to increase liquidity on satellites where high volume is expected, and decrease it where liquidity is expected to remain idle or under-utilized.

Pricing

Pricing on SLAMM satellites uses virtual liquidity (in a manner similar to dAMM). When the hub wishes to increase liquidity on a satellite, it need not move real assets; instead it can send a message to the satellite to increase its virtual liquidity by a given amount. Real assets only need to move when a satellite runs out of liquidity that is needed to repay a withdrawing LP, or when liquidity is decreased following a prior increase (see also LP Accounting further below). 

Note: The bonding curve used by satellites’ pricing formulas can be any appropriate curve for an asset pair (e.g. constant product, stableswap, or concentrated liquidity), provided the LP tokens are fungible.

Liquidity Allocation

Unlike dAMM, a key principle for SLAMM is that system-wide liquidity is zero-sum; any time virtual liquidity is increased on one satellite, it must be correspondingly decreased on another. The system’s total liquidity is therefore not amplified, and LPs do not suffer increased inventory or price risk as prices move. A satellite with increased virtual liquidity will provide traders with lower slippage, while a satellite with decreased virtual liquidity will provide traders with higher slippage. 

A key insight for SLAMM is that even though these two effects are offsetting, if the satellite with increased virtual liquidity achieves higher utilization than the satellite with decreased virtual liquidity, traders will on average suffer lower slippage. The hub’s primary responsibility is therefore to allocate liquidity such that satellites with increased virtual liquidity capture more order flow relative to their reserves than those with corresponding decreases. Fig. 1 explores how dAMMs and SLAMMs approach virtual liquidity.

Fig. 1: Differences between virtual liquidity on dAMMs and SLAMMs.

Optimal liquidity distribution that minimizes trader slippage is proportional to “volume share,” or the relative amount of volume that a satellite achieves. Intuitively, we seek to maximize each LP’s exposure to order flow, regardless of which satellite their assets were initially deposited. 

Given satellites s_0 … s_n,  optimal distribution of liquidity  L_0 … L_n for a period P is proportional to v_0 … v_n, where v_i is the fraction of total system-wide volume expected on satellite s_i during P 

LPs are already capable of allocating their own liquidity this way, but doing so is often not practical. Frequent rebalancing leads to erosion of profits from bridging costs, and this requires LPs to actively manage their capital. Furthermore, LPs may wish to use their positions as collateral with other DeFi protocols on a single satellite chain. Ultimately, SLAMMs improve the LP user experience by maintaining composability and eliminating the need to actively move capital between chains.

Note: While increased risk from divergence loss is mitigated with SLAMM, LPs do assume some additional risks, such as security of the hub as well as security of the chains onto which their liquidity is virtually assigned.

LP Accounting

To keep track of liquidity that has been decreased on one chain and increased on another, SLAMM uses virtual LP tokens (VLP) that are issued by satellites. End users will never interact with VLP tokens; they are instead a mechanism that keeps track of debts and credits between the satellites and the hub.

When the hub requests to increase liquidity on a satellite, the satellite will mint an amount of VLP to the hub representing this increase in assets. In doing so, the total amount of virtual liquidity corresponds to the sum of outstanding real LP shares owned by users plus VLP shares owned by the hub. 

Similarly, when the hub requests to decrease liquidity on a satellite, the satellite either burns a corresponding amount of the hub’s VLP shares, or issues its own VLP shares to the satellite as shown in Fig. 2. When prices change between minting or burning VLP actions, real assets may need to be bridged to properly settle outstanding debts or credits between satellites.

Fig. 2: Rebalancing virtual liquidity across satellites.

Volume Share Prediction

In order for the hub’s liquidity allocation to have the positive effects described above, the hub must be able to use statistical models to predict volume share with some degree of accuracy. In order to test whether this is possible, we examined 3 pools with fragmented liquidity: ETH-USDC on mainnet Uniswap, ETH-USDC on mainnet SushiSwap, and ETH-USDC on polygon SushiSwap.

Using the pools’ utilization rates over 24-hour time periods, we calculated their min, max, and average deltas. Large deltas indicate opportunities for re-allocation of liquidity amongst the 3 pools:

Fig 3: Differences in pool utilisation for fragmented pools.

Given these differences in utilization, optimal liquidity allocation can be calculated proportional to volume share:

Fig. 4: Volume share informs optimal liquidity allocation.

Examining the Uniswap pool more closely, we can see the effect that this liquidity allocation has on its depth. It increases depth (reduces slippage) when Uniswap’s share of volume is higher than its share of real liquidity:

Fig. 5: Pool depth increases when volume share increases.

In a real world scenario, we can’t know volume share ahead of time and must predict a future period’s volume share. Using an ARIMA model, we were able to predict volume share with a mean percentage error of roughly 10%. 

Fig. 6: ARIMA model results

Improvements to volume share prediction will have corresponding positive effects on SLAMM, and therefore validators with more accurate predictions ought to be rewarded (see Validators below).

4. Hub & Pool Architecture

Fig. 7: Hub and pool communication.

At a high level, the Hub acts as a coordinator orchestrating liquidity between all AMM satellites. Its job is to detect and potentially predict which AMM deployment will have the most volume in the near future and “shift” virtual liquidity between pools on different chains. If a particular LP’s liquidity (real or virtual) is used in a given trade, that LP is compensated in the form of trading fees. The Hub is responsible for transferring “real” tokens between chains to settle actual liquidity across its satellites. It also determines which cross-chain pools should be part of the same bundle or Pool controller (explained below). Lastly, the Hub governs over all parameters on each satellite and manages and upgrades its own logic.

Pool Controllers

Fig. 8: Pool controller architecture.

Pool Controllers manage the allocation of liquidity between cross-chain pools with the same assets (i.e. the USDC-axlUSDC pool on Chains A, B and C). A Controller is a box with multiple levers. Each lever symbolizes how much virtual liquidity is allocated to a pool (i.e. the USDC-axlUSDC pool) on a different chain. The Hub can add or remove levers at will from the “box” and change the position of each lever. An important property of the box is that, when a lever moves up (more liquidity goes to a specific pool on a particular chain) one or multiple levers must move down, in aggregate, by the same distance (virtual liquidity is “transferred” between chains and is zero sum).

Each Controller will have four main parameters:

• token0: string: token 0 identifier
• token1: string: token 1 identifier
• nextPoolID: uint: incrementing pool identifier
• pools: mapping(int -> PoolInfo): last known pool metadata

PoolInfo is a wrapper for a specific pool’s metadata which contains:

• pool: address: pool address (Interchain Account)
• token0: string: token 0 identifier 
• token1: string: token 1 identifier
• reserve0: uint: actual amount of token0 present in the pool
• reserve1: uint: actual amount of token1 present in the pool
• virtualReserve0: int: virtual reserves of token0; can be negative
• virtualReserve1: int: virtual reserves of token1; can be negative
• totalSupply: uint: number of outstanding LP tokens
• virtualTotalSupply: uint: number of outstanding VLP tokens

The Hub will be able to add and remove pools from a particular Controller as well as allocate VLP tokens. 

Besides creating new Controllers, the Hub has the power to wind-down a Controller by burning all virtual liquidity from all its associated pools as well as settling any real liquidity within those pools. The Controller would be deleted following the wind-down.

Satellite Pools

Satellite pools facilitate swapping on each DEX instance connected to the Hub. They act as any other pool found on other AMMs (e.g. constant product, concentrated liquidity pools) but also have special functionality which allows the Hub to mint and burn virtual LP tokens in order to keep track of interchain accounting. Specifically, this functionality allocates virtual liquidity across chains and pools with the same tokens.

The Hub keeps track of both real and virtual liquidity using a wrapper which contains the following information:

• pool: address: address of the pool (Interchain Account)
• token0: string: token0 identifier on the chain where the pool was deployed 
• token1: string: token1 identifier on the chain where the pool was deployed
• reserve0: uint: actual amount of token0 present in the pool
• reserve1: uint: actual amount of token1 present in the pool
• virtualReserve0: int: virtual reserves of token0; can be negative
• virtualReserve1: int: virtual reserves of token1; can be negative
• totalSupply: uint: total amount of LP tokens
• virtualTotalSupply: uint: number of outstanding VLP (virtual LP) tokens

Each wrapper is part of a specific Controller (at the Hub level) and is updated at a specific cadence predetermined by the Hub’s governance. Virtual reserve and supply data is updated both at the Hub level and at the pool level during liquidity rebalancing.

Cross-Chain Token Bridging

A common challenge in a cross-chain environment, particularly in Cosmos, is determining the best way to bridge a token between different chains. 

As an example:

• Assume someone LPs axlUSDC on chain C. That axlUSDC was bridged from A → B → C

Fig. 9: The liquidity path from Chain A to Chain C.

• The Hub needs to move liquidity from Chain C to Chain D. The shortest way to get to Chain D is C → D but most axlUSDC liquidity is bridged from A → D
• According to off-chain consensus (a predetermined IBC path approved by the community to bridge tokens between chains C and D), the best way to bridge axlUSDC from C to D is C → B → A → D

Fig. 10: Moving liquidity from Chain C to Chain D.

For every token, there must be an official path to bridge it between any two chains. This ensures that each chain has canonical versions for all the tokens it handles to avoid liquidity fragmentation. To that end, the Hub will maintain and update a registry of IBC paths that can be used to settle real liquidity between any chains.

Volume Predictors & Validators

To properly allocate liquidity, the hub needs access to predictions of volume share from external sources. Volume predictors acting independently may submit their predictions for a particular period to the hub, which is responsible for synthesizing these values into a single weighting (in a similar manner to how L1 oracles arrive at a single price from many inputs). 

Predictors may be rewarded or penalized by the hub based on how close their predictions are to reality, as reported post-facto by the satellites. Each predictor is free to implement their own model to compete for these rewards. This open competition for prediction is preferred over enshrining a single model at the protocol level, as it will likely lead to more sophisticated models and require less governance oversight. 

A natural candidate for volume predictors are the validators of the hub chain itself, should the hub be implemented as an app chain. Alternatively, if the hub is implemented as a smart contract on a host chain, prediction may be permissionless, requiring only some staked value. 

Our own ARIMA models have predicted volume share with a mean percentage error of roughly 10% when backtesting real-world data (see the Volume Share Prediction section). Further research will be needed to analyze attack vectors that may game this reward system such as wash-trading with the aim of making a specific validator’s (proposed) weight distribution match the subsequent real volume distribution.

Risks

There are two major risks associated with a Hub and satellite model. First, a chain where an AMM has a satellite might halt. This pauses withdrawals and swaps on the satellite. Second, the Hub itself could halt. The sections below detail these risks and possible consequences. Because halts can negatively impact traders and LPs, governance would need to carefully consider the risks before incorporating any chain with a history or expectation of chain halts. It is worth mentioning that this section is not meant to be all encompassing but rather presents the more notable risks when it comes to implementing SLAMM.

Cosmos Chain Halting

Though rare, chain halts can negatively impact traders and LPs. Halts on a given chain can impact not just the assets on a chain where the halt occurs but any liquidity that was routed through the halted chain. Three scenarios are possible:

1. An origin chain halts
2. A receiver chain halts
3. An intermediary chain between two other Cosmos chains halts

In the case of Numbers 1 and 2, assume there are three chains, A, B & D, which use a fourth chain, C, as an intermediary chain. Tokens are regularly transferred from A → B → C → D and vice-versa.

If chain A halts, all liquidity that was not bridged to B or D must be removed from global calculations on these chains for the duration of the halt. Global liquidity will only consist of summing up assets on B & D as liquidity previously deposited on Chain A can no longer be withdrawn.

If C halts, liquidity can’t be bridged back from D to A or B so D’s virtual and real liquidity must be subtracted from global calculations on chains A & B. Real liquidity on D can still be used to trade.

If chain D halts, all liquidity bridged there from A or B cannot be withdrawn and is removed from global calculations for these remaining chains.

In the third chain halting scenario, assume Chain B, which is used to bridge tokens between chains A and C, halts. Tokens bridged to C cannot make their way back to A. In this context, the Hub must subtract the stuck liquidity from its global liquidity calculations. Moreover, LPs may be unable to withdraw during the halt or might receive fewer tokens than they deposited because all or a portion of their funds are no longer withdrawable.

If and when any halted chain resumes, virtual liquidity calculations should re-incorporate liquidity that was formerly subtracted. LPs who did not withdraw their initial deposits would then be eligible to withdraw their pro-rata share of the remaining liquidity that was previously inaccessible. 

Hub Halting

The Hub is responsible for managing virtual liquidity and moving actual liquidity across chains. If the Hub halts, virtual liquidity can no longer be updated and actual liquidity can no longer be moved between satellites. This can leave some satellites with little to no real liquidity. As a consequence, LPs may not be able to withdraw their assets from the satellite where it was deposited or any other satellite (as virtual liquidity calculations will be halted). If and when the Hub resumes block production, virtual liquidity updates will resume, and liquidity will be moved between chains as needed. The length of the halt and the actions of LPs could lead to significant losses. Therefore, it’s imperative that the Hub’s validators are properly incentivised to ensure a healthy, robust network that’s willing and able to carefully coordinate updates.

5. Governance

As a standalone Cosmos-SDK app-chain, a decentralized network of validator operators is required to keep the Hub operational. As foundational stakeholders, validators would have the power to propose and make binding votes on smart contract parameter changes, smart contract upgrades and treasury disbursements.

These decisions would be coordinated by a ‘Decentralised Autonomous Organization’ (DAO) of validators and stakers. The protocol’s CosmWasm smart contracts would only be upgradeable by the contract’s owner address. And the owner address would be the Hub governance contract itself. Upon approval, any upgrade or disbursement would be autonomously executed. Since this process will be open and transparent, it should be very difficult to approve malicious or unsecure upgrades.

Specific decisions for SLAMM governance include:

• Approving CosmWasm deployments to establish satellite DEXs on other chains
• Adding individual pools to a shared cross-chain pool controller
• Determining acceptable IBC token paths
• Setting price curves for both general and specific pools
• Adjusting the optimisation algorithm as needed (i.e. to ensure a minimum amount of liquidity is available for specific pairs on specific satellites)
• Modifying the bounds of parameter updates (i.e. how much each pool parameter can change over X seconds). 

Parameter bounds are especially important for specific adjustments including amplification parameters, which may need to be changed frequently. Requiring votes for every individual pool’s amplification parameters would be onerous. Instead, governance could elect to change parameters within specific bounds, which are implemented in phases as predetermined targets are met.

A SLAMM’s complex architecture requires knowledgeable and active governors. Ideally, an open-source, robust risk management framework would be designed to guide the decision-making process. This framework could be used to objectively and openly score the risks of any specific modification or satellite deployment. Pool caps and other phased rollouts could help limit risks to any major upgrades. 

Ultimately, a SLAMM serves multiple masters: validators, stakers, LPs and traders, and every decision by governance has impacts on each stakeholder. A secure SLAMM ensures its long-term viability. Therefore, when in doubt about the safety or prudence of an upgrade, conservative, incremental upgrades should prevail.

6. The Future

An AMM is only as useful as the depth of its liquidity pools. Therefore, it would be advantageous to leverage an established DEX to build out a SLAMM. Any rollout could happen in phases:

1. Create a proposal on an established DEX (DEX 1) to modify its architecture from a standalone AMM to a SLAMM model
2. Assuming that the proposal passes, launch a standalone app-chain Hub. Validators would be required to stake DEX 1’s governance token to operate a full node and participate in consensus. These validators would commit new blocks in the blockchain and receive DEX swap fees in exchange for their work. Validators must also participate in governance by voting on proposals, and their votes would be weighted according to their total stake
3. Integrate DEX 1 as the SLAMM’s first satellite, and transfer control over DEX 1’s contract owner address to the Hub
4. Create proposals to launch satellites on additional chains
5. Connect pools that hold the same assets on different SLAMM satellite deployments by adding them in Pool Controllers
6. Establish cross-chain bridging paths for tokens held in all pools that were assigned to a Controller
7. Hub Validators periodically loop through each Controller and rebalance (virtual) liquidity for all pools which share liquidity  

The SLAMM architecture is currently conceptual, but it presents interesting challenges that warrant further research. Most immediately, mitigations for a black swan Hub chain halt should be explored. If such a halt did occur, LPs must be able to withdraw their liquidity across a range of satellites without any coordination coming from the Hub. Several mitigation strategies have been proposed, but few satisfy all requirements – particularly since governance would be halted with the Hub chain. Any solution should be automated and immediately actionable.

Secondly, there could be improvements to the proposed approach for refilling liquidity across chains, particularly for volatile asset pools. A potential approach would be for each satellite DEX to integrate with a credit protocol (or “money market”) and borrow liquidity for the short term (until the Hub manages to repay the loan).

Finally, a model for integrating non-Cosmos chains should be explored. Other blockchain ecosystems, which are working toward IBC compatibility including Ethereum, Polkadot, Avalanche, and Fantom are obvious candidates. Beyond those, a SLAMM could potentially leverage bridges or asynchronous messaging to integrate liquidity from non-IBC chains, including Bitcoin.

While SLAMM’s are currently theoretical, we believe they represent the ultimate end-game for AMMs. With dramatic improvements in UX for traders and LPs, they could help DEXs rival the performance and asset variety found on centralized exchanges. 

Ultimately, LPs should be able to “deposit once, LP everywhere,” and traders should have access to the assets they want to trade wherever they’d like to trade them. Thanks to their ability to provide instant finality, SLAMM liquidity can potentially be used in non-swap dApps focused on lending, stablecoins and more to provide a truly cross-chain DeFi ecosystem. We believe this unique architecture represents the most efficient and probable step toward that future, and we welcome feedback and suggestions to improve it.

Appendix 1: Divergence Loss in dAMM and SLAMM

Consider a dAMM that begins with 120,000 USDC and 120 WETH tokens, while WETH has a market value of $1,000. The “real” liquidity is split evenly between two satellites. Even though each satellite only has half of the liquidity, they each maintain “virtual reserves” equaling the total amount of deposited liquidity.

Fig. 11: dAMM satellites sharing virtual liquidity.

When the price of WETH moves to $2,000, traders and arbitrageurs will move the pool balances to match on each satellite. Consider a hypothetical single pool of 120,000 USDC and 120 WETH. Ignoring fees, the new reserves at this price can be calculated as:

or ~169,705 USDC and 84.85 WETH. To achieve these reserves, traders have deposited a net of 49,705 USDC and removed a net of 35.15 WETH. The total value of the remaining tokens in this hypothetical single pool is ~$339,411.

Table 1

Even though there are only 60,000 USDC and 60 WETH on each chain, the dAMM offers traders pricing consistent with virtual liquidity of 120,000 USDC and 120 WETH. Since both satellites offer this same depth of liquidity to traders, the amounts from the example above will be deposited / removed from both satellites, resulting in the following state:

Fig. 12: Divergence loss in dAMM.

When we sum the real liquidity in each satellite, we arrive at the red totals above, with a greater imbalance compared to the hypothetical single pool, and greater divergence loss of 11.4%.

Table 2

To contrast with SLAMM, consider a similar deployment of SLAMM with a total of 120,000 USDC and 120 ETH supplied to two satellites, using a constant product pricing curve (for easier comparison with dAMM). The hub has predicted a 2x higher utilization for pool B, and adjusts virtual liquidity accordingly:

Fig. 13: SLAMM liquidity allocation.

When the price of WETH moves to $2,000, traders will arbitrage the satellite balances to match, and again we end up with virtual reserves that match the price using the formula:

This time however, each satellite has a different value of K, and will therefore price trades differently; pool B will price trades with lower impact. So long as pool B achieves a higher share of volume than pool A, traders will on average attain lower slippage. After these trades, the pools end up in the following state:

Fig. 14: Divergence loss in SLAMM.

When we sum the liquidity this time, we end up with divergence loss equivalent to that of a single pool:

Table 3

It is important to note that while the real assets in Pool A and Pool B appear to be of different values, LP’s claims to these assets are proportional to the virtual liquidity; withdrawals from Pool B would not suffer additional divergence loss. Since real liquidity may be low relative to what an LP is owed at withdrawal time, it is possible that LP withdrawals could require asynchronous calls while the hub settles internal VLP accounting.