StableLab Engagement
StableLab has offered to handle the management of the forum process starting September 22, 2023, and has agreed to accept back pay (from the proposal’s passing) via weekly streams forward through January 31, 2023. This arrangement was initiated due to their proactive outreach regarding a competitive rate and interest under unique time constraints and circumstances. If at any point the multisig feels StableLab has not upheld diligence in its responsibilities the multisig is empowered to halt the stream and appoint a new service provided by election.
Further, due to these last-minute circumstances, the DAO is entitled to elect competitive service providers during the first voting round by signaling a competitive offer in this proposal thread. If a counteroffer(s) is endorsed by a delegate with over 500,000 ARB VP the DAO will hold an election for the remainder of the contract length (endorsement to avoid spam).
I will continue to stay involved in helping @Matt_StableLab and the StableLab team support the forum process, contributing toward the data and reporting side (working w/ PL-funded data provider). Given the magnitude of funds and the amount of applications, I hope the community can support this added help on short notice.
Clarified wording on quorum: “To succeed, eligible applications must receive a greater than 50% majority in favor of the proposal, and receive greater than 71.51 million ARB.”
They have been thinking about extending the review time, in total there are 54 proposals and each of them needs to be analysed. I think it would be prudent to extend the review time, and there is still 1 day left to submit applications. We have to bear in mind that we are handing out millions of dollars.
The original timeline intended to allow for delegates to expedite quality applications while pushing more questionable applications to the second round (either by voting no or not contributing to quorum). Given the numbers here though the burden on delegates to identify the quality applicants may be too high.
I can understand the sentiment to extend if delegates need more time given the sheer volume of apps. That said, this is perhaps best signaled by a snapshot vote to gain consensus from delegates if they wish to do so. If delegates feel a need, I’d suggest spinning up a quick amendment vote to adjust the review period to 2 weeks.
My pay for these responsibilities was removed from this proposal and given to StableLab due to their more competitive offer and for the aforementioned bandwidth reasons. It’s all in the proposal above.
There may be someone we would like to sponsor with a competing bid. What does that entail?
In the meantime, if StableLab is the intake filter for applications, this needs to be made known to all the applicants. No one knows they’re commenting on all these threads except as a delegate.
I’ve seen some asking for 3M, others 2M, others 1M and not so many asking for less than 625K. What does that mean? Well, I’m sorry to say but…
… Houston, we have a problem.
I didn’t do the math to see what is the exact total sum requested for, but I’m afraid we can’t serve everyone and make everyone happy. I would’t be surprised if we are exceeded by 20-30M. I wish someone with time and patience could provide accurate data about this numbers.
According to the program’s guidelines:
Now that this scenario is a reality, can you @tnorm elaborate or give some example to make it more clear?
I’m not sure if I get it right. Does that mean that every application that passes the vote will get paid only the same percentage of the total amount requested as the percentage of the votes received in favor? And then if the budget is still exceeded, the FCFS on application submission will apply to exclude the latest ones?
I wonder if given the unexpected outcome it could be a better option to apply new measures like: (just as examples)
1. Size of grants for each tier could be lowered by like 20%. 2. Pinnacle grants could be capped to 2.5M or 3M max.
Not only everyone asked for the max amount in their tier but also many asked for bigger amounts out of the range. I know the amounts so far are just suggestions, but maybe
another measure could be:
3. Turn the amount suggestions into mandatory so everyone should stick within their tiers.
Let me give an example:
This application requests for 1.8M ARB with a TVL of only $3M. They belong to the Beacon Grant tier with a recommendation of 200K ARB to be requested. 9x difference.
However they are still allowed to go through vote since there’s no limitations.
Knowing already at this point that there is no ARB enough to satisfy everyone, and knowing that many will have to be left out to allow others stay in, should this kind of greedy applications even being allowed to go through vote? In case it passes the vote, is it efficient and fair to other protocols with 10x more TVL and almost same grant? or to other protocols being left with 0 ARB?
Wouldn’t make more sense to make them lower that amount by mandatory to one reasonable for their TVL and sensitive to the budget reach like the recommended one? Even more likely to pass the vote.
If everyone sticks to their tier recommendations it might be room for everyone.
I apologize to DODO for using them as an example. My intention isn’t to point to anyone in specific. To begin with they are not doing anything illegal and mostly everyone is doing similar. It’s just that I needed to use some real example to argument what I want to explain.
In summary:
We could make the application process more strict and selective to direct the applications to the voting process with a much more reasonable requests and more likely to pass.
This way our limited budget not only will reach more projects but also the distribution will be more fair, inclusive and reasonable in terms of grant size related to protocol size.
Per this proposal, funds would be allocated to grants on a per-grant basis, meaning those with the most votes in favor of the proposal would be prioritized, with allocations continuing in descending order of the number of votes in favor of each proposal until the budget is exhausted.
This budget constraint was the primary point of the last Snapshot, and the DAO’s decision was conclusive. To the point of not every grant being received, it’s worth noting that grants =/ charity, and I’d expect delegates to act with their best discernment to reward those who request reasonable grants, with strong justification, and clear strategies in line with Arbitrum goals.
A Snapshot vote (referenced by @Matt_StableLab and @axlvaz_SEEDLATAM.eth in previous comments) could presumably modify these parameters, as a ratification of operational guidance for the multisig to base their execution upon, but at this point that post would need to be made rather quickly.
There’s also the possibility that the on-chain vote might not pass, essentially halting the program while the DAO considers other options. It’s really in the hand of delegates now.
Barring any aforementioned changes or needed clarifications, I expect stakeholders will proceed per the guidance of the previous temperature check and current on-chain proposal.
100% agree with this. Pinnacle grants being uncapped is just tipping the balance of power heavily towards larger projects once again. Many of these projects proposing 5m+ grants already received a very large DAO airdrop without showing any data on how their additional ARB proposals will do anything other than lock down their incumbent positions.
2.5m seems fair for the largest grant sizes.
Remember - this is supposed to be a SHORT TERM incentive proposal. A stop-gap until more formality is put into place.
i respect the engagement and well written post but ‘serving everyone and making everyone happy’ was never really in the cards. there was always going to have to be discrimination and decision-making on the part of the delegates, and deciding which proposals deserve to be funded and which don’t. nothing’s changed in that respect.
it seems unlikely to me that the dao would approve more than 50 million worth of grants individually when it capped the aggregate to that amount, but in the event that happens then we’ll just have to go through the governance process again to decide what to do. like you pointed out, a lot of the grants are not objectively reasonable and we should expect delegate voting to reflect that.
Let’s trust delegates then. I hope they advocate for common sense over all.
Fairness and inclusion should be prioritized imo in order to avoid/minimize any further anger and discomfort within the devs community.
Last thing we want is a general feeling of discrimination from the ones who meet the requirements and fully comply with the application guidelines.
Otherwise could easily trigger an exodus leaving us with a least competitive space after the program than the one we had before it.
It’s all in your hands delegates, be aware of your power/responsibility and don’t disappoint please. I’m sure you won’t.
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.
We voted in favour of the proposal during the temp-check with our option being to distribute up to 50M ARB through the program. We’re happy to see that the temp check resulted in that being the most popular option.
We’ll also be voting in favor of the proposal at the on-chain vote.
I have voted yes on Tally for this. I have some reservations about some of the decisions made for this, but I acknowledge that:
This has been the work of lots of contributors over an extended period of time. Decentralized governance (during a bear, no less!) is messy, and the solution was never going to be perfect given the circumstances.
We shouldn’t let perfect be the enemy of good. Inertia works both ways, and I’d rather the ball start imperfectly rolling towards a comprehensive framework then away from it. As others have acknowledged, if this were to fail the grant requests will come rolling in regardless. At least we have some guiderails.
I have not been as active as I have wanted to during the last few months or so due to personal reasons, and in fairness to those who put in the hard work my concerns should of been voiced earlier. However, I see there has been a lot of thought that went into this and respected contributors are agreeing to it.
The size of grant requests is fairly large. Whether that is people looking for handouts or genuine success of the program is to be determined… but it does indicate there is a “market demand” for this in some manner. It will be a tall order, but hopefully delegates will do their due diligence when voting occurs. Although I fear the sheer volume may not allow for that.
Apologies if I missed it. I saw some discussion in the OP about KPIs for the program and determining the success. Has there been talk about what post-grant looks like? Who will use this info to keep the ball rolling into a more fleshed out, long term grants program?
As this is my first time posting on the Arbitrum forums, by way of introduction I am API3 DAO’s ecosystem lead and work closely with our ecosystem, developer relations and business development functions to engage various elements of the Arbitrum community. Thank you for your efforts in driving this initiative and facilitating an open discussion around the Arbitrum DAO. It is great to see somebody taking ownership of ecosystem engagement and by no means is this as easy of a task as it may seem. Kudos to yourself for taking the lead and for the retrospective support from the DAO.
Overview
To date, API3 DAO has deployed a range of oracle services that are accessible to the Arbitrum community. Specifically, we have:
Deployed API3 QRNG to Arbitrum One and Arbitrum Nova in Q2 2022 and have seen just over 200k requests since.
Ensured developer learning resources are easily accessible and supported Arbitrum builders through considered ecosystem activities, community building events and direct builder engagement.
Deployed 120+ decentralized data feeds that provide access to crypto, equities, commodities and forex price reference data through the API3 Market: API3 Market
Upon the request of DeFi protocols have activated 4x price feeds at a 0.25% deviation that are now accessible for all in the ecosystem: API3 Market
Building on that last point, as of August 2023 decentralized data feeds called dAPIs were accessible to builders on Arbitrum One. dAPIs are data feeds powered by first-party oracles, which means that the API provider is running the required Oracle infrastructure without introducing additional third parties between the data producer and data consumer. Managed dAPIs see multiple first-party oracles aggregated on Arbitrum to provide a verifiably decentralized data feed that significantly enhances transparency within decentralized oracles. Since August we have seen dAPIs be utilized in a small number of DeFi dApps within the Arbitrum ecosystem with some updates to official TVS imminent.
What is the query?
Since the introduction of managed dAPIs, API3 has been utilizing the ARB grant from the Arbitrum DAO distribution to activate data feed required within the ecosystem. As of writing, we have utilized just over 1/3 of the initial 75k ARB to subsidize price feed operation for DeFi protocols on Arbitrum. With the introduction of this initiative, we have been considering how we can best support the growth of the Arbitrum ecosystem through the provision of oracle infrastructure within this framework.
Support Network Growth: Accelerate the distribution of incentives to Arbitrum dApps to drive network and ecosystem growth.
With the operation of API3 data feeds, we need to cover gas costs associated with oracle transactions. This means if we are to activate a feed on Arbitrum we would require a conversion from Arbitrum to Eth. With consideration of the below, we wanted to openly communicate this and understand if this is an acceptable scenario or whether we should consider alternate mechanisms to reach this end goal within a request. Or consider an alternate framework.
Grantees are required to keep distributions in ARB without converting to other assets.
When considering this it is worth noting that API3 does not have margins built into our data feed pricing. Any funds provided for data feed operation exclusively cover gas overheads associated with maintaining price on-chain from multiple first-party oracles, with a small buffer to account for abnormal chain behaviors that may see these costs spike. This does not include operational overheads such as contributor grants or API access costs.
Clarification on Abstain Votes
After multiple questions regarding the nature of Abstain votes, it’s been decided to publicly and preemptively clarify the role of Abstain in the Voting Round.
To succeed, a proposal must receive greater than 50% of votes in favor of the proposal and a quorum greater than 71.51M ARB.
Voters can either vote FOR, AGAINST, or ABSTAIN.
FOR: A vote in favor of the grant application.
AGAINST: A vote against the grant application.
ABSTAIN: Neither a vote FOR nor AGAINST the grant application, but a vote towards quorum.
As such, the success conditions of an application can be calculated as the following:
What most are interested tho, is in the mechanism about distribution of funds since we are around a total request of 100M proposals.
In the initial STIP framework, two rules were quoted: a vote-based distribution and a first-come-first-served.