Voting Cycle #3: Roundup

Hey,

These are very valid concerns and I understand why you feel this way but an infrastructure project isn’t pre-determined an instant no. As I wrote, our initial vote was yes but we decided to change our mind, and we will continue to treat each proposal with an unbiased view.

At StableNode we have a combination of factors that we take into consideration, but on a minimal level, smaller amounts of OP requested with supporting metrics and a detailed explanation of OP distribution make it easier to support a proposal. Those protocols with a proven track record have a better rate of getting passed but it’s because they have proven themselves.

I don’t want to delve deeper into our reasons for saying no to Infinity Wallet because I will add them to our delegate thread but the best way is to probably make a proposal. No one is going to “write you off” as you say above but see these proposals as a way to get your project out there. I personally read about every protocol that goes to vote and that itself is a marketing tool and a way to gather feedback.

Yeah, the speed these are coming does seem a bit fast. It’s also tough to get some visibility into the process for a newbie like myself.

Here is a roundup for my votes on Cycle 3 along with links on each proposal and forum post where I explain why each vote was made.

2 Likes

DONE ,nice project,keep optimism

Cycle 3 votes

A: Superfluid: Against
B: Kromatika: Against
C: Hundred Finance: For
D: Biconomy: For
E: Dope Wars: Against
F: Infinity Wallet: For
G: Dexguru: Against
H: Overnight: Against
I: Saddle Finance: For

My vote breakdown:

Proposal A: Superfluid - FOR :white_check_mark:

Money streaming is a novel use case of crypto and i’m super excited to see it grow, especially on optimism. 150k $OP requested is also a reasonable budget for a project with this level of traction

Proposal B: Kromatika - AGAINST :x:

300k $OP requested, 50% to be spent on influencer marketing. My voting will always be heavily biased into builders and honest users. I’m not comfortable with spending $OP for paid tweets.

Proposal C: Hundred Finance - ABSTAIN :yellow_circle:

Abstaining because i don’t understand the process behind this defi system.

Proposal D: Biconomy - FOR :white_check_mark:

Biconomy does a great job at lowering the barriers to use crypto. I’m hugely in favor of using $OP to bootstrap reimbursing fees to Optimism users. The amount requested is big, but as far as i understand it will not be used to directly cover costs.

Proposal E: Dope Wars - AGAINST :x:

I just don’t believe this type of a game works best in driving optimism adoption. I would be more comfortable with assigning 100k $OP since the project already exists and has traction and could use it to build something cool, but 1m $OP is way too much.

Proposal F: Infinity Wallet - AGAINST :x:

500k $OP requested. Directed fully into funding a non-open source project.

Proposal G: Dexguru - AGAINST :x:

300k $OP requested, the distribution will be decided by a token that doesn’t exist yet, which introduces a potential for abuse.

Proposal H: Overnight.fi - ABSTAIN :yellow_circle:

Abstaining since i don’t understand this value proposition.

Proposal I: Saddle Finance - ABSTAIN :yellow_circle:

Abstaining since i don’t understand this value proposition.

Free thoughts:

  • Maybe this is just me, but i would appreciate some criteria for voting in these “ecosystem” rounds. I signed up to be a delegate to work on funding public goods and this voting requires thinking in a different context.

  • Changed AGAINST to ABSTAIN for projects that i don’t understand. In general i assume that overcomplicated defi (gauges, rebases, non-utility-staking) serve to build ponzis and speculation projects, but I don’t want this bias to work against legitimate defi projects.

The good news:

Our votes in this cycle match the current results 100% and wouldn’t have changed the result.

A: Superfluid: Yes
B: Kromatika: No
C: Hundred Finance: Yes
D: Biconomy: Yes
E: Dope Wars: No
F: Infinity Wallet: No
G: Dexguru: No
H: Overnight: No
I: Saddle Finance: No

The bad news:

