Uniswap Delegate Reward Initiative - Cycle 3 Application and Results

Governance-Meta
21

Applicant name: SEEDGov

Specify if you’re applying as an individual or an organization: Organization

Link to Tally onchain voting profile: Uniswap Tally Profile

Applicant summary–briefly explain why you’re interested in applying for this Delegate Reward Initiative:
SEEDGov is the first Latam based Delegate Platform actively engaging in various governance activities and we have a dedicated team of SEEDGov members, passionate about Uniswap and committed to governance activities. It has been a pleasure to have been part of Cycle 2 and ee are excited about the opportunity to continue to collaborate with Uniswap Governance.

The main objective of this delegation will be to continue to maintain active and meaningful participation, contributing to the growth and evolution of Uniswap Protocol Governance within Ethereum and other chains where available. In this sense, we have maintained a 100% voting, participation and justification rate since our joining, participating in community calls, and contributing ideas and asking relevant questions in the discussions to promote improvements in the proposals submitted, and not only that we will continue on this path, but we intend to deepen it, we have strong interest, expertise and capacity in to participate and integrate working groups, committees and workshops in which we can collaborate more intensely for the benefit of Uniswap, the DAO and its community.

It is our understanding that this new program cycle will help to continue to increase participation and discussions in governance, both in quantity and quality, thus strengthening governance itself and the protocol. In our specific case, the rewards received has been used to cover the compensation of the team dedicated to the Uniswap delegation, as well as the rest of the support team in different areas, so it would be very useful to continue to count on an incentive from the governance itself to ensure that we can continue and deepen our participation with the highest levels of quality that Uniswap deserves.

Please provide the date and link of the first offchain and onchain Uniswap vote you made:

Offchain: Jun 18, 2024 - Snapshot

Onchain: May 29, 2024 - Tally

Have you posted an RFC that passed the offchain voting stage before? If so, please provide links here (only the sole author or co-authors explicitly mentioned on the proposal will receive credit): Yes, 1: https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0x0c7b3acc56ad1d276cd4c9338e2ef8ca9e15e8ab3e3a22d395fd34398bda40af

Have you posted an RFC that passed the onchain voting stage before? If so, please provide links here (only the sole author or co-authors explicitly mentioned on the proposal will receive credit): Yes, 1 (pending approval): https://www.tally.xyz/gov/uniswap/proposal/80

Have you joined the Uniswap Community Call for September, October, December 2024 & January - Feb 2025? If so, what name did you join as? If multiple joined as a team, please note theirs as well: We joined all of these Uniswap Community Calls with one of our member, Marian, who completed all the forms on SEEDGov’s behalf.

22

Applicant name: Jojo

Specify if you’re applying as an individual or an organization: Individual

Link to Tally onchain voting profile: Uniswap Tally Profile

Applicant summary–briefly explain why you’re interested in applying for this Delegate Reward Initiative:
I’ll just state what I already provided in my personal platform for voting rationale: I am a builder first, and I firmly believe there has to be a higher representation of people working in protocols in the DAO, because while Governance entities can for sure do a great work, usually builders are the one having enough skin in the game to be able to provide a specific point of view.

As a Jones contributor, one of my focus is providing concentrated liquidity in the most important dexes, and this aligns me in being more involved in the Uniswap ecosystem: despite tons of different models out there, and with a very few exception, liquidity participant tend to prefer Uniswap as a platform, and as byproduct we tend to have on average a better depth and a better yield in Uniswap pools.

So far I have contributed to this ecosystem by being part, for almost a year, to the UAGP . I have brought my builder vision in there while helping Uni growth as much as possible. I would like to replicate the value I brought there in the governance life.

Please provide the date and link of the first offchain and onchain Uniswap vote you made:

Offchain: Sep 10, 2024 - Snapshot

Onchain: Sep 4, 2024 - Tally

Have you posted an RFC that passed the offchain voting stage before? If so, please provide links here (only the sole author or co-authors explicitly mentioned on the proposal will receive credit): No

Have you posted an RFC that passed the onchain voting stage before? If so, please provide links here (only the sole author or co-authors explicitly mentioned on the proposal will receive credit): No

