Kill switch: Polish and integrate MVP version#518
Conversation
1f702fa to
ff8393d
Compare
9eda76e to
d23363d
Compare
Co-Authored-By: Jorge Izquierdo <izqui97@gmail.com>
ff52bb7 to
ae617f6
Compare
There was a problem hiding this comment.
There's a bunch of really small comments in this review, but the main ones I'd like to bring up:
- Making the interface a bit more generic; rather than constraining it to just the kill switch perhaps we can operate on the level of an app being "enabled" or "disabled" by external factors
- Perhaps we can make the check for the
KillSwitchaviewinterface, so we can usestaticcalls - Again, rolling up the kill switch detection in
AragonAppintocanPerform(); to me this fits a lot better with the disabled / enabled model of an app - Simplifying
DAOFactory; I really liked how simple the old one was 😄
|
Thanks for the review @sohkai! I already addressed/answered all your comments. Feel free to take another look if you want. |
|
The coverage task is failing because there are some tests that fail but only when measuring coverage. I've trying to debug it locally but it was completely cumbersome and I couldn't get to know what was going on. After that, I tried running |
sohkai
left a comment
There was a problem hiding this comment.
🎉 This is looking great; not sure how we should work around the coverage task for now (perhaps we can even just install frangio's fork 😄).
One thing I was looking into earlier (and unfortunately dropped) was doing some investigation into why the gas overhead was so high for checking the killswitch (27k without a SSTORE is quite high!). It'd be nice to see if there was anything obvious to make this a bit lower.
Follow up on #516
Based on an offline discussion we had about the next-steps regarding the kill-switch topic, we decided to:
Summing up, the new contracts model looks like:

And the contracts interaction is the following:
