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:
- 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.
- 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.
- 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.
- 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.
- 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.