We created our Gnosis Safe on the Ethereum network and were able to vote on the first 2 proposals but we were not able to vote this time. Due to a vulnerability, Snapshot has changed their settings last week for security reasons and is only allowing votes from safes on the same network from now on.

We’ve been in touch with Snapshot to resolve this (they were helpful!) and ultimately we tried to recreate our Safe on the Optimism network with the same address according to a tutorial and with help from a friend from Gnosis Safe but unfortunately the network address on Optimism differs from the Ethereum network address and they do not recommend redeploying and using the address on another network and make it consequently hard for future use.

Solution - Manual redelegation is needed!
As currently delegated tokens can not be used to vote on proposals anymore(!), we have created a new account that we will use from now on to vote on Op proposals. We ask the Op team to change our delegate address to the new address to make sure no new votes are delegated to our old address.

We hope you consider redelegating with us but we understand if you pick 1 of the other great delegates.

This is our new delegate address:
Superdelegate.eth - 0xA56DfbE8010a8830a9Fe5B56e8efF7236e277120

1 Like

Sorry to hear you guys can’t vote this cycle, might not have any option but to have everything relegated manually as I don’t think the team can tweak delegations for you.

1 Like

are there any updates about the new voting cycle?

@arabianhorses similar to last cycle, once current cycle is completed, we will get some time to review and provide the feedback and voting for next cycle begin. So, in 2 weeks.

1 Like

Isn’t current cycle completed?

" Voting Cycle 3 begins Thursday (July 7) at 12pm PST / 7pm GMT and runs until Wednesday (July 20) at 12pm PST / 7pm GMT."

hey @Cyrus , yes, you are right. Current cycle is closed. Just saw that on snapshot too Snapshot

1 Like

While this is a reply to @MoneyManDoug it is actually more of a general comment.

Doug has stated:

But according to:

the actual amount of OP to be distributed is closer to 196m, i.e. “Phase 1 will begin after Airdrop #1 and will distribute the remainder of the Governance Fund (approx. 196,128,233 OP) to projects in the Optimism ecosystem. Phase 1 will run from Airdrop #1 until the Governance Fund is exhausted.”

Am I wrong here? Or am I not mistaken?

My point is if these voting cycles are going to run back to back for every fortnight, how long is it going to take to distribute 196m OP when more than approximately 3 in every 4 Proposals gets voted down? Has anyone calculated how much OP is being distributed every fortnight, on average? I haven’t done exact calculations, but a rough guess is that it’s going to take a LOT of fortnights to crank through 196m OP.

My suggestion is that the super delegates (let’s be straight, they’re deciding most of these voting outcomes) could maybe be a bit less cynical and/or less risk adverse? No need to be foolish, but if this process is meant to kickstart an ecosystem, then perhaps power voters could try being a bit more optimistic and show a little more faith in new ideas, even if they aren’t proven, world leaders (yet!). Or more formally: They could recalibrate their proposal evaluation criteria to place greater weight on the ecosystem’s early momentum? After all, you’re acting as a delegate of another’s fund. These proposals aren’t asking for the OP to come out of your own back pocket.

Thanks for your time. It’s nice to be back.
Cheers,
Axel

EDIT: Disclosure - part of my motive for this comment is that I’m thinking of re-drafting or creating a 2nd proposal, but I’m still on the fence as to whether it’s worth the time & mental effort when the bar appears so high to pass, and proposal success appears to be limited to established, insider projects who often shouldn’t need any more incentive. So my motive was to see if I could ideally shift the standard For/Against waterline, and from here see which side I came off the fence on.

2 Likes

unfortunately the network address on Optimism differs from the Ethereum network address and they do not recommend redeploying and using the address on another network and make it consequently hard for future use

Hey do you mind elaborating a little bit on this? Is there a technical barrier preventing from voting with an L1 native multi-sig or are you saying that it is possible to vote with the safe by manually inputing tx data and executing through some alternative instance but are choosing not to in order to avoid going through that potentially tedious process repetitively in the future?

