Is Web3 DAO a false proposition? A deep dive into why Bonk was targeted by governance attacks.

Author: Biteye；Source: X，@BiteyeCN

What? Attackers can use $4 million to move $20 million from a DAO's treasury?

Early yesterday morning, the BONK DAO suffered a governance attack. Attackers exploited BONK's low governance threshold, simple majority voting mechanism, and lack of Timelock delayed execution design flaws to attempt to transfer treasury assets through malicious proposals.

So, how exactly is the governance process of a mature DAO designed?

Why do protocols like Aave, ENS, and Lido mitigate risk through multi-layered governance, while BONK is more vulnerable to governance attacks? This article will break down the DAO governance process into five stages: Proposal → Community Discussion → Snapshot Temperature Testing → On-Chain Voting → Timelock Execution. 1. Proposal Stage In the DAO ecosystem, the proposal stage is the starting point for all governance actions. A formal proposal typically covers protocol parameter adjustments, new asset listings, Treasury fund allocation, contract upgrades, incentive plan modifications, and governance rule restructuring. To balance governance efficiency and prevent spam proposals, various protocols have set different token holding or delegation thresholds for initiators: Aave: High threshold, requiring approximately 0.5% of AAVE voting rights. ENS: Execution-type proposals require 100,000 ENS delegation, and social proposals require approximately 10,000 ENS. Lido: Requires prior forum discussion and a minimum of 1,000 LDO. BONK: The barrier to entry is low, requiring only 100M Bonk ($425.99 USD), which is why Bonk is subject to governance attacks. 2. Community Discussion Phase (Governance Forum) Community discussion is a preliminary stage before the formal vote. Most established DAOs require proposals to first enter the official governance forum for public discussion: Proposal Disclosure and Feedback Collection: Allowing the community to understand the proposal content in advance and raise questions. Optimizing the Proposal: Adjusting parameters and implementation details based on feedback to improve the quality of the proposal. Filtering Low-Quality Proposals: Preventing Malicious or Immature Proposals from Directly Entering On-Chain Voting. However, not all DAOs have this stage. For example, BONK DAO does not have a formal Governance Forum process; it primarily submits BIP proposals and votes directly through Solana Realms. Mature DAOs typically form governance firewalls through multi-layered mechanisms such as Governance Forum, Snapshot, and Timelock. Meme DAOs like BONK tend to use direct voting to improve decision-making efficiency but also lowers the attack threshold. 3. Snapshot Temperature Testing (Off-chain Voting) Before formal on-chain voting, many DAOs conduct off-chain voting via Snapshot as a test of community willingness. This stage is typically called: **Temperature Check**. Its main functions include: **Reducing Voting Costs:** Off-chain voting requires no gas payment, allowing community members to participate at a low cost. **Early Consensus Verification:** Observing whether proposals have sufficient support to prevent immature solutions from being directly implemented on-chain. **Optimizing Proposal Direction:** Adjusting proposal details based on voting results and community feedback. If the Snapshot temperature test fails, it usually means that the community has not reached sufficient consensus, and the proposal will be terminated directly or returned for modification, without entering the formal on-chain voting stage. Bonk DAO was easily breached by "thieves" precisely because it lacked this crucial security measure of using Snapshot technology. 4. Formal On-chain Governance After community discussion and the Snapshot temperature test (if adopted by the project), the proposal will enter the formal on-chain governance stage. This phase is executed by the on-chain governance framework, such as: Governor Contract (common in the Ethereum ecosystem) Aragon (DAO governance framework) Realms (Solana governance framework) To ensure the seriousness and security of on-chain voting, smart contracts strictly verify the following two core indicators during settlement. Minimum Participation Threshold: As a security red line for DAO governance, Quorum stipulates the minimum total number of votes required for a proposal to have legal validity. If the total number of tokens participating in the vote does not reach the required threshold, the proposal will be rejected even if the number of votes in favor is as high as 100%. For example, in a token model with a total supply of 100 million, if Quorum is set to 5%, at least 5 million tokens are needed to participate in the vote. The Quorum settings of major DAOs vary: Lido sets a relatively high threshold of 5% of the total supply (approximately 50 million LDOs). Aave (approximately 2% of the total supply) and ENS and BONK (1% of the total supply) are relatively conventional. Optimism, on the other hand, is more flexible, dynamically adjusting between 3% and 30% depending on the proposal type. Voting Passage Conditions: After reaching the Quorum (minimum participation threshold), a proposal must also meet a certain percentage of approvals to be officially passed. Most DAOs use a simple majority system for daily governance: YES > NO. However, for major changes involving the core rules of the protocol, such as amending the ENS constitution, adjusting key governance parameters, or upgrading the underlying protocol, DAOs typically use a supermajority system. This requires a higher percentage of votes, such as 2/3 (approximately 66.7%) or more in favor; or an even higher percentage of support. This mechanism prevents a small number of large holders from using a simple majority to push for major changes that affect the entire protocol. Another important reason why BONK is vulnerable to governance attacks is its relatively lenient DAO governance parameters. The minimum participation threshold is only 1% of the total supply in BONK voting rights to enter into a valid vote. Furthermore, the voting pass condition uses a simple majority: YES > NO. This means that attackers do not need to acquire a vast majority of BONK; they only need to control approximately 1% of the supply and gain majority support for their proposal to drive governance implementation. 5. Timelock Delayed Execution and On-Chain Execution Mature DAOs typically do not execute proposals immediately after a vote passes, but instead incorporate a Timelock mechanism: **Vote Passed → Timelock Waiting → On-Chain Execution** The purpose of Timelock is to provide a buffer period for the community, allowing members to: Inspect the proposal code; Discover potential attack risks; Organize opposition or initiate emergency measures. After the waiting period, the proposal will be automatically executed by the governance framework. A key reason for the governance attack on Bonk was the lack of a standard Timelock delayed execution mechanism in its governance process: vote passed → direct execution. In the BIP #76 governance attack, the attackers exploited the lack of a delayed execution mechanism in the Bonk governance process to quickly execute malicious operations after the proposal was passed. In conclusion, the BONK governance attack has exposed a long-standing problem in DeFi: Is a DAO truly necessary if no one participates in governance? When community governance becomes a performance, is a DAO truly necessary? In fact, the lack of governance participation makes the DAO architecture more of an inefficient burden than a guarantee of the protocol. When true governance power is held by only a very few, while most users are merely silent spectators, deliberately pursuing nominal decentralization increases decision-making costs and exposes the protocol to significant security vulnerabilities. Perhaps we should acknowledge that not all projects need a DAO. Just like in the mature business world, allowing core decision-makers to control the overall direction often leads to more efficient execution and stronger risk resistance. After the decentralization frenzy, we need to return to the basics: the robustness of a protocol often depends on clear accountability and a dedicated execution team, rather than a sham public vote.