Have you joined the Uniswap Community Call for September, October, December 2024 & January - Feb 2025? If so, what name did you join as? If multiple joined as a team, please note theirs as well: No. Only joined a few calls with my personal handle

1 Like
23

Applicant name: Arana Digital

Specify if you’re applying as an individual or an organization: Organization

Link to Tally onchain voting profile: https://www.tally.xyz/gov/uniswap/delegate/0x0579a616689f7ed748dc07692a3f150d44b0ca09

Applicant summary–briefly explain why you’re interested in applying for this Delegate Reward Initiative:
Our members have been active participants in Uniswap DAO for the past 3 years. History with the DAO allows us to make informed voting decisions. During our tenure, we’ve maintained an excellent voting record, passed numerous proposals, and collaborated with multiple other delegates, the Foundation, and adjacent teams associated with Uniswap. Our team lead, Abdullah, is currently serving on three Uniswap working groups: UADP, UAC, and UTWG. Arana hopes to continue delivering on its members’ previous commitments to the Uniswap DAO going forward, abiding by transparent communication & thoughtful decision making, all with the intention of bettering Uniswap as a whole.

Please provide the date and link of the first offchain and onchain Uniswap vote you made:

Offchain: March 1, 2024 – Activate Uniswap Protocol Governance
Onchain: February 8, 2024 – Deploy Uniswap V3 on Zora

Have you posted an RFC that passed the offchain/onchain voting stage before? If so, please provide links here (only the sole author or co-authors explicitly mentioned on the proposal will receive credit):

Yes. Our team has authored over 10 proposals that eventually passed the offchain & onchain voting stages. Links to each can be referenced on our delegate page.

Have you joined the Uniswap Community Call for September, October, December 2024 & January - Feb 2025? If so, what name did you join as? If multiple joined as a team, please note theirs as well.

Abdullah has joined all of the previous community calls, having hosted most of them.

24

As the onchain proposal is still ongoing and ending in 8 hours, the application will be open till the voting closes.

25

Applicant name: Blockchain at Berkeley (@CalBlockchain)

Specify if you’re applying as an individual or an organization: Organization

Link to Tally onchain voting profile:
Two Wallets:
https://www.tally.xyz/gov/uniswap/delegate/0x7ae109a63ff4dc852e063a673b40bed85d22e585
https://www.tally.xyz/gov/uniswap/delegate/0x458cEec48586a85fCFEb4A179706656eE321730E

(Note:
The second wallet is an EOA wallet initially used at Uniswap DAO’s conception. However, due to legal and security risks, this wallet was not used from 2022-2024. Since then, the first wallet, a multisig, has been the primary wallet to be used. From now on, we will be primarily voting with the first multisig wallet. Future activity tracking for performance should be entirely based on this wallet. We recently used the EOA wallet purely to push some votes above quorum at the request of proposal writers.)

Applicant summary–briefly explain why you’re interested in applying for this Delegate Reward Initiative:

Blockchain at Berkeley is a student organization at UC Berkeley focused on innovating, educating, and participating in the blockchain ecosystem. We have been active participants in the Uniswap DAO for many years and believe in the protocol’s sustainability. We prioritize growth and stability.

It takes a lot of time to understand, synthesize, and vote on proposals, as well as keep track of ongoing discussions. Currently, some members in Blockchain at Berkeley do this out of passion, but have to prioritize paid engagements first, like paid consulting projects, research grants, and paid governance participation.

As an active ongoing voter in the Uniswap ecosystem, we are very passionate about Uniswap and would love to take a more active role in shaping its future, as well as having the fiscal justification to staff more members in the Governance department.

The 2 members who currently follow Uniswap governance do so out of passion and with this money, we can finally justify governance participation as an active requirement for all our members (40+). We would love the opportunity to participate in this program and hope to boost governance participation within our club so more members are exposed to this vital part of the blockchain ecosystem.

Please provide the date and link of the first offchain and onchain Uniswap vote you made:

Offchain: Jul 13, 2021 https://snapshot.box/#/s:uniswapgovernance.eth/proposal/Qmeza7LnzTLAGhHeA2psNtf1ua4kgm2Q1NHAMPeVzs5C2i

