Voting Cycle #1: Roundup

Sharing my voting decision and rationale for these proposals:

Proposal A: Voting For. I would have preferred to see these proposals broken out individually instead of a batch vote as I’m in support of some proposals way more than others. However, since there are many that would be beneficial to Optimism and I have confidence in the Optimism Foundation working with the teams to iterate the proposals so they were beneficial to the ecosystem, I’m comfortable voting on it. It also sounds like future cycles won’t have these batched which is great to hear.

Proposal B: Voting For. While Uniswap missed the deadline, they have been and are an important partner for Optimism so I’m comfortable with an exception on this in the interest of furthering the Optimism ecosystem.

Proposal C: Abstaining from this vote due to a potential conflict since my husband is the co-founder of 0x.


I’ve delegated to Quixotic, how could I vote for this?

you cant, Quixotic will vote on your behalf. if you want to vote, you need to delegate the token to yourself

I’m voting For all three proposals, even though they are flawed. Given we’re early, I’m willing to give projects building on Optimism the benefit of doubt. (I don’t see anything particularly objectionable.) In future, I would like to see timely submissions meeting all guidelines, a clear presentation of how the tokens will drive lasting & sustained user activity to their protocol, and how their token distribution programs will benefit the Optimism ecosystem as a whole. Of course, we should not bundle multiple projects into one proposal going forward.

1 Like

Greetings everyone,
hope everyone’s enjoying in such market sentiments.
I’m checking in to see if anyone having the problem with voting on proposals on snapshot. My voting power is shown 0 even though I have the tokens in my wallet. Is it that If I have delegated them, that’s why my voting power is showing up as 0 or is it something else.
Anyone else is facing the same issue, would appreciate the help

Hi all - We (Blockchain at Berkeley) generally disagree with the ethos of how this governance vote is being proposed.

A- It’s ridiculous to expect token house governance to make an educated decision on token allocation by batching 20+ GovFund candidates together. Optimism Foundation is basically asking us to “approve” their decisions, instead of allowing us to vote individually on each one. Correct me if I’m wrong, but isn’t ecosystem funding supposed to be covered by the citizen house? Proposal A should either bring each GovFund to individual vote, or should be the responsibility of citizen house to approve. We are not comfortable voting only to approve OP foundations decision, rather than being able to make our own. It sets bad precedence and diminishes the role of token house. We are strongly against

B- Like @lefterisjp we are unsure why Uniswap is being given special treatment despite missing the deadline. Obviously Optimism foundation is giving them favor - again another point where our governance decisions are being guided by the foundation. We will be voting No but will likely be approving them for the next batch

C- 0x is being voted on how we believe is fit. We are confident in supplying them with a YES vote. And look forward to the grants they will be funding.

We hope not to be harsh on individual grant applications and apply undue scrutiny. But we strongly believe Proposal A and B dismiss the role of governance - a trend we must stop before it becomes normal. Remember in this space things trend towards centralized decision making, and it’s up to us to push against that wherever possible. We would be happy to approve these grants, but not in this way.


Hey all - nice to be here! As a delegate, I want to share how I’m voting on each proposal:

Proposal A: All of the proposals in this group are well-formed and I believe will lead to increased activity on Optimism.

I’m voting YES :white_check_mark:

Proposal B: This proposal missed the deadline. It shows a lack of interest in the governance process and I believe accepting it sets a bad precedent. This proposal can be resubmitted in the next round.

I’m voting NO :no_entry:

Proposal C: This proposal chose to allocate 100% of the allocation toward grants. While it goes against the guidelines, I believe that effective grants are the most likely to stimulate long term growth on Optimism.

I’m voting YES :white_check_mark:

The difference between B and C is that B missed the deadline while C went against the guidelines.

:point_up_2: Bullet A, Batching vs individual vote. Would like to have individual voting on proposals in future.

hey all! here is the summary of my votes:

Proposal A: For :white_check_mark:
Why: Unfortunate to put all the projects subject to the same vote, but in general these guidelines were decided by OP team beforehand and i support them

Proposal B: For :white_check_mark:
Why: Shame that they where late to put a proposal, but since they had an allocation anyway, i’m ok with issuing the grant. I’d vote against if the missed deadline impacted other parts of the plan.

Proposal C: For :white_check_mark:
Why: I’m ok with issuing the whole distribution to grants / builders — imo it’s better than random airdrops or liquidity incentives.

to be honest, i hate being a triple “yes” man in this example, but this is mostly just an approval to the decisions made by the Optimism team beforehand excited to be a voice of reason and a party pooper when the time comes :smile:

I’d like to see the batch vote split up into individual pieces, but since its not, the vote mostly comes down to “all yes” or “all no” — out of which i go with yes, since all of these projects contributed to helping build optimism network as it is

Also published the explanation on twitter:


I prefer batching. Delegates should simply review and remove projects that didn’t meet the grade prior to going to snapshot

I am intending to vote Yes for all 3 Proposals.

