Towards Capital Efficiency - Staple's LP Architecture and Mechanism

1. A Two-Layer Liquidity Pool Architecture:

As seen in Staple's pricing mechanism, the reserve ratio of the two liquidity tokens in a trading pair no longer influences price determination. This means that liquidity can be provided to a specific token within a Staple trading pair without the need for token conversion. Furthermore, in Staple's trading model, liquidity tokens are not subject to impermanent loss. As a result, providing liquidity in Staple becomes quite similar to depositing funds in a single token delta-neutral strategy vault.

Based on the above understanding, we've developed a two-layer single-token architecture for Staple's liquidity pool. On top of this, we've implemented a two-dimensional liquidity sharing scheme to substantially enhance the capital efficiency of liquidity providers (LPs). The structure of the two-layer liquidity pool is illustrated in the following graph.

Figure 1 - Staple's 2-layer liquidity pool architecture

1.1. Layer 1 - Single Token Pool

In the first layer, a liquidity provider (LP) contributes liquidity to a specific single-token liquidity pool. Each liquidity token is associated with only one such pool, and upon its creation, a dedicated smart contract is established. When an LP provides liquidity, both the assets and liabilities of this token pool increase by the supplied amount (See Staple's Pricing Mechanism). Conversely, when an LP withdraws liquidity from a pool, the assets and liabilities decrease.

To support the liquidity sharing mechanism, as discussed in the next section, we categorize a liquidity pool based on the following metrics of its associated token, resulting in a total of three different grades.

• onchain liquidity;

• offchain liquidity;

• onchain transaction volume;

• offchain transaction volume;

• redeemability - if it's an LST, the unstaking time.

The grade serves as an indicator of the reliability of price sources available to an Oracle. It is used to determine the extent to which liquidity sharing is permitted for a given liquidity pool. More information on liquidity sharing can be found in the Chapter 2 Liquidity Sharing for a detailed explanation.

1.2. Layer 2 - Virtual Trading Pair

Once an LP has provided liquidity to an L1 token pool, they are required to allocate the supplied liquidity to the chosen trading pairs. An essential concept in this context is the "Virtual Trading Pair" (VTP). In Staple, while all the physical tokens are located within L1 token pools, a trading pair is considered virtual. The quantities of assets and liabilities for each token in a trading pair are numerical values recorded and maintained in the "controller" smart contract. These values are updated according to the following rule:

• When an LP allocate liquidity to a token in a trading pair, both the assets and the liquidity of this token in the target trading pair are updated;

• When an LP deallocate liquidity of a token from a trading pair, both the assets and the liquidity of this token in the target trading pair are updated;

• When a swap takes place, the assets of both tokens in this trading pair are updated.

  An LP can allocate his supplied liquidity of a token to multiple VTPs, as long as the token is part of the VTP. This two-layer VTP design brings about multiple benefits:

1. Compared to the design of having one dedicated smart contract for each physical trading pair, utilizing one smart contract for each liquidity token and abstracting the trading pair results in significant savings in terms of both code space and gas fees;

2. This design offers liquidity providers (LPs) the flexibility to easily adjust their liquidity allocation across multiple trading pairs;

3. This design enables the implementation of a liquidity sharing scheme that substantially enhances the capital efficiency of liquidity providers (as detailed in Chapter 2 Liquidity Sharing).

1.3. Update of Assets and Liabilities

A layer 1 liquidity pool's assets and liabilities are the combined results of 3 types of user operations: deposit, withdrawal or swap, as shown in the following table.

LP's Action	Pool's liabilities to the LP	Assets of the pool	Liabilities of the pool
Deposit	increases	increases	increases
Withdrawal	decreases	decreases	decreases
Transaction	unchanged	sold token : increases / purchased token : decreases	unchanged

Assets or liabilities of an LP and an affected VTP are both updated following the rules below:

LP's Action	Assets of LP in the pertinent VTP	VTP's liabilities to LP	Assets of the affected VTP	Liabilities of the affected VTP
Allocation	increases	increases	increases	increases
Deallocation	decreases	decreases	decreases	decreases
Transaction	purchase : increases / sell : decreases	unchanged	sold token : increases / purchased token : decreases	unchanged

In addition, allocation fees, deallocation fees, transaction fees and VTP rewards will trigger the update of liabilities at layer 2, but nothing at layer 1. Fees are charged to a LP or a trader during 1 of the above 3 Layer 2 operations and recorded (together with rewards) as VTP's additional liabilities to all its LPs for the token concerned. When deallocated, fees and rewards are held in a seperate account and are claimed indepedantly. Therefore, fee charging and fee claim do not have any impact on the assets and liabilities of layer 1 pools.

2. Liquidity Sharing

2.1. Liquidity Sharing Between A Token Pool And A Delta-neutral Strategy Vault

After analyzing transactions on mainstream non-concentrated liquidity DEXes such as Curve and Balancer, we have observed that over 98% of the transactions involve trading sizes that are within a 2% range of the pool liquidity. This trend is further amplified by DEX aggregators, which often break down transactions into smaller chunks and allocate them in a way that only the edges of DEX liquidity are utilized to achieve low slippage and competitive rates.

Additionally, Staple's pricing mechanism mandates that transactions occur within the initial segment of the price adjustment curve (see Staple's Pricing Mechanism). This segment typically covers only 6% to 9% of the entire liquidity. Consequently, we can anticipate that transactions executed in Staple will primarily tap into a small portion of the provided liquidity, maintaining a non-concentrated nature.

Instead of wasting the idle liquidity, we share part of the idle liquidity in a Staple's L1 liquidity pool with an instantly redeemable single-token delta-neutral strategy vault, as depicted in the following diagram. When this liquidity is shared with a strategy vault, it's important to note that the shared vault liquidity is NOT discounted when calculating the available pool liquidity for a transaction.

Figure 2 - Liquidity sharing between L1 liquidity pools and delta-neutral vaults

To facilitate the initiation and approval of liquidity sharing between a token pool and a proposed strategy vault, a community-governed liquidity sharing verification process is recommended. This process should determine the eligibility of the strategy vault for liquidity sharing and, if applicable, establish the percentage of the pool liquidity to be shared with the vault. A suggested vault rating, along with the corresponding target share, is outlined below:

1. R1: 60%
2. R2: 50%
3. R3: 40%
4. R4: 30%
5. R5: 20%

The vault rating could be made based on the following measurements:

• the security rating of the strategy vault;

• the security rating of the protocols integrated in the strategy;

• the stability and the financial risks of the strategy;

• the capacity of the strategy vault;

• the price impact on the related liquidity token when 50% of the shared liquidity is withdrawn from the strategy vault;

• the yield of the strategy vault.

The strategy vault rating should undergo a review whenever the pool's size experiences a 50% change from the previous checkpoint or in the event of significant changes related to liquidity or strategy.

Furthermore, a dynamic liquidity relocation mechanism should be established between a token pool and a vault, incorporating the following adjustment criteria:

• when the pool's liquidity is smaller than the minimal value required m, no liquidity is shared with vault;

• when the pool's liquidity (excl. vault liquidity) drops 10% below the minimal value required m for 24 hrs, retrieve liquidity from the vault to the pool until m is reached;

• when the vault share drops to the lower level in the target share list, share more liquidity with the vault until the vault share recovers to the target;

• When the vault share rises to the higher level in the target share list, retrieve liquidity from the vault to the pool until the vault share recovers to the target;

To avoid conflicts, no token withdrawal should be allowed during the process of liquidity relocation between a token pool and a strategy vault.

2.2. Liquidity Sharing Across Multiple VTPs

Description

In Figure 3, we see $10m wstETH is hyper-allocated to 2 L2 VTPs:

• $7m wstETH liquidity to ETH-wstETH VTP;

• $9m wstETH liquidity to USDC-wstETH VTP.

This represents Staple's liquidity hyper-allocation mechanism, where $m$ physical liquidity from an L1 token pool can be distributed across n virtual trading pairs as if there were $l \times m$ liquidity available in the liquidity pool. To prevent the cascading of liquidity distribution among VTPs, $l$ is intentionally set to a value smaller than $n$. It's interesting to discuss why liquidity hyper-allocation can be realized with Staple's LP architecture:

• The sequential nature of a blockchain network dictates that two swaps cannot occur simultaneously in two different VTPs. Each swap must be processed in its own sequential blockchain transaction. This arrangement enables the time-sharing of the same physical liquidity among transactions executed in different VTPs, provided that there is enough physical liquidity of the shared token available for each transaction.

• In Staple's architecture, the physical liquidity pools (L1) are structured around single tokens, whereas liquidity is numerically allocated to virtual trading pairs (L2). This design serves the dual purpose of enabling the time-sharing of single-token-based liquidity across multiple VTPs and achieving efficient data updates, all while keeping costs low.

• A VTP functions similarly to a delta-neutral strategy vault without experiencing impermanent loss. Consequently, the liquidity in a shared pool should consistently remain close to the net supply, surpassing the liquidity shared with VTPs. This ensures that there is ample liquidity available for sharing with VTPs.

• VTPs are isolated from one another. To mitigate risks, a restriction is placed on liquidity indentation, such as a 10% limit, for each VTP's shared token. When this limit is reached, only uni-directional transactions are permitted to recover the assets of the affected token, as detailed in Staple's Pricing Mechanism. By regulating a pool's liquidity sharing factor based on the maximum allowable liquidity deviation in each associated VTP, we can ensure that there is always an adequate supply of physical liquidity available to all VTPs, even in cases of unexpected liquidity indentation for a VTP's shared token.

Figure 3 - Hyper-allocation of L1 physical liquidity to L2 virtual trading pairs

Restrictions In Liquidity Hyper-allocation

