[ARFC]: Deploy aCRV & CRV to veCRV

Hi,

Opinion
While all the options presented are novel in their own right (in my opinion) Aave should choose the least risky option: there should be no involvement of multisig-controlled governance via snapshot.

Reasoning
If Governance is the focus, choosing any option (including CVX, sdCRV and others) is too risky. veCRV is the best option here.

If yield is the focus: delegating all that governance power away to cvxCRV, yCRV is the same as giving it away to a multisig.

Now, if that is within the DAO’s risk appetite, then it’s all good. But to minimise risk, choosing the most credibly neutral option (veCRV) is in Aave’s best (short-term) interests. When veCRV alternatives are more reliable (the respective teams are working hard towards finding the best solution to decentralise their veCRV framework away from a multisig), one may choose the one that offers the most bang for the buck (either yield or governance).

Benefits of choosing veCRV over its derivatives (incentivising GHO)
The benefit of choosing veCRV (for the time being) is that the DAO can simply lock a vote for their GHO stablecoin pool (should they choose to incentivise it) in a set-it-and-forget-it manner, with occasional re-locking of unlocked CRV. With multisig style veCRV derivatives, one would need to periodically vote. This is cumbersome if you already know what you want to incentivise (your GHO stablecoin pools).

Final Thoughts
Of course I mean no disrespect to any team that does veCRV derivatives (since I hold them myself and I am a very happy user of their work). But I do think as a DAO as important as Aave, relying on multisig-style snapshot governance can attract unwanted risks (counterparty for sure, but also perhaps reg risk in the future).

I hope the DAO makes the best choice that helps them the best with the roll out of their highly anticipated GHO stablecoin!

With regards,
Fiddy.

5 Likes