Uniswap-Arbitrum Delegate Program (UADP) Communication Thread

Uniswap-Arbitrum Delegate Program (UADP) Communication Thread

Name: UADP
Delegate Address: 0x8326D18edfC50B4335113C33b25116ec268FF3fE
Tally Profile: UADP | Tally
Forum: @juanbug @AbdullahUmar
Discord: juanbug, ubermar
Reference: Uniswap Vote 47
Languages: English, Chinese, Spanish


Hello Arbitrum community, Abdullah and I here! A few months ago, when Arbitrum first airdropped ecosystem projects a significant portion of $ARB, Uniswap received a little over 4 million tokens. After some healthy discussions on how to allocate and use those tokens, a vote was passed through Uniswap governance to create a Uni-Arb Grant Program (UAGP) and Delegate Program (UADP). See the vote here.

The Uniswap-Arbitrum Delegate Program is the Uniswap community’s unique entrance into metagovernance, and Abdullah and I are excited to steward the first 6 months as the committee’s delegation facilitators.


Having both led university delegate arms (at Penn and Michigan) across 10+ protocols collectively, we have each voted and participated in hundreds of votes and governance decisions. Arbitrum holds a unique place in the L2 ecosystem, and our goal is to help it scale sustainably, all the while establishing more synergies with Uniswap.

We will transparently and accountably represent both the Uniswap & Arbitrum communities’ interests throughout the governance process. In an effort to be proactive and discerning in our voting contributions, we will ensure that each decision is well-considered and thoroughly researched. Open lines of communication will be a priority, as we plan to regularly share our voting justifications and insights with delegates and community members of both Arbitrum and Uniswap.

Our goal for the UADP is to strive for transparency, efficiency, and broad community involvement.

Disclosure & Waiver of Liability

When applicable, we will disclose conflicts of interest and at times abstain from voting with proper forum rationale. Further, our votes are our best opinions and should not be considered an agreement on behalf of Uniswap. By delegating to the UADP, you acknowledge and agree that the UADP participates on a best-efforts basis and that the UADP will not be liable for any form of damages related to its participation in governance.


Security Council

Vote: John (Gauntlet) and Omer (Chaos Labs)

We have divided our voting power among the two candidates who we believe can most responsibly bear this role: John (Gauntlet) and Omer (Chaos Labs). Having worked with both Gauntlet and Chaos Labs, we know the important role that they play in sustaining various protocols in the ecosystem. Namely, their work as risk assessors has been vital for DeFi money markets. So, the critical role that the companies behind these individuals play certainly lends itself to our recommendation. John and Omer also have extensive development experience behind their belts, along with skill sets in cyber security.


Empowering Early Contributors: The Community Arbiter Proposal

Vote: Yes

While it is certainly vital for the DAO to support ecosystem contributors like Arbiters, it’s also important to structure a clearly substantiated plan behind implementing such a rewards program. As far as where this proposal is in its current state, it doesn’t seem to sufficiently outline the details behind who will be distributed the stated $ARB rewards. Since there seems to be a cap of 25 recipients, it would be best to first outline those names explicitly for transparency purposes BEFORE going forward with a vote. This isn’t necessarily for the community to judge the selected individuals, it’s merely to track who is being rewarded prior to voting. It is also unclear what metrics exactly are used to determine the top 25 candidates and if 25 is in fact the optimal number. We are in favor of the spirit of this proposal and hope to enable more contributor-based reward programs in the future, but a more systematic approach at designing this initiative would, in our view, make it more compelling. For that reason, we are voting YES for the snapshot but hope to see some of the mentioned issues more fleshed out in the on chain vote.


Build Optimal Onboarding for STIP Teams (BOOST)

Vote: Yes

Creating this proposal was very much a strategic move by the Layer3 team. They could very well have applied as a participant in the STIP race, but they decided to wait until afterwards so they could frame themselves as an initiative that would tie together all the other STIPs. Another reason for not applying during the STIP round is likely because the contents of this proposal would have failed to successfully meet the criteria designated by the STIP designers. Layer3 is NOT distributing the 1M ARB as incentives. The incentives simply come from the $50M STIP pot. Instead, the 1M ARB will be used for development and marketing purposes. Although the breakdown of expenses is not fleshed out to a sufficient degree–granted it’s often hard to anticipate such expenses, but estimates wouldn’t hurt their case–we do see the merits behind questing programs. And since this one is directly tied to helping facilitate the current incentive program that has already been given $50M, it would be a shame if the STIP initiative didn’t prove to be as successful as anticipated. The current Layer3 proposal effectively helps give the STIP initiative a spurt of momentum. That being said, we are voting YES for the snapshot–but hoping to see a more comprehensive breakdown of costs during the onchain vote.


