Is Web3 DAO a false proposition? Deep dive into why Bonk was attacked by governance

Author: Biteye; Source: X, @BiteyeCN

What? An attacker uses $4 million to pry open a $20 million DAO treasury?

Early yesterday morning, BONK DAO suffered a governance attack. The attacker exploited design flaws in BONK, such as low governance thresholds, a simple majority voting mechanism, and the lack of a Timelock delay for execution, attempting to transfer treasury assets through a malicious proposal.

So, what does the governance process of a mature DAO actually look like? Why do protocols like Aave, ENS, and Lido mitigate risk through multi-layer governance, while BONK is more vulnerable to governance attacks?

This article breaks down the DAO governance process into five stages: Proposal → Community Discussion → Snapshot Temperature Check → On-chain Voting → Timelock Execution

1. Proposal Stage

In the DAO ecosystem, the proposal stage is the starting point of all governance actions.

The core content of a formal proposal typically covers protocol parameter adjustments, onboarding new assets, treasury fund allocation, contract upgrades, incentive program modifications, and governance rule restructuring.

To balance governance efficiency and prevent spam proposals, major protocols set different token holding or delegation thresholds for proposers:

• Aave: High threshold, requiring approximately 0.5% of AAVE voting power.
• ENS: Executive proposals require 100,000 ENS delegated, social proposals require approximately 10,000 ENS.
• Lido: Requires prior discussion on the forum and meeting at least 1,000 LDO threshold.
• BONK: Low threshold, requiring only 100M Bonk ($425.99), which is also why BONK suffered a governance attack.

2. Community Discussion Stage (Governance Forum)

Community discussion is the pre-screening session before formal voting. Most mature DAOs require proposals to first enter the official governance forum for public discussion to complete:

• Plan disclosure and opinion collection: Allow the community to understand the proposal in advance and raise questions.
• Optimize the proposal plan: Adjust parameters and execution details based on feedback to improve proposal quality.
• Filter out low-quality proposals: Prevent malicious or immature proposals from directly entering on-chain voting.

However, not all DAOs have this stage. Taking BONK DAO as an example, BONK does not have a formal Governance Forum process; it mainly submits BIP proposals and votes directly through Solana Realms.

Mature DAOs typically form governance firewalls through multi-layer mechanisms such as Governance Forum, Snapshot, and Timelock, while Meme DAOs like BONK tend to vote directly to improve decision-making efficiency, but also lower the attack threshold.

3. Snapshot Temperature Check (Off-chain Voting)

Before formal on-chain voting, many DAOs first conduct off-chain voting through Snapshot as a test of community sentiment.

This stage is usually called: Temperature Check

Its main functions are:

• Reduce voting costs: Off-chain voting does not require gas fees, allowing community members to participate at low cost.
• Verify consensus in advance: Observe whether the proposal receives enough support to prevent immature proposals from directly entering on-chain execution.
• Optimize proposal direction: Adjust proposal details based on voting results and community feedback.

If the Snapshot temperature check fails, it usually means the community has not formed sufficient consensus, and the proposal will be directly terminated or returned for modification, and will not enter the formal on-chain voting stage.

It is precisely because BONK DAO did not have this important anti-theft insurance layer of Snapshot that the "thief" was able to break in easily.

4. Formal On-chain Voting (On-chain Governance)

After community discussion and Snapshot temperature check (if adopted by the project), the proposal enters the formal on-chain governance stage.

This stage is executed by an on-chain governance framework, such as:

• Governor contract (common in the Ethereum ecosystem)
• Aragon (DAO management framework)
• Realms (Solana governance framework)

To ensure the seriousness and security of on-chain voting, the smart contract strictly checks the following two core indicators during settlement.

Minimum Participation Threshold: As a safety red line for DAO governance, Quorum stipulates the minimum total voting participation required for a proposal to be legally valid.

If the total number of tokens participating in the vote does not meet the threshold, even if the approval rate is 100%, the proposal will be directly rejected.

For example, in a token model with a total supply of 100 million, if Quorum is set to 5%, at least 5 million tokens need to participate in voting. The Quorum settings of major mainstream DAOs vary:

• Lido has set a relatively high threshold of 5% of total supply (approximately 50 million LDO)
• Aave (approximately 2% of total supply) and ENS, BONK (1% of total supply) are relatively conventional
• Optimism is more flexible, dynamically adjusting between 3% and 30% depending on the proposal type.

Vote Passing Condition: After reaching the Quorum (minimum participation threshold), the proposal also needs to meet the corresponding approval ratio to be formally passed.

Most DAOs use Simple Majority for daily governance, i.e., YES votes > NO votes.

However, for major changes involving core protocol rules, such as modifying the ENS constitution, adjusting key governance parameters, or upgrading the underlying protocol, DAOs usually adopt Super Majority.

Requiring a higher proportion of supporting votes, e.g., more than 2/3 (about 66.7%) approval; or an even higher proportion.

This mechanism prevents a few large token holders from pushing through major changes affecting the entire protocol via simple majority.

Another important reason BONK suffered a governance attack is its relatively loose DAO governance parameters.

The minimum participation threshold only requires 1% of the total BONK supply voting power for a valid vote. And the vote passing condition uses a simple majority system: YES > NO

This means the attacker does not need to control the vast majority of BONK; they only need to control about 1% of the supply and ensure their proposal receives majority support to push through governance execution.

5. Timelock Delayed Execution and On-chain Execution

Mature DAOs usually do not execute proposals immediately after they pass, but instead add a Timelock mechanism: Vote Pass → Timelock Wait → On-chain Execution.

The role of Timelock is to provide a buffer period for the community, allowing members to:

• Check the proposal code;
• Discover potential attack risks;
• Organize opposition or initiate emergency measures.

After the waiting period ends, the proposal is automatically executed by the governance framework.

Another important reason BONK suffered a governance attack is that its governance process lacks a standard Timelock delayed execution step: Vote Pass → Immediate Execution

In the BIP #76 governance attack incident, the attacker exploited the lack of a delayed execution mechanism in BONK's governance process to quickly execute malicious operations after the proposal passed.

Final Thoughts

The BONK governance attack has exposed a long-standing problem in DeFi: If no one participates in governance, does DAO really need to exist?

When community governance becomes mere performance, is DAO truly necessary? In fact, the coldness of governance participation makes the DAO structure more of an inefficient burden than a protocol safeguard.

When real governance power is held only by a very few, and most users are silent onlookers, the deliberate pursuit of nominal decentralization not only increases decision-making costs but also exposes the protocol to huge security vulnerabilities.

Perhaps we should admit that not every project needs a DAO. Just like in the mature business world, letting core decision-makers steer the main direction often brings more efficient execution and stronger risk resistance. After the mania of decentralization, we need to return to fundamentals: the robustness of a protocol often relies on clear accountability and a focused execution team, rather than a hypocritical universal vote.