Developer Advisory Board

Governance Design 📐 Metagovernance
1

Introducing the Developer Advisory Board

Developers are among the Collective’s most important stakeholders as they are building the Optimism protocol and the applications on top of it. Governance of an L2, and growth of its supporting ecosystem, will require governance to make many technical decisions.

For example:

  • Intent #1, progress towards technical decentralization, is the highest priority for the Collective. Proposals under this Intent require technical expertise.

  • Builder grants aim to increase the number of active developers deploying on Optimism. The Grants Council must make decisions that are heavily informed by the developer perspective, particularly at the application level.

  • The Token House is tasked with evaluating high importance protocol upgrades and enforcing the Law of Chains, both of which require high levels of technical understanding. In future Seasons, the Developer Advisory Board’s mandate may be expanded to assist delegates in assessing technical proposals.

Given the need for Optimism governance to make good technical decisions, the Foundation is proposing the establishment of a Developer Advisory Board (DAB) with the below mandate.

Developer Advisory Board Charter

Goals

Advisory Board Structure

This Advisory Board is not a Council as they will serve in an advisory capacity without official decision making authority. Therefore, they will not be elected as representatives, but will rather be appointed. The initial set of members will be appointed by the Foundation. In subsequent Seasons, members will be appointed by the Grants Council.

The Developer Advisory Board will not vote on proposals. However, the advisory board’s approval will be required on all Delegate Mission Requests under Intent #1. In order to provide approvals, a simple majority of advisory board members must agree that an approval has technical merit. Evaluation criteria and rubrics should be made public, when applicable. The Grants Council should also consider the Developer Advisory Board’s input on all Mission Applications under Intent #1.

Membership

The initial Developer Advisory Board will be comprised of six members and a lead, one of which will be a non-voting member of the OP Labs engineering or product team. One member of the Developer Advisory Board will be designated as the Lead to manage general coordination and operations. The Lead will be a non-voting member. If approved, the Foundation will appoint the below members:

  • Board Lead: Brock
  • Board Member: Philogy
  • Board Member (forfeiting compensation): Noah
  • Board Member: Zach
  • Board Member: Roman
  • Board Member: Jepsen
  • OP Labs Representative (non-voting): Kelvin

Summary of experience and qualifications here

All members may be removed from their positions via the Representative Removal proposal type in the Operating Manual. If a member of the Developer Advisory Board is unable to fulfil the responsibilities listed below, they may publicly step down and the Foundation (Grants Council, in future Seasons) should appoint a replacement by no later than the end of the next Voting Cycle.

Future Appointments

The Developer Advisory Board will need to be re-appointed by the Grants Council each Season as the members of the Grants Council must be re-elected and are subject to change. As the expertise represented on the Grants Council changes, the composition of the advisory board may also need to change.

Future appointees of the board should be selected considering the below qualities:

  • Must have:
    • history of development in the Optimism and/or Ethereum ecosystem
    • deep understanding of developments in the Optimism ecosystem
    • ability to dedicate sufficient time fulfilling member responsibilities
  • Nice to have:
    • experience with security and or auditing
    • experience evaluating technical grants (examples include, but are not limited to, evaluating grants for the Ethereum Foundation, ConsenSys, and/or other protocol grant programs)

Member Responsibilities

  • Review all Delegate Mission Request drafts under Intent #1 and provide feedback/reasoning if the Developer Advisory Board’s approval is NOT provided on any proposal drafts before deadlines. The Developer Advisory Board is encouraged to create a public rubric, using a rubric process similar to that of the Grants Council.

  • Provide a statement on each approved Delegate Mission Request either affirming why it’s important or registering skepticism as to its technical merits.

  • Work with the Grants Council to assess the merits of Mission Applications under Intent #1. The Developer Advisory Board may also assess the technical merits of Mission Applications under other Intents, but it is not required.

  • Assess the completion of technical milestones related to Intent #1 Missions and/or Mission Requests for other Intents that the Developer Advisory Board has advised the Council on.

  • Members may also create their own Delegate Mission Requests, but are not required to do so.

  • Members should expect to dedicate 5-8 hours per week, on average, to these responsibilities.

  • The Advisory Board Lead should:

    • publish the board’s internal operating procedures before the beginning of Season 5
    • facilitate coordination of board member review and host regular board meetings, which should occur at least once per Grants Cycle (every 6 weeks.) It is suggested that meeting minutes or summaries be made available to the community
    • run a process to ensure milestones on technical Missions have been met before milestone-based dispersements are made
    • exercise decision-making authority in the event that the board cannot come to consensus on an administrative or operational matter

Advisory Board Budget

We propose an initial budget of 12,500 OP per Advisory Board Member (excluding the OP Labs representative) and 20,000 OP for the Advisory Board Lead, for a total budget of 70,000 OP to be dispersed at the end of Season 5. The initial budget will be important to attract top talent, but we believe the contributions of the Developer Advisory Board are highly conducive to RetroPGF funding and recommend the board be primarily rewarded retroactively.

Consistent with other reward allocations, all Developer Advisory Board rewards will be subject to a KYC and claims flow process.

What does it Mean for Delegates?

Delegates will need to approve the Developer Advisory Board budget and ratify its membership in Special Voting Cycle #16a. If approved, the Developer Advisory Board will have ample time to establish its internal operating procedures before the start of Season 5.

9 Likes
4

I’m supportive of this proposal. I think having a developer advisory board with expertise around the Optimism dev ecosystem is great and needed.

3 Likes
5

I’m looking forward to the establishment of this board. It will be useful. Especially, the prospect of expansion to assistance of delegates in the future is positive.

1 Like
6

Noting that there has been a request for a summary of the appointees qualifications and why they’d make a good member of the Developer Advisory Board. Working on this request and will post as soon as available.

2 Likes
7

Summary of experience

Brock from Nascent

Heavy early contributor to Foundry, which is now the standard for smart contract development. Pioneered modern mental models on how to go about writing secure smart contracts. Cutting edge security tooling and entry level guides for app devs to write secure code.

Phil from DeReg

Phil is an EVM expert that is known for his optimization and bug hunting abilities. He is currently working on a DeFi circuit breaker design meant to make the ecosystem much safer. He contributes to many open source EVM projects, both defi protocols and at the level of compilers.

Noah from a16z

Noah built out Helios, a light client for Ethereum, as well as Magi, an additional implementation of the op-node in Rust. He has also contributed to Halmos, a symbolic testing tool for smart contracts. He also worked on smart contracts at Index Coop.

Zach, a bug huntooor

Zach is a highly skilled auditor who serves as a Lead Security Researcher at Spearbit at Senior Watson at Sherlock. He found some really tricky bugs in the Optimism bridge, helping to ensure that there are no issues with deposits and withdrawals. He has good insight into the sorts of projects that are being built and challenges they face given his exposure to so many different codebases via auditing.

Roman from reth & Foundry

Roman is a core contributor to reth, a new cutting edge Ethereum Execution Layer client. He has also contributed to the development of op-reth and was heavily involved in Foundry, the leading platform for smart contract development.

Waylon from PrimitiveFi

Waylon is an expert in AMMs and contributes to Primitive’s RMM. He builds simulation tooling that can be used to model how users can interact with smart contracts. Agent based testing is required for complex defi applications, to prevent things from turning out in unexpected ways.

9 Likes
8

I think this is a good experiment. My addition is to create a way to measure efficacy. Some potential questions to ask:

  • how many times during the season was the board contacted by grants council for advice?
  • how critical is the advice?
  • how many times did advice change/shape a decision?
1 Like
9

I would like to also see something like this. A developer advisory board may be a good idea but having no way to choose its members as a DAO or measure their efficiency is a bit antithetic to governance and feels more like rubber stamping what the foundation wants to do.

For now I will vote FOR but would like to see less rubber stamping and more deciding on the DAO’s part.

6 Likes
10

I’m supportive of this proposal

1 Like
11

We vote FOR both the board budget and ratifity its proposed members.

We are happy to see the Foundation take more initiatives like these that promote diversity and encourage the collective to progressively begin to take ownership and self-regulation in the technical part of the protocol and contributions in that aspect; very in line also with the now presence of 3 core teams for the Collective. The budget proposed as baseline is reasonable, considering the possibility of being rewarded retroactively.

Regarding the ratification of the members, in principle this is understood as a signal or reference point of how this board should be constituted and in the future we hope that the members can be elected.

3 Likes
12

The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking and ideation of the two.

The need for in-depth understanding of technical concepts when assessing proposals for their technical merit is apparent. Having a board to rely on will help delegates better assess proposals and the associated benefits & risks without having to possess the technical knowledge themselves. We appreciate the benefits of such a board, and we’ll be voting in favour of the proposal.

3 Likes
13

very powerful, important proposal

1 Like
15

Made a small update to reflect possible member removal via Operating Manual rather than Code of Conduct.

1 Like