Long Term Incentives Pilot Program

[Matt_StableLab]

This is an outdated draft. Please see the updated draft here.

Abstract

This AIP establishes a Long Term Incentives Pilot Program for the DAO to test new incentives designs and answer the necessary questions to ensure we are ready to commit to the long-term program. This Pilot Program will distribute 35M ARB to protocols that have not yet received incentives. The program will run from January 2024 until April 2024.

Motivation

Testing Incentives Mechanisms For a Long-Term Framework

The Arbitrum DAO has spent the last few months experimenting with incentive programs to attract new users and liquidity to Arbitrum. There is a consensus the DAO will use what we learn from these short-term programs to establish a long-term framework. While STIP V1 brought tons of attention to Arbitrum and has resulted in upticks in protocol metrics, we have learned there were many flaws with the structure of STIP Round 1. This Pilot Program looks to implement new mechanisms to address the issues seen in STIP V1. The DAO will use this Pilot Program as a test run for a long-term framework before committing to a year-long program.

The Pilot Program will operate using a Council, have Application Advisors to ensure protocols receive adequate feedback and assistance, and allow protocols more freedom to create innovative ARB incentive plans. We believe these changes will help remedy many of the pain points seen in Round 1. Running the Pilot Program to test these new features will allow the DAO to compare different program methods before implementing a long-term framework beginning in Q2 2024. This will help ensure we have all the knowledge necessary to implement the most effective long-term incentives program for Arbitrum.

Why Protocols Need a Round 2

STIP was an experimental program to distribute ARB to protocols to use as incentives for their users. While it was initially intended to have two rounds, the program was substantially more popular than expected, and the entire 50M ARB budget was used in Round 1 as was permissible in the original rules.

This meant no funds remained for Round 2, leading to its cancellation. Many protocols either missed the Round 1 deadline or intentionally waited for Round 2. This left several protocols with no alternative route to apply for ARB incentives. Many STIP Round 1 grantees have seen upticks in their metrics. This Pilot Program would allow protocols that missed out on Round 1 the opportunity to apply to gain these benefits, which will help level the playing field for these protocols. The Pilot Program will replace a round 2 and will be funded with 35M ARB to accommodate the large expected protocol demand we have already seen. This will complete the incentivizing of Arbitrum-based teams to create a holistic competitive edge not against each other but against other chains.

Rationale

There is a DAO consensus that Arbitrum will need a long-term incentive program in 2024. However, many delegates feel the DAO is moving too quickly and spending too much money on backfund or V2 proposals without yet receiving any of the data on STIP’s effectiveness.

We have learned a lot from STIP and can use what went wrong in STIP and the Backfund to hypothesize what changes would create a better long-term framework. However, we have little evidence to prove these new ideas would be a better solution. DAO members currently don’t have the resources or funds to create a long-term program, nor do we understand what a good long-term program looks like.

This proposal focuses on obtaining this evidence using a committed working stream to guarantee we come away from this program ready to make informed decisions on a long-term framework. The pilot program also allows the DAO to test new aspects of an incentive program such as Application Advisors, Councils, and more flexible incentive distributions before committing long-term.

This will help save the DAO money and time in the long term by preventing the need for more short-term programs before we are ready to commit to the Long-Term Framework

Specifications

Problem / Solutions:

The specifications of the Pilot Program were designed to remedy the 3 largest complaints regarding STIP Round 1. The Pilot Program hopes to be a test run for these additions for the DAO to determine if they should also be included in the long-term framework.

Problem #1: Too large a burden placed on delegates

In the original STIP, delegates voted on each incentive proposal individually, with almost 100 snapshot votes. This was extremely tiring for delegates and left many feeling they could not make informed decisions on every proposal.

Solution #1

To remedy this problem, the Pilot Program will have a 5 person council approved by the DAO responsible for evaluating applications and deciding which protocol will receive ARB. This will ensure all applications are thoughtfully evaluated with only the most deserving receiving incentives. Not only will this help to reduce the burden on delegates, but it will also help expedite the process and allow protocols to receive incentives quickly and efficiently.

Problem #2: Protocols did not receive adequate feedback on their proposals

A major gripe from protocols was they struggled to get feedback from delegates before the deadline. This left many feeling as though the better-connected protocols had an advantage as they were able to modify their proposals based on feedback to make them more competitive during the vote. Many protocols were willing to make changes to their applications to make them more appealing to the DAO but never received the proper feedback necessary to do so.

Solution #2

The Pilot Program introduces Application Advisors. This will be impartial organizations tasked with providing each applicant with detailed feedback and guidance on how to improve their applications. This ensures each applicant can iterate on their proposal so they can put forward the best possible incentive plan for the council.

Problem #3: Strict Limitations on Incentives Mechanisms

STIP Round 1 had strict limitations on how the ARB could be used as incentives. This was done to protect the DAO and prevent misuse of funds. However, the strict rules resulted in the stifling of many innovative incentive designs. Many protocols had interesting designs that used the ARB in ways that increased alignment, improved cost efficiency, or helped to limit the dumping of ARB. However, these designs were not permitted in Round 1 leading to almost all protocols resulting in generic liquidity incentive models.

Solution #3

The Pilot Program provides more flexibility to protocols to create innovative incentive structures. With the addition of the Council and Application Advisors, the Pilot Program does not require the rules to be as stringent. Malicious or inefficient designs will be first filtered out by the Application Advisors and then rejected by the council. Allowing protocols to innovate on incentive distribution mechanisms will allow Arbitrum protocols and community members to get a better idea of which designs work and which don’t work. This will help everyone as we prepare for a longer-term incentives program.

Flow of V2

Application Period (2 week)

Protocols will have 2 weeks to apply using the Pilot Program application template. Applications will be posted in the Pilot Program section of the Arbitrum forum. Protocols only need to post the initial draft of their application during this period. They will then have 2 additional weeks during the feedback period to edit their applications. The template will be posted to the Forum well before the start of the application period to give protocols time to start their applications early. No late submissions will be accepted.

Feedback Period (2 weeks)

During the feedback period, the Applications Advisors will provide feedback and guidance on all proposals. Both Application Advisors will provide feedback on all applications on a rolling basis. Protocols will then use this time to edit their proposals according to this feedback before applications lock at the end of the 2 weeks.

StableLab will also read all submissions during this period and highlight any rule violations to allow applicants to edit their submissions to ensure they comply with all program rules.

Selection Period (1 week)

During this period, the council will complete a rubric for each protocol to decide which protocols will receive ARB. The council will be required to publish these rubrics and provide a brief reasoning for all of their decisions on the forum to create transparency and accountability.

The council must judge applications as they are and cannot accept protocols at lower amounts than their application states. For example, if an application asks for 200,000 ARB the council can not fund them with 100,000 ARB

Incentives Period

Selected protocols will receive their requested ARB using bi-weekly Hedgey streams until April 26th. During this time, protocols will be required to provide bi-weekly updates on the progress of their incentives using this template. Protocols will be required to finish their incentives distributions or return any unused funds to the DAO by May 10th.

Roles & Responsibilities

The Council

The council will comprise 5 DAO members. These members should be unbiased and knowledgeable builders or delegates who will collaborate to allocate the 35 Million ARB to protocols. The council does not need to spend the entire 35M should they feel there are not enough quality applications. Any unused funds will be returned to the DAO to be used in the Long Term Framework.

The council members will be responsible for creating a rubric that all protocols will be judged against. The council will design this rubric with input from the Application Advisors and will communicate what they are looking for with the Application Advisors to ensure the Application Advisors guide protocols in the right direction. The highest-scoring protocols will be awarded incentives. The council will be responsible for publishing the rubrics as well as a brief explanation for all decisions.

The council will also be responsible for determining when to halt a protocol’s stream should they violate program rules or misuse funds. All reports of violations will be evaluated by the council. It will require 4 out of 5 council members to vote in favor of halting the stream for a stream to be stopped.

Additionally, the council will be responsible for selecting who completes each research bounty. While there is 200,000 ARB allocated for research bounties. This selection will be made via a simple majority by council members and will require them to provide their reasoning for all choices made. The council does not need to spend the full amount should they receive lower budget requests or do not find an appropriate party to fill a bounty.

In the long-term incentives framework, council members will be elected by the DAO. However, as this is a short-term program designed to move quickly, the council in the Pilot Program will be predetermined and ratified by the DAO. This is to avoid an election process significantly delaying the Pilot Program.

Delegates Ability to Veto the Council

After the Council makes its final selection on which protocols get funded, the delegates will have the opportunity to veto any protocol the Council has chosen. This will be done via a snapshot vote to signal to the multisig not to start the stream. If this occurs, the vetoed funds will be returned to the Arbitrum treasury. This aims to keep the council accountable and give delegates the final say in how DAO funds are spent.

Council Responsibilities:

• Design a rubric to grade applications
• Grade all protocols against the rubric to determine who will receive funding
• Provide public reasoning for all funding decisions made
• Decide whether a protocol’s funding should be halted if they violate the rules or fail to distribute ARB
• Read over all Research Bounty applications and select who completes each research bounty based on the budget requested and level of expertise in that field of research.

Council Members

Potential Council members are currently being discussed and vetted and will be added to this proposal before it progresses to a vote to allow the DAO to ratify the council.

• TBA 1
• TBA 2
• TBA 3
• TBA 4
• TBA 5

Removing Council Members

Should the DAO feel a member or members of the council are not fulfilling their duty they may remove them using a snapshot vote. An emergency Snapshot vote will then be used to elect replacement member(s).

Application Advisors

There will be two impartial organizations with research expertise that will serve as Application Advisors. Application Advisors are tasked with providing detailed feedback on all applications. Protocols will be able to use this to edit and improve their application during the review period. Protocols do not have to listen to the advisors but may consult their advisor for help. Application Advisors will schedule public office hours for protocols to meet with them to work on adjusting their applications. These calls will be open to anyone so that all applicants have access to the same advice.

The Application Advisors will also work closely with the council to create the application template and grading rubric. This will ensure the council and advisors are on the same page so they can provide the best feedback to applicants and ensure the council understands the details of the incentive mechanisms the Advisors are helping protocols design.

As this is an experimental addition to the incentives framework, having expert advisors working with protocols will help protocols and the DAO understand what is most helpful from an advisor and allow the DAO to adjust the role for the longer-term framework. This will also help protocols design more innovative incentive distribution mechanisms that can be tested to see how effective they are going into a long-term incentives framework.

Advisors:

Potential Application Advisors are currently being discussed and vetted and will be added to this proposal before it progresses to a vote to allow the DAO to ratify the Application Advisors.

• TBA 1
• TBA 2

Application Advisor Responsibilities:

• Work with the council and program manager to design the application template.
• Provide detailed feedback and recommendations for the applications they are assigned during the review period
• Communicate with applicants to facilitate the application process and improve proposals
• Host office hours to allow applicants to ask questions and get help with their proposals

The Multisig

The same STIP-ARB multisig used in Round 1 and the backfund proposal will continue for The Pilot Program. The funds in the multisig belong to the DAO, and the signers act as grant managers on behalf of the DAO in coordination with the Arbitrum Foundation. Funds held in the multisig are explicitly banned from usage in DAO governance, including delegation.

The STIP-ARB multisig includes two features to ensure the accountability of signers and grantees:

1. Clawback capability so the DAO can retrieve funds if the multisig violates the agreement.
2. Streaming of funds to grantees every second week for the grant’s duration using Hedgey. This allows for the halting of funds if misuse is discovered to stop bad actors, not punish bad designs.

Program Manager

Matt from StableLab will act as the program manager. StableLab will function in a similar capacity as they did for STIP Round 1. They will help coordinate between the multisig, council, Application Advisors, applicants, foundation, and community to ensure the Pilot Program program runs smoothly. StableLab will serve as a neutral party and have no power to decide which protocols receive funding or which streams are halted.

StableLab was responsible for designing this Pilot Program and will continue working on designing a long-term Framework with the help of the incentives working group and the DAO. StableLab will be responsible for publishing a research report on the effectiveness of the Pilot Program and their findings on how it operationally compared to STIP V1.

Should the DAO feel StableLab is not fulfilling their duties as program manager, they may remove them using a snapshot vote. An emergency Snapshot vote will then be used to elect a replacement program manager.

In the Long Term Incentives Framework, this position will be decided by the DAO. However, because the Pilot Program is intended to move quickly, it will continue using StableLab’s services given they have experience from managing STIP V1 and already have knowledge from designing this process.

StableLab Responsibilities

• Provide feedback on all applications regarding their eligibility. They will not provide any thoughts on the merits of the applications.
• Answer any questions regarding incentives from the community, protocols, council, Application Advisors, foundation, and multisig
• Handle forum communication regarding the program.
• Provide bi-weekly updates on the progress of the program.
• Help the council coordinate the review and selection process. They will have no say in the council’s decisions.
• Help the data provider coordinate with protocols.
• Coordinate KYC progress with foundation and multisig.
• Coordinate streams between multisig and protocols.
• Continue designing the Long Term Framework, ensuring it has DAO approval and will be ready to begin in Q2 2024.
• Publish a detailed research report breaking down the operational effectiveness of the Pilot Program compared to STIP V1 in terms of DAO costs and effort.

Data Provider

As in STIP round 1 and the Backfund proposal, the Pilot Program will use a data for data monitoring and reporting. Their exact responsibilities will be the same as they were for STIP and the backfund and can be seen in the RFP - Abitrum Short-Term Incentive Program (STIP) Data Monitoring and Reporting.

This will be an elected position in the long-term program. Additionally, given the long-term framework will have a much larger scope and will include many separate incentive categories, it will most likely require the DAO to onboard multiple different organizations to handle the long-term framework’s data monitoring and reporting. However, because the Pilot Program is intended to move quickly, the Data provider will be selected and ratified by the DAO similar to STIP round 1. Potential data providers are currently being discussed and vetted and will be added to this proposal before it progresses to a vote to allow the DAO to ratify.

Research Bounties

The Pilot Program proposal will include research bounties to ensure the DAO collects sufficient data and draws meaningful conclusions from STIP, the Backfund, and the LTIP Pilot Program. There will be up to 200,000 ARB available to those who complete bounties.

When this proposal goes live to Tally, it will include many questions the DAO wants answered. Some examples Include:

• Which protocol incentive designs were most effective at attracting sticky users/liquidity?
• What is an appropriate budget for a Long Term Incentives Incentive Program?
• What was more effective the council or delegates voting?
• What category of protocol received the most funding? Were any categories left out?

Researchers will then apply to claim these bounties by providing why they are the best fit to answer the question as well as providing a budget. The council will be responsible for selecting who completes each bounty. This process guarantees the DAO will have multiple teams working on providing meaningful conclusions regarding incentive programs. These conclusions will be essential to allow the DAO to possess all the information necessary to create the best possible long-term incentive framework.

Arbitrum Delegates

This program is designed to reduce the large burden delegates faced during STIP round 1. While many of their responsibilities are replaced by the Council and Application Advisors, the Arbitrum delegates will still retain the final say in many aspects of this proposal.

Delegates will retain the following powers:

• Ratify all roles included in this proposal
• Remove any position holder via a snapshot vote should the delegates feel they are not fulfilling their responsibilities
• Veto any funding decision made by the council
• propose the final research bounty questions

Eligibility Requirements

• Grantees must be live on Arbitrum at the time of application
• Grantees must not farm their own incentive programs.
• Grantees must outline a spending plan, provide a pro forma, and state the grant’s objective.
• Grantees must commit to providing data on distributions, all ARB spending transactions, and key metrics like daily TVL, transactions, volumes, unique addresses, and transaction fees. This data should cover 30 days before, during, and after the Incentivization period, and be presented preferably in a Dune Spell/dashboard.
• Grantees must agree to share all contract addresses being used to distribute incentive rewards.
• Grantees must disclose the contracts being incentivized and denote any external contracts being incentivized as part of the program.
• Grantees can only incentive contracts on the Arbitrum Network.
• Grants are not to be used in DAO governance.
• Grantees are expected to not encourage or partake in sybil attacks against the forum to sway community opinion.
• Grantees must agree to KYC with the Arbitrum Foundation to receive funds.
• Grantees must apply using the approved program application template

By streaming grant payments, the multisig will be empowered to hold grantees accountable to their proposals by halting fund streaming for any of the following reasons:

• Any use of funds not explicitly described in the grantee’s application.
• Failure to comply with data reporting standards.
  • Grantee recipients will be required to provide Dune dashboards uploaded and posted to the forum
    • Dashboard requirements are: Daily TVL, transactions, volumes, unique addresses, and transaction fees for incentivized protocols. This data should cover 30 days before, during, and after the Incentivization period. If a metric does not apply, or this is not achievable, it should be noted in the application.
    • More granular dashboards (including pool-level and user analysis) will be noted by the community for future programs.
  • If dashboards are not posted by this date, the multisig will be empowered to halt incentive funding streams for protocols at their discretion.

In that this proposal aims to be experimental, the multisig is not intended to provide quality control on the design of incentive programs. Rather, they are empowered to halt streaming in the event of negligence or misuse of funds.

Steps to Implement

• Protocols can begin applying for incentives after a snapshot vote passes.
• At the same time, it is recommended applicants begin the KYC process with the foundation to expedite the process should they receive funding.
• Once protocols begin applying, the Application Advisors and the council will begin providing feedback on proposals on a first come first serve basis.
• Once this proposal passes the on-chain vote, the total amount of ARB will be sent to the multisig.
• Protocols will work with Application Advisors to improve their applications.
• The Council will design a rubric and grade each application using this rubric to select which applications are funded.
• All protocols that will be receiving funding will have to pass KYC and sign grant agreements.
• Once the foundation notifies the program manager and multisig that protocols are ready for funding, the program manager will coordinate with the protocols, and the multisig will initiate the streams.
• Research Bounties will be selected and completed throughout the process.

