Staple: Towards the Era of Stablecoin-Paired Liquidity in DeFi

1. Problem Statement:

In centralized cryptocurrency exchanges, tokens are primarily traded against stablecoins. In contrast, decentralized exchanges (DEXes) have a considerably smaller portion of stablecoin-paired liquidity compared to ETH-paired liquidity for almost all non-stable tokens. The entire DeFi ecosystem is currently facing a significant scarcity of stablecoin-paired liquidity. As of the time of writing, ETH and wBTC are the only non-stable tokens with decentralized stablecoin-paired liquidity pools exceeding $10 million [1].

The shortage of stablecoin-paired liquidity in DeFi becomes a more significant issue as new, large-scale cryptocurrency asset classes like LST [2] and RWA [3] emerge. For instance, the entire ETH LST ecosystem is backed by an ETH-paired liquidity of approximately 160,000 ETH (~$300m, only ETH is counted, ETH LST not included) [4], with almost no stablecoin-paired liquidity in DEXes [5][6][7]. This situation could potentially result in a range of adverse side effects.

1. Users bear extra frictional cost incurred by multi-hop transactions when purchasing / cashing out LSTs.

2. Ideally, ETH LSTs should be price-pegged to ETH but operate independently in terms of liquidity. However, in reality, the liquidity for ETH LSTs is nearly 100% ETH-paired. As the circulating supply of ETH LSTs surpasses that of ETH in the DeFi ecosystem,

   • the ETH LST's liquidity will be bottlenecked by ETH’s liquidity in DeFi;

   • ETH LST, potentially becoming the most substantial standalone asset class in DeFi, may continue to serve as a temporary, interest-bearing substitute for patient ETH holders. However, this role could significantly limit the use cases, user profiles, and overall growth potential within the ecosystem, ultimately constraining the value of LST protocols.

   • In the absence of an ample supply of stablecoin-paired liquidity for ETH LSTs, the entire ETH ecosystem may face a liquidity shortage within the DeFi space. Essentially, the ETH token system comprises circulating ETH and circulating ETH LSTs. As ETH LSTs grow to become a more substantial portion of this system, the availability of stablecoin-paired liquidity for ETH LSTs becomes crucial for the overall security and stability of the entire ETH token ecosystem.

In the case of RWAs (Real World Assets), there are no native tokens available like ETH for wstETH, and RWA tokens may not necessarily have a price correlation with ETH. Therefore, the concept of impermanent loss cannot be mitigated by pairing an RWA with ETH. In such situations, stablecoin-paired liquidity is naturally a preferred and more suitable option.

2. Root cause of the problem - Impermanent Loss:

The scarcity of stablecoin-paired liquidity in DeFi is not primarily driven by traders' token preferences, such as trading against ETH. Instead, it's primarily due to the significant costs associated with establishing stablecoin-paired liquidity in DeFi, both from the perspective of projects and liquidity providers (LPs). This cost disparity compared to ETH-paired liquidity for non-stable assets is attributed to the impermanent loss [8] incurred by the existing AMM mechanisms. This can be better understood through a straightforward income and cost analysis for LPs:

• Income:

  • (full or part of) transaction fees;

  • rewards from the DEX or the project for building or keeping the liquidty in the pool.

• Cost:

  • Impermanent Loss;

  • Gas for higher frequency position management.

• LP’s profit = transaction fees + rewards - IL - GAS for the position management

Assuming that the transaction fees are the same for both ETH-paired and stablecoin-paired transactions, let's compare the other three elements in the profit equation:

• Impermanent Loss - For almost all non-stablecoins, their price fluctuations when denominated in ETH are generally much smaller than their price fluctuations when denominated in stablecoins. This is because ETH captures market sentiment, while stablecoins typically maintain a stable value. Consequently, LPs providing liquidity in stablecoin-paired pools can experience significantly larger impermanent losses compared to LPs in ETH-paired pools for most non-stablecoins.

• The rewards that a project can offer to incentivize stablecoin-paired liquidity are often far smaller in magnitude compared to the potential impermanent loss experienced by liquidity providers, which can be a significant challenge. As a result, many projects opt to incentivize ETH-paired liquidity instead.

• Stablecoin-denominated price fluctuations tend to surpass ETH-denominated price fluctuations in both magnitude and frequency. This results in higher gas costs for active stablecoin-paired liquidity providers due to the need for more frequent position adjustments.

