🦄Concentrated Liquidity Campaigns

Everything you need to know about concentrated liquidity campaigns on Merkl

Concentrated Liquidity Campaigns enable incentive providers to reward Liquidity Providers (LPs) on concentrated liquidity AMMs such as Uniswap V3, Quickswap, Camelot. While most incentivization mechanisms rely on one-size-fits-all approaches where all liquidity providers are rewarded the same way, here in concentrated liquidity campaigns, incentive providers can reward liquidity providers differently based on how they have provided liquidity.

Concentrated liquidity allows liquidity providers to allocate their capital within specific price ranges, making their liquidity more efficient and potentially earning more fees. Merkl mechanism for concentrated liquidity was designed to preserve the full benefits and flexibility offered by this type of Decentralized Exchange (DEX) for LPs, typically enabling them to earn more rewards if they are more concentrated.

While Merkl mechanism enables to reward LPs who provide liquidity directly on the pool, the Merkl engine also integrates Automated Liquidity Management solutions (ALMs), which means that people who provide liquidity through these ALMs can also be rewarded as part of concentrated liquidity mining campaigns. As part of the Merkl engine, these ALMs are handled as specific types of forwarders.

The concentrated liquidity DEX and ALM solutions currently supported by the Merkl engine can be found here. If you want to integrate your AMM or ALM within Merkl, please contact us on the Merkl Discord by opening a BD ticket to discuss the integration process.

Reward formula

When an incentive provider decides to incentivize a concentrated liquidity DEX on Merkl, it specifies a given pool, a period of time for which the pool should be incentivized as well as some specific incentivization parameters that we are going to detail below.

Let's say a pool with two tokens (A and B) is incentivized, the way the Merkl engine works is that it analyzes the swaps that occurred in the pool during the specified period and computes a reward score for each position based on the following factors:

• Fees Earned: The fees earned by the position during the period, which represent the liquidity of the position used by the pool.

• Token 0 Holding: The amount of token 0 held by the position during swaps in the pool, compared to the total amount of token 0 in the pool.

• Token 1 Holding: The amount of token 1 held by the position during swaps in the pool, compared to the total amount of token 1 in the pool.

Each parameter is assigned a different weight, chosen by the incentivizer.

The exact distribution formula for a position in such a pool during a specified time period is as follows:

$\left[ \frac{w_{\text{fees}} \times \text{fees by position}}{\text{fees by pool}} + \frac{w_0 \times A \text{ in position}}{A \text{ in pool}} + \frac{w_1 \times B \text{ in position}}{B \text{ in pool}} \right]$

With:

• w_fees: Weight assigned to rewards based on fees earned.

• w_0: Weight assigned to rewards for Token 0 in the pool.

• w_1: Weight assigned to rewards for Token 1 in the pool.

• Fees by position / Fees by pool: The share of total fees earned by the user’s position compared to the total fees generated by the pool during an epoch.

• A in position / A in pool: The user’s share of Token 0 in the pool, calculated as the amount of Token 0 in the user’s position divided by the total Token 0 in the pool during an epoch.

• B in position / B in pool: The user’s share of Token 1 in the pool, calculated as the amount of Token 1 in the user’s position divided by the total Token 1 in the pool during an epoch.

With this setup, this is as if the overall incentive budget was split in 3, with a proportion being shared by LPs based on how much fees they've earned, a proportion shared based on the overall amount of token 0 they've held and a last portion based on the relative token 1 balance they've had in their position during the time period.

Let's say parameters are set such that: fees = 40%, Token 0 = 30%, Token 1 = 30%:

• if a user earns 50% of the total fees from an epoch, they will receive 20% of the total rewards for that epoch.

• if a user holds 30% of the Token 0 in the pool for an entire epoch, they will receive 9% (30% × 30%) of the total rewards for that epoch.

• if a user holds 20% of the Token 1 in the pool for the entire epoch, they will receive 6% (30% × 20%) of the total rewards for that epoch.

On the Merkl frontend, these parameters can set by incentive providers on the page where they create their concentrated liquidity campaigns.

Reward strategy examples

It's up to incentive providers to fine-tune these parameters and choose them so they align with their campaign goals. Some examples of what you can achieve with different parameters:

• an incentive provider for a stablecoin that is depegging may try to establish a liquidity wall in like USDC to reduce the harm done by people dumping their stablecoin. They can do this by skewing the token parameters and setting a significantly higher value to the parameter associated with holding USDC in pool with respect to the one related to holding their stablecoin: with this LPs with more USDC are earning more than those who have balanced liquidity positions, thereby encouraging the formation of liquidity walls

• a LRT provider who want people to be able to seamlessly be able to swap in or out of their asset for ETH may want to encourage super concentrated liquidity around the tick and allocate 98% of the rewards to liquidity providers based on how much they've earned in fees

Sampling and Anti-DOS

For large pools with numerous swaps, the engine may not analyze all the swaps that occurred during the specified period but instead sample the largest ones. If a position is detected as out of range during the swaps that were sampled, then it will not be eligible to rewards for that period. It's up to liquidity providers to ensure that their positions are actively managed to stay within the effective range to maximize their rewards.

Also on top of the common Anti-DoS filter removing users earning less than 1/10,000,000th (or 0.00001%) of the campaign rewards per engine run, in concentrated liquidity campaigns, the Merkl engine disqualifies positions with less than $20 worth of liquidity.

Out of range liquidity

Beyond the three parameters, incentive providers can choose whether to incentivize out of range liquidity or no on concentrated liquidity pools. If out of range liquidity is not incentivized, only in range positions are eligible to rewards on the pool.

We highly recommend incentivizing in-range liquidity, as this ensures that only liquidity providers actively providing liquidity will receive rewards. While we don't see much value in incentivizing out-of-range liquidity, it’s available if it suits your needs.

Fake Volume Attacks detection

Merkl automatically detects and blacklist users who try to game the reward system by creating very tight positions and trading against themselves (i.e., users engaging in wash trading). The system is consistently being updated and improved. Note on this end that frequent rebalancing due to narrow price ranges can be mistaken for wash trading, leading to address blacklisting.

If you have been blacklisted by the Merkl engine and want to understand why or request removal from the blacklist, please open a support ticket in our Discord. Note that we can only un-blacklist an address; we cannot recover funds that should have been earned by the position while the address was blacklisted.

Automated Liquidity Management Solutions

As explained above, Merkl is compatible with whitelisted Automated Liquidity Management (ALMs) protocols. These protocols actively maintain positions for LPs on concentrated liquidity AMMs. The Merkl engine does not differentiate managers from other "normal" addresses when computing rewards. It then splits the rewards going to the position manager address proportionally among all holders of its token. In Merkl context, this is called forwarding.

With Merkl, if you incentivize a pool that is compatible with one of the liquidity managers supported by the system, it will be automatically detected by the script, and users indirectly providing liquidity through those position managers will be able to directly claim their rewards from Merkl contracts.

Since the system is offchain, new types of position managers can easily be added into the system. For instance, it would be possible to reward users of protocols that use position manager tokens on other contracts, such as collateral for borrowing.

Like any Merkl campaign, incentive providers have the possibility to blacklist or whitelist some addresses, including ALM solutions from rewards in their campaigns.

For more details on forwarding, blacklisting and whitelisting with Merkl, you can check this page on customizability hooks.

APRs in Concentrated Liquidity Campaigns

The Merkl frontend usually displays APRs for all the campaigns live on its frontend. In the case of concentrated liquidity campaigns, the APR values displayed on Merkl frontend are average APRs. In fact, every position earns something different based on how it provides liquidity with respect to the reward parameters that were set.

Typically, if the fee parameter is set at a big value (like 99%), and if you provide a full range position, then you may be providing a significant amount of liquidity in the pool without receiving a lot of rewards.

As a liquidity provider, if the value of the parameter for one token are higher than the other token (e.g 60% token A, 10% token B and 30% fees), then you are better off skewing your position so it has more of token A than of token B.

Providing Liquidity for Concentrated Liquidity Campaigns

Globally on concentrated liquidity campaigns, what you earn is tied to how others have provided liquidity. If you had a concentrated liquidity position, but someone with less liquidity had a more concentrated position, then this user may earn more rewards than you.

People who provide liquidity through the same automated liquidity management solution all earn the same APR though.

In summary, to receive rewards from a concentrated liquidity campaign you can:

1. Provide liquidity directly in one of the incentivized pools. The main choices you need to make when adding liquidity are:

• Range tightness: Decide how tight the position's range should be. For example, a tighter range provides more virtual liquidity and earns more fees and rewards but has a higher risk of becoming out-of-range and suffering from impermanent loss.

• Token Split: Determine the split between the two tokens. You can look into the parameter for token A and token B in the campaign you're targeting to see if there is an optimal ratio to find

1. Or provide liquidity in one of the supported Automated Liquidity Management (ALM) protocols that has position(s) in the incentivized concentrated liquidity pool. If you are using an Automated Liquidity Management (ALM) protocol, be careful to understand how they rebalance liquidity.

If you started providing liquidity in a concentrated liquidity pool (either directly on the AMM or through an ALM) before the incentive was created on Merkl, and your positions are still active and meet the parameters set by the incentive provider, you will be eligible to earn rewards when they are distributed. There is no need to recalibrate or exit and re-enter the liquidity pool with your position(s).