The Anticapture Framework evaluates DAO governance security by mapping common attack vectors and defining protective metrics. It translates complex risks into measurable indicators, enabling DAOs to anticipate vulnerabilities before they escalate. By assigning risk levels (low, medium, high), it categorizes each DAO into stages of security maturity.
Shutter DAO (0x36) was susceptible to governance capture through which a malicious actor could use the governance system to drain the treasury. The combination of 1) low market capitalization, 2) low active voting power, 3) absence of security guardrails, 4) no proposal spam protection and 5) relevant treasury in non-governance token, created a profitable and easy to execute attack vector.
Treasury stablecoin reserves totalled approximately $3M. Quorum was achievable for approximately $100k in token purchases, a ratio exceeding 30x.
We identified this vulnerability in early 2025 during active governance security work within the Ethereum ecosystem. After more than a year of engagement with stakeholders, multiple mitigation approaches considered and discarded, and a controlled simulation validating the attack path, we coordinated an emergency mitigation with a small group of aligned delegates. In line with responsible security practice, we disclosed publicly only after the mitigation was in place.
Shutter DAO (0x36) operates on a governance implementation built using Decent’s framework and the Azorius module. The token holder voting mechanism functions as designed: proposals are submitted, votes are cast, outcomes are executed. The configuration contained a critical gap in its defense parameters.
Governance parameters at the time of identification:
Proposal threshold: 1 SHU
Quorum requirement: 3% of total supply (30,000,000 SHU = ~100K USD)
Voting delay: (0 blocks)
Voting period: ~3 days (21,600 blocks)
Timelock: None (0 blocks)
Proposal limits: None
Hit-and-run prevention: None
Veto mechanism: None
An actor could submit unlimited proposals with 1 SHU. With sufficient token accumulation to meet quorum independently, they could pass any proposal, including direct treasury withdrawal.
We validated the following attack sequence in a controlled simulation environment using a forked state of the live governance contracts.
Phase 1: Voting power accumulation. Purchase sufficient SHU on secondary markets to meet quorum independently. Current liquidity and market capitalization make this economically feasible at approximately $100k. We tested this by acquiring SHU through open market purchases, reaching 2.2 million tokens in 2 days without price impact, and since then the token price has dropped 30%. Showing that accumulation to the 30 million quorum threshold was operationally practical.
Phase 2: Proposal spam. Submit multiple proposals simultaneously or in rapid succession. Each proposal requires only 1 SHU to create. No proposal limits, rate limiting, or delay mechanisms exist to prevent this behavior. A spam-proposal strategy imposes a very high defense cost on legitimate token holders attempting to coordinate a response: the attacker needs only one proposal to succeed, while defenders must vote against every single one.
Phase 3: Treasury extraction. With quorum met through owned tokens, the attacker controls vote outcomes. Proposals transferring stablecoins from treasury to attacker-controlled addresses pass without intervention. No veto mechanism exists to block execution. No timelock exists to delay execution after a vote passes.
The economic incentive is significant: approximately $3M in stablecoin reserves against an approximately $100k cost of capture.
This vulnerability was identified in early 2025, by expanding Anticapture's coverage and integrating new governance systems. At the time, the DAO was even more exposed, with +$6m in liquid treasury.
Upon identification, we disclosed the risk privately to key members of the Shutter community. The response was measured: the team assessed that they had sufficient defensive capability. We communicated that our simulations showed otherwise — no defensive cards were visible on-chain that would prevent the attack sequence we had validated.
Some time after this initial disclosure, a delegation of approximately 60 million SHU was consolidated into a single wallet, making it the largest delegate in the DAO. This was a meaningful defensive improvement. A large aligned voter capable of meeting quorum in opposition provides a real deterrent. However, this approach has structural limitations:
It depends on a single wallet being available and responsive to every malicious proposal.
A spam-proposal strategy can exhaust even a well-resourced defender: the attacker submits many proposals, and the defender must vote against all of them. Only possible defense would be to have a script running with the private key, which also has it's own risks.
If the wallet is compromised or the key holder is unavailable during a voting period, the defense disappears entirely.
It creates a single point of failure in what should be a distributed governance system.
White hat capture considered and discarded. During this period, we evaluated a more aggressive approach: executing the attack ourselves as a white hat operation. The plan would involve buying 30M SHU tokens, changing the admin of the DAO, deploying a new instance of the DAO with corrected governance parameters, and returning admin. We chose not to proceed. The lack of support we found in the ecosystem to address the vulnerability through established channels left us without a clear path forward, and legal uncertainty around unauthorized capture — even with intent to return — created unacceptable risk. We had already disclosed to multiple parties that we understood the attack vector, making an anonymous operation impractical.
Continued stakeholder engagement. We continued discussing the vulnerability with select individuals in the Ethereum ecosystem, seeking guidance on the best mitigation path: one that would not require us to take control of the DAO ourselves, that would survive public disclosure, and that could be implemented through legitimate governance.
In November 2025, at DevConnect in Buenos Aires, we were able to have more direct conversations with key members of the Shutter community. These conversations produced what we had been missing: introductions to aligned delegates with governance expertise, operational knowledge of Shutter DAO, and willingness to coordinate on a security response.
This was the turning point. After more than a year of knowing the vulnerability existed and searching for a viable path, we had a group capable of executing the mitigation.
The decision to act was driven by two factors.
First, the economic context had not improved. Treasury value remained high, token price decreased even more, and the governance configuration remained unchanged since deployment. The vulnerability is not theoretical — it was economically actionable, and had been for over a year.
Second, we were not willing to wait indefinitely for a funding mechanism. Previous attempts to establish a path for compensated security work had not moved forward. We decided to act in the best interest of Ethereum's security and pursue retroactive compensation through proper governance channels. The alternative — continuing to sit on a known, exploitable vulnerability — was not acceptable.
Why the “Security Council” Approach. We evaluated multiple mitigation strategies. The critical constraint was this: any mitigation that changes governance rules (proposal thresholds, proposer gating, voting parameters) only takes effect after the proposal passes and executes. During the voting period, the DAO remains fully exposed under the old rules. If the vulnerability details become public at the moment of proposal submission — which they do, since the proposal itself signals that something is wrong — an attacker has a window to exploit before the fix is in place.
The Security Council guard changes this dynamic. Once proposed, the guard provides retroactive protection: even if an attacker submits malicious proposals during the voting period, the guard can veto those proposals after it is installed. The security council doesn’t just prevent future attacks — it can neutralize attacks that are already in flight, provided the Security Council proposal was submitted before those attack proposals.
This is why we submitted a single proposal containing both the guard installation and a timelock, rather than a multi-proposal sequence. And this is why we prepared all communication artifacts in advance and released them simultaneously with the proposal: we could afford to go public because the mitigation, once passed, would cover the exposure window.
The SecurityCouncilAzorius contract implements the IGuard interface from the Zodiac framework. When installed on the Azorius governance module via setGuard(), it interposes on every proposal transaction at execution time.
How it works:
A proposal passes the voting period and enters the timelock window (2 days, added by the same proposal that installs the guard).
When someone attempts to execute the proposal, Azorius calls checkTransaction() on its configured guard.
The guard computes the transaction hash using Azorius.getTxHash() and checks it against its veto registry.
If the hash is vetoed, execution reverts with TransactionVetoed. If not, execution proceeds normally.
Council capabilities:
vetoProposal(proposalId) — vetoes all transactions in a proposal
unvetoProposal(proposalId) — clears veto on all transactions in a proposal
vetoTx(txHash) / unvetoTx(txHash) — fine-grained control over individual transaction hashes
multicall(calls) — batch operations atomically
Design decisions:
Veto state is stored by transaction hash, not proposal ID. This means if two proposals contain identical calldata, vetoing one blocks both. The council must enumerate active proposals before any veto action.
The council address uses OpenZeppelin Ownable. Rotation is done via transferOwnership() — no redeployment needed. renounceOwnership() is disabled to prevent accidentally leaving the guard without a council.
The guard is a veto mechanism, not a gatekeeper: it can block execution, but it cannot modify proposals or force outcomes. Voting and proposing remain fully permissionless.
Audit. The contract was audited by Cyfrin. The audit returned only informational notes. All were addressed and the final version was approved.
Veto guard contract for Azorius DAO proposals with council-controlled safety - shutter-security-council/audits at main · blockful/shutter-security-council
With the guard contract developed, audited, and ready for deployment, we prepared the full execution sequence.
Veto guard contract for Azorius DAO proposals with council-controlled safety - blockful/shutter-security-council
Preparation (before going public):
Deploy a placeholder 1-of-1 Safe as the initial council address.
Deploy SecurityCouncilAzorius with the council Safe and Azorius module as constructor arguments.
Verify the contract on Etherscan.
Prepare the governance proposal, forum post, delegate messages, and public communications.
Execution (simultaneous):
Submit the Security Council proposal on Decent. The proposal contains two atomic transactions:
Azorius.updateTimelockPeriod(14400) — introduces a 2-day timelock (~14,400 blocks at ~12s/block)
Azorius.setGuard(guardAddress) — installs the Security Council guard
Publish the forum post with a high-level description of the vulnerability, the mitigation plan, and the recommendation.
Send private messages to target delegates with full vulnerability details and council participation requests.
Council formation (during voting period):
Collect confirmed addresses from delegates who agree to participate.
Upgrade the placeholder Safe from 1-of-1 to the full council multisig with appropriate threshold.
Verify multisig configuration.
Once the proposal passes voting and the timelock elapses, the guard is installed and active. From that point, the council can veto any malicious proposal, including any that were submitted during the voting period.
The stakeholder group coordinating the mitigation:
Delegate | Address |
Kleros Labs | 0xffFA76e332cA7afaae3931cb5d513B7fd681C4CF |
5pence | 0xe52C39327FF7576bAEc3DBFeF0787bd62dB6d726 |
d0z3y | 0xDffDb9BeeA2aB3151BcBcf37a01EE8726F22ed94 |
Mikko Ohtamaa | 0x61C2dAE896f93e5f0f10425914CE7868eE8A0e44 |
Jacob Czepluch | 0x06c2c4dB3776D500636DE63e4F109386dCBa6Ae2 |
blockful | 0x1F3D3A7A9c548bE39539b39D7400302753E20591 |
Lanski | 0xB6647e02AE6Dd74137cB80b1C24333852E4AF890 |
DAOplomats | 0x057928bc52bD08e4D7cE24bF47E01cE99E074048 |
The Security Council proposal changes two parameters and leaves voting mechanics untouched.
Parameter | Before | After |
|---|---|---|
Timelock | 0 blocks (none) | ~2 days (14,400 blocks) |
Guard | None | SecurityCouncilAzorius |
Voting period | ~3 days (21,600 blocks) | Unchanged |
Execution window | ~3 days (21,600 blocks) | Unchanged |
Proposal threshold | 1 SHU | Unchanged |
Quorum | 3% of total supply | Unchanged |
Before the Security Council proposal, a passed proposal could be executed the instant voting ended. No review window. No safety net.
The 2-day timelock creates a window between a proposal passing and becoming executable. This window adds more time for the security council reviewing the proposal and veto if necessary. The guard enforces the veto at execution time.
The proposal threshold and other voting parameters remain unchanged in this proposal. Hardening those parameters (raising the proposer threshold, extending the execution window) is recommended as a follow-up through normal governance, now that the council provides a safety net during the transition.
This is a centralizing solution. A small group of delegates holds veto power over governance execution while the DAO is stabilized. We are not framing this as anything other than what it is: a necessary tradeoff to protect the treasury and allow proper governance upgrades to be discussed in the open.
The alternative was leaving the DAO economically exposed with a validated attack path and a ROI exceeding 30x. Emergency response differs from permanent architecture.
Veto any proposal before execution
Unveto proposals that were incorrectly blocked
Submit proposals (unless they separately hold voting power)
Modify proposal outcomes or vote counts
Change governance parameters unilaterally
Access treasury funds directly
On council removal: The guard can be removed through a governance proposal calling Azorius.setGuard(address(0)). However, this removal is itself subject to the council’s veto authority — the council could veto a proposal to remove itself. There are no Safe managers beyond the Azorius module that could bypass this. This is the fundamental trust assumption: the council members are selected for their alignment with the protocol, their reputation in the ecosystem, and their demonstrated commitment to Shutter’s mission. The centralization is real, and the community’s recourse is the accountability and reputation of the individuals holding these seats.
Following our security agenda, we disclosed publicly only after the mitigation was in the governance pipeline and structured to survive the disclosure itself. Publishing vulnerability details before neutralization would have advertised the attack vector to adversarial actors and created a race condition between coordination and exploitation.
Before proposal: No public communication. All coordination was private with the stakeholder group and select counsel.
At proposal submission: Forum post and delegate messages released simultaneously. High-level vulnerability description without step-by-step exploit instructions.
TL;DR Shutter DAO (0x36) has a governance vulnerability where the cost to attack the DAO (approximately $100K to reach quorum) is significantly lower than the treasury value ($3M+). The current configuration allows any address holding 1 SHU to submit unlimited proposals with zero timelock, creating an asymmetric attack surface: an attacker needs only ONE proposal to pass, while defenders must vote NO on every malicious proposal.
![[SECURITY] Emergency Governance Hardening - Attack Prevention](https://img.paragraph.com/cdn-cgi/image/format=auto,width=384,quality=85/https://storage.googleapis.com/papyrus_images/4081345e67a78eebbf55423c8a775fade9da5e4ef33402528efb87344c0d7e55.png)
Exceptions were made for counsel on how to proceed: Loring Harkness from Brainbot, who provided Shutter-specific protocol context.
After neutralizing the acute risk, we recommend the community explore:
Proposal threshold increase. Raising the required proposer weight from 1 SHU to a meaningful amount (e.g., 100,000 SHU, 0.01% of supply) eliminates spam while remaining accessible to serious participants. Based on delegated voting power, not token balance.
Execution window extension. With the 2-day timelock added, extending the execution window from 3 days to 7 days gives legitimate proposers sufficient time to execute without risk of proposals expiring over weekends or holidays.
Azorius module enhancements. Rate limiting on proposal creation, proposal staging windows, and time-delayed execution add defense-in-depth beyond the council’s veto capability.
Broader veto mechanisms. Enabling intervention without permanent centralization of veto authority. The current council is a temporary measure; the long-term goal is governance architecture that is resilient by design, not by delegation.
The objective is designing a resilient system while the DAO is not under active attack. Security creates the conditions for sustainable decentralization.
This work is part of blockful’s security agenda. Our purpose is aligned with the Ethereum ecosystem: we are committed to protecting not only the funds present in it, but every piece of infrastructure that makes it what it is.
Shutter’s research on encrypted mempools and MEV protection positions it as infrastructure-grade technology within the Ethereum ecosystem. Governance vulnerabilities represent structural risks requiring systematic identification, quantification, and mitigation.
This pattern repeats across protocol lifecycles: governance designs adequate at one treasury scale fail at another.
After execution: Full technical disclosure. Safe to publish because the guard is active and can veto any attack submitted after the vulnerability became public knowledge.
blockful blogHow $3.6M in Liquidations Made $BAL Melt 50% in 2 Hours
Once you become large enough, price ceases to be an external signal and becomes a reflection of yourself.
blockful blogSporkDAO's 2026 Board Election: A Governance Security Analysis
And the attacker... apparently didn't want to actually attack or capture the DAO.
blockful blogLessons from Arbitrum DAO: The Architecture of Governance
Difficult actions are often the price of necessary change.
Research that maps DAO governance risks, identifies governance capture vectors, and provides actionable governance security insights.
The Anticapture Framework evaluates DAO governance security by mapping common attack vectors and defining protective metrics. It translates complex risks into measurable indicators, enabling DAOs to anticipate vulnerabilities before they escalate. By assigning risk levels (low, medium, high), it categorizes each DAO into stages of security maturity.
Shutter DAO (0x36) was susceptible to governance capture through which a malicious actor could use the governance system to drain the treasury. The combination of 1) low market capitalization, 2) low active voting power, 3) absence of security guardrails, 4) no proposal spam protection and 5) relevant treasury in non-governance token, created a profitable and easy to execute attack vector.
Treasury stablecoin reserves totalled approximately $3M. Quorum was achievable for approximately $100k in token purchases, a ratio exceeding 30x.
We identified this vulnerability in early 2025 during active governance security work within the Ethereum ecosystem. After more than a year of engagement with stakeholders, multiple mitigation approaches considered and discarded, and a controlled simulation validating the attack path, we coordinated an emergency mitigation with a small group of aligned delegates. In line with responsible security practice, we disclosed publicly only after the mitigation was in place.
Shutter DAO (0x36) operates on a governance implementation built using Decent’s framework and the Azorius module. The token holder voting mechanism functions as designed: proposals are submitted, votes are cast, outcomes are executed. The configuration contained a critical gap in its defense parameters.
Governance parameters at the time of identification:
Proposal threshold: 1 SHU
Quorum requirement: 3% of total supply (30,000,000 SHU = ~100K USD)
Voting delay: (0 blocks)
Voting period: ~3 days (21,600 blocks)
Timelock: None (0 blocks)
Proposal limits: None
Hit-and-run prevention: None
Veto mechanism: None
An actor could submit unlimited proposals with 1 SHU. With sufficient token accumulation to meet quorum independently, they could pass any proposal, including direct treasury withdrawal.
We validated the following attack sequence in a controlled simulation environment using a forked state of the live governance contracts.
Phase 1: Voting power accumulation. Purchase sufficient SHU on secondary markets to meet quorum independently. Current liquidity and market capitalization make this economically feasible at approximately $100k. We tested this by acquiring SHU through open market purchases, reaching 2.2 million tokens in 2 days without price impact, and since then the token price has dropped 30%. Showing that accumulation to the 30 million quorum threshold was operationally practical.
Phase 2: Proposal spam. Submit multiple proposals simultaneously or in rapid succession. Each proposal requires only 1 SHU to create. No proposal limits, rate limiting, or delay mechanisms exist to prevent this behavior. A spam-proposal strategy imposes a very high defense cost on legitimate token holders attempting to coordinate a response: the attacker needs only one proposal to succeed, while defenders must vote against every single one.
Phase 3: Treasury extraction. With quorum met through owned tokens, the attacker controls vote outcomes. Proposals transferring stablecoins from treasury to attacker-controlled addresses pass without intervention. No veto mechanism exists to block execution. No timelock exists to delay execution after a vote passes.
The economic incentive is significant: approximately $3M in stablecoin reserves against an approximately $100k cost of capture.
This vulnerability was identified in early 2025, by expanding Anticapture's coverage and integrating new governance systems. At the time, the DAO was even more exposed, with +$6m in liquid treasury.
Upon identification, we disclosed the risk privately to key members of the Shutter community. The response was measured: the team assessed that they had sufficient defensive capability. We communicated that our simulations showed otherwise — no defensive cards were visible on-chain that would prevent the attack sequence we had validated.
Some time after this initial disclosure, a delegation of approximately 60 million SHU was consolidated into a single wallet, making it the largest delegate in the DAO. This was a meaningful defensive improvement. A large aligned voter capable of meeting quorum in opposition provides a real deterrent. However, this approach has structural limitations:
It depends on a single wallet being available and responsive to every malicious proposal.
A spam-proposal strategy can exhaust even a well-resourced defender: the attacker submits many proposals, and the defender must vote against all of them. Only possible defense would be to have a script running with the private key, which also has it's own risks.
If the wallet is compromised or the key holder is unavailable during a voting period, the defense disappears entirely.
It creates a single point of failure in what should be a distributed governance system.
White hat capture considered and discarded. During this period, we evaluated a more aggressive approach: executing the attack ourselves as a white hat operation. The plan would involve buying 30M SHU tokens, changing the admin of the DAO, deploying a new instance of the DAO with corrected governance parameters, and returning admin. We chose not to proceed. The lack of support we found in the ecosystem to address the vulnerability through established channels left us without a clear path forward, and legal uncertainty around unauthorized capture — even with intent to return — created unacceptable risk. We had already disclosed to multiple parties that we understood the attack vector, making an anonymous operation impractical.
Continued stakeholder engagement. We continued discussing the vulnerability with select individuals in the Ethereum ecosystem, seeking guidance on the best mitigation path: one that would not require us to take control of the DAO ourselves, that would survive public disclosure, and that could be implemented through legitimate governance.
In November 2025, at DevConnect in Buenos Aires, we were able to have more direct conversations with key members of the Shutter community. These conversations produced what we had been missing: introductions to aligned delegates with governance expertise, operational knowledge of Shutter DAO, and willingness to coordinate on a security response.
This was the turning point. After more than a year of knowing the vulnerability existed and searching for a viable path, we had a group capable of executing the mitigation.
The decision to act was driven by two factors.
First, the economic context had not improved. Treasury value remained high, token price decreased even more, and the governance configuration remained unchanged since deployment. The vulnerability is not theoretical — it was economically actionable, and had been for over a year.
Second, we were not willing to wait indefinitely for a funding mechanism. Previous attempts to establish a path for compensated security work had not moved forward. We decided to act in the best interest of Ethereum's security and pursue retroactive compensation through proper governance channels. The alternative — continuing to sit on a known, exploitable vulnerability — was not acceptable.
Why the “Security Council” Approach. We evaluated multiple mitigation strategies. The critical constraint was this: any mitigation that changes governance rules (proposal thresholds, proposer gating, voting parameters) only takes effect after the proposal passes and executes. During the voting period, the DAO remains fully exposed under the old rules. If the vulnerability details become public at the moment of proposal submission — which they do, since the proposal itself signals that something is wrong — an attacker has a window to exploit before the fix is in place.
The Security Council guard changes this dynamic. Once proposed, the guard provides retroactive protection: even if an attacker submits malicious proposals during the voting period, the guard can veto those proposals after it is installed. The security council doesn’t just prevent future attacks — it can neutralize attacks that are already in flight, provided the Security Council proposal was submitted before those attack proposals.
This is why we submitted a single proposal containing both the guard installation and a timelock, rather than a multi-proposal sequence. And this is why we prepared all communication artifacts in advance and released them simultaneously with the proposal: we could afford to go public because the mitigation, once passed, would cover the exposure window.
The SecurityCouncilAzorius contract implements the IGuard interface from the Zodiac framework. When installed on the Azorius governance module via setGuard(), it interposes on every proposal transaction at execution time.
How it works:
A proposal passes the voting period and enters the timelock window (2 days, added by the same proposal that installs the guard).
When someone attempts to execute the proposal, Azorius calls checkTransaction() on its configured guard.
The guard computes the transaction hash using Azorius.getTxHash() and checks it against its veto registry.
If the hash is vetoed, execution reverts with TransactionVetoed. If not, execution proceeds normally.
Council capabilities:
vetoProposal(proposalId) — vetoes all transactions in a proposal
unvetoProposal(proposalId) — clears veto on all transactions in a proposal
vetoTx(txHash) / unvetoTx(txHash) — fine-grained control over individual transaction hashes
multicall(calls) — batch operations atomically
Design decisions:
Veto state is stored by transaction hash, not proposal ID. This means if two proposals contain identical calldata, vetoing one blocks both. The council must enumerate active proposals before any veto action.
The council address uses OpenZeppelin Ownable. Rotation is done via transferOwnership() — no redeployment needed. renounceOwnership() is disabled to prevent accidentally leaving the guard without a council.
The guard is a veto mechanism, not a gatekeeper: it can block execution, but it cannot modify proposals or force outcomes. Voting and proposing remain fully permissionless.
Audit. The contract was audited by Cyfrin. The audit returned only informational notes. All were addressed and the final version was approved.
Veto guard contract for Azorius DAO proposals with council-controlled safety - shutter-security-council/audits at main · blockful/shutter-security-council
With the guard contract developed, audited, and ready for deployment, we prepared the full execution sequence.
Veto guard contract for Azorius DAO proposals with council-controlled safety - blockful/shutter-security-council
Preparation (before going public):
Deploy a placeholder 1-of-1 Safe as the initial council address.
Deploy SecurityCouncilAzorius with the council Safe and Azorius module as constructor arguments.
Verify the contract on Etherscan.
Prepare the governance proposal, forum post, delegate messages, and public communications.
Execution (simultaneous):
Submit the Security Council proposal on Decent. The proposal contains two atomic transactions:
Azorius.updateTimelockPeriod(14400) — introduces a 2-day timelock (~14,400 blocks at ~12s/block)
Azorius.setGuard(guardAddress) — installs the Security Council guard
Publish the forum post with a high-level description of the vulnerability, the mitigation plan, and the recommendation.
Send private messages to target delegates with full vulnerability details and council participation requests.
Council formation (during voting period):
Collect confirmed addresses from delegates who agree to participate.
Upgrade the placeholder Safe from 1-of-1 to the full council multisig with appropriate threshold.
Verify multisig configuration.
Once the proposal passes voting and the timelock elapses, the guard is installed and active. From that point, the council can veto any malicious proposal, including any that were submitted during the voting period.
The stakeholder group coordinating the mitigation:
Delegate | Address |
Kleros Labs | 0xffFA76e332cA7afaae3931cb5d513B7fd681C4CF |
5pence | 0xe52C39327FF7576bAEc3DBFeF0787bd62dB6d726 |
d0z3y | 0xDffDb9BeeA2aB3151BcBcf37a01EE8726F22ed94 |
Mikko Ohtamaa | 0x61C2dAE896f93e5f0f10425914CE7868eE8A0e44 |
Jacob Czepluch | 0x06c2c4dB3776D500636DE63e4F109386dCBa6Ae2 |
blockful | 0x1F3D3A7A9c548bE39539b39D7400302753E20591 |
Lanski | 0xB6647e02AE6Dd74137cB80b1C24333852E4AF890 |
DAOplomats | 0x057928bc52bD08e4D7cE24bF47E01cE99E074048 |
The Security Council proposal changes two parameters and leaves voting mechanics untouched.
Parameter | Before | After |
|---|---|---|
Timelock | 0 blocks (none) | ~2 days (14,400 blocks) |
Guard | None | SecurityCouncilAzorius |
Voting period | ~3 days (21,600 blocks) | Unchanged |
Execution window | ~3 days (21,600 blocks) | Unchanged |
Proposal threshold | 1 SHU | Unchanged |
Quorum | 3% of total supply | Unchanged |
Before the Security Council proposal, a passed proposal could be executed the instant voting ended. No review window. No safety net.
The 2-day timelock creates a window between a proposal passing and becoming executable. This window adds more time for the security council reviewing the proposal and veto if necessary. The guard enforces the veto at execution time.
The proposal threshold and other voting parameters remain unchanged in this proposal. Hardening those parameters (raising the proposer threshold, extending the execution window) is recommended as a follow-up through normal governance, now that the council provides a safety net during the transition.
This is a centralizing solution. A small group of delegates holds veto power over governance execution while the DAO is stabilized. We are not framing this as anything other than what it is: a necessary tradeoff to protect the treasury and allow proper governance upgrades to be discussed in the open.
The alternative was leaving the DAO economically exposed with a validated attack path and a ROI exceeding 30x. Emergency response differs from permanent architecture.
Veto any proposal before execution
Unveto proposals that were incorrectly blocked
Submit proposals (unless they separately hold voting power)
Modify proposal outcomes or vote counts
Change governance parameters unilaterally
Access treasury funds directly
On council removal: The guard can be removed through a governance proposal calling Azorius.setGuard(address(0)). However, this removal is itself subject to the council’s veto authority — the council could veto a proposal to remove itself. There are no Safe managers beyond the Azorius module that could bypass this. This is the fundamental trust assumption: the council members are selected for their alignment with the protocol, their reputation in the ecosystem, and their demonstrated commitment to Shutter’s mission. The centralization is real, and the community’s recourse is the accountability and reputation of the individuals holding these seats.
Following our security agenda, we disclosed publicly only after the mitigation was in the governance pipeline and structured to survive the disclosure itself. Publishing vulnerability details before neutralization would have advertised the attack vector to adversarial actors and created a race condition between coordination and exploitation.
Before proposal: No public communication. All coordination was private with the stakeholder group and select counsel.
At proposal submission: Forum post and delegate messages released simultaneously. High-level vulnerability description without step-by-step exploit instructions.
TL;DR Shutter DAO (0x36) has a governance vulnerability where the cost to attack the DAO (approximately $100K to reach quorum) is significantly lower than the treasury value ($3M+). The current configuration allows any address holding 1 SHU to submit unlimited proposals with zero timelock, creating an asymmetric attack surface: an attacker needs only ONE proposal to pass, while defenders must vote NO on every malicious proposal.
After execution: Full technical disclosure. Safe to publish because the guard is active and can veto any attack submitted after the vulnerability became public knowledge.
Exceptions were made for counsel on how to proceed: Loring Harkness from Brainbot, who provided Shutter-specific protocol context.
After neutralizing the acute risk, we recommend the community explore:
Proposal threshold increase. Raising the required proposer weight from 1 SHU to a meaningful amount (e.g., 100,000 SHU, 0.01% of supply) eliminates spam while remaining accessible to serious participants. Based on delegated voting power, not token balance.
Execution window extension. With the 2-day timelock added, extending the execution window from 3 days to 7 days gives legitimate proposers sufficient time to execute without risk of proposals expiring over weekends or holidays.
Azorius module enhancements. Rate limiting on proposal creation, proposal staging windows, and time-delayed execution add defense-in-depth beyond the council’s veto capability.
Broader veto mechanisms. Enabling intervention without permanent centralization of veto authority. The current council is a temporary measure; the long-term goal is governance architecture that is resilient by design, not by delegation.
The objective is designing a resilient system while the DAO is not under active attack. Security creates the conditions for sustainable decentralization.
This work is part of blockful’s security agenda. Our purpose is aligned with the Ethereum ecosystem: we are committed to protecting not only the funds present in it, but every piece of infrastructure that makes it what it is.
Shutter’s research on encrypted mempools and MEV protection positions it as infrastructure-grade technology within the Ethereum ecosystem. Governance vulnerabilities represent structural risks requiring systematic identification, quantification, and mitigation.
This pattern repeats across protocol lifecycles: governance designs adequate at one treasury scale fail at another.
blockful blogHow $3.6M in Liquidations Made $BAL Melt 50% in 2 Hours
Once you become large enough, price ceases to be an external signal and becomes a reflection of yourself.
blockful blogSporkDAO's 2026 Board Election: A Governance Security Analysis
And the attacker... apparently didn't want to actually attack or capture the DAO.
blockful blogLessons from Arbitrum DAO: The Architecture of Governance
Difficult actions are often the price of necessary change.
Share Dialog
Share Dialog
Research that maps DAO governance risks, identifies governance capture vectors, and provides actionable governance security insights.
Subscribe to blockful blog
Subscribe to blockful blog
<100 subscribers
<100 subscribers
No activity yet