Setup community cUNI Voting

[arr00]

Assuming the success of proposal 25 we will soon have a significant amount of UNI locked up un the cUNI contract. We have the ability as a community to delegate this UNI to any address.

This will be the best UNI governance experience for the average user:

• Earn interest on UNI deposits
• Borrow against your UNI
• Vote for free
• Help the community gather enough votes to propose

I propose delegating to the community multisig (0xbbf3f1421D886E9b2c5D716B5192aC998af2012c) and having off chain voting to decide how to vote as a community.

I have setup a snapshot space for cUNI at http://cuni.comp.vote. Shortly after every Uniswap proposal, we will setup voting where each address has votes according to their cUNI holdings at the time of the proposal. Before the Uniswap voting deadline, the community multisig will vote according to the cUNI holders’ decision.

Once cUNI accrues enough UNI to create proposals, we will allow for community member with at least x (maybe 100k?) UNI deposited in cUNI to start a vote on a new proposal. If the vote has 2/3 for yes, the community multisig will propose the requested proposal. For now, the multisig will not be proposing.

[zino]

Any update on this ? Because the first uni Proposal is live at the moment.

[arr00]

Unfortunately, we’ve missed the boat on voting for the first proposal, but in the coming weeks, I hope to see this done. We will be able to participate in proposals starting after we delegate to the multisig.

[jhvst]

I think this imposes some questions about the possible fee restructuring of Uniswap. With the V2 platform, the UNI governance might make the decision to redirect 0.05% to LPs. This means that the Compound contract might at some point start yielding fees from the sole ownership of UNI tokens. This would open new interesting ways to accrue funds for the Compound project. Nevertheless, it also opens some questions:

a) if I mint cUNI, would my ownership in proportion to non-used capital accrue the LP fees?

This is a relevant question since it might incentivize or disincentivize people to provide liquidity if they miss out on the 5.25% APY that would be produced by the following napkin math:

In other words, the yearly ROI on 400 UNI deposit would yield around 70 usd if kept within the account. Whether by depositing to Compound or not (and assuming the passive income on holding becomes true), you are essentially shorting UNI because you lose on the dividends in relation to what is the token utilization rate on Compound. If the whole APY from fees is lost, it would signal that only a very strongly opinionated shorters (and e.g., but not limited to, people who are very bullish on COMP) would be providing liquidity.

I currently don’t have much more to say, but hope this aspect would be taken into concern in further reiterations of the cUNI token.

[arr00]

This is a great point, and surprisingly, not the first time Compound has encountered a situation like this. A while back, MakerDAO introduced the DSR (DAI savings rate). Compound quickly updated cDAI to deposit market liquidity into DSR to make sure depositors don’t miss out on DSR.

If Uniswap starts disbursing fees to UNI holders, I’m sure that the community will update cUNI to distribute these fees to depositors if possible. A situation that could inhibit this would be requiring UNI to be locked in order to earn fees. I believe there is already a system setup for fee distribution, but I can’t look it up right now. Reading through that system would allow for a conclusive answer here.

[arr00]

Through further thought on the topic and speaking to others in the field, I’ve decided that weighting the votes simply by cUNI held at the time of the proposal is not ideal. This would allow for any large proposer to easily buy the cUNI vote by entering a leveraged position on for a few blocks.

The solution I am proposing is checking cUNI balance about a week prior to the vote and at the time of the vote. The user votes gets weighted with the min of the two. Another idea I have for weighting is setting it to 0 if the address is borrowing any UNI. This way we have slightly more control in avoiding purchasing the vote by large UNI holders. Any more input on the method for weighting votes would be greatly appreciated.

[arr00]

I have updated the snapshot strategy to invalidate any account borrowing cUNI for cUNI voting. Additionally, any new cUNI takes a week to vest for voting abilities. Beyond this, the cUNI voting weight for each account is simply their cUNI balance.

Beyond this, I would like to set some grounds for the multisig Uniswap governance interactions if a proposal delegates to it.

1. The multisig will not vote based on cUNI snapshot voting unless there is a 10% quorum
2. For the time being, the multisig will not be proposing anything
3. Any manipulation of the cUNI market in order to gain an oversized representation in the cUNI snapshot vote will not be honored.

[Mr_Po]

Hello @arr00

I want to express some concerns I have regarding Uniswap governance processes with the introduction of this proposal.

If I understand correctly, cUNI voting is a binary situation, which means that all the cUNI tokens vote one way.
If you lend on Compound and lose the vote, your UNI tokens do the opposite of your will. It is much worse than if they did nothing.

It magnifies the whale dominance in Uniswap governance.
This system allows big UNI holders to hijack the UNI locked on Compound and leverage their voting power.

My estimates are that a whale could gain 2.5x boost on his/her UNI voting power with virtually no cost.

Here’s how it’s calculated:
There are 15m UNI available to vote as cUNI. Bob adds 15m UNI to the fray and wins the vote, thus 2xing his voting power.
Additionally, Bob borrows DAI for 9m UNI (60% collateral) and lends it using another Lending protocol for 60% of UNI = 5.4m UNI. Bob repeats the process one more time and gets another 1.944m UNI.
This leaves us at 37.344m UNI gained from 15m UNI, i.e. ~2.5x boost.

==

I’ve pictured a scenario that is a little exaggerated, but it can easily be done on smaller, more subtle scale.
The important point here is that it can strongly feed into the whale power, or it can mildly feed into it.
But there’s no way it doesnt magnify the whale power, as the minority votes are turned against the minority with cUNI.

[arr00]

Your view is something I took very seriously along the way while setting up snapshot voting. Our strategy for calculating each score eliminates anyone borrowing UNI, which would mean they are attempting to get a leveraged voting position. Additionally, it takes a week for cUNI voting power to vest which should reduce the risk of votes getting hijacked by outside sources.

When voting as a block, there is no way to fully eliminate the issues presented by it, but I believe what I implemented does help. If we see any manipulation, the multisig may not vote. This is an experement, which may work out well: hopefully we will see.

[arr00]

Proposal 28 is live.

[zino]

why was it canceled ?

[arr00]

The CAP delegations dropped below 100k accidentally. It has been reproposed as proposal 29.

[monet-supply]

Hey everyone!

Now that proposal 29 has passed, cUNI can participate in Uniswap governance.

I recently began a governance process for a new Uniswap liquidity incentive program: https://gov.uniswap.org/t/discussion-uniswap-liquidity-incentive-plan/8590

I encourage cUNI depositors to check out the thread. If the initial snapshot poll process is successful, we’ll likely move forward with a formal proposal in the next few weeks.

Additionally, cUNI holders and the Compound community should think about cUNI participation in Uniswap’s “soft governance” procedures, including snapshot polls. The policies in this thread aren’t 100% clear on how cUNI would engage with Uniswap snapshot polls.

[arr00]

If the Uniswap community is interested, we could integrate cUNI scoring into the UNI snapshot polling.

[zino]

Where can we vote on the new uniswap proposal ?

[arr00]

Great question! There is a vote live at https://cUNI.comp.vote.