Only a limited amount of capital from a few of the most sophisticated teams can justify the impermanent loss and gas costs, given the transaction fees they can earn, but only under specific market conditions. This contributes to the scarcity of stablecoin-paired liquidity in DeFi.

3. High level description of Staple’s solution:

3.1. Decoupling price discovery from the ratio of LP token reserve using Oracle

To address the costly on-chain market-making that hinders liquidity provision, existing Automated Market Makers (AMMs), including concentrated liquidity provision, tackle the problem by automating price determination based on the dynamic reserve ratio of liquidity tokens in a pool. However, this integration of price discovery with LPs' position adjustments also introduces impermanent loss.

IL could be avoided only if these 2 elements could be decoupled. Staple tackles this by

• outsourcing the basic price discovery to the Oracle to avoid IL;

• close the gap between Oracle price and market price through a price adjustment curve that decides the small arbitraging space available.

As seen in Uniswap's case, tokens with Oracle price feed account for 90% [1] of the trading volume in DeFi. The above approach sacrifices the ability of serving 10% of the trading volume for the IL elimination in 90% of the transactions.

3.2. Ensuring the delta-neutral LP yield through relating price adjustment curve to liquidity’s Asset-Liability Ratio

While the approach mentioned above successfully eliminated impermanent loss (IL), the sequence of transactions can still cause an imbalance between the two liquidity tokens in a pool, potentially resulting in permanent loss for LPs. To safeguard LP positions from changing after sequences of transactions, Staple introduces the parameters Asset-Liability Ratio ($ALR$) for each liquidity token and the parameter Relative Asset-Liability Ratio ($R_{alr}$):

• Asset of an liquidity token in a pool: the actual amount of a liquidity token in the pool as the result of liquidity supply, liquidity withdrawal and transactions;
• Liability of a liquidity token in a pool: the net amount of supplied liquidity token;
• Asset-Liability Ratio ($ALR$) = $Asset/Liability$;
• Relative Asset-Liability Ratio ($R_{alr}$) = $ALR$ for liquidity token 1 / $ALR$ for liquidity token 2.

By maintaining the Relative Asset-Liability Ratio ($R_{alr}$) of a pool close to 1, Staple ensures that the net supplied liquidity tokens remain (almost) unchanged despite transactions occurring within the pool. To achieve this, Staple designs its price adjustment curve in a manner that price deviation from $R_{alr}=1$ results in a price adjustment in the opposite direction to encourage transactions aimed at correcting the $R_{alr}$ deviation. This figure illustrates how Staple's two-segment price adjustment curve penalizes deviations from $R_{alr}=1$. Further details can be found in the detailed description of Staple's pricing mechanism and price calculations [9].

This design also results in:

• liquidity provision in Staple is always single token based without the need of token conversion;

• the supplied tokens will not be sacrificed by the transactions;

• no position management skills are required from the LPs.

In other words, providing liquidity in a Staple pool is just like depositing in a delta-neutral yield vault.

3.3. Liquidity Sharing

The design of delta-neutral, single-token liquidity provision described above offers Staple the opportunity to substantially enhance LPs' capital efficiency and, consequently, their Annual Percentage Yield (APY). This is achieved through a two-layer liquidity pool architecture that enables a two-dimensional liquidity sharing mechanism. Details could be found in the design document for Staple's LP Architecture [10].

3.3.1 liquidity sharing with the instantly withdrawable delta-neutral yield vault

Since providing liquidity in Staple is essentially analogous to depositing assets in a single-token delta-neutral yield vault, for each token within Staple, a portion of its idle liquidity is shared with a carefully selected delta-neutral yield vault. The criteria for selecting instantly redeemable vaults and the risk management measures to safeguard the shared liquidity are all expatiated in the technical document Towards Capital Efficiency - Staple's LP Architecture and Mechanism [10]

3.3.2 liquidity hyper-allocation - time sharing liquidity across trading pairs

