[Constitutional] DVP Quorum for ArbitrumDAO: Implementation & Parameters

The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.

We are voting FOR this proposal in the Tally voting.

We supported the move to a delegated voting power (DVP) based quorum during the Snapshot vote and we continue to support it. Over time, quorum in the DAO has been tied to the total voteable supply, while actual participation depends on delegated voting power. As supply grows and delegation does not keep pace, this gap becomes more visible and reaching quorum becomes harder even when the same active delegates continue to participate.

Moving quorum to DVP makes the system more aligned with how governance actually functions. It does not change voting power or how votes are counted, but it measures quorum against the tokens that are actively delegated and participating in governance.

In addition, enabling onchain proposal cancellation allows proposers to withdraw proposals during the pending period if issues are discovered or parameters need revision after delegate feedback. In practice, this should help avoid unnecessary votes on proposals that the proposer no longer wishes to move forward. So we support it as well.

Reiterating my previous comments for this new vote.

I’ve been reviewing recent governance proposals and drafted a structured summary of the DVP Quorum & Proposal Cancellation proposal to help delegates evaluate tradeoffs. I may be a little late for this one, but I’m sharing in case it’s helpful.

Governance Brief

Proposal: Delegated Voting Power (DVP) Quorum Model + Proposal Cancellation

DAO: Arbitrum DAO

Decision Snapshot:

Proposal Type: Governance infrastructure upgrade

Core Change: Quorum will be calculated using Delegated Voting Power (DVP) instead of total votable token supply.

Key Mechanism: Quorum becomes a dynamic threshold tied to delegated tokens, with minimum and maximum bounds.

Additional Upgrade: Adds on-chain proposal cancellation, allowing proposers to withdraw proposals during the 3-day pending window before voting starts.

Governance Impact: Aligns quorum with actual voting participation rather than inactive token supply.

Primary Risk: Greater reliance on delegated voting power may increase governance influence of large delegates.

Plain-Language Summary

Under the current system, quorum is based on total token supply, regardless of whether those tokens are actively delegated. This proposal changes quorum to reflect tokens actually delegated to vote.

How the new system works: If delegation is low, quorum defaults to a minimum floor. If delegation increases, quorum scales proportionally. If delegation becomes very large, quorum stops increasing at a defined maximum.

The proposal also adds a governance improvement: proposal creators can cancel their own proposal during the 3-day pending period, allowing errors or outdated parameters to be corrected without requiring the DAO to vote the proposal down.

Key Risks & Open Questions:

Delegation Concentration: Because quorum is based on delegated tokens, governance influence may become more concentrated among large delegates.

Delegation Volatility: Changes in delegation levels could alter quorum thresholds over time, potentially affecting proposal outcomes.

Initialization Estimate: The upgrade requires an initial estimate of total delegated voting power; if inaccurate, a follow-up governance proposal may be needed to correct it.

Governance Complexity: The dynamic quorum formula may be harder for casual participants to understand compared to the current fixed-percentage system.

Governance Accessibility Impact

This change makes governance more aligned with real participation but not necessarily easier to understand. By basing quorum on delegated voting power, the system reflects who is actually engaged in governance rather than relying on inactive token supply. However, the dynamic formula introduces additional complexity that most token holders are unlikely to track without summaries or analysis. As a result, the people who understand this formula will shape governance. Everyone else will need someone to translate it for them, or they’ll continue standing on the sidelines.

Protocol Analyst (PGI)

Voted FOR also for the onchain vote with the same rationale.

I’ve been looking through the technical spec for this, and honestly, basing quorum on total supply never made sense, it’s like measuring voter turnout by including people who aren’t even registered to vote. Moving to a DVP-based model is the right move for the DAO’s long-term efficiency because the switch to getTotalDelegation() finally tracks “active” voting power in real time. By using OpenZeppelin Checkpoints, we stop the participation hurdle from moving up just because more tokens are circulating, which has been a major pain point. Regarding the parameters, setting the Alpha (ɑ) at 0.5 for constitutional votes is a solid safeguard; it’s high enough to prevent “ghost” votes but low enough to keep governance moving given our current participation rates. I’m also a big fan of the 150m ARB Floor, it’s a necessary fail-safe that protects us from a “low participation” attack if delegation numbers ever crash suddenly. After checking the Trail of Bits audit, the initialization logic for the running total seems solid and the gas overhead for these storage updates should be negligible for users. I’m voting FOR this because it’s time our math caught up with the reality of how this DAO actually functions.

While I agree with your comments and understand the challenge with quorum, I do want to highlight that the ARB token’s ONLY UTILITY is governance. If there was any other utility for the token, I can see the rationale of changing the quorum to only active voting power given the multiple utility cases. By changing quorum, there is no motivation from the DAO or the Arbitrum Aligned Entities to find ways to increase governance participation because there wouldn’t be a need. Additionally, there is still new supply of ARB being unlocked that is clearly not being used for governance purposes (they are being sold) which is creating sell pressure. Medium and small delegates will just leave the DAO if price keeps going down.

The DAO should be asking how to increase participation to meet quorum, not how to lower the bar. Lowering the bar leads to an accelerating consolidation of power, smaller delegates exiting once they see their influence is being diluted, continued Arbitrum’s token price downturn, and a governance structure that serves insiders far more.

The following reflects the views of L2BEAT’s governance team, composed of @krst and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.

We voted FOR in the onchain voting.

Despite our earlier reservations, we continue to support this upgrade as it moves on-chain. At the moment, there is no alternative proposal that meaningfully addresses ArbitrumDAO’s quorum challenges, and the DVP-based model remains the only concrete, technically viable adjustment to improve governance operability under current conditions.

We also support on-chain proposal cancellation. Allowing proposers to withdraw proposals during the pending period is a practical improvement that can reduce unnecessary governance friction when errors or revisions arise before voting begins.

We initially voted NO for concerns of governance attack if the larger delegates are getting too much control. However are satisfied by the responses brought up by the Arbitrum team. With that we always agreed with the idea of the scaling the quorum with the # of delegated votes compared to total votable supply of arb, we just were concerned about implementation. Additionally, this proposal does appear to be the strongest proposal yet to address the issue.

We also think the on-chain proposal cancellation is very intuitive and have no objections.

Therefore, we will be voting YES.

I’ve been looking through the technical spec for this, and honestly, basing quorum on total supply never made sense, it’s like measuring voter turnout by including people who aren’t even registered to vote. Moving to a DVP-based model is the right move for the DAO’s long-term efficiency because the switch to getTotalDelegation() finally tracks “active” voting power in real time. By using OpenZeppelin Checkpoints, we stop the participation hurdle from moving up just because more tokens are circulating, which has been a major pain point. Regarding the parameters, setting the Alpha (ɑ) at 0.5 for constitutional votes is a solid safeguard; it’s high enough to prevent “ghost” votes but low enough to keep governance moving given our current participation rates. I’m also a big fan of the 150m ARB Floor, it’s a necessary fail-safe that protects us from a “low participation” attack if delegation numbers ever crash suddenly. After checking the Trail of Bits audit, the initialization logic for the running total seems solid and the gas overhead for these storage updates should be negligible for users. I’m voting FOR this because it’s time our math caught up with the reality of how this DAO actually functions.

That’s a fair challenge, and I definitely agree that we shouldn’t ignore the root cause of voter apathy or the token’s primary utility. However, from a technical and operational standpoint, the current system is creating a different kind of risk: Liveness Risk. Right now, as the ARB supply grows but stays in ‘idle’ wallets (like CEXs or cold storage), the ‘total supply’ math makes the quorum hurdle move higher while the active voting pool stays the same. If we don’t adjust this, we eventually hit a ‘governance gridlock’ where even simple, necessary security upgrades can’t pass because the math is literally impossible to reach.

I see the DVP-based model not as ‘lowering the bar,’ but as re-calibrating the scale to measure the people actually in the room. You’re right that we need more utility and participation and programs like RAD are a great start for that but we shouldn’t let the DAO’s operational security be held hostage by ‘zombie’ tokens while we wait for those utility cases to arrive.

Ensuring that the baseline quorum (the 150m floor) remains high is our best defense against the consolidation of power you mentioned. It ensures that even with a dynamic quorum, a small group of insiders still can’t bypass the community’s check-and-balance.

Vote: FOR

Quorum should reflect the voting power that actually participates in governance. Moving to a delegated voting power-based quorum better aligns quorum with real participation levels and reduces the risk of governance gridlock as token supply grows.

I also support allowing proposal cancellation during the pending period, which avoids unnecessary governance cycles if issues are identified before voting starts.

1 Like

Still voting FOR. My stance hasn’t changed, DVP makes sense, and the addition of proposal cancellation is a great quality of life update.

Voting FOR (on Tally).
Basing quorum on active delegates is a great way forward.

Also, a huge fan of getting the on-chain cancel button. Forcing the DAO to vote down a flawed proposal that even the creator wants to pull was always a massive waste of everyone’s time.

The DVP-quorum approach is interesting as a mechanism for reducing governance
capture risk without raising participation requirements (which tend to entrench
large holders who can afford to vote on every proposal).

One concern worth surfacing: if the quorum threshold is set relative to
participating delegates rather than total token supply, you get a smaller
reference frame — which makes it easier to reach quorum with a coordinated
minority. The classic attack is a proposer who times their vote when large
“good-faith” delegates are inactive (conference weeks, holidays, etc.).

Has the proposal modeled this against Arbitrum’s historical delegate
participation patterns? Knowing the variance in participation rate across
the last 12 months would help calibrate the right threshold. Low-variance
systems can set tighter quorums safely; high-variance systems need buffers.