Author: William Bruce
August 10, 2021
Why do projects want liquidity for their native token?
Fundamentally, having liquidity for a token is important so far as it allows new investors to easily buy into a project and inactive ones to exit. Any less will not derail a strong project and any more is just in vain.
This piece will be confronting the complexities of pool 2s and walking through how projects can think about engineering liquidity for their native token.
We’ll cover:
- Liquidity cap targets + other mechanisms to improve a pool 2
- Uneven pools to cater to long-term participants
- Leveraging capital in idle treasuries as a bootstrapping mechanism
Wait, what’s a pool 2?
Pool 2s are liquidity pools for a project’s native token; they live on decentralized exchanges (DEXs) and are artificially bootstrapped by rewarding liquidity providers (LPs) in the same native token they’re providing liquidity for. Whilst these pools are currently in the limelight for being the default strategy to achieve token liquidity, they are one of the most nuanced and unintuitive mechanisms in DeFi and thus demand careful attention.
How to think about incentivizing native token liquidity
The reality is DeFi is rife with mercenary capital and this is something projects need to consider when setting their pool 2 rewards. Projects might consider a pool 2’s APY as the main marketing tactic to bring attention to their protocol. Not only is this uncreative and often irrelevant to the protocol itself, but our research (see Appendix I) shows how pool 2s are poor marketing tools because they attract liquidity that exists only to farm incentives. Among the dozens of historical pool 2s we sampled, almost all saw 50%+ liquidity drops just 30 days after incentives ended. This fickle liquidity indicates that instead of focusing marketing attention on a pool 2 and its token liquidity, juicing rewards in order to gain more attention, projects should focus on using pool 2s to serve a fundamental need: facilitating investors to buy in/out of a project in an optimal environment (low slippage).
Thinking about what this looks like starts with understanding how LPs think.
On LPs, pool 2s are complex because projects are paying LPs in yield that must be realized from the native token while also holding the token. This is a nuanced balance since LPs are essentially shorting major price movements and are only incentivised to LP so long as they expect the token to trade within a range. If they expect the token price to quickly appreciate, it becomes more profitable to stop LPing and hold the token; meanwhile, if LPs expect the token price to trend downwards, they will rush to exit their positions. If a token is newer, it’s possible that price discovery could be extreme in either direction, accentuating what’s known as impermanent loss. This impermanent loss risk also makes it difficult for a project’s long-term supporters to contribute capital to the pool 2 since they could lose out on the upside.
Nonetheless, liquidity for a project’s token plays a large role in opening up the project to the community. Native token liquidity is worth paying for because it can kick off a reflexive flywheel that brings more users and attention to the protocol.* However, it’s worth noting that liquidity for the native token doesn’t make or break an otherwise solid project. Projects with strong product market fit can succeed even without proper native token liquidity, and projects without strong product market fit will fail despite strong native token liquidity. Therefore, in the same way traditional companies need to be rigorous about their budget, projects should aim to find the right balance between using their tokens to incentivise behaviours that are core to their product and incentivising native token liquidity. As far as pool 2s go, the main challenge lies in figuring out the right cost and paying for the right amount of liquidity.
*There are also other ways to achieve token distribution beyond pool 2s. See Appendix II for a comparison of those alternatives
Ways to better incentivize native token liquidity
Despite their nuances, pool 2s are undeniably scrappy ways for projects to leverage their token (something they have in excess) to bootstrap token liquidity.
If a project determines that a pool 2 is the best method for them, here are three recommendations:
- Run shorter programs (30 – 90 days) to allow for re-configuration and empirical testing
- Experiment with strategies such as lower APYs (<100%), vested block rewards and non-transferable tokens to ensure alignment with longer term participants
- Back out a liquidity cap target to prevent overpaying for liquidity
On point one (1), projects should conduct shorter back-to-back experiments as opposed to locking themselves into multi-year programs. Shorter programs allow projects to run analyses on how effective their pool 2 programs are and gives projects the optionality to reconfigure and reevaluate their levers/rewards (see Appendix III for potential pool 2 metrics to measure). It also allows the community to play a role in determining what token incentives look like for the project. Interesting case studies to look into include PancakeSwap, 1inch and CREAM.
On point two (2), projects should include features that focus on longer term participants. In particular, projects want to incentivise LPs who are already comfortable with holding the token as opposed to pure farmers who are buying the token just to LP because of high APYs. By making it harder to realize gains quickly, these strategies can force LPs to be more aligned as stakeholders rather than mercenary farmers. Aside from Aave’s pool 2 (which we will explore in the following section), another case study is Ribbon Finance, which experimented with withdrawal fees, non-transferable tokens and capped TVL for their early liquidity pool.
We’ll spend the rest of this section on point three (3), liquidity cap targets, and start with why it’s important to have one.
If projects don’t have a target, they’ll be left in the dark trying to figure out if they have enough liquidity and whether they should pay for more. Finding a liquidity cap target boils down to finding the smallest acceptable trade size for larger investors and ensuring the pool has enough liquidity to support it within an acceptable slippage range (<2%). Often, increases in liquidity can support re-rating of the protocol token (to the upside) as volumes become sufficient enough for funds and larger investors buy off the secondary market. Backing out a liquidity cap target ensures you have enough token liquidity for larger investors without overpaying for more than is required.
How to back out a Liquidity Cap Target
One framework to think about a liquidity cap target would be to think about liquidity depth relative to market cap. In the table below, we’ve bucketed the different types of projects based on market cap and given estimates for what percentage of the total market cap a large investor would want to trade within a 2% slippage range.
| Market cap | FDV market cap Range | Percentage of market cap tradable (<2% slip) | Nominal trade sizes (at a given market cap) | Liquidity target (50/50 pool) | Liquidity target (80/20 pool) |
| low | <$10m | 0.1% – 0.3% | 10k – 30k ($10m) | $1m | $1.5m |
| low mid | $11m-$100m | 0.1% – 0.3% | 50k – 150k ($50m) | $5m | $7.5m |
| mid | $100m- $1B | 0.05% – 0.2% | 250k- 1m ($500m) | $25m | $38.5m |
| large cap | >$1B | 0.03% – 0.1% | 900k – 3m ($3B) | $90m | $140m |
Steps:
- Ascertain which market cap the project falls under
- Take the lower bound of the nominal trade sizes
- Use this equation/spreadsheet to determine how much liquidity is required to facilitate those trade sizes for different slippage levels
example: I’m the founder of a project with a low-mid market cap at $50m. I would, at maximum, want to facilitate large investors trading 0.1%-0.3% of my protocol at 2% slippage. This translates to trade sizes of $50k – $150k (50m * 0.1%, 50m * 0.3%). The equation used in the spreadsheet shows that a $5m pool (50/50 weight) can facilitate $50k trade sizes with <2% slippage. This means that I don’t need more than 5m in my pool to facilitate large investors and that I would, at maximum, need $2.5m of my own token and $2.5m in USDC/ETH in the pool.
Note: This has been designed for pools on traditional AMMs. Uniswap V3 changes these numbers and demands more conviction on price movements.
When it comes to thinking about targets, projects can fall into the trap of using this as a success metric. However, having high token liquidity is not always beneficial and while the liquidity cap target can be a guide to prevent overpaying for token liquidity, it’s not the goal. For earlier stage projects, token liquidity is not as important as focusing on the product and finding product market fit. Low market cap projects that focus too much on their token liquidity run the risk of attracting traders/speculators at the expense of long-term oriented investors and stakeholders.
The power of uneven pools
Among historical pool 2s, Aave’s incentivised token pool stands out as one of the only pools that has sustained long-term liquidity without a high APY (<5%).
In this 80/20 AAVE/ETH Balancer Smart Pool, LPs provide liquidity in return for trading fees and rewards in both AAVE and BAL. Aave’s success gives us a window into the benefits of uneven pools over traditional 50/50 pools.
The main benefit: Uneven pools experience less impermanent loss.
Source: Balancer Labs
The lowered impermanent loss risks means that LPs are more willing to provide liquidity for lower yields. From a cost standpoint, this reduces the amount a protocol needs to reward.
At the same time, token holders can put their capital work while the uneven pool caps their impermanent loss risk should the token price appreciate. This results in better incentive alignment as they can LP to receive trading fees and rewards without losing most of their exposure to the token or needing to buy/get forced exposure to 50% of the value in another token they may not have.
While unevenly weighted pools are more LP-friendly, it comes with a tradeoff. The main drawback is that a higher TVL is required to achieve the same slippage environments. As seen in the graph below, 50/50 pools are the most efficient in terms of slippage.
Source: Balancer Labs
Furthermore, as the project matures, uneven pools also affect the token upside because the pool demands more stablecoins/ETH (compared to a 50/50 pool) to increase the price. After the initial raise/distribution is completed and projects mature, projects can consider adjusting towards a 50/50 pool (e.g. 70/30, 60/40) to allow for better slippage and more efficient price discovery. In terms of platform, Balancer is currently the only protocol that offers uneven pools but Sushiswap plans to launch a fork (Trident) in the coming months.
Leveraging idle treasury to create a hybrid approach to liquidity
Established projects who have raised money or have a healthy/diversified treasury should consider fronting all or a portion of their initial liquidity using their treasury and converting a portion of it to ETH/USDC to provide double-sided liquidity. This has a multitude of benefits including:
- Allowing the project to earn additional revenue from trading fees
- Allowing greater control over the liquidity/liquidity isn’t solely influenced by APR
- Creating an automatic “buy back” mechanism if token price falls
- Diversifying the treasury (with other pairs like ETH/USDC)
One caveat is that projects take on the risk of impermanent loss.
dHEDGE is an example of a protocol that started off with rewarding around 10k DHT per week (around $20k USD at the time), but soon after pivoted to providing the bulk of the liquidity themselves with $3.5m USDC (for a 50/50 pool). By fronting the liquidity using their treasury, they were able to reduce dilution of their governance token and instead use it to incentivize people to use their platform. In terms of revenue, dHEDGE collected $500-$1k/day in trading fees and has collected over $45k in fees over the last 2.5 months.
Here are some out-of-the-box ways protocols can implement a hybrid strategy with a pool 2:
- Use idle treasury to provide 50-80% of their liquidity target, then use protocol tokens to incentivise additional liquidity if necessary.
- Use treasury to provide liquidity and take trading fees to incentivise additional LPs.
- Use the idle long-term treasury to provide liquidity for the first 6mo – 1 year while doing short experiments with liquidity incentives.
Or, simply back out a liquidity cap target and use the idle treasury to front liquidity without incentivising any additional LPs.
Summary
There is no exact science to achieving liquidity for a protocol’s native token. But between the various approaches we have explored here—liquidity cap targets, uneven (i.e. 80/20) pools, treasury liquidity provision—there are a variety of ways that thoughtful founders and investors can tackle the problem of native token liquidity. While much of this guidance is just the tip of the iceberg, we hope that it can propel forward the discussion around designing more sustainable and efficient token liquidity.
A huge thank you to the Arena team (Andrew, Ben, Marc, Daryl, Alec) who helped refine these ideas and sift through data and to <Tristan, Zaheer and Julian for their helpful feedback.
Nothing in this article constitutes investment advice.
Appendix
Appendix I: Pool Research
Research from Nansen analysed all token transfers from 400 farms and found that a large percentage of farmers (36.4%) exited within the first 5 days of entering, while only 13% of all addresses continue to farm today.*
Source: Nansen Research
Similarly, the heatmap above gives us a visualization of just how mercenary these farmers are. Forget multi-year incentive programs, most farmers already drop off a cliff at the 75 day mark. To quantify this further, of the farmers that entered at launch (i.e. those at the top of the information funnel), almost half left within 24 hours and a total of 70% left within 3 days. As LP rewards reduce and become diluted, mercenary farmers will simply take their token rewards and exit into another position.
*While this data includes all masterchef.sol forks (pool 1s and pool 2s) and can’t be directly extrapolated to pool 2s only, it still helps stress the importance of factoring in this mercenary capital when designing token liquidity incentives.
Analyzing a dozen historical pool 2s also shows us that while most incentivised pools saw temporary liquidity increases, most of those liquidity levels dropped over 50% within only 30 days after rewards stopped. One (of many) examples is Badger’s pool 2 which was launched at the height of the bull market.
Here, the data shows how early attempts in December to bootstrap token pool liquidity (see red area) were largely unsuccessful and it took the bull market sentiment to drive pool liquidity. From March onwards, the decrease in pool liquidity proportional to the decrease in rewards suggests they had attracted mercenary LPs who sold down the token as rewards reduced. The graph also highlights the reflexive nature of these incentivised pools because as LPs sell down the token, it reduces the APR which leads to more LPs exiting the pool. We saw similar patterns replicated in pool 2s with $DHT, $ALPHA and $1INCH.
Appendix II: Comparing Treasury OTC, CEX & DEX
| Treasury OTC | Centralized Exchange | Decentralized Exchange | |
| What | – Directly selling/buying back protocol tokens from treasury | – Listing on a centralized exchange | – Having a liquidity pool on a decentralized exchange |
| Pros/Cons |
– Maximum control over buyers/sellers – Very centralized distribution – Good for large trades without affecting token price – Investors can request a discount on TWAP |
– More retail participants – Centralized to exchange users – Earns project trust and visibility – Adds speculative premium |
– Attracts DeFi native users and
contributors – Permissionless access to token – In line with DeFi ethos – Large trade sizes can cause price fluctuations if there isn’t enough liquidity |
| Cost | – Gas fees | – Loaned protocol tokens, listing fees* ($250k – $1 million), market maker fees (1-3% of protocol) | – Protocol tokens |
*some exchanges waive listing fees for projects with good growth trajectory
Appendix III: Examples of Pool 2 Metrics
LM traction
- Total number of unique users
- Number of LPs vs number of stakers
- Average LP duration, number of mercenary traders (those who withdrew within short time)
- Number of LPs that withdraw as APR became diluted/reduced
- Customer Acquisition Cost (CAC) vs Long Term Value (LTV)
Liquidity
- Percentage increase in total TVL
- Percentage Increase in pool liquidity
- Pool liquidity post LM incentives
- APR to Liquidity Ratio
- Market Cap to Liquidity Ratio
Statistical Relationships
- What’s the relationship between time entered farm and time LP’d? (inform length)
- What’s the relationship between LP size and length LP’d? (inform TVL/address caps)
- What are some observations that are common with long-term LPs but not more mercenary ones?
Off-chain
- Website traffic and user flow (website hits, time spent on pages)
- Community activities/initiatives/proposals (side projects, discord activity)
- New engagements on social media (number of tweets, new followers, tags)