- Foundation grants have been in the talks for many projects since beginning of the year and have no bearing on the STIP. If you have a project that is of interest to the Foundation, nothing is stopping anyone at any point from putting in a proposal to them.
- Delegate votes should have taken into account potential for back funding as back funding is clearly declared and stated in the STIP documentation
- Appetite for grants will always be there regardless of how the distribution is done
- Groups that did not make it into round 1 cut off also made adjustments in order to try to make the cut off as well. It was not just adjustments being made at the top of the stack, the majority of projects made changes in order to try to be accommodated.
UPDATE - we want to draw attention to a budget clarification that the total listed for Data and Monitoring for Plurality Labs (performed by OpenBlock Labs) is not 100K ARB but 149,500 ARB. The total ask of 21.52M remains unchanged. (also pinning this post)
We are voting no to the STIP backfund. We would like the DAO to revisit the idea of another short term incentives program once the first round of applicants have spent the ARB already allocated. This way analysts can look at the data and evaluate how beneficial the STIPs actually were. In order to efficiently/effectively allocate ARB in the future, delegates need to if/know how much ARB incentives hurt the underlying price, how much TVL and fee revenue changes, whether or not new users are onboarded to Arbitrum, and other important metrics. We would also suggest capping the amount of ARB available to projects to ensure more protocols are included in the allocation next time. January 31st is only 2 months away and we do not believe the benefit of getting this done quickly outweighs the advantage of using data from STIP round 1 for future incentive endeavors.
Is there a reason why Blockworks did not vote in the temp check or engage in any of the conversations here on the forums or the myriad of other comms channels?
Pretty disappointing to see, but at least the community gets to see some rationale of your decision after your decision.
After the original STIP allocation was distributed (mostly uncapped and favoring already massively established projects ahem), there have been plenty of opportunities to contribute to the discussion of this backfund. The results?
Overwhelmingly positive by all those who actually participated in the discussion. I urge the community and our delegates- please don’t let this blunder of over expenditure towards a handful of projects be what drives small startups and innovation away. What we see here are the few gate keeping the many.
Good job, decentralization.
Question, so for those who are stuck in this voting process, if this vote fails to pass, then we will not get an opportunity to apply for STIP round 2. How do we consider those protocols that might have wanted to make a submission, but are waiting for the results of this vote?
Curious why an AGAINST vote was submitted now? Did anything materially change since this post? Would appreciate some transparency and what swayed your thoughts.
Edit: I see the comment on Tally now, still would like clarity on what changed.
I believe they want to include Round 2 too and the backfund will likely deteriorate the previous vote for STIP integrity.
It’s important to remember that when MUX first put up their draft for a grant they asked for 9 Million ARB.
9M ARB for a GMX v1 clone that integrated Gains and GMX as an aggregator on top.
Then they abstained for every vote during the STIP.
But now they really want to express themselves and deny 21.4M ARB to a group of 26 Protocols.
Mostly because of these reasons that were indicated in the original comment:
The 25+ proposals in this backfund bundle have mixed quality; some are worthy of support, while some are questionable, considering the protocol fundamentals, incentives execution strategies, and actual grant requested.
It would be more reasonable to have the proposals being voted on individually in a round 2 type of event instead of binding all the proposals together.
The term “inclusion” was used frequently in this conversation to back up the intention. However, it seems the phrase has been used to dodge the fact that the original grant size was set according to supply & demand + DAO treasury fund management concerns instead of being “exclusive”.
Round 1 was made possible by DAO members advocating for a framework so more protocols and builders who are building projects with solid fundamentals and clear benefits to the ecosystem can be supported. Some of the claims that tried to twist the original intention in this forum thread are a bit sickening to see.
Passing the quorum wasn’t a solid reason to back up the claim for a “guaranteed” grant; Passing the quorum + making it to the cutoff line was, given the fact that the VOTED size for the first STIP was 50M.
We hope the backfund attempt won’t become a recurring behavior that will always happen after all STIP types of events
Although MUX delegates would love to support many individual proposals included in this bundle, the delegates can’t seem to align with the bundle backfund approach. Several proposals involve strategies that can simply initiate sybil-attack type of transactions that will likely boost transactions when the incentives are live, and then the majority of the “ingenuine” addresses will leave after the incentives run out. We simply won’t want to see that happen cuz that will waste DAO funds for nothing. Again, we would love to support many individual proposals included in the backfund proposal, and would have been ideal if it were individual voting.
You could have supported many of the protocols with the round 1 stip and voting for those you deemed suitable rather than abstaining.
Now your team deems it necessary to block instead of abstain.
To me this feels like another maneuver to give certain projects a longer runway against their competition.
As an aggregator, MUX’s proposal has always been using the grant toward 4 perps protocols with a combined liquidity depth of $550M+, with the goal of using the grant to cross the fee barrier and onboard more real traders for the ecosystem and multiple protocols. The increased volume will also mean higher income for GLP, GM, gDAI, MUXLP, and all of the protocols and pools built on top of them. Based on this context, the original 9M size was proposed. It would’ve been more reasonable to include the context than using numbers only to point fingers.
In addition, after realizing the total grant size from all proposals was very high during the review period, MUX was one of the first protocols to voluntarily lower the size to 6M with a 30% drop (one of the highest drop, plus this happened during the review period, not one day before voting period ended ), while still keeping the original execution strategy even when that means the campaign will end earlier than expected.
MUX voted “For” for many of the proposals included in the backfund proposal during round 1 if you checked the record. Voting “Agansit” doesn’t mean we are not supporting some of these proposals, since I have indicated in every comment so far that MUX delegates would love to support many individual proposals included in this bundle, but the delegates can’t seem to all align with the bundle backfund approach.
I don’t understand what changed between temp check and snapshot.
Your proposal combined with your main integration partner’s ask amounted to almost 50% of the total STIP ask.
Now we are hearing about issues with ‘budget’ when the majority of the STIP rd 1 budget was taken by 3-4 protocols.
Which projects do you expect to initiate “sybil-attacks”?
If Sybil attacks gaming transactions with STIP incentives are a plausible concern, then Sybil attacks on individual protocol proposal voting should also be considered a concern. The potential for profit is greater with griefing individual protocol proposal voting, as it’s not capped by grant size.
If a protocol token can be short margin traded, there is an opportunity for significantly more profit using the ancient Italian gambit (gambetto, before chess), the act of tripping someone with the leg to make them fall. For example, voting Against & Abstain can be used maliciously against an individual competitor protocol, enabling predictable profitable short margin trades or price drops for profitable spot trades.
The DAO does not conduct Sybil checks. This absence of systems to monitor for Sybil and self-dealing necessitates proposal bundling. When proposals are voted on individually, it creates an opportunity for profitable Sybil attacks and facilitates self-dealing. On the other hand, bundling aligns interests; it becomes highly implausible for many attacks to affect the entire bundle without being obvious and unprofitable.
Preliminary network analysis of STIP round one, shows self-dealing happens. A delegate, not MUX, who openly opposed and voted against a particular protocol, has profited from trading(last day of STIP voting) the token of the protocol they both, openly advocated against & voted against. Individual proposals cater to self-interest when there are no systems to conduct Sybil & self-dealing checks.
Finally, I agree that certain projects ought to be excluded, but on verifiable, testable, objective values regarding security and trust. For instance, hypothetically, if they deploy into production unaudited contracts, omit critical information from incentives proposals or finger prints link to a sybil attack.
Plutus has decided to vote against the proposed backfunding approach. We acknowledge the good intentions behind this proposal but believe there are more effective strategies to consider.
To begin with, the initial voting decisions in Round 1 were based on specific rules that included the possibility of a Round 2 extension. Incorporating a backfunding approach at this stage might have influenced these decisions differently, potentially altering the outcomes significantly. Furthermore, numerous protocols tailored their proposals in response to the initial rules. Changing the approach now could render these adjustments ineffective.
Additionally, we prefer to review a detailed proposal and subsequent discussion for Round 2 and its interplay with the backfunding approach before making any commitments with DAO funds. The backfunding proposal involves a substantial sum, over 20 million ARB, and there’s a concern that these proposals might compete for the same resources.
Lastly, the backfunding approach aggregates incentives for several protocols, which might inadvertently exclude those anticipating a second round. We advocate for a system that emphasizes merit and inclusivity. This can be achieved through a distinct second STIP round, with its own set of transparent rules and individual voting for each proposal.
As we explained during temp-check, we were originally hesitant with the proposal, but most of our concerns have been addressed since. Given that nothing changed to the extent that it would cause us to have new concerns, and since the team behind the proposal has been very actively working on pushing forward a STIP Round 2, we’ll be voting in favour of the proposal in the on-chain vote as well.
The on-chain AIP to backfund successful STIP proposals has passed!
Congratulations to the 26 projects that are eligible for the backfunding. The Arbitrum Foundation, with the STIP multi-sig’s buy-in, is tasked by the STIP proposal to handle all KYC/KYB checks on teams who are eligible to receive the funds and for arranging the Grant Agreements to be signed prior to the ARB disbursement.
As next steps, please follow the instructions in this post to kickstart the compliance process.
Upon receipt of the email, the Foundation will start the compliance process with a third party service provider.
All formal communication will be conducted over email with firstname.lastname@example.org. Please double-check all email addresses and, if in doubt you may contact @stonecoldpat or @cliffton.eth on the forum.
Love the fact that successful projects that meet the criteria will have their proposals in, looking forward to Bitsave’s Success in Q4 on Arbitrum.
Will keep updated on this.