Thanks, Nikita, for the detailed questions. We hope to address your responses in this thread and the Request for Proposal response which will be posted soon. First, we’d like to address the initial questions about the technical implementation of the new contracts and governance client:
1) On the non-standard implementation of the contract events.
From our exploration of 0x’s new governance contracts and our initial understanding, these mentioned events are standard to the OpenZepplin Governor specification and are already supported by our platform.
The Boardroom SDK manages the collection of protocol integrations, which are defined by imperative protocol registration functions and are flexible to support derivatives of standard governance contract implementations. These functions register information about a protocol and instantiate adapter instances which help us support events in a standard manner on the client.
This allows us to integrate any non-standard aspects of the governance contracts and we are studying the contract modifications made here by the team. We have found that there are deviations from the initial OZ Governor specifications to Vote Power calculations with the introduction of wZRX, updates to the standard Governor for votingDelay, votingPeriod, and proposalThreshold, updates to Quorum and the TimeLock period, and the Voting Strategies. These are all changes that our platform can support and surface through our Adapters. The new 0x governance client will specify the new custom pre-built 0x protocol framework and surface functions and data as any other project displayed on the Boardroom frontend.
2) On the requirements listed in the RFP.
The list of ‘Must Haves’ from the RFP is covered by our current functionality, except for, as noted, deposits and withdrawals of ZRX and the execution of onchain proposals - both of which we’d work to enable on the governance client. This will be the main focus of our technical work to fulfill the requirement outlined in the RFP. You can browse examples in one of our active integrations Uniswap Client or our Client Demo. The following actions are already active (with linked examples):
- delegate voting power (to oneself or others)
- create onchain proposal
- vote on onchain proposal
Our existing platform also covers most of the ‘Should Have/Nice to Have’ including:
- discovering all delegates
- discovering all proposals active or inactive
- quantitative metrics that are associated with the “health” of the community (i.e. protocol-level proposal and voting statistics)
As for the rest of the Should Have/Nice to Have’s, our proposal includes governance facilitation services, in part, to address these. For example:
- “Help[ing] a tokenholder decide which governance participant to delegate to” requires building both technical systems (which are already covered by our platform) and social systems for delegate campaigning and accountability. The latter takes ongoing work and attention to encourage delegates to follow through on sharing a platform, their reasons for voting one way or another, etc.
- “Help[ing] a governance participant decide their stance on an active proposal” requires the ongoing and timely production of objective content related to proposals, which is something we do for several other DAOs as discussed above.
- “Serving as a hub for all related tools that governance participants need” requires ongoing attention to the tools that governance participants need. We will add a list of resources on the project overview page so the governance client can act as a landing page for governance participants.
3) On a proposal’s executable code.
We support “displaying proposal executable code” on our platform (a recent addition) but have not integrated it into any client. We plan to bump it up on our internal roadmap to have it ready for the delivery of the 0x governance client. Here’s an example design specification:
4) On other application considerations.
We’re glad you asked this question because it gives us an opportunity to ask for community feedback. Our current outlined implementation is a hosted governance client for the 0x protocol, managed and deployed by the Boardroom team and under the existing boardroom dot io domain.
With regards to visual design, the frontend - no matter where it’s hosted - will use the same design system as Boardroom’s current application.
As for maintenance and support, all functionality released as part of this build will be maintained in perpetuity at no additional cost or commitment. As we highlight in the proposal, the only reason we would consider additional funding is the buildout of new, custom functionality. We also plan to host shared Discord and Telegram support channels to process maintenance requests.
5) We are in the process of updating our Privacy Policy and ToS and will link directly to the new documents in the next few days.