In order to mitigate potential risks associated with liquidity hyper-allocation, specific rules have been developed for governing this process. To accomplish this, we begin by categorizing LP tokens into three security tiers based on the criteria outlined in section 1.1. Each tier is then assigned a maximum allowable VTP sharing factor for its respective tokens.

Tier of LP Token	Max. Allowed VTP Sharing Factor
1.	92%
2.	90%
3.	80%

If an LP assigns all of the liquidity for a particular token to a single VTP, then 100% of the liquidity can be allocated to that VTP. However, if an LP allocates liquidity for token A to multiple VTPs, the following rules apply:

1. Liquidity of token A could be shared across no more than 3 VTPs.

2. Liquidity of token A could be shared with no more than 2 VTPs having tier 3 LP token other than token A.

3. The maximal amount of liquidity of token A allowed to be allocated to a selected VTP is the maximal allowed VTP sharing factor of the paired token B in that VTP.

4. The overall hyper-alloacted liquidity of token A is the sum of all the liquidity allocated to all selected VTPs.

Rules 3 and 4 can be demonstrated through the following example:

Let's assume we have three LP tokens: A, B, and C. Tokens A and B fall into tier 1, while C is in tier 3. We also have three VTPs: (A, B), (A, C), and (B, C).

Now, to enhance the yield, we aim to hyper-allocate an amount x of token A into both VTP (A, B) and VTP (A, C). The maximum allowable liquidity allocation to each of the selected VTPs is 92% and 80%, respectively. This is because token B belongs to tier 1, and token C is in tier 3.

If we allocate the maximum permitted liquidity of token A to these two VTPs, the overall hyper-allocated liquidity of token A would reach 172%.

3. Benefits of The Design

In addition to expediting the creation of substantial stablecoin-paired liquidity within the DeFi space, Staple's LP design substantially enhances the capital efficiency of current DEXs. This improvement benefits liquidity builders, passive liquidity providers, and traders alike.

3.1. Benefits for Liquidity Builders

Thanks to the elimination of impermanent loss and the relatively low costs involved, protocols can now efficiently expand their existing ETH-paired liquidity to what is arguably the more valuable stablecoin-paired liquidity available on Staple.

Protocols seeking to initiate or enhance the liquidity of their tokens on DEXs will be able to amplify the liquidity increase for every dollar of incentives offered by multiple times:

1. Additional returns are generated through the liquidity sharing between a Staple token pool and a strategy vault. This can either reduce the incentives that a protocol needs to offer or enhance the effectiveness of the incentives provided.

2. The capability to hyper-allocate liquidity across multiple VTPs empowers a single-token liquidity provider to benefit from up to 2.8 times the transaction fees and rewards from all the VTPs to which they've allocated liquidity. This not only lowers the required level of incentives to foster VTP growth but also enhances the monetary value of these incentives.

3. A protocol can establish liquidity around their token (a T2/T3 token) more cost-effectively on Staple compared to existing DEXs. To illustrate this, let's consider an LP providing USDC liquidity to a VTP of T1 tokens, for example, {USDC, ETH}. The attractive APY boost resulting from the liquidity hyper-allocation mechanism is likely to motivate the LP to distribute the allocated USDC liquidity to other incentivized VTPs, including those consisting of USDC and a T2/T3 token.
   
   In this scenario, these VTPs receive the shared USDC liquidity that may not have been directly injected into them in any other DEX. They were not the LP's initial choices. Therefore, the liquidity hyper-allocation mechanism effectively attracts additional liquidity to VTPs for T2/T3 tokens.

4. Staple provides full flexibility to a protocol when distributing incentives within a VTP. The protocol can freely decide in what ratio the rewards are distributed between the two tokens in a VTP. This feature, combined with Staple's single-token liquidity pool architecture, significantly enhances the capital utilization of the protocol's rewarding tokens.

   
   In contrast, existing AMM DEXes typically require that all incentives be evenly distributed between the two tokens in a trading pair. However, for most protocols, the liquidity in tokens like ETH or, preferably, USDC/USDT is more valuable in the trading pair compared to in their native tokens. This is because it's generally more costly to create ETH/USDC/USDT liquidity.
   
   For example, consider Lido's wstETH pool, which mainly serves the purpose of facilitating instant exits for (w)stETH holders (from (w)stETH to ETH), as the other direction of trading can be replaced by staking directly. Therefore, ETH is the crucial liquidity needed in this pool. However, within the current AMM framework, nearly 50% of the incentives must be distributed to (w)stETH, leading to a substantial underutilization of capital.
   
   On Staple, the protocol has the flexibility to allocate all incentives to ETH/USDC, effectively avoiding the degradation of capital utilization and better aligning rewards with the desired liquidity.

3.2. Benefits for Liquidity Providers

LPs' Annual Percentage Yield (APY) experiences an organic boost thanks to the two levels of the liquidity sharing mechanism, which effectively drive up liquidity utilization.

3.3. Benefits for Traders

The liquidity hyper-allocation mechanism effectively augments the liquidity accessible for use in a VTP, indirectly decreasing transaction slippages.