Overall Cost

Total Cost: 35,665,000 ARB

• Incentives: 35,000,000 ARB.
• Council Members: 125,000 ARB - 25,000 ARB each
• Application Advisors: 70,000 ARB - 35,000 ARB each
• Research Bounties: 200,000 ARB Total - the exact amount and sizes of specific bounties will be selected by the Council and can be vetoed by delegates.
• Data and Analytics Provider: 150,000 ARB for data monitoring and reporting
• Program Manager: 100,000 ARB for program design, organization, management, research report, and continuing development of the Long Term Incentives Framework. See the full list of responsibilities above.
• Multisig Signers: 20,000 ARB - 2,500 ARB each

[Matt_StableLab]

This proposal is still a work in progress and will continue to be improved with delegates’ feedback.

We are in the process of filling the Council and Application Advisor positions and will update the proposal to include the potential candidates before progressing to a Snapshot vote.

The proposal is being posted to the forum now to allow all delegates to view the progress of the proposal. We are open to any feedback on the proposal so we can make any necessary improvements before the proposal is ready to move to an off-chain vote.

The remaining open questions for the proposal are:

1. Who will be the candidates for the council and application advisor roles?

2. How will the checks and balances work for the delegates and their ability to veto council decisions?

3. What will the specific responsibilities be for each role (council, application advisors, etc.), how many hours and how long will their commitment be?

4. Conflict of interest forms and agreements

Additionally, we are hosting office hours Friday December 22nd at 11am EST to answer any questions and explain the proposal. Join Via the link here

After tomorrow’s call, we will edit the proposal to incorporate community feedback.

We look forward to hearing the community’s thoughts!

[thedevanshmehta]

Congratulations to Matt and the Liquidity Incentives WG, I’ve been following their efforts over the last few months and I’m glad to see a draft put out for feedback.

In its present form, I would urge all delegates to vote AGAINST this proposal. Giving 5 people the power to allocate 35 million ARB is not only deeply corrupting and against the spirit of DAOs, its also just bad marketing. For all the faults of STIP or RetroPGF, they take over Twitter and the collective mindspace for the time it was live; I don’t see that happening here when 5 people call all the shots.

@Matt_StableLab

In the original STIP, delegates voted on each incentive proposal individually, with almost 100 snapshot votes. This was extremely tiring for delegates and left many feeling they could not make informed decisions on every proposal.

You have identified a valid issue here ; rather than moving to a traditional philanthropy structure where a 5 person board allocates funds, are there other ways to overcome this issue?

One solution we are working on with our groups STEP proposal is having a council similar to what you propose, except their role is to screen applications and ensure only high quality providers are able to enter the round. After that, delegates can use weighted voting (dividing their voting power among different options) to show how much they support individual proposals.

Weighted voting would also free up delegates from having to review each proposal as they could allocate all their voting power to the few proposals they have confidence in.

@Matt_StableLab

the Pilot Program will have a 5 person council approved by the DAO responsible for evaluating applications and deciding which protocol will receive ARB

At another level, I do wonder how this is different from the Questbook proposal. They too have domain allocators elected by the DAO for allocating grants; is this proposal just Questbook except for liquidity incentives only?

@Matt_StableLab

This Pilot Program will distribute 35M ARB to protocols

I also want to know how you have come up with this number - is it based on discussions with potential applicants and extrapolating from there? Or just taking half the amount of STIP 1?

I also wonder why you propose a specific number and not let the DAO vote on a range, similar to the earlier proposal.

Overall, I confess to being a bit disappointed with the proposal - its just a regular grantmaking structure where a 5 person board makes all the decisions. Boohoo

[Bobbay]

Following on from @thedevanshmehta feedback, here are some practical steps that we can incorporate to make this framework more open.

Potential new voting workflow

1. 5 Person Council screen applications (similar to STEP) and present only the potential grantee applications to receive a grant via snapshot
2. Each screened application will go to a Snapshot vote, so delegates have the final say, not the council.

(Delegates that vote on X% (75-90%) of these grantee applications should receive a small retroactive grant since these applications take a lot of time to go through too. The council should have reduced this effort with their screening too.)

3. We can automate the setup of the streams if a snapshot vote passes via oSnap, saving the multi-sig setting that up manually.

ARB Ask

Regarding the 35M Arb ask - Similar to how @tnorm did it in STIP v1, lets present a range of options for the DAO to decide on via a forum poll post. 25M, 35M and 45M ARB can be a starting point to temp check the range.

It makes sense for the ask to be lower than STIP 1 since this is a pilot program and the idea is to test a new voting flow and learn from this pilot before going for LTIP.

[JoJo]

Hello everybody.

After reading the proposal, and discussing it a bit with @AlexLumley in term of how the LTIP was conceived, I would like to propose myself in the role of advisor.
I currently serve in Questook Arbitrum Grant Program for the domain “New protocols and Ideas”, as well as in the Uniswap Arbitrum Grant Program. This, inheretly, means that I can’t be in the council, realistically it would be too much power concentration; on the other hand, I have probably accumulated enough experience to have an advisory role with no specific decision power.

A bit of background on me

• I am currently a contributor, almost since inception, in JonesDAO, as risk analyst and as product designer, dealing mostly with creating models for the vaults
• I have been serving since October as the only domain allocator for “new protocols and ideas” in the Questbook Arbitrum Grant Program, managing a 200k ARB portfolio. So far, I have evaluated around 40 proposals, of which 10 were accepted
• I have been serving since November in the 5 member committee in the Uniswap Arbitrum grant program, in which I helped evaluating around 25 proposals
• I have build deep connections with most Arbitrum protocols, as well as delegates, through several election such as the Questbook and STIP, and BD activities.

A bit on the motivations as well. I mainly want to push further my role as contributor to the Arbitrum ecosystem as a whole. What I have learned, especially in the last few months, is that you need to be able to asses a few key things: how good the team submitting a proposal is, how good the idea is, how good the plan to implement and execute this idea is. Three things that, sometimes, require an external point of view to be able to be focused and spinned in the right way in term of product market fit, in term of viability going forward and in term of chances of success. This practically means that a few times I have found myself advising and helping protocols in changing from a few stuff to a full pivot of a proposal because there was something not working, or because there was an even better possibility to create value overall.

Giving informed feedbacks to delegates, protocols and the council is something in which I can definitely give a contribution: act as the “bridge” between the proposals, the protocols and all the stakeholders involved.

[GFXlabs]

We think that creating a longer-term framework for a steady cadence of grants is a very positive step forward. GFX Labs has a lot of experience in running a multi-tens-of-millions grants program (we, like another major Arbitrum delegate, L2Beat, hold a seat on the Optimism Grants Council since its inception).

Because of this, we propose ourselves as a Council Member.

We understand the substantial time commitment, have experience in developing a smooth process, are committed to helping applicants tweak their proposals to be as strong as possible, have seen what types of milestones tend to hold grantees accountable to the DAO.

Grants have a lifecycle – they are not simply an evaluation and disbursement process. Because of this, we recommend there be a clear separation between those who approve grants and those that manage the grantees’ milestone reporting and the closeout process at the end of the grant plan. That allows those who evaluate grants and report on their success/failure to be 1) specialized to the task, and 2) not have a stake in claiming.

The good news is that creating an additional role for that is probably unnecessary initially because there is not an existing cohort of grant plans to monitor or close out.

This is an exciting step in Arbitrum’s continuing maturation, and GFX would be proud to bring to Arbitrum the hard-won lessons from other grant programs we have served.

[Bob-Rossi]

Thank you Matt / StableLabs for putting in the work on this proposal. I believe focusing on a more long-term outlook is the natural evolution of the grant process. I’m also glad to see this proposal has taken the feedback from the STIP and incorporated potential solutions to the issues.

Along the lines of things to learn from the initial STIP, I’d like to bring up the important topic of applicant behavior for discussion. Within the last few days, it has come to my attention that there are projects that are holding back from applying to Questbook’s current grants program due to uncertainty on how that would affect their ability to then get accepted into the next round of STIP / LTIP grants. The issue is simply they are concerned if they are getting a Questbook grant they will then automatically be denied in the next STIP / LTIP round. As, fairly or not, they feel they will be seen as double dipping in the grant pool and automatically rejected. Or if not rejected, pushed to the back of the line because non-benefiting projects will get priority.

The issue has then been compounded by the fact that Questbook’s grants are smaller in size then the STIP round. This creates a situation where applicants have to decide if they want to get a smaller grant now that risks their chances of a larger grant in the future.

I’m concerned this is causing issues for all parties involved:

• Applicants face the decision noted above, as well as may be soured on the Arbitrum Grant process on the whole
• The Arbitrum DAO / the people running the grant programs are not realizing the full potential benefit of the money being spent. There are likely incentivization projects that would be running now if not for this issue
• The Arbitrum network is not able to attract as many users as otherwise possible

I don’t want to turn this into an issue of pitting the grant programs against each other, but it’s something I hadn’t really thought of until I was told this recently and I’m not sure it’s been widely discussed or addressed by the DAO… so I wanted to bring this up as we look towards the next iterations of the STIP/LTIP projects. I’d love to see others input on this.

