Community Voting Post RAI Ungovernance

General Discussion
1

This post is meant to present the main options we have to govern the FLX treasury as well as any remaining parameters in RAI post ungovernance.

Problem

After ungovernance, FLX holders will be in charge with managing specific parameters in RAI (such as ETH and RAI price feeds). In addition to this, we’d like to find a framework where FLX holders can also manage the foundation treasury.

We alluded to the foundation treasury in an old post where we announced FLX. The foundation is and will be in charge with distributing token incentives to the community as well as offering grants for those who want to work on RAI in the following years.

There are a couple of issues to keep in mind:

  • We’d like to keep protocol and treasury governance separated. The reason is that the RAI protocol will have a fairly long timelock for every governance decision (between 5-7 days) but treasury transfers are instant (once a proposal passes, the treasury should transfer FLX shortly after). The problem with allowing anyone to vote on treasury management is that malicious whales can decide to seize all FLX for themselves. There should be a mechanism in place to prevent a proposal like this or at least make it hard to pass
  • If we keep treasury and protocol governance separate, this makes governance UX a nightmare. FLX holders will need to lock their tokens in multiple places which makes governance management even harder than it should be
  • Most people don’t want to keep their tokens locked or hold them in a hot wallet and be ready to govern while there’s no proposal to vote on. Thus, there needs to be an incentive for everyone to be active even during periods when there’s nothing to govern (possibly most of the time)
  • Ideally, both protocol and treasury governance should allow people to delegate their voting power to other addresses

Solutions

We (the Reflexer team) thought about a couple of options with different tradeoffs for both protocol and treasury governance. I’ll present them in order and detail the merits and downsides for each.

Protocol Governance

  • Compound Governance framework: battle-tested, used in various protocols. Allows people to delegate voting power. Not ideal for treasury governance unless we keep a multisig as guardian that can reject proposals. Keeping a guardian for both protocol and treasury is not ideal because we break the RAI ungovernance promise. Does not offer an option to incentivize voters to stay engaged and aligned with the protocol
  • veToken Model + Compound Governance: here we fork veCRV and require FLX holders to vote lock their tokens in exchange for voting power. Their voting power can be used in a Compound-like voting contract. Vanilla veTokens do not allow vote power delegation so we would need to make a custom implementation which increases the risk of a bug. If we pick this, we ideally drop buyback and burn in exchange for giving RAI surplus to veFLX stakers (requires minimal changes in the current RAI code to transfer RAI to veFLX). Still not ideal for treasury governance and if we keep the treasury separated, veFLX holders can’t vote on it because they are vote locked to receive fees and voting power for the core protocol

Treasury Governance

  • Snapshot: simple and straightforward. No on-chain interactions, saves gas. Relies more on the foundation enforcing the vote instead of automating the vote outcome. Allows delegation. Subject to whale control but malicious votes can be rejected.
  • Compound Governance: same advantages/disadvantages mentioned above. Having two Compound governance contracts is confusing UX. No way to incentivize people to be active in governance.
  • veFLX + Zodiac: Zodiac is a Gnosis Safe module that immitates MolochDAO and allows for interesting governance setups. For example, token transfers can have a governance delay in place. We can also allow the community to vote on spending the treasury and at the same time have a group of core contributors (rotated every 6 months for example) that can reject malicious votes. Combine this with veFLX and people can claim protocol fees while they vote on treasury expenses. veFLX can be used separately in a Compound Governance contract for RAI updates. We’re not yet sure if veFLX could work with Zodiac, we reached out to the team and asked. Does not allow vote delegation unless we customize the vanilla veCRV implementation.
  • FLX + Zodiac: simple token voting with no vote weights in place. Same Zodiac & Gnosis Safe setup. No incentives for voters to stay engaged.

Next Steps

I’d love to hear what the community thinks is the best way to design our (un)governance framework. We want to have a clear idea for protocol governance by end of 2021 so we can prepare all code and tooling prior to ungoverning RAI. Treasury governance is less urgent because there’s no ungovernance deadline but we would still like to have a clear plan in place by end of January 2022.

2 Likes
2

No opinion on veFLX vs FLX at the moment. (I don’t know enough about the ve model).

Zodiac vs Compound
I have been playing a bit with Zodiac myself and it looks awesome.
I’m biased: for long-term investments, I prefer to invest in things I want to succeed, as opposed to things I think will make me money. I want to see Zodiac succeed because I like the way the modules work and make it easier for projects to reuse each other’s code, which I see as a public good for DeFi.
So while compound governance should be a safe bet (or not after last week lol), Zodiac is definitely sexier.

Incentives for Voters:

Incentives for voters to stay engaged is tricky. I am actually more concerned about protocol governance voters staying engaged than I am about treasury governance.

If you can’t hit quorum for treasury governance then your proposal probably wasn’t very good. If you can’t hit quorum for an urgent protocol change then you’re fucked.

For protocol governance, a time may come (could be 10 or 100 years from now) where Reflexer might need a protocol change. If a large number of FLX has been lost or its owners died then it may be impossible to hit quorum. Therefore, quorum needs to be able to change based on the number of active voters.
Proposal: some sort of annual or quarterly “roll call” where FLX holders are incentivized to check-in (perhaps with FLX dividends or something). The quorum is then based on how much FLX is used to check-in.

1 Like
3

This can also be a rolling average of # of participants in the last X proposals.

4

Thanks for starting this discussion Stefan.

To re-iterate your separation between protocol governance and treasury governance:

Protocol (Un)Governance:

  • slowly and deliberately remove governance over certain parameters over time (e.g. PID)
  • upgrade oracle / denomination if needed
  • have meetings to figure out how to have fewer meetings (explicitly anti-bureaucracy)

Treasury (Un)Governance:

  • starting budget of ~10% of the FLX supply
  • provide sufficient incentives to bootstrap RAI growth & liquidity
  • automate incentive distribution as much as possible
  • provide grants to people who want to build on RAI (impossible to automate)

Putting on our “governance is an attack vector” hats, let’s think about what is at stake if protocol/treasury governance are captured.

Treasury Governance Captured:

  • Steal ~10% of the FLX, dump it all immediately
  • More annoying/demoralizing - steal the FLX, but then sell it slowly over time…

Protocol Governance Captured:

  • Steal 100% of the ETH collateral, mint infinite RAI
  • Use minted RAI to steal all assets paired against RAI in liquidity pools
  • Use minted RAI to steal all assets available to lend against RAI in lending protocols
  • Infinite mint FLX, steal all assets from FLX/XYZ liquidity pools & lending protocols
  • Update to a malicious oracle

Fortunately, as stated in our ungovernance roadmap, we will be removing the admin control over collateral in the system and over minting RAI, which eliminates the first three risks of capture. We will also be removing control over FLX minting and have it minted by a smart contract on a fixed schedule, as mentioned in our monetary policy update. Thus the risk of infinite minting FLX is eliminated as well.

The only remaining protocol capture risk is that the governance would update to a malicious oracle. The risks of updating to a malicious oracle are as follows:

  • ETH/USD price feed set to 0 → all RAI minters are immediately liquidated
  • ETH/USD price feed set to infinity → SAFE owners can infinite mint RAI
  • RAI/ETH price feed set to 0 → RAI redemption rate hits upper bound (currently 400%/y)
  • RAI/ETH price feed set to infinity → RAI redemption rate hits lower bound (currently -99%/y)

The RAI/ETH price feed being tampered with would still cause the system to collapse if not quickly rectified, but is unlikely to cause sudden harm to anyone but the most dangerously leveraged SAFE owners (by virtue of them getting liquidated by a rising RAI redemption price rising). Setting RAI/ETH to infinity and crashing the redemption rate would only devalue SAFE owners’ RAI debt faster, so it wouldn’t liquidate anyone.

The ETH/USD price feed being set to 0 on the other hand, would immediately liquidate all SAFE owners and auction off their ETH to the highest RAI bidders. And depending on the magnitude of the liquidations and lost confidence in the system, there could be massive amounts of FLX minting to cover any lingering bad debt. The ETH/USD price feed being set to 0 wouldn’t liquidate any SAFE owners, but it would allow them to mint infinite RAI, and thus steal all assets paired with RAI in liquidity pools and available to lend against RAI in lending protocols.

It should be clear from the above that the protocol being captured presents greater risks to RAI than the FLX treasury being captured. This is also why (at first pass) it makes logical sense to use separate governance systems to manage them. As Stefan said, we likely want ~1 week time delay for protocol updates (and probably longer as time goes on), whereas treasury proposals can be more agile.

Coin-Voting Governance

Most of the governance systems employed today fall into the category of “Coin-Voting” which is 1 vote per 1 coin. Stefan already mentioned Compound governance and the veCRV models, but I’ll also suggest the traditional MakerDAO Governance [1] system as well.

MakerDAO Governance:

  • Governance Polls - onchain votes that are used for signaling to inform the larger community
  • Executive Votes - onchain binding votes that are used to upgrade MakerDAO smart contract system to a new state
  • Continuous Approval Voting - each Executive Vote only passes when it receives more MKR approving it than the previous Executive Vote. This can also occur when MKR that approved the previous proposal migrates to approving the current proposal (you can only approve one proposal at a time).

Of the three coin-voting systems discussed, I have a slight personal preference for the MakerDAO governance system. It has delegation built in, and it has an implicit quorum requirement in that any new upgrade must have more support than the previous upgrade. The veCRV system as used by Curve has a fixed quorum requirement of 15% for parameter updates and 30% for ownership upgrades. Compound governance has a 1% quorum for proposing votes, and a 4% quorum for passing votes.

Of course, the MakerDAO system is also only as secure as the level of governance participation. The current active MakerDAO executive proposal is approved by 6.7% of the MKR, which is even lower than it was (8%) when I published my TakerDAO troll plan [2] to launch a “9% attack” about 18 months ago. At the time, MakerDAO protocol governance was effectively a 1-of-4 multisig, as I wrote about in my original MetaCoin announcement [3]. As of this writing, 5% of the MKR is available to borrow in Aave, so anyone with at least 2% of the MKR could consider launching a governance attack. Fortunately, due to the 48 hour Governance Security Module Pause Delay [4], in the event of a governance attack other users would have at least 2 days to sound the alarm and attempt to flee the MakerDAO system.

My least favorite thing about the MakerDAO governance is the lack of long-term alignment required for someone to participate in the governance. Someone who does attempt a governance attack is free to sell their MKR the following day and exit the system, leaving everyone else holding the pieces. Compound governance does nothing to address this, but the veCRV model does, allowing users who lock up their CRV a maximum 2.5x boost in voting power for locking up their tokens for up to 4 years. It should be noted that in their most recent “Clean Money” proposal [5], MakerDAO founder Rune proposed upgrading governance to a veCRV like time-based lockup governance model.

Beyond Coin-Voting

As Vitalik writes in Moving Beyond Coin Voting Governance [6]:

Some DAO protocols are using timelock techniques to limit these attacks, requiring users to lock their coins and make them immovable for some period of time in order to vote. These techniques can limit buy-then-vote-then-sell attacks in the short term, but ultimately timelock mechanisms can be bypassed [7] by users holding and voting with their coins through a contract that issues a wrapped version of the token (or, more trivially, a centralized exchange). As far as security mechanisms go, timelocks are more like a paywall on a newspaper website than they are like a lock and key.

In theory, even a vote locking system like Curve is susceptible to unbundling the economic and governance interest in the locked tokens, which reduces the benefit that comes from having governors be long-term incentivized to vote towards positive outcomes.

He lists several categories of solutions:

Limited Governance

  1. Limit governance to fixed parameter choices (RAI already does this)
  2. Add time delay (RAI plans to do this too)
  3. Be more fork-friendly (RAI has this as well via the “poison pill”)

Non-coin-driven governance

  1. Proof of personhood (1 vote per 1 human)
  2. Proof of participation
  3. Hybrid systems (quadratic voting, requires proof-of-personhood for anti-sybil)

Skin in the game (skipping due to complexity)

Hybrid Solutions

  1. Time delays plus elected-specialist governance (relevant for RAI, expanded below)
  2. Futarchy + anti-collusion = reputation (complex)
  3. Loosely-coupled (advisory) coin votes (basically snapshot + multisig governance)

Time delays plus elected-specialist governance : this is one possible solution to the ancient conundrum of how to make an crypto-collateralized stablecoin whose locked funds can exceed the value of the profit-taking token without risking governance capture. The stable coin uses a price oracle constructed from the median of values submitted by N (eg. N = 13) elected providers. Coin voting chooses the providers, but it can only cycle out one provider each week. If users notice that coin voting is bringing in untrustworthy price providers, they have N/2 weeks before the stablecoin breaks to switch to a different one.

Since RAI is already limiting governance as much as feasible, the other of Vitalik’s suggestions that I find most interesting are quadratic voting and time delays plus elected specialist governance.

Quadratic Voting:

  • Participants receive the square root of their capital as voting power
  • More level playing field between small holders and large holders
  • Requires proving unique identity of all participants (anti-sybil)
  • Governance participation must be permissioned to enforce anti-sybil

Time delays plus elected-specialist governance:

  • Instead of having the protocol decide the oracle directly, elect N proxies
  • Can only vote to cycle out the proxies one at a time, with a fixed delay
  • Protocol users a long time to flee when they see an oracle attack coming

Generally speaking, I’m against coin-voting for much the same reasons Vitalik is. That said, coin-voting governance systems are battle-tested in production whereas more the non-coin-voting systems are more experimental. If I had to pick a non-coin-voting system today, my preference would be to use the Zodiac framework to combine a Gnosis Safe + MolochDAO [8].

Zodiac Gnosis Safe + MolochDAO:

  • MolochDAO handles permissioned entry (and can kick)
  • Quadratic voting can be implemented at the social layer
  • Gnosis Safe can hold assets and executive arbitrary transactions (e.g. protocol upgrades)
  • Gnosis Safe can have signers that veto DAO decisions before they execute
  • The signers can be removed over time as confidence builds in the DAO’s trustworthiness

It would be relatively straightforward to use a MolochDAO for permissioned coin-voting as that would avoid the anti-sybil requirement while still providing some protection against malicious governance participants, but it doesn’t provide the benefit of leveling the playing field between smaller and larger holders, which means there would be fewer people to corrupt in order to corrupt the governance.

The primary challenge in using a MolochDAO for permissioned quadratic voting is enforcing anti-sybil. We could create an anti-sybil system ourselves, but KYC isn’t our core competency (nor do we want it to be!). The best anti-sybil system that exists today is proof-of-humanity [9], but it is still in its infancy and has yet to be thoroughly battle-tested.

Recommendations

Protocol Governance

I think it’s likely that we can avoid duplicate effort by waiting to see how the MakerDAO governance evolves. If they build something like veCRV but with delegation baked in, that seems ideal to use for protocol governance. Alternatively, we could work with them to develop it. In the meantime, I would recommend we use something battle-tested, like the existing MakerDAO governance system, but with a longer time delay.

Treasury Governance

Given that this is less urgent, I would recommend we punt on this for now, but tentatively plan to use the Gnosis Safe + MolochDAO system, and ideally with quadratic voting. I would like to see proof-of-humanity continue to be tested in production before introducing it as a dependency. That said, having permissioned entry would greatly reduce the risk of treasury capture, while credibly building a path towards decentralization (eventually removing the gnosis safe multisig signers).

Additional Considerations

  • Gas costs on L1 could 10-100x within the next 1-2 years, making L1 voting prohibitive for smaller voters anyway, eliminating their participation all together
    • This reduces any benefit that “quadratic voting” would presumably provide
    • If we wanted to have a DAO managed treasury, it would either need to be offchain or on L2 or we would have to accept that it is going to be dominated by whales
  • If we move towards a governance by token lockup model like veCRV, I agree with Stefan that we would need to move away from a buyback & burn model and instead reward those participating in governance - a potential split would be 20% stakers, 80% governance

Links (because my link limit is still 2 - remove the space)

  1. MakerDAO Governance - makerdao. world/en/learn/governance/how-voting-works/
  2. TakerDAO - twitter. com/ameensol/status/1229848488621428736?lang=en
  3. MetaCoin - twitter. com/ameensol/status/1229848488621428736?lang=en
  4. GSM Pause Delay - makerdao. world/en/learn/governance/param-gsm-pause-delay
  5. Clean Money - forum.makerdao. com/t/the-case-for-clean-money/10684
  6. Beyond Coin Voting - vitalik. ca/general/2021/08/16/voting3.html
  7. Bypassing Timelocks - blog.openzeppelin. com/bypassing-smart-contract-timelocks/
  8. Gnosis Safe + MolochDAO - daohaus.substack. com/p/-daohaus-adopts-zodiac-to-enable
  9. Proof-of-Humanity - proofofhumanity. id/
3 Likes
5

Rant in defense of buyback+burn

If we pick this, we ideally drop buyback and burn in exchange for giving RAI surplus to veFLX stakers (requires minimal changes in the current RAI code to transfer RAI to veFLX)

I strongly prefer “buyback and burn” over distributing surplus to stakers. I know this is a somewhat controversial stance on CT because people prefer what they think is steady and predictable income.

Reasons buyback + burn is better:

  1. Tax efficiency for United States (I know this is a dumb reason but it can increase profits by 10%+).
  2. My understanding is if I lose the private key for my veFLX-holding account (or I die or whatever), then the system continues distributing RAI to it for eternity. This is essentially just burning a stable asset for no good reason (since RAI doesn’t benefit from scarcity).

If you’re doing buyback+burn then if someone loses their private key for their FLX holdings then that’s essentially the same as burning that FLX.

I haven’t seen any good estimates for the rate of private key loss but wouldn’t be surprised if it was on the order of ~0.5%/yr (hopefully trending down). So after many years this could turn into a substantial percentage of protocol revenue.

Protocol Governance
I agree with pretty much everything Ameen said.

One thing to add is that IMO it’s important that FLX/ETH LP stakers also get a vote as they clearly have skin in the game. (Maybe even ~1.5-2 votes for each FLX staked, we can figure out the exact number later).

Quadratic Voting
I’m in the category where I would benefit from quadratic voting (I have enough FLX that I care deeply about the outcome, but not enough that my vote would matter when compared to bigger holders) and I would love to use it to abuse the VCs.

I think quadratic voting is awesome for all sorts of scenarios. I’m not sure this is the correct one though. Anti-sibyl is a really hard problem and won’t be battle-tested 1 year from now. Even if we had perfect anti-sibyl, what’s preventing me from registering my whole family and dividing my stake amongst them? (Or a VC from registering all their employees).
Also, how does delegating + quadratic voting even work?

This is awesome. I’m not a lawyer but I suspect there may be some liability for the proxies but the actual system seems robust and tamper-proof.

6

Regarding governance, in principle I agree stakers should be able to vote but then we’ll have two tokens to govern with and this is not great.

Regarding buyback and burn, agree it’s tax efficient although personally I don’t think this reason alone should tilt the balance. Losing private keys is a better one imo and currently trying to think of ways to circumvent that.

Got my own bias here because I degen in Curve and Convex and like the veToken model.

1 Like