Partnered With:

How does the liquidity "pool 2" address its native token liquidity?

Read this article in 25 Minutes

Fundamentally, having token liquidity is important because it allows new investors to easily invest in projects and unhelpful investors to exit.

原文标题：《 The Art and Science of Native Token Liquidity 》

Source: Eva Wu, Mechanism. Capital

The porridge of the night, Babbit

Why would a project party want to provide liquidity for its native token?

Fundamentally, having token liquidity is important because it allows new investors to easily invest in projects and inactive investors to exit. A little less liquidity does not destroy a strong project, and too much is futile.

In this article, we will look at the complexity of 2 pools and give some solutions for how the project parties can solve their native token liquidity.

We will introduce:

1. Liquidity ceiling target + other mechanisms to improve pool 2;

2. Uneven liquidity pools to cater to long-term participants;

3. Use the capital in the idle fiscal Treasury as a guidance mechanism;

Wait, what exactly is pool 2?

2 pools are liquidity pools with project native tokens that survive on decentralized exchanges (DEX) and artificially direct liquidity by rewarding liquidity provider (LP) tokens. While these pools are currently receiving attention as the default strategy for achieving token liquidity, they are one of the most subtle and least intuitive mechanisms in DeFi and therefore require careful attention.

How to consider incentivizing native token liquidity

The reality is that DeFi is rife with hiring capital, something that projects need to consider when setting up 2-pool rewards. The project side may consider the APY of pool 2 as the primary marketing strategy to attract participants' attention to the agreement. Not only is this uncreative and often irrelevant to the agreement itself, but our research (see Appendix I) shows how bad a marketing tool 2 pools are because the liquidity they attract is unsticky. In almost all of the dozens of pools we sampled, liquidity dropped by more than 50% in the 30 days after the incentive ended. This volatile liquidity suggests that rather than focusing marketing attention on Pool 2 and its token liquidity, project parties should focus on using Pool 2 to meet a fundamental need: facilitating investors to buy/sell project tokens under the optimal environment (low slip points).

To consider what this might look like, first understand LP's thinking.

For LP, the 2 pool is complicated because the project pays LP revenue, which must be realized from the native token, and the LP also holds the token. This is a delicate balance, as LPS are basically shorting major price movements and will only motivate LPS if they expect the tokens to trade within a range. If they expect the token price to appreciate rapidly, it becomes more profitable to stop providing liquidity and hold the token. Alternatively, if the LP anticipates a downward trend in token prices, they may opt out of liquidity. If a token is newer, then price discovery can be extreme in both directions, exacerbating what are called volatile losses. This risk of volatile losses also makes it difficult for long-term backers of the project to inject capital into Pool 2, as they may suffer from providing liquidity.

Nonetheless, the liquidity of the native token plays an important role for the project and the community, and it is worth the cost to the project side because it can start a reflexive flywheel that brings more users and attention to the protocol. * However, it's important to note that the liquidity of native tokens does not make or break an otherwise solid project. Projects with a strong product market fit will succeed even without proper native token liquidity, while projects with a weak product market fit will fail even with strong token liquidity. So, just as traditional companies need to be on a tight budget, projects should aim to find the right balance between using tokens to incentivise the core behavior of their products, and incentivise the liquidity of native tokens. In the case of pool 2, the main challenge is to determine the right cost and pay for the right amount of liquidity.

There are other ways to distribute tokens outside of pool 2. See Appendix II for a comparison of these alternatives.

Better ways to incentivize liquidity in native tokens

Despite the nuances, there is no denying that pool 2 is a useful way for projects to use their tokens (the excess tokens they have) to boost their token liquidity.

If a project party decides that 2 pools is their best approach, here are three suggestions:

1. Run a short schedule (30-90 days) to allow reconfiguration and experience testing;

2. Try to reduce APY. 100%), unlock block rewards, and non-transferable tokens to ensure consistency with long-term participants;

3. Remove the liquidity ceiling target to prevent excessive payments for liquidity;

At point (1), project parties should run shorter back-to-back experiments rather than locking themselves into multi-year plans. The shorter plan allows the project party to analyze the effectiveness of its 2 pool plan and gives the project the option to reconfigure and reevaluate its leverage/reward (see Appendix III for potential 2 pool indicators to be measured). It also allows the community to play a role in determining the project's token incentives. Interesting case studies worth studying include PancakeSwap, 1inch, and CREAM.

At point (2), the project should include a functional focus on long-term participants. In particular, the project side wants to motivate LP's who have become accustomed to holding tokens, rather than pure yield farmers who buy tokens purely because of the high APY. By making it more difficult to achieve revenue quickly, these strategies can force LP to act as a stakeholder rather than a revenue-seeking farmer. In addition to Aave's 2 pools (which we'll explore in the next section), another case study is Ribbon Finance, which experimented with drawdown fees, non-transferable tokens, and capped TVL for its early liquidity pools.

We will discuss point (3), the liquidity cap target, in the remainder of this section, and start with why it is important to have one.

If the project doesn't have a goal, they're stuck trying to figure out whether they have enough liquidity and whether they should pay more. Finding a liquidity ceiling target boils down to finding a minimum acceptable trading size for larger investors and ensuring that the pool has enough liquidity to support it within an acceptable slippage range (< 2%). Typically, an increase in liquidity can support a re-rating of protocol tokens (up) as volumes are sufficient for funds and large investors to buy in the secondary market. Removing the liquidity cap target ensures that you provide sufficient token liquidity to large investors without having to pay more than required fees.

How to withdraw the liquidity ceiling target

One framework for considering a liquidity cap target is to consider the depth of liquidity relative to market capitalisation. In the table below, we have classified different types of items by market cap and estimated the percentage of total market cap that large investors would like to trade within the 2% slip range.

Steps:

1. Determine the market value of the project;

2. Set a floor for nominal transaction size;

3. Use this equation/spreadsheet to determine how much liquidity is needed to facilitate trading sizes at different slip levels;

Example: I am the founder of a low - to mid-cap project with a market cap of $50 million. At best, I would like to facilitate large investors with 0.1% to 0.3% tokens in a 2% slip-point transaction agreement, which is about $50,000 to $150,000 in transaction sizes.

The formula used in the spreadsheet shows that a $5 million pool (50/50 weighting) can result in a $50,000 deal with a slippage of less than 2%. This means I don't need more than $5 million in my pool to accommodate large investors, and I need up to $2.5 million in my own tokens and $2.5 million in USDC/ETH pools.

Note: Designed for traditional AMM pools, Uniswap V3 changes these numbers and requires participants to have more confidence in price movements.

However, having high token liquidity is not always beneficial, and while a liquidity cap target can be used as a guide to prevent overpaying for token liquidity, it is not the goal. For early projects, token liquidity is not as important as focusing on the product and finding product market fit. Low cap projects that are overly focused on token liquidity risk attracting traders/speculators at the expense of long-term investors and stakeholders.

The force of the uneven pool

Of the previous two pools, Aave's incentive token pool is the only one without a high APY. 5%) to maintain long-term liquidity.

In this 80/20 AAVE/ETH Balancer smart pool, LP provides liquidity to earn AAVE and BAL transaction fees and rewards. The success of Aave provides a window into the benefits of uneven pools over traditional 50/50 liquidity pools.

The main benefit: less volatile losses in uneven pools.

The reduced risk of volatile losses means that LPS are more willing to provide liquidity at lower yields. From a cost point of view, this reduces the amount of money the agreement needs to reward.

At the same time, token holders can put their money to work, and the uneven pool limits their risk of volatile losses if the token's price rises. This leads to better incentive alignment, as they can earn transaction fees and rewards without losing most of their exposure to tokens.

Although an unevenly weighted pool is more friendly to LP, there is a tradeoff. The main disadvantage is that high TVL is required to achieve the same slippage environment. As shown in the figure below, a 50/50 liquidity pool is the most efficient for slippage.

Source: Balancer Labs

In addition, uneven pools also affect token appreciation as the project matures, as pools require more stablecoins /ETH (compared to 50/50 pools) to raise the price. After the initial raise/allocation is completed and the project matures, the project can consider adjusting to a 50/50 pool to allow for better slippage and more efficient price discovery. On the platform side, Balancer is currently the only protocol offering uneven pooling, while Sushiswap plans to release a forked version (Trident) in the next few months.

Create a hybrid liquidity approach using the idle fiscal pool

Existing projects that have raised funds or have healthy/diversified funds should consider using all or part of their Treasury pool's initial liquidity and converting some of it into ETH/USDC to provide dual liquidity. This has a number of benefits, including:

1. Allow project parties to earn additional income from transaction fees;

2. Allow for better control of liquidity, rather than just being affected by APR;

3. Create an automatic "repurchase" mechanism if the token price drops;

4. Diversify the fiscal pool (combine other asset pairs, such as ETH/USDC);

It is important to note that the project side bears the risk of volatile losses.

In the case of dHEDGE, the deal started out rewarding around 10,000 DHT per week (about $20,000 at the time), but quickly moved to providing most of the liquidity at $3.5 million (in a 50/50 pool). By using their Treasury to pay for liquidity, they are able to reduce the dilution of governance tokens and use it to incentivise people to use their platform. In terms of revenue, dHEDGE charges between $500 and $1,000 a day in trading fees, and has charged more than $45,000 in the past 2.5 months.

Here are some out-of-the-box ways in which protocols can use 2-pooling to implement mixed policies:

1. Use the spare Treasury to provide a liquidity target of 50-80%, and then use protocol tokens to stimulate additional liquidity if necessary;

2. Use the Treasury to provide liquidity and charge transaction fees to incentivize additional LP;

3. Use the idle long-term fiscal Treasury to provide liquidity for the first six months to one year, and conduct short-term experiments on liquidity incentive;

Alternatively, the project can simply remove the liquidity cap target and use the spare Treasury to provide liquidity without incentivizing any additional LP.

conclusion

There is no exact science to implement protocol native token liquidity. But the various approaches we've explored, such as liquidity cap targets, uneven (i.e., 80/20) pools, and Treasury pool liquidity provision, allow thoughtful founders and investors to address the liquidity issue of native tokens. While most of this guide is just the tip of the iceberg, we hope it will contribute to the discussion around designing more sustainable and efficient token liquidity.

Many thanks to the Mechanism team (Andrew, Ben, Marc, Daryl, Alec) for helping refine these ideas and sifting through the data, as well as to Tristan, Zaheer and Julian for their useful feedback.

Nothing in this article constitutes investment advice.

The appendix

Appendix I: Asset Pool Study

Nansen's study analyzed all token transfers across 400 mobile farms and found that a large percentage of earning farmers (36.4 percent) withdrew within the first 5 days of entering the pool, whereas today only 13 percent of addresses continue to be LP's.

Source: Nansen Research

Again, the heat map above gives us an intuition of what's going on for these benefit farmers. Forget years of incentive plans, most of the benefit farmers were out of the pool by day 75. To further quantify this, almost half of the revenue farmers entered at startup (that is, the farmers at the top of the information funnel) leave within 24 hours, and then 70% of the revenue farmers leave within 3 days. As LP rewards are reduced and diluted, participants who are attracted by incentives will simply take their token rewards and transfer liquidity to another pool.

After analyzing 2 pools across 12 projects, we also found that while most incentive pools experienced a temporary increase in liquidity, most liquidity levels declined by more than 50% within 30 days of the rewards stopping. One example is Pool 2, which Badger launched at the peak of the bull market.

Here, the data shows that attempts to channel liquidity in the token pool (see red zone) in early December largely failed, with bullish sentiment driving the pool's liquidity. Starting in March, the pool liquidity decreased in proportion to the decrease in rewards, indicating that they attracted mercenary LP's who sold their tokens as the rewards decreased.

The chart also highlights the reflexivity of these incentive pools, because as LP sells tokens, it lowers the APR, which causes more LP to exit the pool. We see a similar pattern in the $DHT, $ALPHA, and $1INCH pools.