Staple also allows LPs' physical liquidity to be time-shared across multiple trading pairs that require the same common token. To illustrate this, let's consider an LP who supplies 100,000 USDC into Staple for yield. (S)he is allowed to hyper-allocate the 100,000 physical USDC liquidity into multiple trading pairs simultaneously as if there were 200,000 (or even more) USDC available, with some restrictions in place for risk management purposes. For example, with the 100,000 physical USDC liquidity (s)he supplied, the LP can allocate 100,000 USDC to (USDC, ETH) and another 100,000 USDC to (USDC, wstETH) at the same time. In this scenario, the LP can benefit from their share of transaction fees and liquidity rewards from both trading pairs.

This liquidity sharing mechanism allows LPs to hyper-allocate their liquidity of a single token into multiple trading pairs, and optimizes the utilization of the LP's capital across different trading pairs, allowing them to maximize their potential returns to the capital supplied. It also significantly increases the efficiency with which a protocol builds or maintains the liquidity for its token (see here [11] for reaons). The liquidity hyper-allocation could be achieved for following reasons [10]:

• The sequential nature of a blockchain network dictates that two swaps cannot occur simultaneously in two different trading pairs. Each swap must be processed in its own sequential blockchain 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).

• Trading pairs are virtual and isolated from one another. With the strict risk management measures implemented on the virtual trading pairs, they are immune to each other's possible loss, even though they share the common physical liquidity.

3.3.2 Flexible Incentive Allocation

In the single-token LP design described above, the two liquidity tokens in a trading pair are managed independently, and their ratio does not impact the trading price. This level of flexibility provides token projects with the ability to distribute liquidity rewards to the two paired tokens in any proportion they desire to incentivize the most desired liquidity distribution. Consequently, this significantly enhances the capital efficiency of projects' incentives.

For instance, consider Lido's ETH - stETH Curve pool, where the real liquidity bottleneck is ETH (as converting ETH to stETH can be done instantly through staking). However, Curve's [12] pricing mechanism mandates that rewards be provided equally to both ETH and stETH LPs. In the context of Staple, these same incentives could be distributed in any desired proportion, such as 90:10, to encourage the supply of ETH, aligning incentives more effectively with the liquidity needs of the project.

In summary, Staple's design offers the following benefits, although it does not support tokens that lack a reliable oracle price feed:

• making stablecoin-paired liquidity available in DeFi;
• higher overall income for LPs as a whole - no frictional cost and no gas fee needed for LP frequent position adjustment to avoid IL;
• delta-neutral returns for LPs to attract large idle passive capital;
• potentially much better liquidity depth for traders compared to DEX adopting concentrated liquidity AMM;
• higher LP capital efficiency - much higher than non-concentrated liquidity DEX through liquidity sharing;
• higher capital efficiency for project incentives;
• completely decentralized.

Bibliography

[1]: Uniswap Info: https://info.uniswap.org/#/pools
[2]: Bitcoin.com's introduction of liquid staking tokens: https://www.bitcoin.com/get-started/what-is-a-liquid-staking-token/
[3]: Coingecko's introduction of RWA: https://www.coingecko.com/learn/what-are-real-world-assets-exploring-rwa-protocols
[4]: Defillama's liquidity stats: https://defillama.com/liquidity
[5]: Uniswap's stablecoin paired liquidity for ETH LST pools: https://info.uniswap.org/#/pools
[6]: Balancer's stablecoin paired liquidity for ETH LST pools: https://app.balancer.fi/#/ethereum
[7]: Maverick's stablecoin paired liquidity for ETH LST pools:https://app.mav.xyz/pools?chain=1
[8]: Techopedia's exaplanation on impermanent loss: https://www.techopedia.com/definition/impermanent-loss#:~:text=Impermanent loss is a financial,makers (AMMs) are designed.
[9]: Luffy, Mihawk, Hajrudin, Clover, Rayleigh Staple's Pricing Mechanism https://docs.staple.exchange/files/Staple's Pricing Mechanism.html 2023
[10] Luffy, Mihawk, Hajrudin, Clover, Rayleigh Towards Capital Efficiency - Staple's LP Architecture and Mechanism https://docs.staple.exchange/files/Fees for Liquidity Allocation & Deallocation.html 2023
[11] Luffy, Mihawk, Hajrudin, Clover, Rayleigh Towards Capital Efficiency - Staple's LP Architecture and Mechanism Section 3.1 https://docs.staple.exchange/files/Towards Capital Efficiency - Staple's LP Architecture and Mechanism.html#3.1-benefits-for-liquidity-builders
[12] Decentralized Exchange Curve: curve.fi