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:
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.
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.
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: