Respectfully, I think this is a bad call - issue one is a real, and significant issue.
There is a certain irony to a proposal that seeks to optimize and improve ENS governance simultaneously creating a regression as regards the atomic nature of proposal execution.
This effectively replaces a deterministic safety mechanism with human review. It also creates a dependency on yourselves..
We have examples of this exact class of issue happening in the past:
-
I missed this exact category of problem in the original on.eth proposal (reference).
-
You yourselves missed this exact category of problem in the calldata review of the original on.eth proposal (reference).
Given that this proposal moves us toward more automation and fewer governance checkpoints, silent partial failures are potentially incredibly dangerous. Yes, the surface area for something going wrong here is small but we should be setting high standards for ourselves. How do we expect large and serious players to depend on the ENS protocol and take us seriously if we take a ‘meh, we can fix it later’ attitude to basic software delivery?
The fix here is minimal (a few lines of code to bubble reverts), and preserves the atomic guarantees that ENS governance currently relies on.
I agree this proposal is important and worth moving forward promptly but I don’t think we should knowingly introduce a regression in safety when it’s this straightforward to avoid.
It is also concerning to me that Cyfrin missed this in their audit.