We would like to thank @Immutablelawyer and Axis team for the detailed proposal on the needs to streamline the engagement with service providers. Especially for the Optimistic Governance, we are very much aligned with the challenges laid out in its motivation section and the concept of introducing the Optimistic Governance to achieve this framework. It will benefit other similar requirements to make the process faster, yet with the proper governance procedure.
Since we have similar concerns as other delegates have on the details like dependence on OpCo establishment and possibly an excessive oversight committee structure, etc, we believe we should continue to discuss those points to refine the proposal going forward.
We would like to highlight the other part of the proposal, the implementation of the optimistic governance. As an active delegate in the Lido DAO, we believe its Easy Track Motions works well to achieve the optimistic governance and the DAO should look into how it’s implemented.
Lido’s Easy Track system is designed to handle frequent, low-stakes governance actions (like topping up reward programs or adjusting node operator limits) without requiring a full token holder vote each time. For the implementation details, Lido does NOT use the OpenZeppelin Governor modules (like GovernorCountingSimpleUpgradeable) for Easy Track. Instead, it was heavily inspired by Aragon’s governance model, using Aragon’s MiniMe token for vote snapshots and its EVMScript execution format (Details can be found here). Lido also has built a front-end interface for Lido’s permitted committees to create relevant motions and for the community members and tokenholders to monitor and vote on them.
On Arbitrum, we can leverage OpenZeppelin’s Governor framework to manage proposals (motions) and voting. However, we can consider other solutions; instead of the default GovernorCountingSimple (which expects For/Against/Abstain votes), we can implement a variant that only uses Against votes by subclassing the Governor contract and override the voteSucceeded() or quorumReached() logic. An alternative is to not use the Governor counting at all and simply incorporate an “objection tally” in a custom contract. For instance, a simple OptimisticGovernor contract could maintain a mapping of proposalId → objectionVotes and allow token holders to call object(proposalId) to cast a no-vote (summing up their weights via getPastVotes(token, proposalSnapshot)). This contract could then have a function to finalize/execute proposals after the deadline if objections < threshold.
We could also consider utilizing ERC20Votes for automatically keeping track of vote power at past block numbers and introduction of a Timelock controller with limitations like only the governor or proposers can execute the passed proposals for extra safety.
We should also consider having a dedicated UI similar to the one for Lido and a notification system for delegates to take appropriate actions on those proposals (possibly additional considerations should be done for the DIP criteria as well).
In conclusion, we are in support of the framework and initiative to make this proposal forward! We are looking forward to hearing opinions from other delegates and contributors.