Trust minimized proxy

The proxy does not upgrade logic suddenly. Instead, it sets nextLogic and keeps it for a month.

bytes32 internal constant NEXT_LOGIC_SLOT = 0xb182d207b11df9fb38eec1e3fe4966cf344774ba58fb0e9d88ea35ad46f3601e; // eip1984.proxy.nextLogic
bytes32 internal constant NEXT_LOGIC_BLOCK_SLOT = 0x96de003e85302815fe026bddb9630a50a1d4dc51c5c355def172204c3fd1c733; // eip1984.proxy.nextLogicBlock

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.

bytes32 internal constant DEADLINE_SLOT = 0xb124b82d2ac46ebdb08de751ebc55102cc7325d133e09c1f1c25014e20b979ad; // eip1984.proxy.deadline

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.

bytes32 internal constant PROPOSE_BLOCK_SLOT = 0xbc9d35b69e82e85049be70f91154051f5e20e574471195334bde02d1a9974c90; // eip1984.proxy.proposeBlock

Meta comment: EIP/ERC number are not selected at random. They are issue/pr numbers from the https://github.com/ethereum/EIPs repo. 1984 is already the identifier of this PR: https://github.com/ethereum/EIPs/pull/1984. You might like this number, but please, open an issue or PR, follow the expected format, and use the number you get.

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.