To close with my personal thoughts, I do think it is something that needs to be learned from and addressed. I know the easiest answer will be to only run one grant program, but I’d be hesitant to just do that. I do really think Questbook has shown success so far and I don’t know if throwing that all away is the best solution either (or blocking out potential future grant ideas). I think we need to find a way to have the STIP / LTIP and the Questbook programs (as well as any future grant programs) be structured with each other mind. Versus sort of passing individual projects and hoping they mesh together.

For example, running these grant projects for similar durations during similar timeframes. Or setting the structures up with each other in mind - maybe differentiate what grant project handles which projects as determined by size / scope / subject matter. Or out of fear of becoming to complex… maybe the solution may just be as simple as all grant programs must include language that approval in one grant project does not affect eligibility for another grant project.

[tnorm]

Succesful results from a development grant from the DAO should be a major signal FOR incentive eligibility, not a deterrent. If the DAO is giving an impression that development support is antagonistic to incentive support, that is likely a signal something is seriously wrong with the culture.

IMHO the idea of fairness/equality in outcome is what is toxic. The DAO should prob be more worried about wasting tokens on low quality projects, forks, etc. in the name of “equality”, rather than overfunding great ones.

Great projects with innovative solutions to market needs should 100% be supported and rewarded. Not punished.

[lindsey]

Great proposal @Matt_StableLab.

The problems / solutions you’ve outlined from STIP 1 are pretty spot on. I like the shift towards having a group of dedicated reviewers / advisors more ownership over the review process.

I see what @thedevanshmehta is saying around his concerns on 5 people being the final say on how 35m ARB grants are distributed, but think you’ve mentioned in some of the commentary already that this is something meant to be discussed during this part of the process.

My first question around these council members / advisors would be

• How much time do you think council members / advisors will spend end-to-end?
• What types of people would be good candidates for the Arbitrum DAO grants council specifically?
• Is there a dynamic mix of backgrounds / skillsets that would make for a better council?
• What conflicts of interest might council members / advisors have and how should that be disclosed?

Other than that, I would wonder if 5 is the right number. Would 10 or 12 allow for a more diverse group of contributors?

@Bobbay brings up a good idea around having the council create their preferred list and having the delegates have final say. Not sure if that doesn’t put the same headache back on the delegates, but perhaps if there’s a thorough review process w/ tons of notes on every project by the delegate committee + a recommended list of qualified applicants it could make the process more fluid.

Cool stuff- looking forward to seeing how it develops

[Bob-Rossi]

Succesful results from a development grant from the DAO should be a major signal FOR incentive eligibility, not a deterrent.

Great projects with innovative solutions to market needs should 100% be supported and rewarded. Not punished.

I agree on both these points and is part of why I think the simplest solution to the problem is making sure approval in one program does not preclude or provide prejudice to approval in another program.

Which I should probably add to clarify, I personally don’t believe that the grant programs ran so far have actively pushed that message / acted in that manner. I’d imagine in the scenario I was presented it was more the lack of that distinction within the way the grants were set up that lead to this line of thinking. I don’t know if there is necessarily a ‘culture’ issue, as much as it just being a miscommunication through absence of direction. One that the DAO wouldn’t have reasonably forseen, especially given the early stages of the DAO.

The conversation simply to say that I have now seen an example where that is the perception of active builders in the space. Even if the group I’m talking about is a smaller, isolated case… I think adding wording to clarify this is pretty low effort for the benefit. As ultimately I don’t want any project to feel they have to withhold applications for certain grants because it may affect their chances in another grant.

[paulsengh]

Hi, everyone! It’s Paul from OpenBlock Labs.

Thank you to Matt and the entire Liquidity Incentive WG for their collaborative efforts in orchestrating this initiative.

As many of you know, OpenBlock has been engaged in conducting incentive efficacy analysis for the STIP + Backfund. It has been wonderful to work with over 56 projects across both programs. Throughout this process, our team has developed various frameworks, encompassing tasks such as onboarding projects, auditing existing queries, identifying KPIs for various sectors, building granular insights at the protocol level, contributing to open-source data, analyzing overall trends, presenting results in an easily digestible format, and much more. We’ve provided bi-weekly updates to the DAO and are on track to deliver a comprehensive final report by the April 2024 deadline. In each update, we’ve actively sought feedback from dozens of founders and community members. It’s great to see numerous projects incorporating our developments to monitor and grow their KPIs, along with a large community involvement in monitoring the use of funds.

Inevitably, these insights will play a pivotal role in optimizing the long-term incentive pilot outlined in this proposal, and we’re enthusiastic about the prospect of extending our role as a data provider for this initiative.

I look forward to seeing the continued discussion and engaging with the community.

[englandzz]

I appreciate StableLab’s efforts in drafting the Long-Term Incentives Pilot Program for the Arbitrum DAO. However, I am concerned about the centralization of decision-making in the hands of a 5-member council. It’s essential that the final decision on which projects to fund rest with the DAO community, not just a select few. The council should focus on screening applications, ensuring only high-quality proposals reach the voting stage.

Overall, while the proposal is a step in the right direction, further adjustments are needed to ensure it aligns with the decentralized and community-driven values of the DAO.

[JoJo]

I can maybe bring a bit of an light in this.

There are problems currently in the several grant programs for one reason:

1. there is no coordination between the program managers/organizers of different programs
2. there are no clear rules.

On the former: I pinged, the other day, Nina from the AF specifying that more than once I have had projects applying both to Questbook and to AF (because either the project disclosed, or it was a direct question on my side). I can also so far say that nobody tried to game the current environment and, in a few occasion, I have personally explained the whole grant eco to the applicant up to the point in which they decided to withdraw the Questbook application in favour of an AF one.
I don’t think there is anything wrong in a project applying to more than 1 program, as long as they don’t apply to get capital to be utilized for the very same things (ie: grant K to build X through questbook, and grant Y to build X through the AF). It can have a “bad” optic in some cases, but again is a case by case scenario depending on how the whole thing developed. No hard rule. And so, to me, someone can apply to questbook AND to the stip/ltip being the scope different. Council, or committee, can always decide for a now due to also a previous grant, but in my opinion never because of a previous grant such as in this case. With a few exception of course, ie protocol pocketed the money without properly deliver.

On the latter, is a problem of overall framework + marketing. I think AF should be more explicit in term of what can and can’t be done by protocols through multiple grant. This also, in my opinion, should also be just an indication. If an independent council is elected, as long as the council follows the rules in their election/proposal, can technically guarantee a grant to an entity even if this goes against the reccomendation of the AF. I also see this as quite unlikely.
But, in general, we need an overall effort in term of creating rules for protocols applying in different grant programs, marketing in the sense of explaining what is out there as programs and what is the scope, and also general reccomendations from AF regarding multiple applications.

Which again, to me, are possible, as long as we clarify the scope.

For what it matters, a few times I evaluated with the project that them applying to questbook was not the best way, usually due to the size of max grant (25k), and so advised, and sometimes helped, creating a proposal directly for the AF, for the very same goals, while putting on pause the application in questbook. I have also killed a few cross application that were live both in questbook and in uniswap arbitrum grant program because they were a match, as well as applications that requested a grant for something already build through a grant from another chain. This requires a decent level of DD on the committee side tho… Not easy.

But I don’t know if most committee work this way just cause maybe they don’t know about all the programs out there.

[Blueweb]

@Matt_StableLab

Research Bounties

Hey @Matt_StableLab,
I suppose the proposal covers many aspects including drawing attention from contributors & I support this initiative.

The Pilot Program proposal will include research bounties to ensure the DAO collects sufficient data and draws meaningful conclusions from STIP, the Backfund, and the LTIP Pilot Program. There will be up to 200,000 ARB available to those who complete bounties.

Where will these bounties to posted and how will it be managed?
I would suggest using platforms like DeWork budget is stated instead of asked to propose. This can simplify the task and increase the number of contributors working for Arbitrum DAO.

Also, I would love to see the dashboard creation open up partially or run parallelly to “Data Provider” on public platforms which can allow more members to contribute at their level.

[DisruptionJoe]

@Bob-Rossi

Within the last few days, it has come to my attention that there are projects that are holding back from applying to Questbook’s current grants program due to uncertainty on how that would affect their ability to then get accepted into the next round of STIP / LTIP grants. The issue is simply they are concerned if they are getting a Questbook grant they will then automatically be denied in the next STIP / LTIP round.

This a huge problem. We need pathways for grantees to be successful. Grants aren’t one-off allocations, they should be pathways that fund ideas to become prototypes and prototypes to become legit projects. Then Incentive Programs can follow up by attracting users.

This focus on pathways will be one of the primary focus areas for our second milestone. Thanks for pointing this out. I’d love to connect with someone who was feeling hesitant about applying to better understand their perspective.

@JoJo

I don’t think there is anything wrong in a project applying to more than 1 program, as long as they don’t apply to get capital to be utilized for the very same things (ie: grant K to build X through questbook, and grant Y to build X through the AF). It can have a “bad” optic in some cases, but again is a case by case scenario depending on how the whole thing developed. No hard rule. And so, to me, someone can apply to questbook AND to the stip/ltip being the scope different.

A project we are funding is tentatively called the “Grant Routing System”. This system does three things:

• gives citizens one place to go to submit a form showing interest in grant applications.
• automates and task manages the steps from grant approval through compliance and payout
• Provides dashboards and view db (airtable) for anyone to see grants info across all programs (This has Questbook, Plurality Labs, and uniswap programs - still need foundation support)

This project’s next major milestone is Jan 15 with expected completion Jan 30th.

Also, thanks for the diligence behind the work you’ve done!

[feems]

Great proposl, some areas also discussed that are missing might be resolved with adding 3 roles specfically in the areas of operations, checks and balances and keeping delegates up to date. I think to have it decided by the council might not be the best as the roles presented can act as implementers.

Project Scoping Squad
Role: The project scoping squad is responsible for defining the scope of the Long Term Incentives Pilot Program and ensuring that all aspects of the program are well-defined.

What area does it currently solve missing from the proposal
Transparency: The project scoping squad can ensure that transparency mechanisms are well-defined in the program scope. They can specify that all decisions and discussions related to applications, council decisions, and program progress will be made publicly available, promoting transparency.

Council Assessment Administrators:
Role: The council assessment administrator is responsible for tracking the work of the council and communicating their actions to delegates and the community.

What area does it currently solve missing from the proposal

• Decision-Making Authority: The council assessment administrator can monitor the council’s decisions and actions to ensure that they align with the defined criteria and rubrics. They can provide regular summaries of council decisions to delegates and the community, enhancing checks and balances.
• Limited Community Involvement: The administrator can facilitate community feedback channels, allowing community members to express their opinions and concerns regarding council decisions. This involvement can enhance community participation in decision-making.
• Emergency Actions: The administrator can help define clear criteria for triggering emergency actions, such as the removal of council members or program managers. This clarity reduces the potential for disputes and ensures that emergency actions are taken when necessary.

Content Designers
Role: Content designers are responsible for creating process flows, documentation, and communication materials to streamline program operations and ensure checks and balances.

Some areas also discussed that seem to be missing in the current proposal form and also something worth noting for future proposals or intitives as wel.

Here are some potential issues in the proposal to think about durng the implementation phase or even before slection process.

• Lack of Transparency: The proposal lacks specific details on ensuring transparency, including making decisions and discussions publicly available.
• Decision-Making Authority: The proposal’s 5-person council may concentrate power and limit checks and balances.
• Limited Community Involvement: Community participation beyond veto power is unclear in the decision-making process.
• Reporting Requirements: Specific reporting standards and update frequencies are not defined, affecting transparency.
• Lack of Data on Effectiveness: The proposal lacks a clear plan for gathering and analyzing data on program effectiveness.
• Role of Program Manager: Accountability and evaluation mechanisms for program managers are unclear.
• Emergency Actions: Criteria for emergency actions like removing council members are undefined, leading to potential disputes.
• Data Provider Selection: The selection process for data providers in the Pilot Program needs clarification.
  Budget Allocation: The proposal lacks a breakdown of fund allocation across program aspects, impacting transparency.

[tnorm]

This is a great start to a LTIP for protocol-funded incentives and I definitely support StableLab’s offer to run a pilot program as a proof-of-concept prior to requesting a larger administrative budget. It’s great to see @Matt_StableLab independently drive forward a long-term program for protocol grants after great execution on STIP.

A few considerations prior to the publication of a snapshot might be:

@Matt_StableLab

• Design a rubric to grade applications
• Grade all protocols against the rubric to determine who will receive funding
• Provide public reasoning for all funding decisions made
• Decide whether a protocol’s funding should be halted if they violate the rules or fail to distribute ARB
• Read over all Research Bounty applications and select who completes each research bounty based on the budget requested and level of expertise in that field of research.

Adding preliminary ideas of a rubric would instill confidence of the Council’s capability. Incentives are complicated, and the team should have clear goals/KPIs to work back from to establish their decision rubric.

@Matt_StableLab

Application Advisor Responsibilities:

The Application Advisors are a great addition, but I’d define specific a purpose (or even KPI’s) for the role to hammer home the expertise and quality required. In my mind, this role would serve two purposes:

1. To ensure each applications alignment with Arbitrum network goals (which I think the proposal should prob define)
2. To maximize ROI on a per ARB spent basis by working with applicants to optimize their incentive tactics.

Ideally, I’d expect the quality of this role to be in the vein of a quant/analyst from a Gauntlet, OpenBlock, SixDegrees, etc.

@Matt_StableLab

Incentives Period

Selected protocols will receive their requested ARB using bi-weekly Hedgey streams until April 26th. During this time, protocols will be required to provide bi-weekly updates on the progress of their incentives using this template . Protocols will be required to finish their incentives distributions or return any unused funds to the DAO by May 10th.

A key issue with STIP was that both the program’s size and streaming design limited the ability for milestone-based applications.

For example, multiple proposals (I think Vertex/Radiant/GMX?) had offered to do iterative/performance based incentives, where funding for consecutive disbursements increased or decreased (10%, 15%, etc.) depending on performance. With stronger admin powers, it’d be great to accommodate these structures.

This might increase the multisig workload, but considering this is a trial program, additional compensation for extra admin would be justified.

@Matt_StableLab

Data Provider

As in STIP round 1 and the Backfund proposal, the Pilot Program will use a data for data monitoring and reporting. Their exact responsibilities will be the same as they were for STIP and the backfund and can be seen in the RFP - Abitrum Short-Term Incentive Program (STIP) Data Monitoring and Reporting .

There’s a subtle difference in scope for a data provider vs. data analysis. To realize the vision for the research bounties (which I love), the DAO requires open data for analysts to work with. The way the Data Provider is articulated here doesn’t quite make that clear, and it seems to be asking more for a provider build everything turnkey (data pipeline, collection, and analysis) but potentially gatekeep the data itself as IP/private data pipelines.

I’m not sure if I’m articulating this as I’m not a data science guru, but it’d be better to build open-source data here. We should fund a pipeline for public data availability via Dune spells, or an open-data repo. Maybe have Carl Cervone or the Open Data folks brainstorm how to build a pipeline on each incentive program that’s available/query-able the full community?

@lindsey

@Bobbay brings up a good idea around having the council create their preferred list and having the delegates have final say. Not sure if that doesn’t put the same headache back on the delegates, but perhaps if there’s a thorough review process w/ tons of notes on every project by the delegate committee + a recommended list of qualified applicants it could make the process more fluid.

If delegates want a final say an optimistic funding route might lower the pain for delegates, while ensuring oversight. I think each app going to a vote will be burdensome and prob adds unnecessary pain.

Might look something like:
Program Proposal —> Multisig —> Council Approves Grants —> Multisig Approves Transactions —> One-Week Grace Period where delegates can veto a grant w/ XX Voting Power —> Grants are streamed.

Does that make sense?

[Matt_StableLab]

Hi all! Thank you so much for your feedback on the Pilot Program - we are currently incorporating it into the proposal.

Taking a break for the holidays but in the next week, we will continue responding to forum comments and editing the proposal to make positions and workflows clearer. We will post an update next week explaining all the changes and how we have addressed the forum feedback.

After feedback regarding concerns over how the council and advisors would be chosen, we have decided to include an election process for these positions.

Anyone interested in these positions can apply by responding to the Pilot Program Position Application Thread

Additionally, we will be hosting our next open proposal discussion meeting next Friday, January 5th at 11 am EST

[Matt_StableLab]

Abstract

This AIP establishes a Long Term Incentives Pilot Program for the DAO to test new incentives designs and answer the necessary questions to ensure we are ready to commit to the long-term program. This Pilot Program will distribute 25-45M ARB to protocols building on Arbitrum. The exact amount will be determined by the DAO via Snapshot vote and will be ratified via Tally vote. The program will distribute ARB to protocols for 12 weeks.

Motivation

Testing Incentives Mechanisms For a Long-Term Framework

The Arbitrum DAO has spent the last few months experimenting with incentive programs to attract new users and liquidity to Arbitrum. There is a consensus the DAO will use what we learn from these short-term programs to establish a long-term framework. While STIP V1 brought tons of attention to Arbitrum and has resulted in upticks in protocol metrics, we have learned there were many flaws with the structure of STIP Round 1. This Pilot Program looks to implement new mechanisms to address the issues seen in STIP V1. The DAO will use this Pilot Program as a test run for a long-term framework before committing to a year-long program.

The Pilot Program will operate using a Council, have Application Advisors to ensure protocols receive adequate feedback and assistance, and allow protocols more freedom to create innovative ARB incentive plans. We believe these changes will help remedy many of the pain points seen in Round 1. Running the Pilot Program to test these new features will allow the DAO to compare different program methods before implementing a long-term framework beginning in Q2 2024. This will help ensure we have all the knowledge necessary to implement the most effective long-term incentives program for Arbitrum.

Why Protocols Need a Round 2

STIP was an experimental program to distribute ARB to protocols to use as incentives for their users. While it was initially intended to have two rounds, the program was substantially more popular than expected, and the entire 50M ARB budget was used in Round 1 as was permissible in the original rules.

This meant no funds remained for Round 2, leading to its cancellation. Many protocols either missed the Round 1 deadline or intentionally waited for Round 2. This left several protocols with no alternative route to apply for ARB incentives. Many STIP Round 1 grantees have seen upticks in their metrics. This Pilot Program would allow protocols that missed out on Round 1 the opportunity to apply to gain these benefits, which will help level the playing field for these protocols. The Pilot Program will replace a round 2 and will be funded with 25M-45M ARB to accommodate the large expected protocol demand we have already seen. This will complete the incentivizing of Arbitrum-based teams to create a holistic competitive edge not against each other but against other chains.

Rationale

There is a DAO consensus that Arbitrum will need a long-term incentive program in 2024. However, many delegates feel the DAO is moving too quickly and spending too much money on backfund or V2 proposals without yet receiving any of the data on STIP’s effectiveness.

We have learned a lot from STIP and can use what went wrong in STIP and the Backfund to hypothesize what changes would create a better long-term framework. However, we have little evidence to prove these new ideas would be a better solution. DAO members currently don’t have the resources or funds to create a long-term program, nor do we understand what a good long-term program looks like.

This proposal focuses on obtaining this evidence using a committed working stream to guarantee we come away from this program ready to make informed decisions on a long-term framework. The pilot program also allows the DAO to test new aspects of an incentive program such as Application Advisors, Councils, and more flexible incentive distributions before committing long-term.

This will help save the DAO money and time in the long term by preventing the need for more short-term programs before we are ready to commit to the Long-Term Framework.

Specifications

Problem / Solutions:

The specifications of the Pilot Program were designed to remedy the 3 largest complaints regarding STIP Round 1. The Pilot Program hopes to be a test run for these additions for the DAO to determine if they should also be included in the long-term framework.

Problem #1: Too large a burden placed on delegates

In the original STIP, delegates voted on each incentive proposal individually, with almost 100 snapshot votes. This was extremely tiring for delegates and left many feeling they could not make informed decisions on every proposal.

Solution #1

To remedy this problem, the Pilot Program will have a 5 person council elected by the DAO responsible for evaluating applications and selecting which protocols will advance to a snapshot vote to receive ARB. This will ensure all applications are thoughtfully evaluated with only the most deserving receiving incentives. Not only will this help to reduce the burden on delegates, but it will also help expedite the process and allow protocols to receive incentives quickly and efficiently.

Problem #2: Protocols did not receive adequate feedback on their proposals

A major gripe from protocols was they struggled to get feedback from delegates before the deadline. This left many feeling as though the better-connected protocols had an advantage as they were able to modify their proposals based on feedback to make them more competitive during the vote. Many protocols were willing to make changes to their applications to make them more appealing to the DAO but never received the proper feedback necessary to do so.

Solution #2

The Pilot Program introduces Application Advisors. This will be impartial organizations tasked with providing each applicant with detailed feedback and guidance on how to improve their applications. This ensures each applicant can iterate on their proposal so they can put forward the best possible incentive plan for the council.

Problem #3: Strict Limitations on Incentives Mechanisms

STIP Round 1 had strict limitations on how the ARB could be used as incentives. This was done to protect the DAO and prevent misuse of funds. However, the strict rules resulted in the stifling of many innovative incentive designs. Many protocols had interesting designs that used the ARB in ways that increased alignment, improved cost efficiency, or helped to limit the dumping of ARB. However, these designs were not permitted in Round 1 leading to almost all protocols resulting in generic liquidity incentive models.

Solution #3

The Pilot Program provides more flexibility to protocols to create innovative incentive structures. With the addition of the Council and Application Advisors, the Pilot Program does not require the rules to be as stringent. Malicious or inefficient designs will be first filtered out by the Application Advisors and then rejected by the council. Allowing protocols to innovate on incentive distribution mechanisms will allow Arbitrum protocols and community members to get a better idea of which designs work and which don’t work. This will help everyone as we prepare for a longer-term incentives program.

Flow of V2

Application Period (2 week)

Protocols will have 2 weeks to apply using the Pilot Program application template. The application template will be created by the Council and the Application Advisors to ensure everyone has the same goals and make it easier for the council to process applications. Applications will be posted in the Pilot Program section of the Arbitrum forum. Protocols only need to post the initial draft of their application during this period. They will then have 2 additional weeks during the feedback period to edit their applications. No late submissions will be accepted.

Feedback Period (2 weeks)

During the feedback period, the Applications Advisors will provide feedback and guidance on all proposals. Protocols will be assigned an Application Advisor who will provide feedback and guidance on applications on a rolling basis. Protocols will then use this time to work with the Advisors to edit their proposals before applications lock at the end of the 2 weeks.

StableLab will also read all submissions during this period and highlight any rule violations to allow applicants to edit their submissions to ensure they comply with all program rules.

Screening Period (1 week)

During this period, the council will use the pre-determined rubric to grade each protocol and decide which protocols will advance to the voting period to receive ARB. The Council will use the rubric to select which applications will progress to a snapshot vote. The protocols that the council selects to advance to a snapshot vote must have a total funding amount that is equal to or lower than the incentives budget. This will ensure the DAO does not overspend should all Snapshot votes pass. Any unused funds will be returned to the DAO.

The rubric will be created by the Council and Application Advisors during the Tally voting period and will be publicly available by the time protocols begin to apply. The council will be required to publish a brief reasoning for all of their decisions on the forum to create transparency and accountability.

The council must judge applications as they are and cannot accept protocols at lower amounts than their application states. For example, if an application asks for 200,000 ARB the council can not fund them with 100,000 ARB

EXAMPLE: This is a hypothetical example using a budget of 10 ARB with 50 applicants that each request 1 ARB

50 protocols apply requesting 1 Arb Each → Councils grades all 50 applications using the rubric and narrow the selection down to the top 10 applicants to not exceed the budget → 10 snapshot votes are created to allow the DAO to confirm the council’s decisions → 9/10 Snapshot votes receive a majority of “fund” votes → 9 protocols are funded with 1 ARB each and 1 Arb is returned to the DAO

Voting Period (1 Week)

Upon completion of the preliminary applicant screening process by the council, the selected applications will be formally presented for consideration. Each application will then be subject to a voting process via Snapshot, allowing Arbitrum delegates to vote on the allocation of funds. In the event that the Snapshot vote is favorably concluded, the respective protocol will commence receiving its funding through an Hedgey stream, facilitated by oSnap execution pending the protocol successfully passing KYC.

Incentives Period (12 weeks)

Selected protocols will receive their requested ARB using bi-weekly Hedgey streams for 12 weeks. During this time, protocols will be required to provide bi-weekly updates on the progress of their incentives using this template. Protocols will be required to finish their incentive distributions or return any unused funds two weeks after their final disbursement is available.

During this period Application Advisors will continue to work with the protocols to help them analyze and improve their distribution mechanisms. Protocols will be allowed to adjust their incentive plans as long as they do not violate any rules and provide their updated plans in their next bi-weekly update.

Roles & Responsibilities

The Council

The council will comprise 5 DAO members. These members should be unbiased and knowledgeable builders or delegates with experience in incentive programs, grants councils, or growing a protocol.

The council will decide which protocols will progress to a snapshot vote to be awarded the ARB incentives. The council does not need to spend the entire incentives budget should they feel there are not enough quality applications. Any unused funds will be returned to the DAO to be used in the Long Term Framework.

The council members will be responsible for creating a rubric that all protocols will be judged against. The council will design this rubric with input from the Application Advisors and will communicate what they are looking for with the Application Advisors to ensure the Application Advisors guide protocols in the right direction. The highest-scoring protocols will progress to Snapshot votes to allow the DAO to determine if they should receive ARB. The council will be responsible for publishing the graded rubrics as well as a brief explanation for all decisions.

The council will also be responsible for determining when to halt a protocol’s stream should they violate program rules or misuse funds. All reports of violations will be evaluated by the council. It will require 4 out of 5 council members to vote in favor of halting the stream for a stream to be stopped. Streams can also be halted via a DAO snapshot vote should the DAO disagree with the council’s judgment.

Additionally, the council will select who completes each research bounty. While there is 200,000 ARB allocated for research bounties. This selection will be made via a simple majority by council members and will require them to provide their reasoning for all choices made. The council does not need to spend the full amount should they receive lower budget requests or do not find an appropriate party to fill a bounty.

Council Election

The 5 council members will be selected by DAO vote. The 5 Council Applicants with the most votes will be elected to serve on the council for the Pilot Program.

Those who wish to serve on the council can apply here. Once the Pilot Program moves to a snapshot vote, anyone who applied to be a council member will be included in a simultaneous snapshot poll to allow the DAO to select who will sit on the council.

Those who serve on the Pilot Program Council are not guaranteed to be included on a council in the full Long Term Incentives Program. There will be new elections to select council members when it comes time for the full long-term program.

Council Workload:

The exact amount of hours the Council position will require is difficult to estimate given this is the first time the DAO will use a council for incentives. However, the following is an estimated breakdown.

Designing Rubric and Application Template: 20 hours

Grading Protocols and providing Reasoning: 4 hours per protocol.

Determining if a stream should be halted: 5 hours per week

Selecting Research Bounties: 4 hours per applicant

Council Responsibilities:

• Design a rubric with the help of Application Advisors to grade applications
• Grade all protocols against the rubric to determine who will progress to snapshot vote
• Provide public reasoning for all funding decisions made
• Decide whether a protocol’s funding should be halted if they violate the rules or fail to distribute ARB
• Read over all Research Bounty applications and select who completes each research bounty based on the budget requested and level of expertise in that field of research.

Council Members

Council members will be elected via a Snapshot vote and will be added to this proposal before it progresses to an on-chain vote to allow the DAO to ratify the council. Those who wish to serve on the council can apply here.

• TBA 1
• TBA 2
• TBA 3
• TBA 4
• TBA 5

Removing Council Members

Should the DAO feel a member or members of the council are not fulfilling their duty they may remove them using a snapshot vote.

Anyone will sufficient voting power can initiate a Snapshot poll to remove council member(s). Should the poll receive a majority “remove” votes the council member(s) will be immediately removed.

Should this occur there will then be a week-long application process where replacement council members can apply via the forum. This will be followed by a Snapshot vote to elect replacement member(s).

Application Advisors

Overview

Three Application Advisors will help protocols design, implement, and update their incentive plans. Application Advisors are integral to the proposal process, serving as impartial entities with DeFi expertise. Their primary function is to provide detailed, unbiased feedback on applications, aiding protocols in refining and improving their submissions.

The Application Advisors will also work closely with the council to create the application template and grading rubric. This will ensure the council and advisors are on the same page so they can provide the best feedback to applicants and ensure the council understands the details of the incentive mechanisms the Advisors are helping protocols design.

As this is an experimental addition to the incentives framework, having expert advisors working with protocols will help protocols and the DAO understand what is most helpful from an advisor and allow the DAO to adjust the role for the longer-term framework. This will also help protocols design more innovative incentive distribution mechanisms that can be tested to see how effective they are going into a long-term incentives framework.

Responsibilities

Collaboration with Council and Program Manager: Work jointly to design the application template, KPIs, and a grading rubric, ensuring alignment with council expectations and clarity in the evaluation process.

Feedback and Recommendations: Offer detailed feedback on each eligible application assigned to your team during the review period.

Communication with Applicants: Engage actively with applicants to streamline the application process, aiding in proposal improvements and clarifications.

Hosting Office Hours: Schedule and conduct public office hours 3 times per week while the program is running for protocols to seek advice. This will focus on transparency and accessibility. All interactions during these sessions will be recorded and summarized for everyone. Order of speaking during office hours will be on a first come first serve basis.

Expectations

Impartiality: Advisors must remain unbiased, especially as they do not have the final say in proposal acceptance. While application advisors will work closely with the council members to create the Rubric, advisors should not interfere with the votes from the council nor guarantee any outcome to projects they speak with.

Continuous Engagement: Post-application feedback is crucial, as is ongoing involvement in the later stages of the process, subject to discussion and agreement with relevant parties. There may also be later involvement in the process when the program is running or over.

Timeline and Process

Pre-Application Phase: Advisors are required to hold open office hours, focusing on guiding applicants in preparing their proposals.

Application Review Phase: Each proposal receives at least one detailed feedback report addressing key criteria established by the DAO.

Post-Application Feedback: After the submission of proposals, advisors provide insights on the process and suggest improvements for future cycles.

Selection and Ratification

Application Advisors will be elected via a Snapshot vote and will be added to this proposal before it progresses to an on-chain vote to allow the DAO to ratify. Those who wish to serve on the council can apply here.

Once the Pilot Program moves to a snapshot vote, anyone who applied to be an Application Advisor will be included in a simultaneous snapshot poll to allow the DAO to select the Advisors.

Those who serve as a Pilot Program Advisor are not guaranteed to be included onboarded in the full Long Term Incentives Program. There will be new elections to select Advisors when it comes time for the full long-term program.

The application to be an advisor is currently open here: LTI Pilot Program Position Application Thread

• TBA 1
• TBA 2
• TBA 3

The Multisig

The same STIP-ARB multisig used in Round 1 and the backfund proposal will continue for The Pilot Program. The funds in the multisig belong to the DAO, and the signers act as grant managers on behalf of the DAO in coordination with the Arbitrum Foundation. Funds held in the multisig are explicitly banned from usage in DAO governance, including delegation.

The STIP-ARB multisig includes two features to ensure the accountability of signers and grantees:

1. Clawback capability so the DAO can retrieve funds if the multisig violates the agreement.
2. Streaming of funds to grantees every second week for the grant’s duration using Hedgey. This allows for the halting of funds if misuse is discovered to stop bad actors, not punish bad designs.

Program Manager

The Program Manager will be responsible for coordinating between all parties involved to ensure the Pilot Program runs smoothly. They will be available to answer any questions the DAO has regarding the Pilot Program and will publish bi-weekly reports so the community understands the status of the program. The Project Manager will be available to the community at least 40 hours a week. This role is designed to add efficiency and clarity to all aspects of the Pilot Program. The Program Manager will have no input into which protocols receive funds. However, they will be responsible for handling any operational tasks that arise throughout the Pilot Program.

Matt from StableLab will act as the program manager. StableLab will function in a similar capacity as they did for STIP Round 1. They will help coordinate between the multisig, council, Application Advisors, applicants, foundation, and community to ensure the Pilot Program program runs smoothly. StableLab will serve as a neutral party and have no power to decide which protocols receive funding or which streams are halted.

StableLab was responsible for designing this Pilot Program and will continue working on designing a long-term Framework with the help of the incentives working group and the DAO. StableLab will be responsible for publishing a research report on the effectiveness of the Pilot Program and their findings on how it operationally compared to STIP V1.

Should the DAO feel StableLab is not fulfilling their duties as program manager, they may remove them using a snapshot vote. An emergency Snapshot vote will then be used to elect a replacement program manager.

In the Long Term Incentives Framework, this position will be decided by the DAO. However, because the Pilot Program is intended to move quickly, it will continue using StableLab’s services given they have experience from managing STIP V1 and already have knowledge from designing this process.

Program Manager Responsibilities

• Provide feedback on all applications regarding their eligibility. They will not provide any thoughts on the merits of the applications.
• Answer any questions regarding incentives from the community, protocols, council, Application Advisors, foundation, and multisig
• Handle forum communication regarding the program.
• Provide bi-weekly updates on the progress of the program.
• Organize the Council and Advisor Elections
• Help the council coordinate the review and selection process. They will have no say in the council’s decisions.
• Help the data provider coordinate with protocols.
• Coordinate KYC progress with foundation and multisig.
• Coordinate streams between multisig and protocols.
• Continue designing the Long Term Framework, ensuring it has DAO approval and will be ready to begin in Q2 2024.
• Publish a detailed research report breaking down the operational effectiveness of the Pilot Program compared to STIP V1 in terms of DAO costs and effort.

Data Provider

Overview

As in STIP round 1 and the Backfund proposal, the Pilot Program will use a service provider for data monitoring and reporting.

Responsibilities

Making Data Publically Available: The Data provider will be responsible for publically displaying data from all funded protocols. This will serve two purposes. First, it will allow the entire community to see the success of the program. Second, it will ensure those completing the Research Bounties have access to this information so they can provide proper analysis of this data. This will allow for the Bounty completers to provide better reports and data visualizations for the community. This provides the DAO with a decentralized method for analyzing and understanding how effective this program is as well as better setting up the DAO for the Long Term Framework.

Data required to report:

• TVL
• Transactions
• Users
• Fees Generated
• Volume
• Protocol Type
• Contracts Incentivized
• Impact per ARB

Communication with Protocols: Engage actively with funded protocols to collect all data necessary.

Monitor For Misuse of Funds: The data provider will monitor data from all funded protocols to detect any misuse of funds. Should they find suspicious activity the data Provider will be responsible for sharing this with the Council.

Create a Recap Report: The Data provider will be responsible for creating a recap report that tells the story of the Pilot Program and breaks down the successes and failures of the different incentive strategies.

Expectations

Impartiality: The Data Provider must remain unbiased. While the Data providers will not have the power to halt streams themselves, they must be impartial when it comes to reporting the data and examining for any misuse of funds. Any suspicious behavior they find must be communicated to the council for further review.

Continuous Monitoring: The Data Provider must continually update the data to reflect the latest updates. This will ensure the bounty researchers and community have access to the correct information. They also must continually monitor for misuse of funds to allow the council to act quickly should any issues arise

Timeline and Process

Post-Selection Phase: The Data Provider will communicate with all funded protocols to ensure they can collect all necessary data and understand which contracts are being incentivized.

Incentives Phase: The Data Provider will continually update the data and monitor for any violations.

Selection and Ratification

This will be an elected position in the long-term program. Additionally, given the long-term framework will have a much larger scope and will include many separate incentive categories, it will most likely require the DAO to onboard multiple different organizations to handle the long-term framework’s data monitoring and reporting. However, because the Pilot Program is intended to move quickly, the Data provider will be selected and ratified by the DAO similar to STIP round 1. Potential data providers are currently being discussed and vetted and will be added to this proposal before it progresses to a vote to allow the DAO to ratify.

Research Bounties

The Pilot Program proposal will include research bounties to ensure the DAO collects sufficient data and draws meaningful conclusions from STIP, the Backfund, and the LTIP Pilot Program. There will be up to 200,000 ARB available to those who complete bounties.

When this proposal goes live to Tally, it will include many questions the DAO wants answered. Some examples Include:

• Which protocol incentive designs were most effective at attracting sticky users/liquidity?
• What is an appropriate budget for a Long Term Incentives Incentive Program?
• What was more effective the council or delegates voting?
• What category of protocol received the most funding? Were any categories left out?

Researchers will then apply to claim these bounties by providing why they are the best fit to answer the question as well as providing a budget. The council will be responsible for selecting who completes each bounty. This process guarantees the DAO will have multiple teams working on providing meaningful conclusions regarding incentive programs. These conclusions will be essential to allow the DAO to possess all the information necessary to create the best possible long-term incentive framework.

Retroactive Community Funding

In STIP Round 1 we saw many community members go above and beyond by providing valuable contributions without any funding. 100,000 ARB will be allocated for retroactive funding to community members who add valuable contributions during the Pilot Program. Earmarking these funds upfront lets people know there will be retro funding which will encourage community members to contribute. This section is intentionally vague to encourage all kinds of community contributions. The DAO will have the final say in how these funds will be used.

Arbitrum Delegates

This program is designed to reduce the large burden delegates faced during STIP round 1. While many of their responsibilities are replaced by the Council and Application Advisors, the Arbitrum delegates will still retain the final say in many aspects of this proposal.

Delegates will retain the following powers:

• Elect Council Members and Application Advisors
• Ratify all additional roles included in this proposal
• Remove any position holder via a snapshot vote should the delegates feel they are not fulfilling their responsibilities
• Veto any funding decision made by the council
• propose the final research bounty questions

Eligibility Requirements

The pilot program is intended for protocols that did not receive ARB during STIP or the Backfund. However, protocols that received grants from the Arbitrum Foundation, Questbook’s grant program, or any other Arbitrum Grants program are eligible to receive Pilot Program funding. Additionally, receiving funding from the Pilot Program does not prohibit protocols from applying for funding from other DAO or foundation programs including the Long Term Incentives Program.

Additional eligibility requirements

• Grantees must be live on Arbitrum at the time of application
• Grantees must refrain from farming their own incentive programs.
• Grantees must outline a spending plan, provide a pro forma, and state the grant’s objective.
• Grantees must commit to providing data on distributions, all ARB spending transactions, and key metrics like daily TVL, transactions, volumes, unique addresses, and transaction fees. This data should cover 30 days before, during, and after the Incentivization period, and be presented preferably in a Dune Spell/dashboard.
• Grantees must agree to share all contract addresses being used to distribute incentive rewards.
• Grantees must disclose the contracts being incentivized and denote any external contracts being incentivized as part of the program.
• Grantees can only incentive contracts on the Arbitrum Network.
• Grants are not to be used in DAO governance.
• Grantees are expected to not encourage or partake Sybil attacks against the forum to sway community opinion.
• Grantees must agree to KYC with the Arbitrum Foundation to receive funds.
• Grantees must apply using the approved program application template

By streaming grant payments, the multisig will be empowered to hold grantees accountable to their proposals by halting fund streaming for any of the following reasons:

• Any use of funds not explicitly described in the grantee’s application.
• Failure to comply with data reporting standards.
  • Grantee recipients will be required to provide Dune dashboards uploaded and posted to the forum
    • Dashboard requirements are: Daily TVL, transactions, volumes, unique addresses, and transaction fees for incentivized protocols. This data should cover 30 days before, during, and after the Incentivization period. If a metric does not apply, or this is not achievable, it should be noted in the application.
    • More granular dashboards (including pool-level and user analysis) will be noted by the community for future programs.
  • If dashboards are not posted by this date, the multisig will be empowered to halt incentive funding streams for protocols at their discretion.

In that this proposal aims to be experimental, the multisig is not intended to provide quality control on the design of incentive programs. Rather, they are empowered to halt streaming in the event of negligence or misuse of funds.

Steps to Implement

• Protocols can begin applying for incentives after a snapshot vote passes.
• At the same time, it is recommended applicants begin the KYC process with the foundation to expedite the process should they receive funding.
• Once protocols begin applying, the Application Advisors and the council will begin providing feedback on proposals on a first come first serve basis.
• Once this proposal passes the on-chain vote, the total amount of ARB will be sent to the multisig.
• Protocols will work with Application Advisors to improve their applications.
• The Council will design a rubric and grade each application using this rubric to select which applications are funded.
• All protocols that will be receiving funding will have to pass KYC and sign grant agreements.
• Once the foundation notifies the program manager and multisig that protocols are ready for funding, the program manager will coordinate with the protocols, and the multisig will initiate the streams.
• Research Bounties will be selected and completed throughout the process.

Overall Cost

Total Cost: 25,815,000 - 45,815,000 ARB

• Incentives: 25,000,000 - 45,000,000 ARB. The exact amount will be determined by the DAO through a Snapshot vote. The entire budget does not need to be spent by the council. Any unused funds will be returned to the DAO
• Council Members: 125,000 ARB - 25,000 ARB each
• Application Advisors: 105,000 ARB - 35,000 ARB each
• Research Bounties: 200,000 ARB Total - the exact amount and sizes of specific bounties will be selected by the Council and can be vetoed by delegates.
• Data and Analytics Provider: 150,000 ARB for data monitoring and reporting
• Program Manager: 100,000 ARB for program design, organization, management, research report, and continuing development of the Long Term Incentives Framework. See the full list of responsibilities above.
  Proposal Creation Assistance: 15,000 ARB - 10,000 ARB for Alex Lumley and 5,000 ARB for Bobby Bola for their time spent assisting with proposal design, hosting proposal office hour calls, and communicating with delegates to gather feedback.
• Retroactive Community Funding: 100,000 ARB
• Multisig Signers: 20,000 ARB - 2,500 ARB each

Voting Options

1. Fund Pilot Program with 45,815,000 ARB
2. Fund Pilot Program with 35,815,000 ARB
3. Fund Pilot Program with 25,815,000 ARB
4. Don’t Fund Pilot Program

[Matt_StableLab]

After receiving amazing feedbackin the forum, speaking with many delegates, and sharing the proposal in multiple community calls we have improved the proposal in the following ways:

1. To avoid too much centralization of power with the council the delegates will now get the chance to vote to confirm all of the council’s choices. The council will screen all applications and select only the best applicant to move to Snapshot votes for the delegates to vote on.

EXAMPLE: This is a hypothetical example using a budget of 10 ARB with 50 applicants that each request 1 ARB

50 protocols apply requesting 1 Arb Each → Councils grades all 50 applications using the rubric and narrow the selection down to the top 10 applicants to not exceed the budget → 10 snapshot votes are created to allow the DAO to confirm the council’s decisions → 9/10 Snapshot votes receive a majority of “fund” votes → 9 protocols are funded with 1 ARB each and 1 Arb is returned to the DAO

2. Additionally the DAO will now have the ability to choose the size of the Pilot Program with voting options of 25M, 35M, and 45M in incentives budgets. This will be voted on during the proposal Snapshot

3. The Application Advisors and Council members will now be elected via Snapshot to allow the DAO to choose who they want to fill these positions.

4. Added role responsibilities, goals, and selection criteria to provide more clarity to the community and assure accountability for these positions.

5. There are now 3 Application Advisors to accomadate the expected application demand and ensure each applicant is able to recieve sufficient attention from advisors. Additionally, Application Advisors will now help protocols throughout the entire incentive period to help protocols manage, evaluate, and tweak their incentive plans.

6. Clarified how this Incentives program relates to eligibility for other DAO grant programs

“The pilot program is intended for protocols that did not receive ARB during STIP or the Backfund. However, protocols that received grants from the Arbitrum Foundation, Questbook’s grant program, or any other Arbitrum Grants program are eligible to receive Pilot Program funding. Additionally, receiving funding from the Pilot Program does not prohibit protocols from applying for funding from other DAO or foundation programs including the Long Term Incentives Program.”

7. Retroactive Community Funding has been added to encourage community members to provide valuable contributions throughout the program.

Thanks again to everyone who has provided feedback on this program! Please read the entire updated proposal here.

Additionally, anyone interested in being an Application Advisor or Council Member is encouraged to apply here