Hey @paulofonseca, as you mentioned on yesterday’s call, the main question in your Snapshot vote is whether we want a predictable, algorithmic DIP.
Your proposal has more hard-coded rules, while DIP 2.0 is more flexible (meaning the PM or OpCo can adjust the rules as needed).
At ETH Warsaw, Mateusz from Arbitrum Foundation asked me the same question: do I prefer a predictable, hard-coded system or a flexible one? I told him I prefer flexibility, and I still feel the same way.
The main reason is that every system eventually gets gamed. That’s why we need flexibility, so that rules can be quickly adjusted when that happens. This naturally requires some level of centralization, in the form of a program manager.
And it’s not just about preventing the system from being gamed. If we notice that a rule (or set of rules) within the DIP isn’t working as intended, it should be possible to change it and try something else, without having to go through the governance vote each time.
That’s why I voted against your proposal on Snapshot. That said, I think your proposal includes some interesting ideas that could be incorporated into future iterations of DIP 2.0.