Designing A Smart Liquidity Mining Program (LM 2.0)

A Case Study Using KPI Options for Balancer’s Liquidity Mining Program on Polygon

Liquidity Mining 2.0

The idea of Liquidity Mining 2.0 was first introduced in a tweet. It involves replacing liquidity mining rewards with call options or KPI options. As mentioned in the tweet, this accomplishes the following:

• prevent farmers from dumping a project’s token regardless of price
• incentivize farmers to learn about the protocol and potentially contribute to the community
• give more rewards to farmers if the protocol performs well

The net result would be a more targeted incentive program that benefits both the project and liquidity providers. The DeFi community is very receptive to this idea and believes this should be the path forward. However, there are a lot of questions asked about how to design such a program. We hope to answer some of these questions here.

Layer 2 Case Study

The launch of Layer 2 solutions has initiated a new wave of liquidity mining programs to encourage farmers to migrate their liquidity. In this article we show how using KPI options can be more effective and efficient in incentivizing the adoption of L2 solutions. We look at the recent Balancer liquidity mining program and show how it could have been redesigned with KPI options and provide some simple concepts to show how other protocols can design their own program in the future.

In the beginning of July, Balancer announced a $10MM liquidity mining program on Polygon that involves Balancer, Matic and Qi tokens. The program is expected to run for 10 weeks and is summarized in the below table.

Prices as of 7/1/2021

Choosing Parameters

Let’s design a smart liquidity mining program that replaces $BAL tokens with KPI options that can be redeemed for $BAL dependent on the Total Value Locked (TVL) on Balancer in Polygon. These KPI options are ERC-20 tokens and can be distributed in the same way.

To start we need to define parameters for these KPI options:

1. Floor Payout — the minimum number of tokens the KPI option will payout
2. Maximum Payout — the maximum number of tokens the KPI option will payout
3. Floor TVL — the minimum TVL achieved before additional rewards are paid on top of the Floor Payout
4. Maximum TVL — a stretch goal that would reward the maximum payout
5. Base Payout — the same payout as in a regular mining program (1 token)
6. Base TVL — the expected TVL the project would like to achieve in a normal environment
7. Expiry — the date when TVL is observed and payouts are calculated and redeemable

With the first 4 parameters we can define a simple linear payout function of the KPI option in terms of $BAL as a function of TVL.

Putting in actual numbers will make this easier to understand…

To start, we define the expected base case scenario for TVL — or in this case what is an achievable TVL for Balancer on Polygon? To forecast this number we look at SushiSwap given it is one of the first protocols to be on Polygon and has accrued some meaningful data. Using data from Defi Llama prior to July 1st we are able to compare SushiSwap’s TVL on Polygon relative to Ethereum to forecast Balancer’s expected TVL. From the data gathered and the simple calculation below we would expect a TVL of $369MM for Balancer on Polygon to be reasonable. To skew the numbers in favor of the liquidity provider, we choose a base case scenario of $300 MM where the KPI option would pay 1 $BAL token.

SushiSwap TVL on Ethereum: $2,740 MM
SushiSwap TVL on Polygon: $670 MM

Balancer TVL on Ethereum: $1,510 MM
Balancer TVL on Polygon: $369 MM Expected (1,510 * (670/2,740))

(Source: Defi Llama for SushiSwap and Balancer)

Using this base case scenario, a DAO can choose a floor and maximum scenario along with a corresponding payout around this base expectation. As an example, we choose a Floor TVL of 100 MM which would pay 0.5 $BAL token and a Maximum TVL of 500 MM which would pay 1.5 $BAL tokens. All of this is summarized in the table below.

The final parameter to choose is an expiry. The expiry serves two purposes. First, it defines how long the tokens will be locked before the miner will receive them. Second, and more importantly, it provides some time period for the protocol to achieve its goal. In the case of Balancer’s program, we kept it simple and chose a minimum 1 month expiry and made any KPI option farmed in the month to expire at the end of the next month. For example, any KPI option farmed in July would expire and be redeemable on August 31, 2021.

With all these parameters defined, a DAO can build and deploy their own KPI options contract immediately using UMA’s financial contract templates. As long as the project token is an approved collateral no governance vote is needed. The DAO would then deposit their project tokens into their KPI options contract and mint KPI options for their liquidity mining program. These KPI options are ERC-20 tokens so they can be distributed in the same method liquidity mining rewards are currently rewarded by the DAO.

Scenario Analysis

As a final illustration, we take the hypothetical Balancer liquidity mining program with KPI options defined above and compare it with the existing liquidity mining program. To keep things simple, there are just two sets of KPI options — one that expires at the end of August and one that expires at the end of September. We create three different scenarios of a possible TVL path and tally up the total $BAL rewarded to liquidity providers. (As a reference, the current TVL as of this writing is $238MM.) By design, liquidity miners receive more tokens when the TVL rises quickly and less when it rises slowly. More importantly, the KPI options will make liquidity miners and the entire community more engaged and actively track and work to improve their metric.

All data and formulas can be viewed here.

Summary

Designing a smart liquidity mining program can be as simple or complex as a DAO wishes to make it. However, the general idea is very straightforward — the project chooses a metric to target and defines a payout of tokens dependent on the performance of that metric. In our Balancer case study, we chose TVL; however, a project can choose any observable metric such as volume, fees, users, Twitter followers, or anything that is relevant and verifiable. To add further flexibility, the payout function does not need to be linear, as it is in our example. It can be exponential, broken into multiple functions or whatever the DAO believes makes sense.

All DeFi projects looking to incentivize liquidity should consider implementing a smart liquidity mining program. There are clear benefits to the project’s community and more potential upside for liquidity providers.

The UMA team continues to be dedicated to providing DAOs with innovative products to better address their many needs. We would love to engage any communities interested in smart liquidity mining and would be happy to walk a project all the way through from design to deployment for their own program.

Join is on Discord, mention us on twitter, or email us at hello@umaproject.org to start a conversation.

Designing A Smart Liquidity Mining Program (LM 2.0) was originally published in UMA Project on Medium, where people are continuing the conversation by highlighting and responding to this story.