The Arbitrum Coalition

Vote: Fund the Coalition

Going forward, large DAOs need to begin hiring professional research and development contractors to equip voters with the information to make informed decisions. Expecting token holders & delegates to over a long period of time and remain consistently up-to-date about proposals is idealistic. Mitigating issues like groupthink is quite difficult and becomes increasingly prominent with technically complex or cumbersome proposals, like the STIP process. Funding well-known groups like Blockworks and Gauntlet to provide data-driven summaries and recommendations is a step towards alleviating voter fatigue/apathy along with groupthink.

The proposal is formatted in a manner that can reasonably prevent concentration of power amongst a small group of service providers. For example, the Advocate will act as the intermediary between the coalition and the DAO, hopefully creating proper checks and balances. We trust that the members that we are electing will act in an unbiased manner and not directionally influence voting decisions. Our previous interactions with the Blockworks and Gauntlet teams is why we can make such a statement.

One of our main concerns, however, is how turnover will be handled between service providers. If a certain SP decides to leave the coalition and they have remaining work to complete, that can become an issue. The departure of an SP that’s had a long tenure is also a friction point. Each new SP will have to go through a slight learning curve to provide services on par with the quality of the previous SP. A good example of this issue can be seen in Aave DAO, in particular with the departure of Llama.


Activate ARB Staking

Vote (Ranked Choice Voting):

  1. Do not fund staking
  2. Fund staking with 100M ARB
  3. Fund staking with 125M ARB
  4. Fund staking with 150M ARB
  5. Fund staking with 175M ARB

Although the premise of this proposal is that it will create long-term ARB token holders, this activity is entirely incentivized by inflation and should therefore be discounted significantly–this is simply how all incentive programs should be viewed, especially this staking initiative. What makes an ecosystem thrive is the quality of the dapps. That’s why we were in favor of the STIP proposal. Driving users to use dapps is a more effective way to distribute treasury funds, as opposed to just paying token holders. Even though the hope is that a handful of the new ARB holders become long-term investors and/or Arbitrum ecosystem participants, stickiness is very difficult to measure. Instead, more sticky demographics should be rewarded, like builders and devoted community members, which is currently being done via the grant and STIP distributions.

Investors should, however, at some point be compensated–but a pure inflation play, without recognizable ARB utility, isn’t the best way to facilitate that goal. Sharing decentralized sequencer revenue with $ARB stakers is much better utility and can be implemented when the time is right. Incentivizing sequencer stakers is real utility, and that’s an example of where the DAO should designate its future incentive allocations.

Plus, the $ARB token will suffer in other ways because of the alluring staking APRs. Who would want to lend $ARB or be a liquidity provider if you can just stake for a better return? If this proposal passes, the DAO should consider ways to prevent an $ARB drain from dapps. This can be addressed, for example, via protocol owned liquidity provision for particular Uniswap pools. As representatives of the Uniswap DAO and delegates in the Arbitrum DAO, we would like to explore this option.


Non-Constitutional AIP: Arbitrum Security Enhancement Fund

Vote: Against

We are concerned about the proposed funding mechanism. We share similar opinions as @pedrob as allocating 2 million dollars to a single auditor could create a monopoly situation, diminishing the incentive for high service standards due to reduced competition and possibly leading to overcharged service fees due to the large subsidy available.

Additionally, the approach suggested concentrates decision-making power, presenting a risk of centralization in the distribution of funds. This could be counterproductive to the decentralized ethos of the ecosystem​ and crate a lack of checks and balances within this security system.

Possibly, an alternative funding approach suggested in the forums that we’d like to consider more is direct subsidies to protocols that need auditing before deployment on Arbitrum, rather than to a service provider. This would allow for a more equitable and decentralized allocation of funds, ensuring a wide range of protocols can access audit services from a variety of reputable auditors, avoiding the centralization of power and potential service quality issuess.

Overall, we’re happy to see the discussion for the “Consolidate Security Proposals into a RFP Process” arise from this and believe this sets a good standard for votes to come.

Consolidate Security Proposals into a RFP Process

Vote: For

This proposal aims to create a structured and transparent approach to selecting auditors and security service providers. This move seeks to replace the current piecemeal method, where individual auditors make separate budget requests, with a comprehensive framework that ensures the community’s due diligence and financial responsibility.

The importance of smart contract security in the Arbitrum ecosystem cannot be overstated, and the proposed RFP structure is intended to attract and fairly compensate top-notch security professionals. This process would be open to all security engineers, researchers, and organizations, ensuring that the selection of service providers is based on merit and qualifications, as well as most importantly, cost-effectiveness​.

The criteria for selection would include the experience and qualifications of security professionals, their audit methodology, and competitive pricing. A committee appointed by the Arbitrum DAO would oversee this selection process, reviewing submissions and choosing the most qualified candidates based on these criteria. We are heavily in favor.


Proposal to Backfund Successful STIP Proposals

Vote: For

Distributing 50M worth of rewards for STIP round one was really based on arbitrary consensus by the DAO. Since nothing of this magnitude has previously been conducted across any DAO, it was difficult to decide how much capital should be allotted to this type of program. We, along with many others, were surprised by the number of proposals. One can argue that the 50M allotment was anticipated for a smaller number of participants, and now, back funding is our way to compensate for the unprecedented number of successful applications.

Another consideration is recognizing that the most well known protocols attracted the most voting power. This is in part due to heuristic voting–people just vote for entities that they’re familiar with. Another factor is network–larger protocols typically have more sway over the decision-making of delegates. Since not all delegates made it a priority to help fund up-and-coming protocols, back funding those smaller projects seems reasonable.

Plus, it’s too soon to conduct a round two of STIPs. The next best step would be to observe and analyze the efficacy of the current STIP round. We don’t want to go through another round of voting so soon for the protocols who didn’t make the cut. Back funding is the less operationally intensive alternative.


Funding Gas Rebate and Trading Competition Program to Amplify Arbitrum’s Ecosystem Growth

Vote: Do Not Fund

We voted against this proposal because general incentive programs initiated by individual protocols are not favorable for the DAO from an organizational perspective. It makes operations more messy. If an individual protocol has a unique contribution to propose–something that goes beyond mere user acquisition via incentive programs–then such a proposal would be intriguing. The reason the STIPs were created was to collectively enable the DAO to choose which protocols should be involved in a large-scale incentive program. Therefore, Rage Trade should have applied for the first round of STIPs. Plus, it’s probably best to ask for incentives when Rage is out of its closed beta phase. Waiting for round 2 of STIPs would therefore be best to re-propose this rebate program.

We also feel that this proposal would be better received if it were created by a collection of perp platforms, not just Rage. This would make it more of a community initiative as opposed to just a Rage Trade initiative (yes, we understand that it’s ideally meant to benefit Arbitrum as a whole, but that means other perp protocols should also be involved in the conversation). It may be wise to talk to the teams at MUX & GMX, for example, and try to co-author such an initiative. Without an inclusive ecosystem buy-in, we feel that this proposal is not as appealing as it could be.

1 Like

We have voted FOR and FOR on-chain for these prior snapshot votes that we voted YES for.

Procurement Framework | Security: Non-Constitutional Proposal

Vote: For

In line with our prior approval, this subsequent next step is in line with our expectations.

AIP: ArbOS Version 11

Vote: For

This proposed AIP for Arbitrum introduces significant improvements, aligning with the Ethereum Virtual Machine (EVM) Shanghai upgrade and introducing the PUSH0 opcode. This upgrade ensures compatibility with Ethereum’s latest developments, potentially enhancing the efficiency and capabilities of smart contracts on the Arbitrum network. Additionally, the proposal includes miscellaneous bug fixes and technical enhancements, signaling a move towards a more stable and reliable platform. These changes are crucial for maintaining a modern and efficient blockchain infrastructure.

A notable aspect of the proposal is the refinement of fee structures, particularly regarding retryable transactions. The distinction between the network fee account and the infrastructure fee account suggests a more nuanced approach to fee management, which could lead to fairer and more efficient transaction processing. Furthermore, improvements in precompile methods, like preventing certain methods from consuming all gas upon reverting, create better resource management and efficiency. These adjustments are important for both developers and users, as they contribute to a more user-friendly and cost-effective environment.

