Virtuswap virtual pools linked two AMM pools through a shared asset and temporary reserves

Updated: 19 Oct, 2026

Virtuswap virtual pools used two automated market maker (AMM) pools with a shared asset to support reserve-token swaps. The active pool accepted an approved non-native token and paid out one of its native assets. The reference pool supplied the relationship used to calculate the exchange amount. This arrangement depended on compatible assets, available output liquidity and remaining reserve capacity. Virtuswap has closed its exchange operations, so these relationships describe the platform’s historical design.

Why Was a Shared Asset Necessary?

A shared asset connected the two native-pair prices that defined the virtual exchange. Each pool supplied a different side of that relationship.

The Active Pool

The active pool held the asset that a reserve-powered swap would deliver. Its other native token provided the common link to the reference pool. During a reserve-to-native swap, the active pool took the input token into reserves and sent out the output token. The exchange changed its holdings immediately, leaving less output inventory and more of the accepted reserve asset.

The common asset remained in the active pool during that exchange; it did not pass through the trader.

The Reference Pool

The reference pool contained the reserve token and the shared asset as its native pair. Its balances helped construct the virtual AMM curve between the input and output tokens. That role established a price relationship without requiring the shared token to move through both pools. The virtual price relied on both pools, although the active pool performed the actual exchange.

Virtual Liquidity and Pool Size

The virtual pool drew its liquidity from the underlying AMM balances. Its two virtual balances together represented the total value locked in the smaller underlying pool. Adding together both real pools would therefore overstate the depth of this virtual relationship. Price impact still depended on the amount exchanged against that depth. The shared-asset construction created another trading relationship from existing liquidity; it did not create a separately funded pool or double the capital supporting the trade.

Approved Tokens and Actual Reserve Holdings

Reserve approval determined which outside tokens a pool could accept, while actual reserves showed what it currently held. The initial release used a protocol-level allowlist across the pools. The decentralized autonomous organization (DAO) governed additions and removals. Approval made an asset eligible for reserve treatment. It did not mean that every pool already owned that token, or that a particular pool had capacity for another incoming swap.

Pool composition distinguished the two native assets from current reserves and approved assets that were absent. That separation mattered for interpreting liquidity provider (LP) exposure. The current reserve list described existing additional holdings. The allowlist also described assets that the pool could acquire through later trading, subject to the applicable threshold.

Reserve Valuation and Trading Capacity

Reserve capacity limited the additional asset exposure that the active pool could acquire through reserve-powered trading.

The Native-Asset Value Base

The reserve ratio compared the total value of non-native reserves with the combined value of the pool’s two native assets. The calculation required comparable values, not a sum of unrelated token quantities. A reference pool holding the reserve asset and a native asset supplied the implied exchange rate. Each reserve balance could then be valued in terms of a native token. This connected the capacity test to pool prices as well as reserve quantities.

View image file

The original protocol description set the initial threshold at 2% on that native-asset value base. Governance could change the threshold, so the initial figure did not define every later pool configuration.

The Post-Trade Limit

A trade could proceed only if its resulting reserve ratio remained within the applicable threshold. The test considered the pool after the proposed swap, including the incoming reserve token and reduced native holdings. Room below the limit before execution did not establish capacity for every order size. Reserve exchanges could restore room by replacing reserves with native assets.

How Did Reserves Return to Native Assets?

The reserve-exchange routine replaced reserve tokens with the holding pool’s native assets through exchanges with other pools. An asset that counted as a reserve in one pool could count as native in another. Those complementary holdings allowed the pools to exchange reserves and replenish native balances.

Reserve removal depended on suitable exchanges among pools. The architecture treated reserve holdings as temporary, but the end of the original swap did not itself establish that those holdings had cleared. This distinction also affected withdrawals, because a pool could still contain reserves when an LP removed liquidity.

LP Shares Across the Pool Portfolio

LP tokens represented a proportional interest in the pool’s holdings, including any reserve assets present. Reserve-powered trading could therefore change the composition of an LP position without changing the pair that named the pool.

When liquidity left the operating protocol, the withdrawal included the LP’s relative share of native assets and any reserves present at that moment. A pool’s reserve-clearing routine did not make every withdrawal a two-token distribution. The threshold limited reserve exposure by value, while the underlying tokens and smart contracts retained their own risks.

Conditions Behind an A-C Virtual Pair

In the symbolic A-B and B-C construction, a C-to-A swap required A-B to accept C as reserves. The shared B asset connected the prices. An apparent A-C pairing therefore needed both the pricing connection and a receiving pool that could accommodate the input.

Identify A-B as the active pool supplying A.
Use B-C as the reference pool linking C to the shared B asset.
Require permission for A-B to hold C as a reserve token.
Evaluate the post-swap ratio using all reserves and the remaining native-asset value.
Distinguish the amount of A available for delivery from the reference pool’s pricing role.

If A-B lacked room for C, the common B asset still connected the prices. It no longer established an executable C-to-A reserve-powered swap on its own.

Trading Costs and Separate Incentive Allocation

Reserve-powered execution avoided exchanging the shared asset through two successive native swaps. That could remove duplicated trading costs associated with the conventional indirect route. The active pool still charged its applicable trading fee, and available depth still shaped price impact. Network transaction costs remained another execution input. The architecture changed how existing pool liquidity supported an exchange; it did not establish a fixed saving for every token pair or order.

Minerva guided the allocation of liquidity incentives, while the virtual AMM curve determined exchange amounts.

LP trading fees and applicable VRSW emissions belonged to the incentive side of the system. Reward allocation could influence where liquidity accumulated, which in turn affected the pools supporting virtual pricing. Any cost advantage still required compatible pools and sufficient reserve capacity. A change in their balances, permissions or configured charges could change which exchange the architecture supported and what it cost.

Common questions, answered

Did Native Assets Mean Only the blockchain’s Gas Token?

Native assets meant the two tokens defining a particular AMM pool, regardless of which token paid blockchain transaction costs. An asset could hold a native role in one pool and a reserve role in another. The designation followed each pool’s pair, so reading it as a network-wide token classification would misidentify the assets involved in virtual pricing.

Why Did Minting LP Tokens Account for Reserve Value?

The v1 pool contract included existing reserve-token value when calculating the LP tokens minted for a deposit. Those LP tokens represented a share of the whole portfolio, including reserves alongside the two native assets. Considering only native balances would leave out part of the value that the new liquidity provider was joining.

Could a zero-valued Composition Screen Establish an Underlying Pool?

A zero-valued composition screen did not establish that an underlying native pool existed. The historical liquidity interface also showed zero values when the selected pair had no pool. Choosing two token names therefore did not prove that a required component of a virtual pool had liquidity. The active and reference roles required actual pools with the necessary shared asset.

When Could Reserve Liquidation Replace Ordinary Reserve Exchange?

The v1 contract allowed admins or emergency admins to liquidate reserves when ordinary reserve exchange could not clear an asset. The emergency admin could call liquidateReserve only when the pool’s reserve ratio exceeded the warning threshold. The emergencyDiscount setting let the pool accept fewer native tokens for its reserve assets than ordinary virtual-pool pricing required.

Were Native Swaps and Virtual Swaps Required to Share One Fee Setting?

The v1 pool contract allowed separate fee settings for native-to-native swaps and reserve-to-native virtual swaps. The fee that applied to one route therefore did not establish the other route’s charge. Those pool trading fees were separate from price impact and the network transaction costs associated with execution.