Context
The Security Council proposal has been approved and executed. The veto guard and 2-day timelock are now active on Shutter DAO (0x36).
This was a critical first step — and it worked. The Security Council is in place, the DAO’s treasury can be protected in case of an attack, and we can now focus on building stronger governance foundations. With the council as an active safety net, the community has the space to discuss and implement additional improvements without time pressure.
Why This Matters Now
The Security Council addresses the symptom — it can block malicious proposals. But it doesn’t fix the underlying governance configuration that made the DAO vulnerable in the first place:
-
1 SHU proposal threshold — anyone can submit proposals for near-zero cost
-
No voting delay — proposals go to vote immediately once proposed
-
3-day execution window — legitimate approved proposals can expire without execution
And, most importantly:
- No rate limiting — anyone can submit as many proposals as they want
As long as these parameters remain unchanged, the Security Council is the only thing standing between the DAO and a quorum-sized attack vector. That’s not a resilient position. The council members are trusted individuals, but the DAO should not rely indefinitely on 5-of-8 signers being available, aligned, and uncompromised. The Security Council is also a centralizing solution, that while highly efficient, depends on vetoing power to do so.
The objective: make the governance architecture resilient by design, so the council becomes a safety net rather than the primary defense.
Suggested Improvements
Based on the Anticapture framework analysis, Shutter DAO is an organization at Stage 0 for governance security. You can check the whole analysis on Anticapture’s Shutter DAO Dashboard
From our experience with DAO governance systems, we recommend the following areas for improvement. We welcome community input on specifics, but these represent what we believe are the necessary hardening measures.
1. Proposal Spam Resistance
The Anticapture framework identifies three complementary mechanisms for spam defense. These work together — each addresses a different angle of the same attack vector:
Proposal Threshold Increase
-
Current: 1 SHU (≈ $0.003)
-
Suggested Minimum: 500,000 SHU
Raising the threshold to a meaningful amount stops part of the spam vector at its source. The threshold is already based on delegated voting power, so active governance participants can propose without needing to use wallets that hold large token positions.
Proposer Balance Threshold
Require proposers to maintain a minimum voting power not just at submission, but throughout the voting period. This prevents hit-and-run proposals where an attacker submits a proposal and immediately sells their position. It also prevents circumventing rate limits by transferring tokens between wallets to spam proposals from multiple addresses. This is implemented as a permissionless cancel function — anyone can trigger cancellation of a proposal if the proposer’s voting power drops below the required threshold.
Rate Limiting on Proposal Creation
Cap the number of active proposals per address. This eliminates the spam strategy where an attacker submits hundreds of proposals forcing defenders to vote against every single one.
Together, these three mechanisms eliminate the asymmetry that would make the original attack vector viable: the attacker could submit unlimited proposals at near-zero cost while defenders would have to respond to all of them.
2. Execution Window Extension
-
Current: ~3 days (21,600 blocks)
-
Suggested: ~7 days (50,400 blocks)
Extending the execution window is straightforward good practice. A longer window ensures proposers have adequate time to execute passed proposals without risk of expiration due to operational delays. Having any limit to execute after approval is uncommon among DAOs today, and having more time to execute should be treated as a common sense improvement.
3. Voting Delay
-
Current: 0 blocks
-
Suggested: 1–2 days
A voting delay between proposal submission and vote start gives the community time to review, discuss, and coordinate before voting begins. This is standard in most mature DAO governance implementations. While it does increase the time from proposal to execution - which is already extended with the timelock - it allows for proper incident response and community discussion, reducing the attention demand over delegates and increasing security.
What We’re Asking
We’ve laid out what we believe are the necessary next steps based on the Anticapture framework and our direct experience with this vulnerability. We’re bringing this as the specialist reference — this is what we recommend.
That said, we want the community engaged in this process:
-
Do you see additional improvements that should be part of this hardening phase?
-
What’s the priority order? Which changes should go first?
blockful is here to lead the technical work and support the governance process through to execution. The specifics should reflect community input, and we want to reach a common understanding of what’s necessary before moving to formal proposals.
Next Steps
-
Community discussion — this thread. Share your views, push back, propose alternatives.
-
Working group formation — if there’s interest, we can form a small working group to draft specific parameter proposals based on community input.
-
Formal proposals — once there’s rough consensus on priorities and parameters, submit governance proposals through the standard process. The Security Council provides a safety net during this transition.
The DAO is secure today. Let’s make it secure by design.
This post is part of blockful’s ongoing security work with Shutter DAO. For full context on the vulnerability and emergency mitigation, see the original disclosure and the governance forum post. All governance data is available on the Anticapture Dashboard