Analysis of the DAO's Technical Decision Making Process

As the Research Member of the ARDC V2, @DefiLlama_Research was mandated to examine how Arbitrum DAO makes technical decisions and to chart a clear path toward a more robust, delegate-friendly governance process.

Our work centred on three pillars:

  1. Diagnose the status quo – we traced recent constitutional upgrades such as BoLD, ArbOS 31 and Timeboost, interviewed delegates, and surfaced six recurring pain-points ranging from “documentation sprawl” to “no institutional memory.”
  2. Benchmark against peers – using a six-factor scorecard we compared governance tooling in zkSync, Optimism, Lido, Aave, MakerDAO and Curve, distilling what works (Developer Advisory Boards, rigid templates, public archives) and what doesn’t.
  3. Deliver an actionable roadmap – we propose a governance-light yet high-leverage framework outlined below:
    • embed expert-review duties inside Arbitrum-Aligned Entities (AAEs)
    • introduce delegate-facing “crash-course” workshops for Tier-1 proposals
    • launch a tightly scoped Technical Missions programme to attract outside builders
    • mandate a live metadata table for every forum post and maintain a proposal archive.

The Google Doc is fully navigable via the panel on the left and contains:

  • Final Report – A full narrative that ties research findings and recommendations into a single, end-to-end blueprint.
  • State of Technical Decision Making in Arbitrum – Walks through recent upgrade proposals to surface six recurring governance gaps that slow or confuse delegates.
  • Key Takeaways – Distils the most common delegate pain points and desired improvements into an easy reference list.
  • Technical Decision Making in Other DAOs – Compares six peer protocols across criteria like expert access, documentation quality, and lifecycle transparency, showing where Arbitrum lags.
  • How Other Protocols Attract External Technical Contributors – Explains programs such as Optimism Missions and zkSync Contributor Track that successfully pull in outside builders, and extracts lessons for Arbitrum.
  • Survey – Presents quantitative and qualitative feedback from delegates that pinpoints barriers around clarity, consistency, and impact assessment.
  • Additional Recommendations – Lists quick wins and minor add-ons, from proposal checklists to a central archive, that complement the primary roadmap.

Whether you are a delegate seeking clearer guard-rails, a protocol developer aiming to ship upgrades, or an external team looking to contribute, these documents provide the context and tools needed to help Arbitrum evolve into a more structured, transparent, and scalable governance model.

4 Likes

We must have missed this survey somehow but thank you for this research! Something like the framework suggested would definitely help us with the technical proposals that come up. It’s interesting that from the examples that were looked at, the chains had better support for delegates on these kinds of proposals than the protocols. We think that sets a higher bar for us to meet as well, since those are our real competitors.

Pulling a couple things out of the report:

from 1.3.2. Limitations of Existing Approaches:

Despite the open governance process and public repositories, there is currently no dedicated track, onboarding path, or support system tailored for external contributors looking to submit technical Arbitrum Improvement Proposals or modify core smart contract infrastructure.

Additionally, roles and responsibilities for critical steps such as code review, integration testing, and technical approval are often undefined or implicit. Contributors must rely on informal relationships or community goodwill to obtain feedback, guidance, or alignment with core stakeholders, such as Offchain Labs or the Arbitrum Foundation. In some cases, teams have proceeded with audits and development without receiving any confirmation that the DAO would consider the upgrade. This was the case with the proposal for Arbitrum DAO to register the Sky Custom Gateway contracts in the Router. Due to the lack of clear guidance from Offchain Labs, delegates were uncertain about the feasibility of the implementation.

from 4.1.1.1. Lessons from Optimism: The Developer Advisory Board:

Optimism has pioneered a structured approach to technical consultation via its Developer Advisory Board. The DAB includes expert developers drawn from core teams and the wider Ethereum ecosystem. While the DAB does not vote, it plays a crucial role in reviewing governance proposals, publishing technical assessments, and issuing advisory memos that help delegates understand trade-offs and feasibility.

The DAB operates with defined workflows, internal consensus procedures, and compensation. Their input has become a valuable source of clarity, especially for complex protocol upgrades. Most importantly, the DAB reduces the knowledge gap between highly technical proposals and generalist governance participants.

and the proposed enhancements in 4.1.1.2. A Scalable Alternative: Embedding Responsibilities in Aligned Entities:

Arbitrum can draw inspiration from Optimism’s DAB without replicating its structure directly. Rather than introducing a standalone advisory board, Arbitrum can embed expert consultation responsibilities into its existing Aligned Entities (AAEs). These entities are already operational and aligned with the DAO’s strategic priorities, making them well-suited to support proposal assessment.

Each AAE should designate team members capable of reviewing proposals that intersect with their domain. For example, protocol development teams can evaluate smart contract changes or infrastructure upgrades, while ecosystem strategy entities might assess ecosystem alignment or implementation feasibility.

The core responsibilities of each participating AAE should include:

  • Technical Evaluation: Structured analysis of proposals involving smart contracts, protocol upgrades, or validator operations. Reviews should consider design integrity, backward compatibility, maintainability, and risk exposure.
  • Advisory Memos: Each review should result in a clearly written memo or briefing summarising feasibility, risks, and trade-offs. These should be accessible to non-technical delegates.
  • Author Guidance: AAEs should assist authors, especially external contributors, with technical preparation, review timelines, and design alignment before proposals move to formal governance.
  • Milestone Oversight: For proposals with deliverables, OpCo or an AAE can track milestones and provide updates to OpCo and relevant oversight bodies to support funding decisions and ensure accountability
  • Workshop Coordination and Documentation: AAEs, in collaboration with OpCo, should ensure that workshops supporting complex proposals are properly documented, use accessible formats, and follow consistent templates. These sessions should be aligned with governance timelines and designed to help non-technical delegates engage meaningfully.

Where the evaluating AAE is also the author or implementer of a proposal, OpCo should coordinate with neutral technical contributors or external experts to ensure that assessments remain independent and credible.

but it’s also noted that

This approach may require additional manpower, and its feasibility at this stage remains uncertain

can the proposed AAEs please let us know if this is feasible now? If not, what would it take for each AAE to get to a spot where it could handle this kind of responsibility, and what kind of timeline might we expect to get there if the DAO wanted to implement this kind of framework?

While the other suggestions like workshops, metadata, and an archive would definitely be helpful, we think being able to have trusted experts to help interpret proposals has the biggest impact on delegates decision making. Workshops would be the second most effective, but having more flexible access to subject matter experts is always the best. From the ratings, looks like ZKSync or Optimism might be something to emulate here, for both options.

not sure who the best tags are here but think some info from @Entropy and @Arbitrum might be a good place to start.

1 Like