I ask these questions because I’m in a similar situation and would appreciate the insight, thanks.

This is the process we went through:

  • We voted with our Safe deployed on Ethereum mainnet the first 2 voting cycles.

  • Then Snapshot changed their settings, now requiring voters to be on the same network to vote (Op governance → Optimism).

We needed to gain access to our Safe address on Optimism. :point_down:

  1. We checked how to recover funds / redeploy gnosis multisig on other networks (Gnosis Safe guide)

  2. Our hopes got up as we saw that our case is covered (Safe version 1.3.0) and we found this tutorial

  3. Following the short tutorial, we realized that the network address of Optimism (Chain ID 10) differs from Ethereum (Chain ID 1). The tutorial speaker tell us that it’s impossible to recreate a Safe on another network if the network address differs. Snapshot guys confirmed: “And in your case, your contract factory is not 0xC22834581EbC8527d974F8a1c97E1bEA4EF910BC , relayer only read and verify signatures coming from this factory on OP network” (See Gnosis Safe proxy contract)

Also, the Gnosis Safe interface does not support the new Op Safe: (not exactly sure why)

  • It needs to be noted that Safes with the same addresses on L2 and sidechains work out of the box with the Web and desktop UI. However, existing Safe addresses on Eth mainnet re-created on L2/sidechains (and vice versa) do not load up within our UI. This is because they use different singleton contracts.

  • Gnosis Safe doesn’t support redeployed Safes in their frontend as that feature is only available to recover funds but not supposed to be used for ongoing processes

There we stopped initially due to too many hurdles to get going and for future use.

  1. Then, we saw the guys from GFX claiming that they could vote with their multisig address using the Boardroom interface.

  1. We tried to use Boardroom but we got the following error message "Boardroom requires that you switch your wallet to the Optimistic Ethereum network to continue. Some wallets may not support changing networks. If you can not change networks in your wallet you may consider switching to a different wallet" - basically running into the same issue again.

  1. At that point, we tried once more to access the address on Optimism following the tutorial but we realized that we created our original Ethereum Safe with the Argent Wallet which basically makes it impossible to go through the process of recreating the address on Optimism.

Maybe GFX managed to access their Ethereum address on Optimism despite the network address difference and could therefore utilize the Boardroom interface? Did you use Metamask?

@GFXlabs @kevinknielsen maybe you can help?

1 Like

Thank’s a bunch for that detailed explanation @ScaleWeb3, really appreciate it as it clears up some things for us.

I did not know that piece about the Argent wallet, I’ll try to also dig up some answers as well. So far we have made some progress around voting with our L1 native safe on Optimism but nothing conclusive yet.

Will keep you posted here, thanks again.

2 Likes

GFX Labs has a msig on mainnet eth we use for all of our governance needs. We used the same address for OP governance. We were able to redeploy our msig (with the same address) on OP and use it since we have access to the controlling addresses.

For Boardroom, I used WalletConnect and the Gnosis Safe site to connect our OP msig with their site, and then I could vote like normal.

You need to deploy your mainnet eth msig onto OP and then you should be good to go.

1 Like

how were you able to get the mulit-sig working with Gnosis? That is the part we are kind of stuck with

From @ScaleWeb3’s response and Gnosis’s guide:

It needs to be noted that Safes with the same addresses on L2 and sidechains work out of the box with the Web and desktop UI. However, existing Safe addresses on Eth mainnet re-created on L2/sidechains (and vice versa) do not load up within our UI. This is because they use different singleton contracts.

We found the same Gnosis Safe Proxy Factory that we used on mainnet eth and on OP link. Use the createProxyWithNonce function and use the same input data you used on mainnet eth. That will generate the safe on OP. Just make sure you have the safe’s owners on OP as well. Typically the safe’s owners are EOA,s so it shouldn’t be an issue.

1 Like

Thank you sir for your answering :smiling_face_with_three_hearts: :smiling_face_with_three_hearts: :smiling_face_with_three_hearts: