@cattin May I asked what compelled you to push the snapshot vote in such urgency while many where calling for time and moderation? You don’t see any conflict of interest in having STIP grantees vote for this proposal ? Does it seem to you that it’s a functioning governance process ?
Snapshot simply serves as a temperature check, it’s not binding in any way. Those who drafted the proposal reached out to me so that I could send it to Snapshot since only delegates with more than 0.01% of votable tokens delegated can do this, and as a delegate I was happy to help with this. I have no relation to the proposal or decision making behind it, I simply assisted them with putting it up for temp check. I haven’t even voted on this proposal yet or said anything about it.
If you have any questions about this, you should maybe ask those who drafted the proposal or are involved with it.
5 Likes
Thanks for the answer, It doesn’t remove my concerns about what is happening here but It helps understand the process.
1 Like
A few questions:
- If teams violate the STIP terms and conditions, do they get the STIP-bridge?
- Several teams made no claims on their STIP funds. Are these eligible for the STIP-bridge?
- What was the logic of the <250k teams getting a 1:1 bridge? Why do they now get a larger portion of their funding than everyone else?
Not sure if anyone has called this out already, but this wording is kind of nonsense, no? If anything <= 500k can only get a request up to 250k, then they are not eligible for 100% of their prior funding. It’s really that anything <= 250k is eligible for 100% of their prior funding, everyone else is eligible for 50% unless you are between 250k and 500k. It’s kind of a convoluted rule to apply, but the wording certainly doesn’t help.
1 Like
Below is feedback from the UADP (we abstained):
Our team is generally in favor of supporting incentive programs. We voted FOR the previous STIP initiatives, as well as the LTIPP. This proposal, however, caused us to pause. There’s a degree of ambiguity present that leaves too many questions unanswered, and we are unsure if further incentivizing these protocols is the best use of treasury funds. There needs to be a more comprehensive analysis of the impact of the STIPs–hard numbers and data.
It seems many are beginning to justify large incentive spending as a way to compete with other L2s. Vampire attacks become especially rampant during bull markets, with new protocols offering exorbitant APRs. We’re of the opinion that enough incentives should be paid out to worthy protocols–and those incentives must be coupled with products that have market fit. If STIP incentives for a protocol don’t work, the cop out cannot simply be “there are higher yields elsewhere”. We have to consider if the products we are incentivizing actually have merit. Sure, capital chases yields, but consumers chase good products. Before providing STIP projects with more incentives, the DAO should conduct a more comprehensive analysis of the failures and successes of the already deployed incentives.
Furthermore, capital inflows shouldn’t be the only metric for judging the success of the incentives. Stickiness of capital and users is perhaps a better measure for sustainability. It’s great that these incentive programs have increased Arbitrum TVL. And we get that there’s a desire to grip onto that capital, making sure it stays in the ecosystem. But we should also consider the lasting impact of these incentives. A good way of putting it perhaps–the current TVL is like pouring water into a glass…but that glass has a hole in the bottom. Instead of continually filling up the glass with incentives, maybe we should figure out how to patch the hole.
The UADP will abstain from voting for this proposal. We hope that the authors take the DAO’s constructive feedback and provide delegates with more substantive reasoning behind why this proposal is worthwhile. If the provided reasoning is sufficient, we may alter our vote to FOR later on either during a new snapshot or the onchain vote.
9 Likes
Echoing many of the comments above, the team at FranklinDAO/Penn Blockchain is skeptical of this proposal for the 2nd STIP round. This proposal would distribute capital subject to a DAO wide vote without providing a clear criteria to judge past STIP recipients success or success of STIP program as a whole. In our view it’s very important to prioritize sustainable and organic growth, rather than have protocols and activity be run on a flywheel of incentive handouts. We also believe that it may be better to isolate large funding rounds from one another, and hence focusing on LTIPP rather than this STIP round 2, so we can better assess the impacts of each funding round.
3 Likes
gm all, voting AGAINST this proposal.
I am fully supportive of all projects that received the previous grants, and I want to see them succeed on Arbitrum.
At the same time, I don’t think they are entitled to enter a special “whitelisted” category where they can just optimistically get money.
On the contrary, any recurring incentive (especially for a considerable amount of ARB) should focus on being:
-
Smart: demonstrate previous impact and expected ROI. Not every activity deserves to be rewarded. What was your most successful pool? Have the incentives created a sustainable flywheel? How can we replicate/increase its usage?
-
Meritrocatic: new and exciting builders should be incentivised to create innovative products with clear product market fit. Those that do will be rewarded. We shouldn’t insist on failed experiments.
-
Sustainable: resources are not infinite, and spending anywhere has trade offs. Did we really need vaults with 50% APR fully paid in ARB? That’s an easy game, but it can’t go on forever. As there will always be another L2 trying to vampire attack Arbitrum, let’s try to build a composable ecosystem that can be kickstarted by external ARB incentives, but doesn’t rely on them for the long term.
6 Likes
I’ll be voting against this proposal on behalf of the ARB holders who have delegated their voting power to me. The proposal lacks a thorough analysis of the previous STIP incentives’ impact and does not provide clear criteria for assessing the performance of past recipients. It’s crucial to focus on sustainable growth rather than relying on continuous incentive distributions. The proposal also fails to demonstrate the anticipated return on investment and does not adequately address the retention of capital and users. Until more compelling arguments are presented, I cannot support this proposal in its current form.
4 Likes
I will be voting “Against” this proposal.
As I noted above, I believe the time and funds would be better spent using what was learned from the prior 2 STIPs, as well as the current LTIP, to move forward with one large round that any project (regardless of prior funding in either of those rounds) can participate in after the 12 week LTIP is completed.
The STIP voting was flawed, and the LTIP trial run has (so far) seemingly remedied a lot of the prior issues. While I still see room for improvement with the LTIP, automatically re-upping prior STIP winners based on no real framework is a big step backwards in our process. Especially given the timeframe, there is no reasonable way to review all the proposals for who is actually deserving of additional funds. We do not have time to setup a committee to determine who was successful and who was not, nor do delegates have the time to assess 100 proposals again (which will be double duty considering the LTIPP needs approval by delegates as well).
Others have echoed similar concerns about the proposal. While I understand the urgency to post to snapshot given the timelines, it further concerns me that I have not seen any response to any opposing comments over the last few weeks - ample time to flesh out a discussion. Plus, I’ll also add that some of this urgency is self-inflicted, as the LTIPP Tally vote was 2 months ago.
Simply put - I do not agree with the proposal as stands and do not believe there has been enough discussion on this. With the vote ending within 48 hours I have decided to move forward with my against vote as I do not anticipate concerns will be adequately addressed before the poll is closed.
2 Likes
After carefully considering the feedback from various members of our community regarding the proposed approach to incentives, we still have many concern, including unsufficient data from the previous STIP round. As a result, we have decided to vote against the proposal. Our decision is grounded in several key concerns and rationales, as outlined below:
- Lack of Comprehensive Data on STIP Program Efficacy:
We are seeking more detailed information on the impact of the STIP program, specifically regarding the ecosystem’s condition without any incentives versus with the STIP program in place. A deeper analysis is necessary to understand the true impact and effectiveness of STIP. The goal of STIP is to iterate on the results and findings from the initial program.
- LTIPP is Coming and Questioning the Necessity of Doubling Down.
@pedro raised a good point of view, we also agreed on the distrubtion of LTIPP is coming soon and should be able to achived the intented goals of this proposal.
- Exclusivity to STIP Participants:
The proposal appears to benefit only those protocols that previously participated in the STIP, which may limit the inclusivity and overall effectiveness of the incentive strategy.
3 Likes
After careful consideration, I voted abstain on this proposal.
Things I like about this proposal
- It continues to invest in the growth of leading projects on Arbitrum, many of whom were successful pre-STIP (and therefore have demonstrated product-market fit)
- STIP projects are excluded from LTIPP. In retrospect, I think it’s weird that we exclude specific protocols from incentive programs and think I should have pushed back harder on this aspect of LTIPP. This creates an environment where the excluded protocols are incentivized (no pun intended) to create their own program. I like that this proposal allow projects excluded from LTIPP to be eligible for incentives. Going forward, I don’t think specific projects should be excluded from incentive programs.
Things I don’t like about this proposal
- This proposal does not attempt to learn from the results of STIP. I would like to see some analysis of the successes/failures baked into future incentives strategies.
- I suspect there was a significant gap in effectiveness among STIP projects. I’d like to see a plan to surface some analytics around this to help delegates with the optimistic voting process.
A note about Tally specifically:
- We (Tally) were able to successfully deploy 100k ARB of our 200k ARB STIP grant to onchain DAOs that deployed on Arbitrum. We earmarked the last 100k for distribution to GMX, who is launching their DAO on Arbitrum shortly. However, we technically are not able to deploy it because the GMX DAO will not exist onchain until (shortly) after the STIP period is officially over. This proposal would allow us to technically follow the procedures of STIP by sending back the 100k we earmarked for GMX and then applying for it again during the STIP bridge period. With that said, if this proposal does not pass, we would very much like to be able to deploy the 100k from the original STIP period to GMX after the STIP period is technically closed.
1 Like
So at the moment we have FOR winning the snapshot solely due to STIP recipents voting to double-dip on their grant… If this goes through, it’s time to stop for a moment and seriously question the benefits of the existence of this DAO as it is.
cp0x voted against this proposal
I have several complaints about this proposal:
- Projects received a certain number of ARBs for their ongoing activities. If they needed more money, they would have asked for it immediately
- Before funding a project, it is necessary to understand its effectiveness. Therefore, it is incorrect to give additional funds without analysis, since we do not know what we did with the previous grant
- There is no problem in analyzing the activities of projects in order to issue grants to them. There is no problem in spending time on this
- I categorically do not support the idea that funding should ultimately be permanent. Grants are needed for startups and to attract liquidity, and not to keep projects afloat only at the expense of this money
I’m confused that the projects that are interested in this proposal have a large enough number of ARB to pass this vote
1 Like
I think this proposal is just a little bit too early.
Give it a few more months, and I would vote yes.
For now I have to vote against it.
1 Like
DAOplomats (previous DAOStewards) voted against this proposal.
First off, we believe this is a wrong motivation for this proposal to move forward. Giving out funding solely/majorly because we want to retain integral projects is not sustainable.
Also, echoing what a number of delegates have already said, the timing and eligibility criteria are not palatable. Let’s see how LTIPP plays out then we can revisit these conversations.
After consideration Treasure’s Arbitrum Representative Council (ARC) would like to share the following feedback on the proposal
TreasureDAO’s ARC will vote AGAINST this proposal. Although we do agree with the need for incentivization for the original STIP participants to stay competitive in relation to other projects and chains that incentivize usage in whatever form (points, funding etcetera), and as they cannot enter the LTIP under its current form, we think that the STIP has taught us valuable lessons to proceed towards more sustainable forms of funding like the LTIPP and the soon to be PIP.
-
Motivation. There isn’t enough research done on the STIP metrics to conclude that the STIP has been successful in sustainably growing the network (i.e. network growth that will stay even when incentives are taken away). Even if this has not been the case, an argument could be made that projects need incentivization to winter a period of other chains heavily incentivizing competition. Yet, a lot of the early STIP participants have been competitive without incentivization and are well-established projects within Arbitrum, and should therefore be robust enough to function irrespective of incentivization so that a stronger and more sustainable program can be applied than the more immediate extension of the STIP. @pedrob also makes a solid argument that this period can be used to study the effectiveness of the STIP (in terms of stickiness, performance without incentives and in regards to incentivized competitors).
-
Rationale. Although definitely possible, there is no proof to show that the STIP will lead to ‘the imminent risk of losing key ecosystem participants to competitors.’ Furthermore, the top 10 wallet addresses to receive STIP incentives through the STIP have gotten a combined 18.43% (6.22 million $ARB) of all the incentives, and the top 100 wallets 44.83% (15.43 million $ARB). Sure, having high value users on board is a good thing, but questions can be drawn about the nature of usage and if these users would stay equally as active on these platforms regardless of the incentives. For this reason, research on these metrics is important to make verifiable claims of the effects that either extending or moving away from the STIP will have.
-
Addendum. As said above, more research on the effects of the STIP is needed. The Addendum paragraph talks about the STIP proposals needing: ‘Data on the performance of their activities during STIP’. Having individual projects report on data of their STIP incentivization is problematic because it will lead to data being used differently by the projects and therefore making them less comparable to each other, and other non-incentivized projects.
-
Voting mechanism. From a psychological perspective, requiring the delegates to ‘challenge’ individual applications on their own takes a lot of courage and will therefore have a higher chance of leading to passive acceptance (see: trolley problem, bystander effect). We are all for having a more streamlined voting process, but it shouldn’t come at the cost of proper review. On top of that, as @pedrob and @Bob-Rossi have also mentioned, the burden to review these applications is effectively still on the delegates and is therefore a step back from the lessons we learned from the STIP and applied to the LTIPP (i.e. ‘Too large a burden placed on delegates’, ‘protocols did not receive adequate feedback on their proposals’ and ‘Strict limitations on Incentives Mechanisms’).
In our opinion the best way to move forward would be to research the effects of the STIP to see which conclusions can be drawn from it that can be applied in future incentive mechanisms; including a period of non-incentivization that can be used to gather more data to be able to create even more robust incentive mechanisms. Other potential options would be to research the effects of the STIP as is, and directly apply these to an improved STIP or propose to up the funds for the LTIPP and go through the LTIPP approval process.
2 Likes
Blockworks Research will vote against this proposal.
While it is clear that a vast amount of onchain activity across ecosystems is currently inorganic, and Arbitrum needs to maintain its competitiveness, we feel the distribution of incentives should be done on a more granular level. Moreover, in a hypothetical situation where Arbitrum doesn’t distribute incentives at all, users/capital that opt to leave the ecosystem completely aren’t valuable for Arbitrum in the long term in the first place, as these users/capital are likely to be purely extractive.
As has been mentioned across several sources, the original STIP process had many nuances that could be improved on, implying that the selection of protocols could have been more effective. Arbitrum is rightly in a growth mode, but distributing incentives in a semi-automatic way will—in the long term—likely lead to a situation akin to the problem known as Zombie Financing in corporate finance.
Due to the aforementioned reasons, we suggest that previous STIPs as well as the upcoming LTIPP be studied more closely through quantifiable KPIs and with a focus on customer retention. Furthermore, we think that a detailed execution plan for the usage of Arbitrum’s balance sheet should be considered to ensure the ecosystem’s long-term success. This will be especially important once market conditions worsen, and, in our opinion, is something that the DAO should start preparing for.
We consider this proposal to be structurally incomplete in its current form, and thus, vote against it.
3 Likes
Savvy DAO has voted FOR this proposal.
See or reasoning in the proposal above.
Snapshot: Snapshot
Delegate thread: Savvy DAO - Delegate Communication Thread - #10 by SavvyDAO
The below response reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
After careful consideration, we’ve decided to vote in favor of the proposal during the temp-check, without however necessarily committing to supporting the proposal during the on-chain vote in its current form.
Our support should be treated as a signal of overall support for continuing incentive programs for the biggest protocols in the Arbitrum ecosystem, but we see the need for more debate and clarity around the results of the previous programs and the expected outcomes of this one.
As others have already pointed out, there’s a lack of information around the proposal, such as the efficacy of previous such initiatives (STEP, Backfund, LTIPP), and not enough overall discussion and involvement from delegates.
While reviewing the proposal, we realized that it’s basically a proposal coming from/involving some of the most prominent builders on Arbitrum. That was something that urged us to carefully review the implications that the outcome of the proposal was going to have in either case (passing or failing). Voting against the proposal during temp-check and effectively “killing it” doesn’t really provide the DAO with steps forward other than sitting on our hands until LTIPP concludes.
We’d much rather keep pushing forward and hold constructive discussions to figure out how to fill in the gaps and improve the proposal, especially based on the feedback of the people who are currently opposed to the proposal or abstaining from it than take steps backward.
With that in mind, we’re voting in favor of the proposal at the Snapshot vote so we can signal that we’d like to figure out how we can best improve the proposal before going to an on-chain vote.
10 Likes