We support this proposal. The extended delay on the L2TimeLock would not impose any performance bottlenecks upon smart contract development, but in fact the effect would be the opposite, as there will be more time allocated to repair and upgrade previous smart contracts. In addition, the added time will be crucial for the security council to act upon any malicious attacks if they occur, and the user themselves gain more time to withdraw their funds to protect themselves from a potential attack for instance.
We vote for this proposal. Since the Operations budget has already passed, this proposal just approves the distribution of the funds to the respective parties. The percentage and cost breakdown for each portion of the operational budget is logical and below industry average.
We vote for this proposal. We believe the idea of delegating 7M ARB to a community voting pool will bring in more small-wallet ARB token holders to participate within the Arbitrum DAO and governance community. In addition, this proposal leaves room for flexibility to un-delegate these 7M ARB tokens from the community pool at any time under discretion from the MSS Committee. Lots of benefits in terms of increasing governance participation.
Overall, like the direction this is going in compared to v1 introducing more quantitative criteria. However, we think that some of the thresholds for voting are still too low (thinking about this program in comparison to Uniswap’s DIP). Lots of comments in the RFC stating similar points we agree with about quantifying participation, comments, and call attendance.
We vote for this proposal, especially after some of the promises made in the July 22 update by Frisson. Voting for how the future fund rewards will be distributed and deciding how the staking percentages will be set at a later date allows for the flexibility to alter the rates that delegates get, which can be important in ensuring that centralization by a few key players is avoided. The idea of staking seems like it would benefit the DAO and Arbitrum as a whole, as more people being involved thanks to the monetary benefit that comes from staking means governance decisions will involve more people than before.
We vote against this proposal, as there are some concerns with the value of this service. The first point is that while confirmed by Blockworks that this sums up to below market value, the total cost coming out to 210k is still a big ask. The ROI and value proposition of this proposal is not apparent to us, and until that proposition is visible, this proposal does not seem like a good use of money. If another vote were to take place with more explanation/vision of how Orbit chains and their analytics can be useful in specific cases, we could get behind that.
Voting against this proposal because of crossover with Karma services. Think that there are specific use cases for a project like this such as to avoid gov attacks or inspect governance tangential areas like grant usage, rather than the current generalist scope of the project. Some of the individual delegate metrics may be redundant or not particularly useful to many unless they can be integrated into the delegate incentive program rewards calculations, instead of just complementary dashboards as an audit.
Vote for this proposal. Not having any incentive system until 1.1 is implemented seems problematic, therefore maintaining the current system until the upgrades are there is the sound thing to do.
Voted for since not even a full fledged proposal yet, just interest check. Too many details are missing so making a fair conclusion is not possible. Update the temp check with more relevant details and a supposed cost estimate.
Against b/c procedural issues. Hugely in favor of this especially for delegates like us who function as an organization and have turnover. Makes onboarding process a lot easier and generally looking for information about the dao without having to go digging for information. Will vote in favor next time it’s created on snapshot. Just move to the proposals category to keep everything in one place.
Voted for “strict self voting policy”. Don’t believe delegates should be able to vote for themselves in a beneficial way especially when a nominee for an election is a large delegate. The other two policies still allow said nominee to give themselves a large number of votes. When this passes the temp check and comes down to a vote to adopt a final policy, we would also support “responsible voting policy”
We vote in favor of whitelisting Infura. They have been an integral part of keeping the Arbitrum Nova network stable, and the fact that Infura is not already whitelisted seems to be an oversight.
We vote in support of this proposal. Because the standard precautions on user safety are taken, and no costs are incurred, we see little downside. In addition, USCB is a trusted research partner and we have confidence in their practices and methodologies. Definitely could see a lot of upside in onboarding new members to governance and getting them caught up quickly.
We vote in favor of this proposal and to use ENS text records. This proposal will be big for any new users entering the Arbitrum ecosystem as there is one platform for the DAO to report on its statistics which can be used for governance and non-governance purposes. No cost is a huge plus.
Voting abstain for a few reasons, one being that there is little evidence or direct proof on how much contributions each of the community members have put in during the pilot program making it hard to directly judge the appropriate amounts of funding each member gets. In addition, this vote does not seem appropriate for the community to make, but rather something that the LTIPP council should take the responsibility of deciding. Another approach could be having a third party writing an objective report detailing all the contributions so there is a more quantifiable measurement, but as it stands, a community vote does not seem like proper protocol.*
We vote for this proposal, obvious benefits of expanding Arbitrum’s outreach at major web3 conferences. The mechanism to return unused funds to the treasury makes sense, and the 1.5M USD estimate seems on par for an outreach budget.
We vote against this proposal. Allocating $10 million for audit subsidies without a clear performance evaluation framework or long-term accountability risks inefficient spending, especially when many projects may not need the full 100K subsidy or may fail despite receiving funds. Additionally, the selection process for auditors and projects lacks transparency, concentrating decision-making power in a small committee dominated by the Arbitrum Foundation, with no clear safeguards against favoritism or efficiency. The auditor approval process is vague, and there is no guarantee that projects receiving funding will stay on Arbitrum long-term
We vote in favor of this proposal. This program is well-structured with accountability and safety measures, ensuring early-stage projects meet security standards through subsidized audits. The criteria for audit subsidies for projects is clear and assures that only high-potential projects receive funding, preventing the misuse of treasury funds. By subsidizing audits, Arbitum ensures that early-stage projects launching on its network meet security practices which reduces the risk of exploits, protecting both the projects and users. This is a proactive investment that helps maintain a secure ecosystem. It lowers financial barriers to entry while also incentivizing projects to launch on Arbitrum instead of on other platforms. The exclusivity clause promotes developer retention and pushes projects to stay within the Arbitrum ecosystem. Also, this program is structured to prioritize projects that have already demonstrated success on Arbitrum, improving the likelihood that funded projects will contribute meaningfully to the ecosystem. Though a $10M budget seems steep, security is a necessary investment, and investing in audits now prevents higher losses and failures in the future. $10M to secure 100+ projects is a proactive measure to prevent potential losses. This program also ensures DAO oversight through governance safeguards, like quarterly transparency reports and a technical expert on the committee. Any unused funds will be returned to the DAO treasury. Overall, this proposal mitigates risk and promotes long-term growth by increasing developer retention and strengthening the ecosystem.
