Last week, I discussed the growth of the Merkl incentivization framework on Polygon and zkEVM with the Polygon team.

They mentioned a really cool use case that's explained in the Merkl docs, but which we never emphasized in our external communications: with Merkl, you can give liquidity providers a boost on their rewards if they own a specific token. This is similar to what Curve provides with their 2.5x yield boost in CRV for veCRV holders who participate in their gauges.

While I hadn't really thought about the power of this before, it has given me new ideas for use cases that the Merkl system could further unleash in projects that use it.

If you're not familiar with Merkl, don't worry - let me bring you up to speed right now.

Merkl is a platform which allows everyone to incentivize liquidity on concentrated liquidity AMMs like UniswapV3.

Imagine you're a project and you have some token (e.g. a governance token) that you want to use to grow and incentivize liquidity somewhere beneficial for your project (e.g. incentivize liquidity for your stablecoin). Then, Merklenables you to do this with no technical overhead and maximal efficiency.

Merkl is in fact the most efficient liquidity incentivization solution built on top of the most efficient type of AMMs. It leverages the full flexibility offered by concentrated liquidity decentralized exchanges (DEXes) like Uniswap V3: you can stream rewards to all Liquidity Providers in a Uniswap V3 pool and make sure that within this pool some specific behaviors you choose are getting more rewarded.

We have been using this solution with Angle for about 10 months now. Customizing our distributions to reward people with more concentrated liquidity positions has enabled us to maintain similar liquidity and facilitate more volume on agEUR pools. This has substantially decreased our incentives budget.

The license for Uniswap V3 expired in April 2023. Since then, many more protocols, particularly v3.3 DEXes, have been working to support concentrated liquidity pools.

These protocols usually work if there are other projects bribing on it. The thing is that established protocols and projects do not tend to bribe for their pairs.

Do you imagine the Ethereum Foundation bribing for pairs with ETH? Or Circle bribing for USDC liquidity pools? Usually, projects bribing are more contenders trying to grow their market share. We've been playing this game with Angle, and we've definitely not been the only ones to do this (QiDAO, FRAX, …).

Issue is that projects like Angle usually come later in the development stage of new chains. Common trend on new chains is that you usually get the blue chip tokens first, and then contenders which need incentives if they want to boost demand for their token arrive.

So you've got new chains, projects (ve3,3 DEXes) which want to launch on it, but with no one to use them and create the flywheel effect the 3,3 model is initially intended for. Sounds very much like a chicken and egg situation?

The key question is: can you find another type of stakeholders who can be interested in bribing or at least participating early on in the life of a project on a new chain?

Providing liquidity on concentrated liquidity AMMs is hard. If you want to make a profit on it, you must either be a professional trader or be quite lucky. Liquidity managers take your liquidity and manage it for you on concentrated liquidity AMMs.

The good news is that liquidity managers are integrated in Merkl. This means that if the Merkl system detects that an individual LP went through a liquidity manager, the rewards will be directly distributed to the LP and not to the manager. If Gamma is managing your liquidity for you, the Merkl system will directly reward you.

And it can work with any liquidity manager: Gamma, Arrakis, DeFiEdge, Ichi are some of the ones already integrated. Any other can technically be added.

These liquidity managers are making their revenue on the transaction fees of pools in which they're managing liquidity. Blue chip pools (ETH-USDC, ETH-wBTC) for which no one is bribing are actually what drives most of the volume, and so they tend to be the preferred pairs of liquidity managers.

A big differentiator between managers is the quality of their algorithms to actively manage liquidity and capture transaction fees while minimizingimpermanent loss.

Merkl as an incentive mechanism does not only make it easy for DEXes to benefit from the skills of all liquidity managers at the same time, creating a healthy competition between them, it also gives these liquidity managers another degree of latitude on how to make a difference.

Merkl provides the opportunity for people distributing incentives to specify a token granting a boost.

Suppose I am eligible for 100 ANGLE rewards in a distribution. If I own veANGLE and the distribution creators decide to grant a boost to veANGLE holders, I may receive 250 ANGLE from the distribution with the same amount of liquidity instead of just 100 ANGLE.

Liquidity managers can transfer their boost to users providing liquidity through them, e.g: I am providing liquidity with Gamma and Gamma has a boost because its contract owns veANGLE tokens. I can get boosted even if I do not own veANGLE myself.

And this is where we get to the flywheel for ve3,3 DEXes. Whenever a new ve3,3 protocol like Retro launches, it's in the best interest of liquidity managers to start bribing to effectively receive more incentives (provided that they control themselves some liquidity in the pool), lock them and therefore get a higher boost. This in turn enables them to become more advantageous than their respective competitors since for a same amount of liquidity provided by someone, they can unlock higher yields through their boost.

There's a parallel to be drawn with liquid lockers for ve-tokens (like veCRV). In this case, it's as if liquidity managers were akin to Convex, and ve3,3 DEXes were similar to Curve-like systems. The reason one might choose Convex over another liquid locker is that Convex provides higher boosts. The same dynamic could be at play when choosing one liquid manager over another for a pool on a ve3,3 DEX.

Having Merkl supporting boosts for LPs on concentrated liquidity AMMs is a way to:

• align incentives between liquidity providers and the DEXes they're providing liquidity into, by enticing them to lock rather than dump their rewards

• Move the healthy competition between liquidity managers beyond the efficiency of their algorithms

• But mostly, create from scratch a bribing demand from liquidity managers who want to provide more value or become more attractive.

The Merkl system with boosts is already live. Now, I am excited for a v3.3 DEX or any other project to adopt this feature and create interesting game theoretic behaviors between its different types of liquidity providers.

Hopefully, some good surprise to expect on Polygon zkEVM 👀

Boosts in a protocol are typically complex to provide. They rely on intricate smart contracts, as seen in those of Curve. Integrating them into a front-end interface is also not an easy task.

The Merkl solution is built for developers at its core. If you're a protocol trying to launch a boost, or if you gave up on boosts because it was too difficult, be aware that there's nothing specific you need to develop to have this supported if you're using Merkl. In less than 5 minutes, you can get a boosted distribution and easily integrate it into your app, just as we're doing at the moment for Angle.