Security Council Emergency Action – 21/04/2026

At 11:26pm ET, 21st April 2026, the Security Council executed an emergency action to freeze 30,765.667501709008927568 ETH held by the KelpDAO Exploiter on Arbitrum One. The funds are now held at 0x0000000000000000000000000000000000000DA0. To release the funds, a subsequent action must be taken by Arbitrum Governance, which will be coordinated with relevant parties.

Key point: KelpDAO exploiter funds are frozen on Arbitrum One.

Security Council Actions

The technical approach taken by the Security Council was to implement an atomic action to upgrade the inbox contract on Ethereum, freeze the funds, and return the contract back to its original implementation.

The Inbox Contract was upgraded to add a new function, sendUnsignedTransactionOverride, which imitates the structure of a standard cross-chain transaction with the ability to impersonate the transaction sender. A cross-chain transaction was created to impersonate the address associated with the KelpDAO Exploiter, and this transaction transferred the stolen funds to 0x0000000000000000000000000000000000000DA0. Finally, the inbox implementation was upgraded to return it back to the original implementation.

Arbitrum contributors prepared the transaction payload and it was verified by the Security Council before it was signed and executed. You can find the current security council members here Security Council Members | Arbitrum DAO - Governance docs.

Emergency Action Transaction

The Security Council signed the following transactions to perform the on-chain action:

The frozen funds can be found at Arbitrum One Transaction Hash: 0x5618044241... | Arbitrum One

10 Likes

So many people talk about decentralization on tg groups/X. The Security Council is a feature WE ALL KNOW ABOUT, and I’m glad it helped rescue people’s funds after a theft, making the lesson a bit less costly. Thank you!

1 Like

Thank you Arbitrum team and Security Council for acting promptly on the issue affecting the DeFi ecosystem on Arbitrum and Ethereum, and potentially recovering a significant amount of user funds.

I also appreciate that unlocking these assets will go through governance.

At the same time, this created a precedent that shapes the neutrality of Arbitrum and the role of the Security Council. ETH was moved on Arbitrum without the user’s consent.

My request, once the situation is clarified, is to formalize and publish the process.

When is the Council allowed to proceed in this way? Do authorities need to request the action (as it seems it happened in this case)? What are the safest steps that can be implemented? What are the safeguards to prevent abuse? How long before a governance vote is held? And many more questions that I’m sure will emerge.

Thank you

1 Like

First — the Security Council executed this well. 30,765 ETH recovered. Clean operation. The outcome is unambiguously good.

But the mechanism deserves serious scrutiny, because what happened here sets a precedent that extends far beyond one exploit recovery.

What Actually Happened (Technically)

The Security Council upgraded the Delayed Inbox contract on Ethereum mainnet, added a function capable of impersonating any L1 address, used it to transfer the exploiter’s funds to 0xdead, then reverted the contract to its original implementation.

Read that again. The Security Council demonstrated the capability to impersonate any address interacting with Arbitrum’s L1 infrastructure. They used it for recovery — this time. But the capability itself is not scoped to recovery. It’s a general-purpose power embedded in the upgrade authority.

The Governance Speed Tradeoff

This is worth examining alongside what happened at Aave during the same incident. When rsETH depegged, Aave’s governance couldn’t move fast enough to adjust risk parameters. The protocol had ~$8B in TVL exposed to cascading liquidation risk, and the governance process — designed for deliberation — became a liability in an emergency.

Arbitrum’s model is the opposite: a 9-of-12 multisig that can upgrade core contracts instantly. That speed saved 30,765 ETH. But it also means 9 people can modify the fundamental trust assumptions of a chain securing billions in value.

Neither model is wrong. But we need to be honest about the tradeoffs:

Aave-style (slow governance) Arbitrum-style (Security Council)
Emergency response Too slow — parameters couldn’t adjust before damage propagated Fast — funds frozen within hours
Censorship resistance High — no small group can unilaterally act Lower — 9/12 signers can upgrade core infra
Scope of power Limited to parameter changes Effectively unlimited (contract upgrades)
Accountability On-chain, transparent voting Post-hoc disclosure

Questions That Need Answers

1. Scope limitation. The “impersonate any address” function was added, used, and removed. But what prevents it from being re-added for purposes beyond exploit recovery? Is there a formal framework defining when this power is appropriate? If not, there should be.

2. Cross-chain coordination. This exploit spanned Unichain, Ethereum, and Arbitrum — three chains with completely different governance structures. Recovery required coordination across all of them. As cross-chain composability increases, we need explicit frameworks for multi-chain incident response. Who leads? What’s the communication protocol? How are conflicting governance decisions resolved?

3. Precedent documentation. This is the kind of action that should come with a detailed post-mortem — not just “what we did” but “here’s the decision framework we used, and here’s when we would vs. wouldn’t use this power in the future.” The community deserves that transparency, especially given the scope of the capability demonstrated.

4. Progressive decentralization. The Security Council exists because Arbitrum is still in a stage where this kind of intervention is expected. But the path toward removing this capability should be explicit. What milestones need to be hit before this power is deprecated? What replaces it?

The Broader Pattern

We’re seeing a recurring theme across DeFi governance this month: the infrastructure layer carries risks that protocol-level governance isn’t designed to handle. The rsETH exploit originated in a bridge DVN — infrastructure. The recovery happened through L1 contract upgrades — infrastructure. The Aave governance failure was a speed mismatch between infrastructure-speed risks and governance-speed responses.

The lesson isn’t that Security Councils are good or bad. It’s that governance design must be calibrated to the risk surface it’s governing. Emergencies require emergency powers. But emergency powers require explicit scope, sunset clauses, and transparency frameworks.

This was the right call. Now let’s build the framework that ensures future calls are equally well-reasoned — and that the community has visibility into the decision-making process, not just the outcome.

-– Robby Greenfield | tokedex.org

1 Like

Thanks to Security Council

A very cool idea and implementation, thanks for the rather prompt solution and unconventional approach.

This action was necessary and I support it speed was critical here, and waiting for a full governance vote would have meant losing the funds entirely.

But this moment raises a question we can’t ignore:

What stops this power from being used again under less clear circumstances ?

Today we had a confirmed exploit, time pressure, and a clean atomic execution. But there’s no published criteria for when this power can be triggered. No formal threshold. No disclosure of whether external authorities were involved in the decision.

The action itself was right. The absence of a framework around it is the problem.

Security Council should now publish a clear Emergency Action Policy defining:

What conditions justify bypassing governance

Who can request an emergency action

Mandatory post-action transparency report

We got lucky this time the intent was honest. Governance shouldn’t rely on luck.

The handling here is a useful case study in why pre-authorized emergency powers
with clearly scoped limits are preferable to either (a) full on-chain governance
with no emergency path, or (b) unconstrained admin keys with no accountability.

The KelpDAO situation shows the middle path working: the Security Council had
authority to act within a narrow scope (freeze, transfer to dead address, revert
implementation), executed transparently, and the subsequent step (release of
funds) still requires DAO coordination. That’s the right shape.

One thing worth examining in the post-mortem: the time between the exploit being
identified and the freeze being executed. If that window was hours, the current
architecture worked well. If it was days, that’s signal to revisit either the
council’s activation threshold or the monitoring infrastructure. Publishing the
full timeline would help the community calibrate whether response speed is
adequate for future scenarios.