Double-Down on STIP Successes (STIP-Bridge)

After careful consideration Treasure’s Arbitrum Representative Council (ARC) would like to share the following feedback on the proposal.

The ARC will vote AGAINST the STIP-Bridge proposal for the Tally vote. The ARC fully agrees with the initiative to continue funding to promote and accelerate the adoption of DeFi on Arbitrum, and thereby also the broader adoption of Arbitrum as a whole. However, we think that the parties involved in this proposal will benefit more from a program that is data-driven and an iteration on previous incentive programs.

With respect to the updates, we do not think that the concerns have been adequately addressed:

  1. Performance audits for the STIP-Bridge would obviously be a good thing, but the concern expressed by the community was about there not being enough data to support the STIP-Bridge, not the fact that the proposed data-collection on the STIP-Bridge was insufficient.
  2. Involving the advisors from the LTIPP program is a good improvement to the STIP-Bridge. However, the administering of the PM role to the same individual as the STIP and the LTIPP without a vote seems rushed and anti-democratic.
  3. There have been no changes to the way proposals are voted for, and the ‘optimistic voting mechanism’ will in our eyes lead to a higher chance of passive acceptance by delegates, while also still effectively having the burden of review on the delegates.

Realizing that the STIP-Bridge vote has a high probability of passing, we wish all relevant parties the best and hope that the program will add measurable value to the Arbitrum ecosystem.

Anyone who is against this proposal, please read it carefully.
It is strategically better not to vote at all, let me explain:
Now there are a lot of votes FOR, a significant part of which are from those projects that will receive additional funding and can be understood.
But there is a quorum that could not be overcome without other votes. So the votes against are also now FOR this proposal. Wintermute and Treasure voted against it, but in doing so they helped the proposal move closer to the Quorum.


@cp0x - interesting take, I did some research, only vote types: For and Abstain aggregate to the total Quorum amount, not vote type Against.

The primary purpose of setting a quorum is to ensure that decisions are made with broad consensus and are not dictated by a small subset of the community, thereby reflecting the collective interest.

Setting the right threshold and using the right mechanism to arrive at that threshold is non-trivial.

3 excellent articles exploring quorums and voting mechanisms:

I asked some questions of Tally about our Quorum setup for Arbitrum.

This is defined as parameter in the Governor module per treasury, and for the Arbitrum Treasury it is as follows:

support=bravo&quorum=for,abstain string

Right now vote type: against are not aggregated to count towards Quorum. This doesn’t need to be the case and can be changed but that’s how it’s been configured right now.

Going forward any changes would need consideration, dialogue and agreement to determine what’s an appropriate mechanism for Arbitrum. It should also have periodic review to determine if the threshold is set too loose or too tight given voter turnout and voting patterns.


Thanks for the clarification - this is a very correct setting to not sum up all the votes for a quorum.

As for Abstaining, it is simply necessary for all voters to know that in essence they are voting FOR in this case. It is better to make a specific decision, except for a conflict of interest

1 Like

Thanks for looking into this! Let me jump on this little sidetrack here because I find it an interesting topic.

Given the primary purpose being consensus and collective interest, I would personally think having all votes count towards consensus makes the most sense, since every voice counts (with Abstain being the least useful to measure towards reaching quorum, because having a high number of Abstain doesn’t do anything and could therefore lead to quorum based on a smaller number of votes that will actually impact the vote; although unlikely). If you argue that against votes don’t uphold consensus, you should have them impact quorum negatively (most probably in relation to positive votes). What I am trying to say is, that you don’t really measure consensus if you leave out the against votes entirely. Going beyond that, if the aim is stricter consensus a higher than 50% majority should be employed, and not a higher quorum.

Even if cp0x were to be right I would personally not switch my vote, since I don’t want to ‘interfere’ with the majority vote by strategically voting so that a vote won’t pass. That feels similar to a soft veto, and I don’t think we should employ such tactics.

These comments and thoughts reflect my personal opinions on this proposal as a member of the Arbitrum Representative Council (ARC). These do not necessarily represent the overall views of the council, Treasure DAO or provide an indication of final voting decision by the ARC.


I will explain why I started this conversation specifically on this vote.

There are too many interested projects here - 57, with a large share of votes. Of course they will vote to allocate money to themselves.
However, I don’t want to create a precedent where every week you can create such proposals and they will always pass easily FOR due to the large number of interested parties.

This approach does not benefit the community, but I cannot condemn projects that vote for their own interests.

Since I am not associated with any of the projects, it is easier for me to take an objective position, as it seems to me


Blockworks Research will vote AGAINST this proposal on Tally.

First of all, we appreciate the updates made to the proposal posted onchain. Having said that, as many have pointed out, there are still several concerns that haven’t been addressed adequately. From the point of view of growing the Arbitrum ecosystem, we feel that there is no robust argument for running an additional incentive program on top of the LTIPP. As such, our opinion is that the currently optimal action for the DAO is to better understand past incentive programs to create an even better framework, which can be implemented once the LTIPP has ended. To be clear, we fully support incentive programs, but they have to be implemented in a manner that balances growth with sustainability.

More specifically, in addition to the points raised in our previous comment, some of our main concerns comprise:

  • Almost no STIP applicant rigorously justified the number of tokens requested, with the STIP-Bridge building on this arguably somewhat arbitrary allocation. We’ve screened several STIP addendums, and no applicant has quantifiably validated their grant request.
  • The optimistic voting structure is interesting but should be accompanied by a council (similar to what was utilized in the LTIPP), at minimum. As no in-depth research covering the performance of all STIP recipients has yet been published, community members would be forced to conduct due diligence on each applicant’s performance themselves, in addition to assessing all STIP addendum structures. The aforementioned, combined with an extremely short challenge and review period, means that several undeserving protocols and incentive mechanisms are likely to pass.
  • We’re especially concerned about the possibility of an extension that is included in the STIP-Bridge proposal. It’s clear that it isn’t sustainable for the DAO to indefinitely hand out incentive allocations, and since the extension will be posted directly to Tally, it’s unclear how framework improvements would be added to this extension and who would be responsible for deciding the next incentive program’s structure.
  • The longer-term sustainability and user retention of the STIP are not yet understood, and running an extension of the aforementioned incentive program renders it impossible to research these factors.

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

We have chosen to ABSTAIN from the on-chain vote.

We originally voted in favor of the proposal during temp-check in an attempt to not block the momentum and instead help move things forward as we’re overall supportive of programs that help the ecosystem grow and thrive.

After careful consideration we voted abstain because although we see the value in the incentive program, we felt there weren’t enough convincing arguments to vote in favor of the proposal that basically seeks to extend the STIP, without however making any structural changes based on solid data or on the lessons learned so far.

One of the free-floating arguments for the need to run incentives programs, even if imperfect, is that the “war of L2s” for both mind and market-share makes it difficult to stop and assess as that would necessarily also mean falling behind. However, we haven’t seen any concrete examples of that being the case. We’re not questioning this argument as such, but we believe that at this point, after three different incentive programs already voted in, we should have a better understanding of what exactly we are fighting against.

During the temp-check both us and other delegates raised concerns around the lack of data on the efficacy of STIP/Backfund/LTIPP. We believe that those concerns haven’t been adequately addressed yet. Although the proposal suggests that performance audits will take place, we haven’t seen the results of these audits anywhere. The ARDC is working on a review of the STIP, but it’s not yet complete so we cannot use it to inform our decision. We’re also not sure if both of the aforementioned data sources will be complete by the time the challenge period ends to inform us on the need to potentially challenge protocols’ requests.

As it stands, there simply isn’t enough actionable information to evaluate, let alone justify, an extension of the STIP. Therefore, we cannot in good conscience vote in the proposal’s favor at this time.

As the DAO Advocate for the ARDC, but also in our capacity as delegates, we will follow up with a deep dive on the data from the STIP which can help all of us understand whether protocols are meeting the expectations set forward by both the program itself, and also by their applications.

