User owned liquidity: a new DeFi bonding system model for launchpad platforms

The last part of the three-part posting series on DeFi bonding.

TL;DR.

User owned liquidity is a DeFi bonding system model for launchpad platforms. It improves upon protocol owned liquidity in 3 ways:

1. “Bonding dependent liquidity provider incentive model” that solves the mercenary liquidity and encourages users to provide liquidity.
2. “Direct liquidity bonding” allows a gas-efficient bonding scheme for UniswapV3 liquidity.
3. “ETH centric DeFi bonding system” to reduce the risks of stablecoin such as depegging or government sanctions.

Special thanks to Oscar.K, Richard.N, Harvey.J, Kevin.J, Praveen.S, Zena.P, Gongpil.C, Wyatt.P, and Jamie.J for the useful discussion leading to the modeling of UOL. This posting would not have been possible without Kevin.J’s internal posting about how to improve TONStarter’s rewards program.

What is User Owned Liquidity?

In the previous posting, we defined DeFi bonding as a general bootstrapping system that couples the three bonding primitives -bonding, swapping, and locking mechanics- into a single system that promotes the stability of the native token.

In this posting, those primitives are used to define a new DeFi bonding model that is specifically designed for launchpad platforms called user owned liquidity (UOL).

For those that are not familiar with the launchpad platform, it is a fundraising service where new projects can advertise their projects, raise funds, provide advertised services on L2, and govern the launchpad.

Launchpad platform provides (to onboarded projects) advertisement opportunities, fundraising tools, L2 support to run their services, deep liquidity for the project tokens, and a way to govern the launchpad platform related policies.

Existing DeFi bonding systems like Olympus DAO are based on the protocol owned liquidity (POL) model which is not a good fit for launchpad platforms like TONStarter for the following reasons:

1. POL is designed to make a stable currency with treasury backing to support the stability of their native coin with deep liquidity, but launchpad platforms require a currency that is not necessarily a stable currency, that promotes stable funding and deep liquidity not just for its native launchpad token but also for project’s tokens, and a way to govern the launchpad policies.
2. Launchpads have to constantly accept new projects, where a good number of them will fail. A model like POL where launchpads have to own the majority of the projects’ liquidity is costly, risky, and financially unrealistic.

Olympus DAO is a POL based DeFi bonding system. Under this model, the majority of the liquidity is owned by the protocol, providing a stable and deep liquidity.

TONStarter is a launchpad platform that would benefit from a DeFi bonding model where the majority of the liquidity pool is owned by users. The financial burden of owning the liquidity of a project that may possibly fail in the future is distributed between users and solves the unrealistic scenario where the protocol has to own the majority of the liquidity pool for every onboarded project.

So how do we design a model for the DeFi bonding system that is optimized to create an effective launchpad? We propose user owned liquidity (UOL) model, where the protocol effectively incentivizes users to provide liquidity while encouraging them to participate in launchpad-related services, including launchpad governance.

The rest of the article is organized as follows:

1. Explain POL and its limitations.
2. Explain the problem with the current incentive model for liquidity providers.
3. Description of UOL.

1.1 What exactly is Protocol Owned Liquidity (POL)?

Before discussing the user owned liquidity (UOL), we want to explain how protocol owned liquidity (POL) based projects like Olympus DAO fixed the mercenary liquidity problem.

POL solves the mercenary liquidity problem by redirecting the efforts of maintaining the liquidity pools from users to themselves and removing the incentives for the liquidity providers. Since there are no incentives for the liquidity providers, mercenary liquidity providers have no reason to provide liquidity, eliminating the problem.

POL redirects incentives that would have been allocated to the liquidity providers to stakers instead. Mercenary liquidity providers have no reason to provide liquidity and stakers receive a very high return on staking.

For POL to own the majority of the liquidity, it offers a discounted bonding price for UniswapV2 LP tokens (which represent a portion of the total liquidity in the liquidity pool). This means that users can get native tokens cheaper than in the open market if they use their LP tokens for bonding. This creates a positive feedback loop where users buy native tokens to make LP tokens, which increases the token’s price, and bonds the LP tokens to get more native tokens.

The native token’s price is further boosted by offering an unrealistically high return for staking. Since stakers can earn high returns, they are discouraged from holding on to unstaked native tokens or providing liquidity for a long period. These two reasons reduce the number of native tokens in the open market and quickly raise the token’s price. Conversely, the native token price can quickly go down if stakers start to sell their native tokens.

To summarize, POL eliminates mercenary liquidity by redirecting the incentives for the liquidity providers to the stakers instead. It is also designed to attract users by choosing a mechanism like UniswapV2 liquidity pool that can quickly increase the price of the token and a bonding mechanic that encourages them to buy the native token, which greatly rewards the early adopters to take advantage of the system when the price is low.

