[GRANT REQUEST] Boardroom to support 0x Protocol Governance

Basic Details

Project name:
Boardroom to build 0x Protocol’s Governance Portal

Point of contact:
Kevin Nielsen
Twitter: @kevinknielsen
Email: hello@boardroom.info
Discord: kevinknielsen | Boardroom.io#7885

Team background:
Boardroom is a governance platform offering tooling, services, and governance infrastructure to protocol contributors and stakeholders supporting over 350 DAOs, helping them make faster, smarter, and more informed decisions.

Other sources of funding and approximate amounts (grants, VC, etc.):
$2.2M led by Standard Crypto, Grants from Aave and Optimism RetroPGF

Project Details

Describe the problem being solved:
This proposal is in response to the RFP for a new 0x Protocol Governance Portal ([Request For Comment] New 0x Protocol Governance Portal). Boardroom will upgrade 0x Protocol’s governance with a new Governance Client leveraging Boardroom’s full-stack governance solutions. The proposal for 0x Protocol governance includes:

  • Governance Client - a hosted portal supporting all existing 0x Protocol governance functionality as well as future additions. (Boardroom)

  • Governance Toolkit - a developer toolkit enabling anyone to build their own governance interface or integrate 0x governance into their application (ie wallet providers). (Governance API)

The initial RFP lists ‘Must Haves’ that are covered by current functionality, except for, as noted, deposits and withdrawals of ZRX and the execution of onchain proposals. 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):

Our existing platform also covers most of the listed ‘Should Have/Nice to Have’ including:

quantitative metrics that are associated with the “health” of the community (i.e. protocol-level proposal and voting statistics)

Explain how the funding will be used:
Boardroom will use the grant funds to cover engineering and development costs related to the following deliverables:

  • Governance Client - Initial integration at no cost. $17,500 at delivery. The Boardroom team will provide maintenance and support and would aim to renew the grant after six months with an updated scope set by the community.
  • Governance Toolkit - Full integration at no cost. APIs will be free and accessible for any developer integrating 0x governance functionality on their application.

Governance Client

The Boardroom Governance Dashboard helps users manage their decision-making process by providing all the information they need in one place. This interface can be integrated with the existing governance browser or built as a standalone interface.

The dashboard helps users easily:

  • Discover and vote on proposals executed on any governance system
  • Create onchain and offchain proposals for any governance system
  • Delegate vote power and contextualize recipient activity with comprehensive profiles
  • Track activity with notes, notifications, and calendars updating you on significant events
  • Keep up with activity through weekly updates, governance explainers, and key metrics

Explore the demo

Governance Toolkit

Boardroom’s Governance Platform easily allows any developer to build a governance interface or support DAO governance directly in their applications by integrating a simple toolkit.

Governance API

Boardroom’s API allows you to easily query all the information you need to know about DAOs and their governance.

Developers can query governance data for the 0x Protocol:

  • Proposals
  • Voters
  • Votes
  • Delegates
  • Delegations

The API allows you to quickly get all the information you need to know about DAOs and their governance from the blockchain. Rather than searching, indexing, and storing data yourself - you can now make one request to fetch specific governance information.

Governance SDK

The Governance SDK makes it easier for developers to interact with protocol governance in a normalized way by leveraging 100s of protocol integrations. It is a protocol and blockchain-agnostic governance interoperability framework. Developers are easily able to:

  • Support any contract type
  • Inject new protocol functionality
  • Use adapters to add specific functionality (cast a vote, initiate a delegation)
  • Integrate across multiple chains
  • Outsource upgrade maintenance

Indicate whether your solution/product will integrate directly with the 0x Protocol contracts (such as the 0x Exchange Proxy) or via APIs. If APIs, please list them (if known):

The proposed work will integrate directly with the newly deployed 0x Protocol governance contracts (protocol/contracts/governance at development · 0xProject/protocol · GitHub).

Most functionality under these contracts is standard to the OpenZepplin Governor specification and is already supported by the Boardroom 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 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. We have found that there are deviations from the initial OZ Governor specifications for:

  • 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
  • Updates to 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.

List any critical milestones and dependencies (if applicable):

Estimated Timeline

  • 2 weeks for the platform integration (APIs available)
  • 2 weeks for the initial staging site
  • 2 weeks for client custom functionality
  • 2-4 weeks for testing and feedback before release

To help guide the design of the governance portal, Boardroom will like to work with 5 - 10 active governance participators (30 minutes, 1-2 times each). Additionally, we are eager for feedback from the 0x community on all aspects of this proposal, particularly:

  • Client Functionality - What additional features would voters and delegates like to see supported on the application?

Describe how the solution/product benefits the 0x Protocol Ecosystem:
Boardroom provides a full-stack governance solution that will make 0x Protocol governance more efficient and effective. While we recognize that delegation is already robust and a critical part of 0x Protocol governance, this proposal seeks to upgrade this critical function with a focus on increasing distribution and delegator access to governance.

Do you agree to tag your solution/product for visibility in 0x Explorer:
N/A

What are the actual and/or target usage metrics (such as users and volume) for your solution/product:

Provide links to any of the following for the project (if available):
Demo: Boardroom
Website: https://boardroom.io
Twitter: https://twitter.com/boardroom_info
Discord/Discourse/Community: Boardroom
Github: Boardroom, Inc. · GitHub
Other: Governance API (API Docs)

Funding Request

Grant amount requested (in fiat):
$17.5k

Grant amount by token (ratio of tokens):
100% ZRX

Receiving address and chain:
0x6b27E26dc09d9c9FD9527526f79C9c8C659d1761 (Ethereum)

1 Like

I am putting a placeholder here expressing my strong concerns with this proposal as submitted. Governance as a service was not part of the original scope. I will provide additional feedback next week.

It is difficult to evaluate the merits of the proposal because it only abstractly addresses the technical requirements and focuses mostly on something that wasn’t in the RFP, namely, “governance as a service.” While being offered as “free,” this service could constitute or be interpreted as the operating and reporting activities of a business entity, which could create unnecessary and unacceptable risks to the protocol, which is software. IMO the solution being sought is a narrow one that technically enables the actions associated with governance, and my initial questions are about the technical implementation.

  1. It is my understanding that the RFP is being driven by the non-standard implementation of the events Transfer, DelegateChanged, and DelegateVotesChanged in the 0x governance and treasury contracts. Please describe how your solution addresses this at a technical level.

  2. Please indicate specifically how your solution addresses the “mandatory/must have” and “desirable/nice to have” requirements listed in the RFP. For example, please specify which requirements are met by the existing platform functionality, which ones require new development, and how those functions will be implemented and/or exposed in the API.

  3. While not specified in the RFP, please indicate whether your solution will include displaying proposal executable code and/or other data relevant to proposal execution.

  4. For the governance client specified in the proposal, please provide more details regarding the domain and application hosting, visual design, and maintenance/support.

  5. Please provide Boardroom’s privacy policy and information regarding the collection and storage of user data for all elements of the proposed solution, i.e., the Boardroom platform and/or standalone portal, as I wasn’t able to find this information on your website.

1 Like

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):

Our existing platform also covers most of the ‘Should Have/Nice to Have’ including:

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.

1 Like

Congrats to the Boardroom team for being selected to lead this important project!

@ericwong would you be able to share what made you to choose Boardroom over other candidates?

Hey Fig, I shared some context behind why @mintcloud and I ultimately decided to recommend Boardroom for the RFP in that thread but realizing it’s easy to miss that so relinking here: [Request For Proposal] New 0x Protocol Governance Portal - #17 by ericwong

tldr; Boardroom team’s proposal hit a large majority of the must have criteria with their existing solution, particularly ones that we thought are more complicated such as proposal creation, and had a very competitive cost and timeline to implement the missing features. We also felt that given their team is focused heavily on governance infrastructure, that there is high confidence in them producing a reliable governance client that may improve as they improve their product offerings more generally.

2 Likes

Thanks, @kevinknielsen for your detailed answers. Following up…

1/ Non-standard implementation of contract events - No additional questions at this time.

2/ RFP requirements - [My Understanding] The term ‘governance client’ and ‘governance toolkit’ are used to refer to the ‘project’ integration on the Boardroom platform, rather than a standalone portal or application. The governance support/facilitation services were included in response to some of the ‘Should Have/Nice to Have’ requirements in the RFP.

[Followup Comment] IMO all of the ‘Should Have/Nice to Have’ requirements can be met without adding additional services, even if those services are offered as ‘free.’ Given the typical form, cadence, and participation levels of 0x governance, along with the higher risk profile associated with ‘officially’ endorsing and/or sponsoring these types of services, I would like to see an option where governance support services are not included in the proposed solution.

3/ Executable code - [Followup Question] Is it possible to display not only the parameters as shown in the screenshot, but also a plain English explanation of the execution effects, similar to how wallets are starting to expose what the transaction actually does?

4/ Application - [My Understanding] Similar to #1, the solution will be an integration on the Boardroom platform, will conform to the look and feel of the platform with minor customization, and will not require additional costs associated with hosting, maintenance, and support.

5/ Privacy/data policy - [My Understanding] This information will be made available prior to the proposal vote.

6/ Proposal creation - [New Question] Will the workflow for creating a new proposal include a ‘preview’ to see how the proposal will be rendered before submitting?

1 Like

The proposal has been updated via initial feedback - please continue to direct any questions to @kevinknielsen and the Boardroom team!

1 Like

Hey @nikita,

1/ Please don’t hesitate to ask if any additional question come up here.

2/ That is correct. The governance client and toolkit cover most of the ‘need to have’ requirements outlined in the RFP. We’ve processed the feedback on the governance support and facilitation services and the updated proposal should now reflect an outline of how Boardroom can deliver the client and toolkit in response to the original RFP, without additional services.

3/ Boardroom does not currently support this functionality natively, but we’ve begun exploring potential options and third-party providers that we could integrate with. This feature however would likely be out of scope for the initial delivery of the client in the previously stated timeline. Nevertheless, it’s something we recognize could be very beneficial to most voters and would prioritize on our roadmap.

4/ Correct, and any minor customizations to the hosted client will not incur any additional cost.

5/ EDIT This information will be accessible on our website in the next few weeks, but in the meantime, our Privacy Policy can be found here.

6/ The creation flow currently includes a preview of the parameters for onchain proposals, but we would be likely able to extend this to include a full render of the entire proposal before it has been posted. Boardroom can include this in the final delivery of the client.

1 Like

Thanks for these clarifications and for revising the proposal. I have voted in the snapshot to move this forward to an onchain vote.