Onchain: Nov 2, 2021 https://www.tally.xyz/gov/uniswap/proposal/9

Have you posted an RFC that passed the offchain voting stage before? If so, please provide links here (only the sole author or co-authors explicitly mentioned on the proposal will receive credit): https://snapshot.box/#/s:uniswapgovernance.eth/proposal/QmaG6nJYW3xLeQwAa6xxhpbuYS8h6PVQpbx1vfqpqxAtik

Have you posted an RFC that passed the onchain voting stage before? If so, please provide links here (only the sole author or co-authors explicitly mentioned on the proposal will receive credit): https://www.tally.xyz/gov/uniswap/proposal/19

Have you joined the Uniswap Community Call for September, October, December 2024 & January - Feb 2025? If so, what name did you join as? If multiple joined as a team, please note theirs as well.

No

26

Applicant name: Argonaut

Specify if you’re applying as an individual or an organization: Organization

Link to Tally onchain voting profile: https://www.tally.xyz/gov/uniswap/delegate/0x21b3b193b71680e2fafe40768c03a0fd305efa75

Applicant summary–briefly explain why you’re interested in applying for this Delegate Reward Initiative:

Argonaut is a team of highly motivated crypto enthusiasts eager to participate in governance and make meaningful improvements where we see opportunities. We were part of the second cycle of this program and learned a lot from it. The financial compensation allowed us to better organize and bring new talent to the team. We would love to participate in the third cycle of this program to continue growing, add value to DAO governance, and take on key roles where the DAO sees us as a good fit.

Since our first vote, we have maintained a 100% voting participation rate and we will continue maintaning this participation and monitoring every proposal. Being part of the 3rd cycle of the program presents a significant opportunity for our team, especially as a new, unfunded group. We’re driven by passion and would love the chance to dedicate more time to this work and create value for Uniswap!

Please provide the date and link of the first offchain and onchain Uniswap vote you made:

Offchain: https://snapshot.org/#/uniswapgovernance.eth/proposal/0xc2eed288ba61241dd86928eff15b7c8c9622168fc4b435657f58dda8ce285d13 (Jul 22, 2024)

Onchain: https://www.tally.xyz/gov/uniswap/proposal/65 (Jun 27, 2024)

Have you posted an RFC that passed the offchain voting stage before? If so, please provide links here (only the sole author or co-authors explicitly mentioned on the proposal will receive credit):

Uniswap Delegate Race Tiebreaker - We know PGov is the author of these proposals (the on-chain and off-chain proposal), but since we were the ones who flagged the issue in the forum, prepared the slides, and presented them in the Community Call, we thought we should also be considered co-authors of the off-chain and on-chain proposal.

Have you posted an RFC that passed the onchain voting stage before? If so, please provide links here (only the sole author or co-authors explicitly mentioned on the proposal will receive credit):

Uniswap Delegate Race Tiebreaker

Have you joined the Uniswap Community Call for September, October, December 2024 & January - Feb 2025? If so, what name did you join as? If multiple joined as a team, please note theirs as well.
Yes, we’ve combined them under the following names: Argonaut, Argonaut Team, Orpheus - Argonaut, Kaer, and Ragnar.

27

Thanks all for applying. We will work on recording points and will share with the community once ready.

28

1. Applicant name: Event Horizon

2. Specify if you’re applying as an individual or an organization: Organization

3. Link to Tally onchain voting profile:

https://www.tally.xyz/profile/0xb35659cbac913d5e4119f2af47fd490a45e2c826

4. Applicant summary–briefly explain why you’re interested in applying for this Delegate Reward Initiative:

Event Horizon is the largest metagovernance platform and public-access voter pool now governed entirely through Agentic voting. The new AI-driven voting mechanism utilizes what we’ve coined as the emperor-consol model by which each human is an emperor to their own personal agent. The human sets preferences and requests and the agent automatically votes in the humans proxy.

