I suggest we consider a roadmap leading to immutable core contracts. That is, an eventual final code freeze on the core v2 protocol (Comptroller, CToken, …), replacing upgradable proxy/delegate pairs with plain contracts. Some operational changes would still be possible (adding new assets, changing collateral parameters, changing interest rate models, pause/resume), but functional changes would not be possible without a new v3.
Trade-offs:
Pros:
-
Higher security due to greater “Lindy”: estimated security is a function of cumulative (Time X Value), which is partially reset on any upgrade.
-
Higher security due to reduced risk of governance attack leading to delegate upgrades.
-
Stability → higher integrator confidence, could lead to more long-term integrations.
-
Simpler code without delegatecalls → lower gas costs.
-
Reduced support costs, freeing developers to focus on more fundamental improvements in v3, working without technical debt of the existing design.
Cons:
-
Inability to fix newly discovered bugs and security vulnerabilities.
-
Inability to add new features → less competitive with evolving alternatives.
-
Fragmented liquidity: if v3 is created, then v2 and v3 compete for liquidity.
The most likely response to this idea is “Sure, eventually, but not yet” and I share that opinion today. But I do think it’s worthwhile to consider what would need to change before the balance moves in favor of a freeze. Some day, we’ll want to make deep improvements that require a base rewrite anyway, and at that point a v2 freeze is probably best.
I imagine a protocol lifecycle, guided by governance, where each generation begins as a fluid beta release, settles into a mature but still mutable phase, and is finally frozen, usable forever but guaranteed to never change again.