Plus Surplus Buffers, Preventing Governance Attacks, and Vitalik Challenges How DAOs vote
Grant Debacles on Uniswap
Blockchain protocols often reserve a portion of their governance tokens for community grants to help grow the protocol. Uniswap and Celo are two protocols that do this. They each allow their community members to make grant proposals that are then voted on by token holders. To be approved, grant proposals must both a) get a minimum number of votes (the "quorum") and b) get more yes votes than no votes. Voting is one vote per token (not one vote per person or one vote per wallet address).
Often, tokens allocated for community grants are largely unused. This is currently the case with Celo, where the vast majority of tokens made available for grant proposals have not been applied for yet. It is also an issue for Uniswap.
On the flip side, there is the challenge of businesses or individuals who apply for grants that strongly benefit themselves over the community. One specific example is this week's debacle around Flipside's proposal to Uniswap. In short:
Flipside is a private company that helps to run grant programs for protocols.
Flipside initially made a proposal whereby they would be allocated $25M worth of UNI tokens to run a grants program for Uniswap.
Under the proposed terms, Flipside would invest the $25M with the aim of earning a 30% yield. Half of the yield would go to grantees, and half of the yield would go to Flipside. Note: Financially this is equivalent to Uniswap granting Flipside a present day payment of $12.5M to run the program.
Under an amended proposal, Flipside pared back the proposal to a $15M allocation in the first year, increased by $10M in the second year.
My biggest problems with this proposal are that:
It is ridiculous that the grant manager should get 50% of the yield. This is too high.
It is ridiculous that the grant manager should get 50% of the yield indefinitely! Why should the protocol make such a long term and expensive commitment?
Maybe getting 50% of the yield in the first year is ok (still generous). After that, I think the opportunity should be opened up to other companies to run the program at a more competitive rate. My recommendation and the full forum discussion is here.
The proposal above by Flipside very nearly got through. Ironically, it failed only on a technicality because IndexCoop (who had delegated votes to Flipside in order for Flipside to have enough votes to make the proposal) accidentally withdrew their tokens prematurely.
To conclude, I commend Flipside for making a proposal because clearly many community funds are unused and need to be used. I think their proposal is too generous, but maybe if it had passed it would have encouraged other companies to apply and - over time - we might see more competitive bids to run grants programs.
Just as banks keep a reserve to cover against losses, DeFi lending platforms like Maker are thinking about how to provide a safety buffer for their protocol. Currently, the Maker safety buffer comes from a "stability fee" that is charged to those who borrow the DAI stablecoin on their platform. Right now, the safety buffer is about 1% of the funds on the platform. For reference, banks might have a reserve ratio closer to 3% apparently. Here's a snapshot of the Maker balance sheet (from SebVentures post on the forum):
Preventing Governance Attacks
Making protocols open to governance proposals makes them vulnerable to malicious or self-serving proposals. Here's how someone self-serving would do that:
Gather up enough tokens so you have enough votes to make quorum.
Quietly submit a proposal that benefits yourself.
Vote yes and hope that not enough people notice or care to realise the proposal is self-serving. (Actually easier than one might think as there are large token holders that don't follow governance votes).
It's interesting to see how different protocols address this:
Celo currently has a preapproval step prior to a referendum. This preapproval requires a 3-of-9 multisig approval. The signers currently are not public. This adds a veto layer.
Uniswap has no such preventative measure and relies on market incentives and the threat of a hard fork (i.e. if there is a bad proposal, then participants create a copy of the blockchain without that proposal - which is disruptive but would solve the issue).
Here I suggest how Celo might move to a more Uniswap-type approach and remove the centralisation the comes with the multi-sig step.
Vitalik Challenges How DAOs Vote
Some of the issues above (and there are many more) stem from the one-token-one-vote type system that DAOs (decentralised autonomous organisations, like Maker and Uniswap) typically operate today. In short, this means that large token holders can wield influence that is bad for the network as a whole.
One simple problem is that small token holders have little incentive to vote (it's a similar issue in democracies). There is also the risk of bribery of small token holders by larger token holders. This can often be done in a way that benefits the briber and the bribe recipients but is negative to the platform as a whole.
In a long blog post, Vitalik lays out the case for why DAOs will need to move beyond one-token-one-vote if they are to succeed in the long term. Some examples include a) limiting what DAOs can change in the protocol or b) changing to one person one vote. A deep but worthwhile read here.
That's it for this week. Subscribe on Pinotio.com to get my weekly recap on Wednesdays.