Uniswap didn’t meet the deadline and 0x didn’t fit the specified criteria, but both proposals seem like they will be beneficial to the ecosystem so I think flexibility with rules is sensible in this first round.

I’m not completely happy with all of the ones included in the big batch and would have voted No for a couple had they been separated out, as I don’t think they are designed to be maximally beneficial to the Optimism ecosystem. Due to them being included with other great proposals I will have to vote yes on A as a whole. A short breakdown of my views on the batched group follows:

Perfect Proposals - Would vote yes without reservations:

  • Synthetix

  • Perpetual Protocol

  • Lyra Finance

  • Celer Network

  • Hop Protocol

  • Chainlink

  • Rubicon

  • Thales

  • Pika Protocol

  • Connext

  • Layer2DAO

  • Gelato

  • AAVE

Okay Proposals - Would probably vote yes, but hesitantly:

  • Stargate Finance (assuming that ‘Qualified Partners who integrate Stargate widget’ will be builders on Optimism)

  • Synapse Protocol (large chunk of incentives to SYN holders seems a little self-serving, but this was addressed somewhat in the comments)

  • Zipswap (Proposal is fine but they are deployed on Arbitrum as well as Optimism so not sure why they got the 3x multiplier)

  • Aelin Protocol (Would just like clarity on the Aelin Council if they are to have veto over OP incentives to liquidity pools)

  • Polynomial Protocol (20% retroactive distribution which will probably have less effect on encouraging future users than the other segments, basically fine though)

  • Clipper (Unsure about the method of requiring Discord verification and the Optimism pools were closed at the time of checking, also the project’s community engaged in a ridiculous brigading of the governance forum… however the team attempted to stop this and on reflection it probably demonstrates that they are already attracting ‘new’/inexperienced users to their platform)

  • Slingshot (No response was given to a query regarding avoiding sybil attacks on the referral link based rewards)

  • WePiggy (20% retroactive distribution which will probably have less effect on encouraging future users than the other segments, basically fine though)

Disappointing Proposals - Would vote no if not part of the batch:

  • Kwenta Protocol (66% is targeted specifically at 1,000 previous users of dYdX, if they were to get an even distribution they would end up with 600 each, purely because they didn’t claim their dYdX tokens? Kwenta is a key part of Optimism’s synthetix ecosystem but I don’t think this proposal is reflects this.)

  • 1Inch (one of the requirements for Phase 0 was “Token allocations should not be used for internal development or operations costs” it would have seemed important that they clarify what is meant by “1inch Network plans to accelerate the development of Optimism native features and expand R&D for L2”. This question was raised 2 weeks ago but the 1Inch team never responded)

I will not vote until tomorrow, to give time for any strong objections to my reasoning to be offered.


Rational thinking paired with clarity makes your post very reassuring for any possible delegators.

1 Like

Proposal A

Vote: No

It doesn’t make sense to vote for all 24 projects in one vote. Most users are unlikely to read all 24 proposals and thus can’t make an informed opinion. It would make sense to approve each individual proposal as each proposal is unique.

Proposal B

Vote: No

Deadlines are deadlines. Even though uniswap is an important partner, there are rules to follow and it is important that there are no exceptions to this rule. We are open to approving their application for their next cycle but it is unfair to give them special treatment.

An individual vote also makes it more likely to be passed so this might encourage other protocols in the future to purposely miss a deadline since uniswap got this treatment.

Proposal C

Vote: Yes

We believe grants are a great way to help the community.

I’m still undecided. Most of the proposals are worthy but I second @lefterisjp about rubber-stamping. Governance must have more granularity.

I’ll repeat what I wrote on discord. Voting on grant proposals should use quadratic points like we did in the first RPGF round, and delegates will sign a single message with the points distribution. For other types of proposals (non-grants) we should vote on each one separately by signing an array of Yes/No/Abstain votes for all the proposals.

I might vote For the current proposal because we didn’t discuss this beforehand, but in the future I’m going to vote Against any rubber-stamp batch proposals.

1 Like

@haonan can confirm the deadline was extended to 27 May. That’s what was communicated to us in the Optimism Stimpack telegram chat where all the applicants were coordinating with the Optimism team

I don’t like having this conversation in multiple forums nor repeating myself so please read here why this does not matter to me:


I have the same issue with you. About not voting power.

Proposal A - Batch vote - :no_entry:

I voted NO. Batching many projects, with mixed quality, teams and ideas together is a bad idea.

Proposal B - Uniswap - :white_check_mark:

Uniswap is not only a critical piece of infrastructure but the team also supported Optimism for a very long time. I believe that having deep liquidity for many different token pairs is a must-have for any chain and that’s why I am voting YES (despite the proposal slightly missing a deadline).

Proposal C - 0x - :white_check_mark:

Similar to Uniswap, 0x is a critical piece of infrastructure and I am voting YES.


Is it possible to add an abstain option on each proposal for future snapshot votes.

1 Like

Yes, snapshot allows this. It’s just a configuration setting that needs adjustment.