Until chain reaches the block defined in NEXT_LOGIC_BLOCK_SLOT, nextLogic can be reviewed and cancelled, and in case if developers or governance being malicious, it allows investors to safely exit before a malicious upgrade.
Also, there is an optional DEADLINE_SLOT, a block after which it becomes impossible to upgrade the contract.
Value stored in PROPOSE_BLOCK_SLOT defines when setting nextLogic again will become possible and the period can be prolonged with prolongLock(): for example, if there is no upgrade planned anytime soon, next upgradeBlock can be set so that it will only be possible to upgrade the contract again after a year passes. This creates investors piece of mind, as they won’t be required to audit the code every single month.
Thanks for taking it seriously. It’s unclear to me if I have shared enough information about the EIP, but here is a pool request as you advised: EIP3561: Trust Minimized Upgradeability Proxy by SamPorter1984 · Pull Request #3561 · ethereum/EIPs · GitHub
For example, mentioning cap.finance is questionable, because the wealth distribution there is laughable, but on the other hand you could say it’s a good prototype and fits into the issue, so yeah, I would love to hear your thoughts or anybody else’ on all this
Also, an argument “just don’t make those contracts upgadeable at all” fails when it comes to complex systems. Because it might be impossible to model it right on first try.