To conclude, we wish that we don’t, as a DAO, have to vote for another similar proposal to extend an existing program and funnel more money into it without properly evaluating its performance and, if needed, making the appropriate changes. We plan on getting engaged in the near future into a final, long term incentive program framework, that will address all those concerns.


I have voted against this proposal on Tally as, like many other delegates reported above, I don’t feel the concerns have been fully resolved - Although I appreciate some progress has been made to streamline the process with a PM and the support of the LTIPP advisors.

As it looks like the program is going to pass, I want to reiterate the key requirement that I think all “optimistic proposals” should be centered on (I wish the template was more straightforward on this).
What was the impact (not only the outcome!) of the grant you received?

Fair distribution of ARB is just the basic step to demonstrate that projects didn’t commit any fraud.
To earn the right for a STIP-Bridge, an actual positive impact should be demonstrated.


I am choosing to abstain.

This has been a really tough vote for me.

I was originally pretty against the proposal. The timing for this is not ideal, part of the agreement for LTIPP would be that STIP applicants would be excluded from the first round. I would like to see the LTIPP projects have a chance to shine and giving the STIP Recipients overlapping incentive periods helps them retain the users they gained from STIP. I actually think it would be healthy for the ecosystem for users to have incentive to float between protocols. It creates healthy competition and the protocols with the best systems will retain more users when the incentives end.

However, I do agree with the point that we need to compete with the many up-and-coming L2s and believe incentivizing the STIP protocols will showcase many of Arbitrum’s best home grown projects, which can attract and retain users for the ecosystem for the rest of the bull market. There is a good case to be made that the timing of all these incentives could line up well with the next push higher in the market which could be perfect for us to grab market share.

Personally, I would love to see the STIP-Bridge pass but be delayed 2 months.

I don’t think this timing preference is enough to vote no for the proposal… but I also don’t really want to vote yes either. So I abstain.


I just saw on tally that this proposal is listed as “Defeated” but I’m a little confused as to why this is the case when the votes FOR are greater than AGAINST and ABSTAIN, and quorum has been met.

@Frisson do you know the reason for this?


Saw this too and don’t think that should be the outcome given the votes. Could be a bug, the Defeated label was showing up intermittently last week.

1 Like

This was a bug on Tally’s UI that has been fixed. Apologies for the confusion.


I was not able to save my reasoning on Tally, so I’m leaving it for recording keeping purposes:

I supported the proposal as I understood that the program, in general lines, was successful. It would be better to wait for a proper results sharing, with a deep analysis, but right now the competition between L2 is huge, and it is reasonable to grant this extension.

Moving forward, my hope is that we consolidate the grants programs under a comprehensive and ongoing one, so the rules, duration are unified.

Blockworks Research has posted support material to help the community evaluate STIP-Bridge applicants who don’t automatically require a challenge vote on Snapshot.


For completeness, Blockworks Research has posted qualitative data and a summary of findings on STIP-Bridge applicants who automatically require a challenge vote on Snapshot.

Hey everyone,

We (Lampros Labs DAO) have created a live voting dashboard to track the voting of all protocols that are up for voting in the STIP-bridge program.

This dashboard provides information about all the protocols’ snapshot voting links, forum proposal links, asks, and live voting statuses for each proposal, all in one accessible dashboard.

Anyone can track the live voting of the protocols in the dashboard. There are 6 protocols that were submitted late and will go through the snapshot voting process, 12 protocols that were challenged by delegates, and the rest were optimistically funded as there were no challenge snapshots posted for these protocols.

Delegates can personalize the dashboard for themselves by creating a copy of the sheet, allowing them to update the status of voted proposals in the last column of the dashboard and see dynamic changes in cell background colours for the first four columns to track their own votes. (P.S. - Please note that while personal copies enable personalization, the sheet will not be updated for personal copies. The main public link remains active and is updated every 5 minutes for all community members.)

I would love to receive feedback, suggestions, or any changes you would like to see in this sheet.

Check out the dashboard from the below link and share your feedback.

Dashboard link -

STIP-Bridge_Voting Dashboard_Created by Members of Lampros Labs DAO - Google Sheets.

1 Like