Web3 DAOs often present themselves as open governance systems where every token holder can participate. In practice, participation and influence are not the same thing.
A small holder may have the right to vote, but large token holders and active delegates may have enough voting power to decide the final outcome.
This raises a simple question:
If a user studies a proposal, finds budget or technical problems, and votes against it, what meaningful value does that vote have when a few large delegates can still pass the proposal?
The Arbitrum Security Program is a useful case study. It expands the previous audit program into a 12 month security initiative covering AI assisted screening, human audits, bug bounties, and oversight by the ArbitrumDAO Security Council.
The stated budget is approximately 7.8 million, including 1.76 million USDC and 25 million ARB at the stated market prices. Around 1.2 million is linked to earlier commitments, while approximately 6.6 million is intended for new security work.
The security objective is valuable. Smart contract audits and bug bounty programs can reduce risks for builders and users. However, a good objective does not remove the need for clear budgets, independent review, and enforceable accountability.
Assume a user holds 100 ARB.
The user reads a proposal and votes against it because:
The budget is not clearly separated.
Technical responsibilities are unclear.
The Foundation has too much discretion.
There is no clear milestone or post vote review.
Security Council or bug bounty costs may overlap with other funding.
The proposal still passes because large delegates vote in favour.
Technically, the user’s 100 ARB vote is counted. The tokens remain in the wallet, and the vote becomes part of the public record.
But practical decision making power may be almost zero if the opposing delegated voting power is measured in millions of ARB.
This is the central weakness of token weighted governance:
Every eligible voter may have a voice, but every voice does not have comparable influence.
Small holders may provide participation and quorum, while large delegates provide the final outcome.
Delegates are not formal employees. However, when a DAO pays delegates through an incentive program, they become professional governance representatives in practical terms.
The DAO should therefore expect more than a simple vote.
A responsible delegate should:
Read and understand the proposal.
Review the budget.
Identify technical and execution risks.
Disclose conflicts of interest.
Publish a clear voting rationale.
Ask questions before voting.
Monitor performance after approval.
Explain whether the proposal delivered the promised results.
A generic statement such as “Voting FOR because security is important” is not enough.
Security may be important, but a governance rationale must also explain:
Why this budget is reasonable.
Why the structure is technically suitable.
What risks remain unresolved.
What conditions should be monitored.
What action should be taken if milestones fail.
Voting with a whale is not automatically wrong. A delegate may independently reach the same conclusion as a large token holder.
The real question is:
Can the delegate explain the decision with evidence, or is the delegate simply repeating the preference of a powerful voting bloc?
A high approval rate does not automatically prove corruption or collusion.
Many proposals pass because:
The proposal provides genuine ecosystem value.
Opposition voters do not participate.
Delegates have limited time.
Security and growth narratives make opposition difficult.
Large delegates already control substantial voting power.
Delegates prefer continuity over delay.
Questions are raised but not converted into binding conditions.
Still, when almost every proposal passes, the community should examine the system more carefully.
Important questions include:
How much voting power is controlled by the largest delegates?
How many unique holders actually voted?
What percentage of circulating supply participated?
How often do compensated delegates publish independent dissent?
How many proposals changed because of delegate questions?
Are delegates paid for quality analysis or mainly for voting activity?
What happens when approved milestones are missed?
Can a small holder meaningfully challenge a large delegated bloc?
A proposal passing does not prove that every concern was resolved. It only proves that the voting threshold was reached.
The Arbitrum Security Program has a strong objective, but its governance design needs careful review.
The program combines:
AI assisted pre audit screening.
Human conducted audits.
Arbitrum bug bounty work.
Security Council oversight.
Builder audit subsidies.
A multi million dollar budget.
The first concern is budget separation.
The program should clearly state the minimum amount reserved for:
Builder audits.
AI screening.
Bug bounty payments.
Security Council compensation.
Administration.
Future commitments.
The DAO should also explain how these expenses relate to the existing Foundation budget.
Without this reconciliation, the community may not know whether it is:
Funding genuinely new work.
Continuing earlier commitments.
Moving money between categories.
Duplicating costs already covered elsewhere.
The program also needs clear rules for:
Idle fund deployment.
Risk limits.
Auditor selection.
Milestone payments.
Reporting frequency.
Failed deliverables.
Remediation verification.
Changes made through an optimistic approval process.
A 14 day objection period is useful only when delegates and community members actively monitor it and have enough information to respond.
What Delegates Should Publish
Area | Minimum disclosure |
|---|---|
Voting | Vote, voting power, rationale, and conflict disclosure |
Budget | Pillar wise allocation, spent amount, and remaining balance |
Security | Number and severity of findings and remediation status |
Selection | Eligibility criteria, auditor matching, and rejection reasons |
Performance | Milestones, delays, failed deliverables, and corrective action |
Compensation | Payment formula, attendance, research quality, and review results |
A delegate should not receive payment merely for being present.
The community should be able to see whether the delegate:
Identified risks before approval.
Asked useful questions.
Improved the final proposal.
Monitored the project after approval.
Reported failures honestly.
Changed their view when new evidence appeared.
Delegate compensation should depend on:
Independent research.
Clear voting rationale.
Risk identification.
Conflict disclosure.
Community engagement.
Post vote monitoring.
Voting participation should be only one part of the evaluation.
Every vote should answer four questions:
What decision was made?
What evidence supports the decision?
What risks remain unresolved?
What will be monitored after the vote?
Large treasury and protocol proposals should require more than a delegate majority.
Possible safeguards include:
A small holder review stage.
A community approval layer.
Minority protection thresholds.
A second vote after public questions.
A delay before execution.
The DAO could consider:
Voting power caps.
Diminishing voting power above a specific threshold.
Multiple independent approval groups.
Better delegation tools.
Transparent concentration dashboards.
Each program pillar should have:
A defined allocation.
A spending limit.
A responsible owner.
Quarterly reporting.
A clear unused fund policy.
Every major proposal should have a 30, 60, or 90 day review.
The review should check:
Whether the budget was used as approved.
Whether milestones were delivered.
Whether security findings were fixed.
Whether the program produced measurable value.
Whether further funding is justified.
Weak rationale:
Voting FOR because security is important.
Stronger rationale:
I support stronger security for Arbitrum, but I expect quarterly reporting on pillar wise spending, Foundation budget reconciliation, builder audit allocation, Security Council costs, and the status of remediated findings. If these disclosures are not delivered, I will oppose any extension or material change.
A delegate voting against the proposal could write:
I support security spending, but I cannot support a budget that does not clearly ring fence builder audit funds or reconcile bug bounty and Security Council costs with the Foundation budget. I would support a revised proposal with defined allocations, risk controls, and independent reporting.
This is the difference between a vote and a governance decision.
The issue is not that delegates vote with whales.
The issue is whether they exercise independent judgment and remain accountable after receiving compensation and delegated voting power.
A DAO should not treat small holders as a source of quorum while allowing a few delegates to control outcomes without detailed explanations.
Token weighted voting can provide a useful governance foundation, but it requires:
Transparent delegates.
Minority protection.
Measurable responsibilities.
Independent review.
Budget discipline.
Outcome based compensation.
The most important question is simple:
If a delegate receives payment to represent the community, is the DAO paying for a vote, or is it paying for independent research and responsible decision making?
The answer should be visible in every vote rationale, every monthly report, and every post vote review.
A small holder’s vote may not always change the outcome. But the system should still make that vote meaningful by giving the voter transparency, representation, accountability, and a genuine way to challenge concentrated power.