I want to take this back to first principles for a moment. I think WAGMIcapital does a good job laying out the What of Cooler, but I think equally important is the Why and the Where to.
At the core of the original proposal is an attempt to derisk the protocol. This should manifest in several ways, some of which have been more discussed than others.
First, it removes the need for treasury management. There is no need to compose a basket of treasury assets or deploy them into various protocols if individuals can do these actions on their own. I have not, and still do not, see any rational argument against this position in a world in which an individual can access a cooler loan and diversify their backing as they see fit. The one argument I do understand, that of protecting the vanity metric of volatile (and possibly appreciating) backing because of ie ETH holdings, is not one that I agree with and not one that holds any water, in my opinion.
Second, it ensures holders are as protected from financial and smart contract risks as they want to be. Worried about USDC? Hold your backing in something else. Worried about Ethereum? Move to a different chain or off-chain. You might think: but if any of those risks were to manifest, the protocol is still rekt — and you’d be right. But the status quo is not that there would be any less harm on the protocol level, but simply far more harm on the user level.
Third, it makes the implementation of on chain governance (in my opinion, the single most important development) far easier. This is not only because less/no treasury management means less complexity and scope of governance. The biggest blocker for OCG to date has been what I will call the “honeypot dilemma”: if the system is fully controlled via token voting, then token voting could be used to send all treasury funds to a single (or small group of) voter(s). Imagine OCG with the ~8% turnout for TAP-25 (the highest in a while) — if a voting bloc has >8% of supply, they could vote to transfer the entire treasury to themselves (12.5x their share). This is the single worst possible outcome for the network and it has proved very difficult to hedge against with a governance system. I used to think that this dynamic would actually serve to ensure a consistent premium for the network: for example, if 33% of supply is needed to pass a rug vote, then OHM would always remain priced at >=3x premium. This hypothesis remains neither valid or invalid; but at the current discounted state it doesn’t really matter. OCG is untenable so long as OHM remains so cheap relative to its treasury liquidity.
Here is where Cooler comes in though. By lending backing to holders, you remove the honeypot. Rather than focus on premium (controlled by the market and not by governance), we can focus on treasury liquidity (controlled by governance and not by the market). Using our previous example with an 8% governance threshold, trying this attack does not make much sense if only 10% of the treasury is liquid and able to be heisted — a max-25% ROI is not worth the risk you would take on by trying the attack.
I think that, following the launch and utilisation of Cooler, OCG can be implemented quickly and easily with a Compound/Open Zeppelin governor. The idea of a custom, complex, and untested system taking on such an important role makes me uncomfortable to begin with, and if its not necessary it should not be done. We can take some additional solace in the fact that the Compound/OZ system has a suite of tooling around it, meaning no custom smart contracts, front ends, monitoring, or anything else of the sort. This should sound especially great to those that have been dissatisfied by the governance process around Cooler.
The thing to understand about the benefits to the implementation of OCG, however, is that it relies on high subscription. I wish I had fully understood this dynamic going into this whole process, because if I had I would have made fewer concessions when it came to capacity. I have heard many share the same sentiment I had around the limit — that if/when its reached, more would be added. However, this seems like a ‘kick the can down the road’ strategy that offers little benefit versus the already tapered deployment strategy (OIP 144) and carries the risk of undermining the entire proposal. The other detriment of limited capacity, which again I did not understand fully until well into this process, is that low interest rates run the risk of harming holders that cannot access the loans. If treasury productivity was 3% but falls to 2% of a result of loans, holders unable to borrow because of capacity limits lose at the expense of those able.
With the long form out of the way, I will suggest this:
Use TAP-27 to reject the TAP-25 configuration (as seems to be occurring already)
Start over with a new proposal (I can do this part)
Implement the following terms
Capacity for all tokens (this can be iterative to hedge smart contract risk)
2,850 DAI per gOHM loan (a wider buffer to backing makes sense)
0.5% interest rate (incentives subscription at no individual loss bc full capacity)
3 month tenor (loans can be rolled over in advance of their expiration, so all this will do is require more frequent interest payments. I get the arguments favouring this and I’m here for it.)