1.2 What are the limitations of Protocol Owned Liquidity (POL)

POL solves the mercenary liquidity problem by eliminating the incentives for the liquidity providers, but it has three limitations:

1. Decentralized Autonomous Organization (DAO) governance can be abused to manipulate the market.
2. High price volatility from supporting UniswapV2 liquidity.
3. Supports a stablecoin-centric system that can fail if the underlying stablecoin becomes depegged or regulated.

Let’s take a closer look at these limitations.

DAO is the group responsible for the governance of the project. The operations are decided among the users who hold the governance tokens, which assumes that the most invested user in the system will also participate the most. Thus the power to govern is directly proportional to the number of governance tokens owned. In some cases, DAO can be designed to enforce the vote via a smart contract. One simple example is modifying the staking APY % by a vote.

In the optimistic world, the governance token holders should govern under the assumption to provide fair chances to everyone. Any benefits should be distributed to the community fairly and not specific to a few individuals who hold the majority of the governance tokens. But in practice, this is not always true.

Market manipulation and essential protocol manipulation using governance tokens is one such issue.

• For example, in 2021, Snowdog DAO, a fork of Olympus DAO, voted to buy back its native tokens using the treasury assets. However, only a handful of accounts were able to make a profit from the buyback because the buyback amount was so limited. Olympus DAO runs a separate policy team to finalize any governance proposal that changes the fundamental parameters that make their bonding system work to avoid situations like this.
• Similar to the previous example, governance can be used to manipulate the Uniswap market price by temporarily removing the liquidity owned by the treasury which increases the price volatility. When liquidity is removed, especially in UniswapV2 liquidity pool, the price slippage becomes higher because liquidity is spread evenly across all price ranges. This problem is magnified for POL because POL owns the majority of the liquidity pool.

For POL, since it owns the majority of the liquidity, the governance needs to be designed to ensure that the protocol cannot manipulate the market.

The second limitation of POL is its reliance on UniswapV2 liquidity pool for bonding and swap. UniswapV2 liquidity has higher price slippage and lower capital efficiency compared to UniswapV3. However, POL utilizes the high price slippage as a feature to raise their token’s price quickly and encourage users to bond at a cheaper price at the same time. But, conversely, the price can fail equally quickly when the majority of the users decide to liquidate their staked tokens.

Finally, the third limitation of POL is its reliance on stablecoin logic in its system. Because POL’s goal is building a stable currency with a stable reserve, much of its logic including treasury and bonding is tied to a stablecoin. However, the recent Luna/UST fiasco demonstrated the risks of building a whole system that relies on one particular stablecoin in case of depegging or government regulations.

On the other hand, the proposed user owned liquidity (UOL) model is designed to fix all the aforementioned limitations of POL with the caveat that it is a DeFi bonding system model designed specifically for launchpad platforms.

2. Problem with the current liquidity provider incentive model

Before discussing UOL, the problem with the current liquidity provider incentive model needs to be addressed.

In November 2021, Onther’s CEO Kevin Jeong wrote a special internal posting that discussed the problems of Onther’s launchpad platform called TONStarter, particularly the incentive model for liquidity providers.

TONStarter introduced “rewards program” as an incentive for UniswapV3 liquidity providers. The idea was to give project tokens from the launchpad platform based on the active liquidity users provided. Although rewards programs attracted liquidity, it was only for the short term. As soon as the reward was depleted or a better opportunity turns up, the liquidity providers would liquidate their assets (including the rewards). This is also known as the mercenary liquidity problem.

On top of that, because the reward was proportional to the active liquidity mercenary liquidity providers can provide liquidity at a very narrow price range for a short time to claim the majority of the rewards and leave almost no rewards for other users.

Consequently, TONStarter’s rewards program model had difficulty attracting long-term liquidity providers, and TONStarter’s native token TOS price fell whenever a mercenary liquidity provider liquidated their assets.

A prominent DeFi analyst, Andre Cronje also offered his view on the incentive for liquidity providers in a posting. He argues that the problem lies with the fundamental of the liquidity provider incentive model of “giving something for nothing”.

What does “giving something for nothing” mean? To put it to the extreme, a liquidity provider can earn rewards even if no one used the liquidity for swapping. Then, if they remove the liquidity and liquidate their related assets right away, the token’s price will fall while there is no change in the liquidity.

Then, if they remove the liquidity and liquidate their related assets right away, the token’s price will fall while there is no change in the liquidity.

Kevin and Andre suggested two independent solutions to the problem:

1. Kevin: Let’s add the auto compounding effect to the reward. Then the reward gets bigger as the liquidity is provided for a longer time, giving more incentive to the long-term liquidity providers than the short-term liquidity providers.
2. Andre: Let’s give “options contract” as the reward to the liquidity providers. An options contract gives the user the right to purchase or sell an asset at a fixed price in the future. For the user to make a profit from the right to purchase, the user needs to be able to buy the token at a discount than the future market price. If the token’s price drops below the discounted price, the user cannot make a profit, but if the price rises above the current price, the user profits from the difference. Similar logic applies to profiting with the right to sell. If the option contract is given as the reward, the liquidity provider has to provide additional capital to fully utilize their incentive for providing the liquidity, effectively solving the “giving something for nothing” problem.

I hope the readers can infer what user owned liquidity (UOL) model could be from these two ideas. Here is a hint, how do we design a DeFi bonding system that incentivizes long-term liquidity providers such that they have to utilize the bonding mechanic to get the rewards?

3. User owned liquidity (UOL)

User owned liquidity (UOL) is a new DeFi bonding system model for launchpad platforms. Unlike protocol owned liquidity (POL), where the protocol is responsible for owning the majority of the liquidity, UOL is designed such that:

• The protocol provides just enough liquidity for the onboarded projects in the launchpad platforms to function effectively and incentivizes users to provide liquidity.
• There is a way to govern the launchpad policies.

UOL improves upon POL by

• Adopting bonding dependent liquidity provider incentive model which solves the mercenary liquidity and encourages users to provide liquidity.
• Offering a gas-efficient bonding scheme using UniswapV3 liquidity called “direct liquidity bonding”.
• Moving away from a stablecoin-centric to ETH centric DeFi bonding system to mitigate risks of stablecoin such as depegging or government sanctions.

Under UOL model, the protocol maintains & manages just enough of the project token’s liquidity to promote stability to the liquidity pool and reduces the risks associated with the protocol owning the majority of the liquidity by incentivizing users to provide liquidity.

UOL vs POL. UOL model is specifically designed for the launchpad platform.

The subsequent sections will describe how UOL solves the aforementioned mercenary liquidity issue and insights into how UniswapV3 liquidity can be offered as a bond such that it is more gas efficient than UniswapV2 LP token bonding.

3.1 Bonding dependent liquidity provider incentive model

The current liquidity provider incentive model is built on a flawed assumption that liquidity providers must be compensated for any impermanent loss they may experience. But, it is ultimately the user’s choice to allow their tokens to be exchanged at a specified price range, thus it shouldn’t be considered a loss, but a way to hedge the risk due to a change in price by providing liquidity.

For example, if the token’s price rises, the gain is smaller because some of the tokens would have been swapped at a lower price, but on the other hand, if the token’s price falls, their loss is not as large because some of the tokens have been swapped at a higher price.

However, users do not want to provide liquidity as they want to hold on to the tokens as long as possible to maximize the gain or possibly because of the unpredictability of gain or loss for providing liquidity. Accordingly, projects that want liquidity must provide compelling reasons for liquidity providers, but not at an expanse of attacks from mercenary liquidity.

We propose a bonding-dependent liquidity provider incentive model to solve the aforementioned issues. It is designed with the following four goals in mind:

1. Encourage providing the liquidity for longer terms
2. Liquidity provider incentive is predictable
3. Does not allow incentives to be sold easily
4. The incentive should encourage bonding

The mercenary liquidity problem is solved because it is more difficult to utilize the incentive. Compare to the existing model where the incentive can be sold back to the market and bring down the token’s price, the liquidity provider has to bond to utilize the liquidity provider incentive.

Let’s take a closer look at how the proposed model works.

The liquidity provider receives “discount tokens” that can be used for bonding (or inverse bonding) when they stake their LP token to an LP staker contract.

The discount token offers an additional discount on the bonding price for bonding. For example, if the bonding price is 1 ETH, with the discount token with a 10% discount rate, it will only cost 0.9 ETH to bond. With the discount token, users can can bond earlier at a cheaper price before they are sold out.

The discount token can also be used for inverse bonding to increase their return. Inverse bonding is a feature introduced by Olympus DAO, where users can deposit OHM (Olympus DAO’s native token) for a treasury asset.

For example, suppose an inverse bond offers 100 DAI if the user deposits 10 OHM. If the user also has a discount token with a 10% discount rate, the user can get 100 DAI by depositing only 9 OHM.

Furthermore, to encourage users to provide liquidity for longer terms, the number of discount tokens is auto compounded based on the staking period. This also has an additional effect that the incentive is predictable, so users can plan how much liquidity to provide and for how long.

To discourage unstaking LP tokens, the discount token should be designed so that it cannot be transferred to another user, and such that the balance disappears once they unstake their LP.

To summarize, bonding dependent liquidity provider incentive model solves the issues of lack of incentive for long-term liquidity providers (mentioned by Kevin Jeong) and “giving something for nothing” (mentioned by Andre Cronje), while solving the mercenary liquidity problem by making the liquidity providers to bond using the incentive.

3.2 Direct liquidity Bonding for UniswapV3 liquidity

Although the new liquidity provider incentive model is an important feature of user owned liquidity (UOL) model, the integration of UniswapV3 liquidity in DeFi bonding may be equally important.

Just like other DeFi bonding system models, UOL uses the bonding mechanic to continuously introduce new funds to the project without negatively impacting the existing investors.

Unlike POL (Olympus DAO and its forks) where users can bond with UniswapV2 LP tokens, UOL supports a feature called direct liquidity bonding for UniswapV3 liquidity. This allows users to bond without creating an LP token and is more gas efficient and simplifies the management of LP tokens.

“Increase Liquidity” interface offered on UniswapV3 app: Anyone can add liquidity to a UniswapV3 LP token. Direct liquidity bonding utilizes this feature to make bonding -using UniswapV3 liquidity- gas efficient and greatly improve the management of the liquidity owned by the protocol.

How is this possible? The direct liquidity bonding uses UniswapV3 specific feature called “Increase Liquidity”. This function increases the liquidity of an existing LP token and anyone can use this function. This means that users can increase the liquidity of LP tokens owned by the protocol as a way of bonding. More on this will be explained in a separate posting later.

The direct liquidity bonding greatly simplifies the management of the UniswapV3 LP because the protocol can consolidate their liquidity by providing their LP addresses for bonding.

This is a stark contrast to POL model based systems, where users would have to give up their LP tokens and the protocol needs to manage each LP token. Although it is not a problem for UniswapV2 LP tokens because they are ERC20 based and each LP token is the same, it is a problem for UniswapV3 LP tokens where each LP token is a unique NFT.

For example, the protocol has to manage each UniswapV3 LP token’s price range, liquidity level, and swap fee collection. But, this is infeasible under the assumption that many users will bond, and the gas fee for managing every LP token would be very costly. This is why direct liquidity bonding is required for any bonding schemes that want to support UniswapV3 liquidity bonding.

The protocol can also implement an automatic LP management contract to distribute the liquidity based on its goal. For example, normally distributed liquidity provides the least price slippage, whereas evenly distributed liquidity ensures that there is an equal amount of liquidity at any price point so that users always pay a fair price even during high demand on one asset.

3.3 ETH centric DeFi bonding system

Protocol owned liquidity (POL) is a DeFi bonding system model designed specifically to support stable currency with deep liquidity. For the native token to be somewhat stable, it has to be backed by stablecoins such as DAI, USDC, and the minting logic by extension has to be dependent on a stablecoin as well. For example, Olympus DAO uses DAI as the central currency that defines how OHM is minted, i.e., mint 1 OHM per 1 DAI.

However, POL’s dependency on a single stablecoin in their smart contracts opens up to the system failure if it becomes depegged or sanctioned by a government entity.

If Olympus DAO’s minting logic was dependent on UST instead of DAI, the backing logic and any contracts that use UST pricing would not have worked properly when it became depegged recently.

Unlike systems based on POL, Launchpads do not require its token to be a stable currency; it is ok for the token price to rise and fall. It also means that the logic behind the bonding and treasury contracts do not have to be dependent on a stable currency, and can be dependent on Ethereum instead.

By moving away from a stablecoin-centric system to Ethereum centric system, UOL model mitigates the external dependency and risks of stablecoins.

Conclusion

In conclusion, we discussed the limitations of protocol owned liquidity (POL), and the liquidity provider incentive model, and proposed a new DeFi bonding system model called user owned liquidity (UOL).

UOL is designed specifically for launchpad platforms to provide a stable liquidity pool for all the project tokens, incentivize users to provide liquidity, and a way to govern launchpad platform-related services.

UOL achieves this by offering

• Bonding dependent liquidity provider incentive model that solves the mercenary liquidity problem
• Direct liquidity bonding to support UniswapV3 liquidity bonding that is gas efficient and easy to manage
• Moving away from stablecoin centric system to ETH centric system to reduce the dependency on stablecoin in case of depegging or government sanctions.

Full disclosure: Onther, the company I work for is servicing a launchpad platform called TONStarter. Note that some or all elements and design choices of UOL that are discussed in this article are expected to be reflected in the next version of TONStarter to improve the onboarded token’s price and stability of the liquidity pool.