Timeline Extension for STIP and Backfund Grantees

Vote: Extend deadline for both

We see no reason to not extend the timelines and thank the teams for their transparency on this matter

1 Like

Proposal: Experimental Incentive System for Active ArbitrumDAO Delegates

Vote: Without Karma, then With Karma, then Against

We are in support of more robust delegate compensation initiatives. Most DAOs today don’t have the bandwidth, financial runway, or even the need to pay delegates for their efforts. Arbitrum, however, is a different story. Due to the broad distribution of the token and continual activity by the token holder & delegate community, multiple initiatives have been implemented. Most importantly, Arbitrum DAO has shown a culture open to experimentation, which is the only way forward for DAOs. To make sure the activity from this year persists perpetually into the future, throwing out a carrot for active delegates is not a bad idea.

We’d be curious to see what material changes occur after this initial 6-month pilot phase concludes. One worry that we’ve always had regarding delegate compensation is selecting data points for rewarding certain behaviors. Should voting be the main criteria? Do you get penalized for voting in a non-consensus direction? Does the quality of your comments count towards your reward? The weighted point system described in this proposal makes sense for this pilot and does address some of our concerns behind what is rewarded. We are glad that it takes into account forum participation and not merely voting participation. Again, this has a good side and a bad side. It’s likely that we’ll see multiple throw-away comments just so users can increase their participation rate for the sake of it. Important discussions will become cluttered with fluff. In an ideal world we’d be able to automate reading responses and devise how “thoughtful” a comment was or how much attention it received. From there, thoughtful comments attain points, while fluff is penalized. These intricacies are to be thought about in the future.

All this being said, we are in favor of the manual option for implementing this proposal. Automating this process can be very valuable, but we believe that testing it out manually will help the SEED Latam team become subject matter experts in this compensation process, and with that experience, they can later collaborate with Karma more effectively, introducing more intricate ways to reward participation in the DAO.


Proposal [Non-Constitutional]: Establish the ‘Arbitrum Research & Development Collective

Vote: Don’t Fund, then Abstain, then the values in increasing order

We are not in favor of this proposal due to its overly broad nature and lack of receptivity from the DAO. There are a lot of new functions that the proposal seems to address, and each of these four divisions could easily have their own proposal. Predetermining the cost of each division is also, in our view, premature. We’d like there to be increased discussion around what exactly each division does more specifically—and then ascertain a more detailed compensation plan. Broad proposals like this should start simply by asking for community feedback.

Once enough conversation has transpired, the proposal should be divided up into multiple parts, each detailing more intricately the job of each division and how exactly the RFP process will be conducted. It would also be nice for the proposal author to have potential candidates for this program to comment their perspectives on the program. Post discussion, it should be decided how the voting should take place. One vote may just be a snapshot around the structure of the program, without any mention of compensation. This aspect would determine if there is a need for such a program and what the true job-to-be-done is. Assigning budgets could be a separate discussion and should be better outlined.

Overall, this proposal moved too swiftly to snapshot without nearly enough debate. We’d like to see the DAO create working groups such as the ones proposed—but this must be done in a more precarious manner.


AIP: ArbOS Version 11

Vote: For

Confirming our prior reasoning and Snapshot vote onchain.


Proposal [Non-Constitutional]: Establish the ArbitrumDAO Procurement Committee

Vote: Establish Procurement Committee

We are voting in favor of this proposal but have our reservations with the continuity of this program.

The ARDP and ARDC are both examples of how a DAO can become more sophisticated in terms of professionalizing its operations. Creating subcommittees is a good practice for effective decision making and proposal creation. But the introduction of numerous subcommittees can also create unnecessary overlap in jobs. In our eyes, the functions of the ARDP and ARDC have enough overlap to justify combining them to an extent in the long run. Either way, they’ll need to be in close communication. A natural point for something like the ARDP would be to create frameworks based on the interactions they have during their tenure, this way the frameworks are empirically designed. But that’s likely too much to ask for. To establish strong frameworks there should be a dedicated task force like the ARDP, but the current six month timeline, along with the corresponding compensation package, should be limited to 6 months and not subject to an automatic reelection period. Unlike the ARDC, which is more-so a continual program, the ARDP can likely accomplish its tasks within the 6 month period. The hard part about creating these frameworks is the initial stage. Afterwards, it’s about monitoring and revamping current frameworks. Therefore, this committee should be ascribed a passive role long-term. In its passive state, the ARDP should also begin resorting to the ARDC and the DAO for continual feedback. We believe it’s fine for the working group to be limited to 3 competent people, but during the passive lifetime of the ARDP after the initial 6 months, it may be a good idea to add more members to the team. Again, this later stage ARDP is mostly a monitoring committee.