Metrics & Traction: Event Horizon has mobilized >$500,000,000 of voting power across ~700 proposals on 9 DAOs all on behalf of retail voters at no cost to the user. This is $500,000,000 of voice amplification for the low-capital, high-conviction citizens which would never have been possible prior to the Event Horizon’s product.

5. Please provide the date and link of the first offchain and onchain Uniswap vote you made

Offchain: 11/05/2023 (under our previous wallet address)

Current: https://snapshot.box/#/s:uniswapgovernance.eth/profile/0xb35659cbac913d5e4119f2af47fd490a45e2c826

Previous: https://snapshot.box/#/s:hvax.eth/profile/0x518647d7BB25c1b22f70b1344E26a06e7Fb751c0

Onchain: 04/27/2024 https://www.tally.xyz/gov/uniswap/proposal/62

6.Have you posted an RFC that passed the offchain voting stage before? If so, please provide links here (only the sole author or co-authors explicitly mentioned on the proposal will receive credit:

No

7.Have you posted an RFC that passed the onchain voting stage before? If so, please provide links here (only the sole author or co-authors explicitly mentioned on the proposal will receive credit:

No

Have you joined the Uniswap Community Call for September, October, December 2024 & January - Feb 2025? If so, what name did you join as? If multiple joined as a team, please note theirs as well.

No

29

Hello everyone,

First of all, we want to say that we’re really happy and grateful for the opportunity to have been part of the second phase of the program.

We’d like to explain the issue we raised in the community call. To clarify, we flagged this before knowing we would end up in the 16th position, though now it directly affects us.

We had requested to review the calculations before they were posted because our team is particularly skilled at verifying these kinds of calculations. We have an great data analyst, and we want to contribute where we excel. For example, we previously identified an error in a highly complex compound query in Dune for a similar program, which was later corrected after we reported it:

https://www.comp.xyz/t/delegate-compensation-program-pilot-final/6383/2?u=argonaut

Regarding this specific issue we flagged in the community call, when we accessed the calculation sheet, the first thing we noticed was that a delegate who had submitted two profiles with relatively low participation (one at 81% and the other at 63%) was listed with a combined 91% voting participation. After a deeper review, we found that both addresses had been merged into one, effectively converting two low-participation addresses into a single high-participation address, securing this delegate’s place in the program.

At first, we assumed this was a mistake and informed multiple members of the team responsible for the calculations, who acknowledged it. However, the issue was never corrected.

The right approaches to handling this application

We have not based our analysis on the specific delegate involved, as we believe the calculation process should be neutral and number-driven. Those responsible for these calculations should focus on the numbers rather than individual delegates, as this approach prevents bias, otherwise, the method could be chosen based on personal preferences.

The most logical method, in our view, would have been to select the profile with the higher participation rate (81%) rather than combining both to artificially improve the delegate’s standing.

Alternatively, if both addresses were considered, votes where only one address participated should count as 0.5 rather than 1.

Reasons against merging two addresses:

  1. It was not part of the original program
    The approved program never mentioned the possibility of applying with two addresses. In Web3, an address represents a user, so it makes sense to use only one.

  2. It’s unfair to other participants
    Since this wasn’t outlined in the original proposal, other participants may have assumed it wasn’t allowed and, as a result, missed out on the program. Additionally, if this was permitted for one delegate, what would stop others from teaming up and submitting joint applications? For example, we could have easily secured a spot by partnering with any of the following delegates who were also not accepted: Avantgarde, DAOplomats, Blockchain EDU, Areta, or Event Horizon.

  3. It goes against the spirit of the program
    The reason voting participation is weighted so heavily is that voting is the primary responsibility of a delegate, it ensures the protocol remains secure against governance attacks and bad actors. If a delegate has low participation across two profiles, it means they are missing votes on both. Even if they occasionally vote with only one profile, they are still leaving part of their voting power unused, weakening DAO security.

  4. It creates incentive issues
    Combining two low-participation profiles into one with high participation sends the wrong signal. It suggests that as long as a delegate with multiple profiles votes in one of them, it doesn’t matter if they fail to vote consistently in the others. This could encourage teams with multiple members to create separate voting profiles for each member and take turns voting, knowing that at least one of them would participate while the others remain inactive. Where do you draw the line? Can a delegate apply using five addresses?

  5. It opens the door to potential exploitation
    A delegate with bad intentions could recruit someone who voted in an old proposal just to win a tiebreaker. They could also add a high-participation delegate to their team solely to merge addresses and improve their score.

  6. It introduces conflicts of interest
    Unfortunately, this is the most serious one. Since using multiple addresses was never part of the program, allowing the team responsible for calculations to make this interpretation creates a risk of bias, potentially favoring friends or business partners. These decisions should be explicitly outlined in the proposal, not made arbitrarily during the process.

The only valid reason to merge addresses

The only situation where merging addresses would make sense is if a delegate had to migrate from a compromised address. However, we verified that this is not the case, as both addresses have been actively used for voting in recent months and years.

Conclusion

Our analysis suggests that the team responsible for these calculations made an unusual interpretation that benefited a delegate who wasn’t part of the program in the previous cycle, while negatively impacting a delegate with perfect participation. We don’t want to be drastic, and we’re also aware that we have a conflict of interest in this situation, but we believe this sets a concerning precedent for Uniswap Governance.

30

Uniswap Delegate Reward Initiative - Cycle 3- Results

Summary

Uniswap Delegate Reward Initiative - Cycle 3 passed the Onchain Vote. And the application lasted till the Onchain Vote ended. After examining the Voting Participation, Proposal Authorship, and Community Participation, top 15 delegates are selected. The post outlines the list of top 15 delegates as well as addresses the questions and clarifications. For detailed breakdown in excel, it can be found here

Total Points For Uniswap Delegate Reward Applicants
Total Points For Uniswap Delegate Reward Applicants814×504 23.3 KB

Details

Tie Breakers

The maximum point possible was 11. There were 6 delegates with score of 8 that were competing for last 4 spots.

First Tie Breaker: On Chain Vote. Between 404 DAO, KeyRock, L2BEAT, Tane, Argonaut, and Curia

  • 404 DAO, KeyRock, L2BEAT Proceeded

Second Tie Breaker: Most Votes. Between Tane and Agronaut

  • Unresolved. Move to Third Tie Breaker

Third Tie Breaker: Earliest Delegate Platform Post. Tane and Agronaut

  • Tane proceeded

Note:

  • Blockchain at Berkeley and its Voting History

Argonaut has raised a question about the delegate Blockchain at Berkeley and whether their two voting wallets with different voting history should be recorded separately or together. The post can be found here.

Blockchain at Berkeley clarified their wallet usage and set up in the application forum.

Assessing both sides. We maintain our current decision because of three main reasons

  1. Regarding Program Details

-The application has guidance but it realistically can’t lay out literally every “Yes” and “No.” We don’t believe whether one can use one or more wallets is a crucial element that needs to be explicitly laid out, as delegate wallets often change and this situation is rather normal in the space. It is in the domain for us to interpret as needed for the program.

  1. Established Presence

-Both of Berkeley’s wallets were long standing public wallets that were able to be identified even before the start of the program and thus we don’t find foul play or malicious intent. This was not an attempt to sybil the program or hedge their voting record. Additionally, going forward, there will only be one wallet used for tracking compensation.

  1. Regarding Precedence and Fairness Concerns

-Case of potential delegate recruiting another delegate just for voting history is unlikely but even if so, not a significant concern. Other elements such as Proposal Authorship and Community Participation are considered and Blockchain at Berkeley is a community member who has been known to the community for years.

Other points to note:

  • Event Horizon and Submission Deadline

Event Horizon’s application was posted more than 24 hours after the onchain voting closed. We still calculated the points for information, but even if Event Horizon’s points were within top 15, other applicants would be given priority based on the missed deadline.

  • Argonaut and Proposal Count

Argonaut in their application requested the proposal “Uniswap Delegate Race Tiebreaker” as a Proposal Authorship. However, a question, a comment, or even a long post not in the form of RFC, does not meet the criteria of “only the sole author or co-authors explicitly mentioned on the proposal will receive credit.”

4 Likes
31

We want to point out that this clarification was edited and posted after we flagged the issue to the team and was not originally part of their application post:

Aside from this mention, we also want to state that we disagree with the approach outlined in StableLab’s post.

Even if the application using two addresses was accepted, there was no explanation for the interpretation that both addresses should be combined rather than using a fairer approach, like the ones we suggested:

The post states that moving forward, using two wallets won’t be allowed. So why should it be allowed in this cycle?:

The delegate has a total combined voting power of 3.11 million UNI across these two addresses. In multiple proposals, they voted with only one address, representing 40% of their voting power, yet this was counted as a full vote. If both addresses are considered, why not count those votes as 0.4 instead of 1?

Wouldn’t it be fairer if the program coordinator didn’t have to make these kinds of interpretations?

We understand this was an unforeseen event, but wouldn’t it be easier to simply say, “This wasn’t anticipated, and we didn’t account for a candidate having two voting profiles, so we will select the one with the higher points?”. This approach would have avoided the need for the program coordinator to choose a method for considering both wallets instead of just one and avoiding bias in the selection.

This will be our final post on this subject. We don’t want to create conflict over something that isn’t critical for the DAO or cause any hard feelings with the program’s authors. Our goal as delegates is simply to flag something we believe is unfair.

We sincerely appreciate @marian, @Juanbug, @AranaDigital and @Doo_StableLab for taking the time to evaluate and respond to our concerns.

1 Like
32

I am responding personally since I was tagged in my personal account.

First of all, the situation presented was completely unforeseen and does not have an objective solution, meaning it is subject to interpretation. Clearly, when a situation is open to interpretation, there is no ideal solution, so any decision made or opinion expressed will never satisfy all parties involved. Therefore, I understand @Argonaut’s disagreement and do not take it as a conflict or anything of the sort. It is entirely valid to express disagreement with an interpretation one does not agree with.

My general interpretation is that we are dealing with a delegate who has used two wallets and built a voting history in the DAO with them. This is not a case of a Sybil attack or a governance activity merge between different delegates to artificially and maliciously increase participation percentage. Blockchain at Berkeley clarified in its application the reason for using two wallets, which is completely understandable. Any delegate may decide to change their delegation wallet for legal or security reasons, and if that happens, they should not lose their voting history, as that would be entirely unfair and illogical.

I also do not share this view. Delegates have the right, in any vote, to not vote, to vote with 100% of their VP, or to vote using only a portion of their VP. In the latter two cases, participation is still taking place; a vote is still being cast. It is incorrect to say that voting with a percentage of their VP means the delegate did not participate in that vote or only participated partially. A delegate who votes in an voting has participated in that vote, regardless of whether they used 100% or only part of their VP.

I also disagree with this point. As I mentioned above, a delegate’s participation history should be counted comprehensively. If, over the course of their involvement in the DAO, a delegate changed their voting wallet, their participation history should be computed considering all the wallets they have used for participation. The history does not belong to the wallet; it belongs to the delegate. It would not be fair for a delegate to lose their participation history or have only one of their wallets counted simply because they changed voting wallets for any reason. Again, it is important to clarify that this is not a case of a Sybil attack or the merging of wallets from two or more delegates to artificially combine a shared history that did not exist. Here, there is one delegate who has always been the same delegate with the same account who has used two wallets. Therefore, their participation history should be considered as a whole, accounting for their involvement with both wallets.

For all these reasons, I believe the interpretation shared by @Doo_StableLab has been correct and I agree with it, as it respects and accurately accounts for the delegate Blockchain at Berkeley’s full participation history.

3 Likes
33

We said we wouldn’t continue replying, but we just want to clarify something. You’re making it seem like the delegate stopped voting with one wallet and switched to another, and that we were trying to prevent them from including past voting history from a migrated wallet. We specifically stated that this would be the only valid reason for merging addresses:

However, if you look at the votes from the past six months, both wallets have been actively used during this period and even before that. The analysis should not be based on the personal situation of a specific delegate. Trusting their explanation without verifying the data undermines the integrity of the program. This process should be based on facts and numbers. Otherwise, the organizers have too much power to interpret cases subjectively, introducing potential bias.