[RFC] Thoughts on the End-Game Perpetual Incentives Program

The below response reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.

The Incentives Problem

Somewhere along the way, the understanding of the purpose of the incentives has shifted away from making protocols on Arbitrum competitive with protocols on other L2s, and has now become about making protocols on Arbitrum competitive with each other.

Furthermore, it feels as if incentives are now taken for granted and necessary things, and not as something that’s meant to act as a boost. While we are all for helping protocols provide their users with incentives, we shouldn’t forget that protocols should grow because they have a strong product that is being used, not because they’re giving away free money courtesy of the DAO.

At the end of the day, incentives are meant to highlight protocols’ competitive advantages by incentivizing users to try them. Incentives are not meant to be a competitive advantage in and of themselves.

We’ve found ourselves in a precarious position where if some protocols do not receive incentives, they’re at a disadvantage to the ones that do, and they are driven away from building on Arbitrum because they cannot compete.

Taming a necessary evil

Overall, incentives are a necessary evil for any ecosystem in the current landscape of crypto, including Arbitrum. They help boost numbers and make the ecosystem more appealing to users on other chains for them to move their capital over. They help users explore and experiment with different protocols to learn about what they have to offer, and they help protocols get more users to try them.

However, the very existence of incentives creates a power imbalance between the biggest and most well-established protocols and the newer ones, especially the ones that haven’t yet deployed on Arbitrum. It creates an inherent competitive disadvantage, fosters a monopolistic mindset, and eventually drives builders away from Arbitrum which is a net negative for the ecosystem.

With that in mind, we need to find a way to leverage the advantage of offering incentives while mitigating the downside mentioned above.

A not-so-random solution?

While internally thinking and discussing the different incentives program proposals we’ve had so far (STIP, Backfund, LTIPP and STIP Bridge), and how they all fit together, we realized that each of them had attempted in one way or another to mitigate the implications of some protocols having incentives while others didn’t.

After brainstorming, we came up with an experimental approach that could prove to be a solution to the problems outlined above. Its goal is to unify the incentive programs wherever applicable so protocols under the same vertical do not compete with each other on the amount of incentives they provide. For example, the DAO should avoid situations where we are providing different amounts of incentives to 2 different DEXs if they both want to incentivize liquidity provision for an ARB/ETH pair — the amount of incentives shouldn’t be the only differentiating factor.

We should find ways to be flexible in the distribution of incentives so protocols can leverage and showcase their unique features. Instead of creating a rigid rubric and asking every protocol to fit in it, we (e.g. the LTIPP council and application advisors) should work with protocols to make their incentive structure eligible for funding. As the famous quote goes, “You don’t judge a fish by its ability to climb a tree”.

We’ve come up with a process that goes against the initial instincts of how an incentives program should work, but we believe it makes sense the more we think about it. On a high level, it looks like this:

  1. Protocols apply not to receive incentives, but to become eligible for receiving them. Similar to how the ADPC creates a list of whitelisted service providers, we’ll create a list of protocols that are eligible for receiving incentives. Eligibility basically means that they have a structured plan to distribute the incentives and they meet some minimum requirements.
  2. Every epoch (for example every month), we sample the projects from the list and randomly choose a few that will receive incentives for that epoch.
  3. The sampling should be done vertically (e.g. dex, yield, games, etc) and there should be mechanisms in place to prevent cases of protocols being “sure” that they’ll get incentives (e.g. if only 2 protocols exist under a vertical). We should also ensure that the chosen projects are rotating so no single protocol has over 2 consecutive epochs of incentives, even if by simple luck.
  4. The amount of incentives should somehow be normalized per epoch and per vertical so there are no big discrepancies between protocols of relatively same size. It is expected that protocols with more/less users will need more/less incentives, but that should be determined by the council in advance, as part of the protocol’s eligibility. This specific point should be discussed separately as it’s a broader topic and we will address it further in a separate post.
  5. Ideally, protocols receiving incentives should commit to some marketing effort during the epoch when they’re receiving incentives. For example, a multi-chain protocol should urge its users to use Arbitrum while incentives are running. This specific point should be discussed separately as it’s a broader topic and we will address it further in a separate post.

Why selecting at random might make sense

The reasons why we thought about selecting a few protocols at random every epoch on a rotating basis are many:

  • Incentives can act in a more targeted way to attract users.
  • We can have a better sense of how effective incentives are at attracting users over a shorter period of time.
  • Protocols under the same vertical won’t have to compete with all other protocols under the same vertical at the same time.
  • We won’t have to play favorites as each protocol will have the same chance to be selected if they’re eligible.
  • Makes protocols focus more on building cool products that stand out.
  • Encourages users to seek which protocols have incentives during a given epoch and try them out.
  • Enables the incentives program to be an ongoing thing that protocols can join at any time and reduces governance overhead.

When speaking of DEXs, can’t the DAO incentive pools (choosing among all the pools on all DEXs) directly - through an app like Merkl Reward Mechanism, instead of giving ARB to the DEX protocols? There may be different criteria (TVL, trading volume, newly launched protocols tokens, etc…) on which base the pools will be selected.

1 Like

Thanks @Sinkas for bringing this up. I agree with your point: incentives are now taken for granted and seen as a competitive advantage. This causes projects to focus on how to accumulate the largest amount of incentives, rather than focusing on their product.

While this is a problem for the entire industry, the issue is being highlighted in the Arbitrum ecosystem by the high number of projects (including established protocols with product-market fit!) applying for incentives.

Your not-so-random solution sounds interesting and a paradigm shift compared to the current approach. I am sort of curious to know what the outcome of that would be.

1 Like

The idea itself is positive.
However, I have little idea of its implementation and justification.


  1. Competition for liquidity differs in different periods (bear market or not). In a bull market, the cost of liquidity is very high and equality within the same network will not give any advantage to Arbitrum.
  2. I’m not sure that there is competition within the Arbitrum network. If a protocol appears that gives more incentives (no matter which network), liquidity will go there. If you give the same incentives to 5 DEXes at 5%, and another network has an incentive of 10%, then equality within Arbitrum will not provide any advantages. It is necessary to consider the values themselves from a competitive point of view.


  1. I have little idea of the calculations for users of some projects, especially for future periods of time. Therefore, someone will always be dissatisfied with the calculations or arguments that this project got a lot, and this one got little.
  2. Small projects need initial capital to be able to compete with anyone, so giving the same incentives to a unicorn and a new project is wrong.

It is possible to implement general incentives that will not be given to projects, but as implemented in other networks (Blast, Mode) with points. For example, for a swap you give a certain number of points, for which the user can then receive incentives from Arbitrum itself.