Long-Term Incentives Pilot Program

Vote: Fund Program with 25,815,000 (then increasing numbers and lastly don’t fund)

We are in support of the Long Term Incentives Pilot Program as its structured approach to enhancing the Arbitrum ecosystem takes into account much of the negative feedback from prior proposals and finds a nice common ground between many different opinions. The program addresses key issues from STIP Round 1, like delegate workload and feedback for protocols, and offers a more streamlined and equitable process. The introduction of a council for application evaluation and Application Advisors for feedback ensures a more fair and efficient selection of deserving protocols. This structure promises a more transparent and balanced allocation of resources.

Opting for the smaller 25 million ARB option is prudent for several reasons. It allows for a cautious approach to gauge the effectiveness of the new system without overcommitting resources. Starting smaller provides a controlled environment to test the new incentive structures and make adjustments based on real-world trial outcomes. This conservative start can lead to more informed decisions in scaling up the program in the future, ensuring the long-term sustainability and success of the initiative. Overall, we would like to see some more clarity and communication on some of the budgets, such as for example we think the milti-sig signers are compensated a bit too much.


Experimental Delegates Incentive System

Vote: For

Type: Onchain

As per our previous Snapshot vote, we still believe that this initiative should not incorporate Karma to start with. Once the program matures and it becomes clear what exactly needs to be optimized after manually operating this initiative, then Karma should ideally be incorporated. Regardless, we voted FOR the onchain proposal because, on the whole, we believe in the positive impact that this program can have on delegate participation. One aspect we’d like to flag one more time is the ability for the DAO to weed out pointless contributions–those done for the sake of contribution.

Proposal to Establish the Arbitrum Research & Development Collective

Vote: For

Type: Onchain

We voted FOR the initial coalition proposal but voted against this proposal during the Snapshot. However, our position has since changed, so we voted FOR this proposal onchain. Our general stance is that the DAO should have committees for facilitating various critical DAO functions. The initial release of this proposal was met with a lack of engagement, so we wanted more conversation to transpire before being in favor. Although the feedback for this initiative still hasn’t met the same level of engagement as the coalition proposal in the forums, when observing conversations in private channels, it became clear that there is appetite from most delegates to see this through.

We also suggested previously that this proposal can be divided up into multiple proposals to prevent bundling too many decisions into one vote. The broad nature of the proposal may still make this the better approach, however, we do realize that unbundling this proposal may be operationally difficult, requiring multiple snapshots /onchain votes.


Pilot Program Council Elections

Vote: 404DAO, GFX, Wintermute, Karpatkey, Bob Rossi
Type: Snapshot

Pilot Program Advisor Elections

Vote: Seed Latam, JoJo, Boardroom
Type: Snapshot

We’re excited to see the next step of the Pilot Program being voted on, and we’re happy the individual council elections are taking place democratically. We believe these 5 councilors and 3 program advisors are best suited for the first iteration of the role. When choosing our reviewers, we looked for people that have been long involved in the Arbitrum ecosystem and have also had a great track record in Arbitrum and other DAOs; bonus points for being on other grant councils and delegates. When choosing our advisors, we looked for teams or individuals that high a great holistic understanding of the DAO, were involved in various aspects, and also held and had experience with other web3 communities.


Constitutional AIP - Security Council Improvement Proposal

Vote: Increase the threshold to 9/12
Type: Snapshot

We respect the L2Beat team’s continual efforts to bring awareness towards the risks surrounding L2s as they continually mature. Our vote went towards increasing the threshold from 7/12 to 9/12 since this approach is the simplest way to null the second multisig. It also allows for more flexibility in the future than entirely removing the second multisig. Increasing the delay has its merits, but we feel that it’s a topic that the DAO should discuss in further detail before executing. To us, this proposal is meant to be a quick response to a potential security concern as opposed to implementing a more sticky alteration like the delay increase.