How Arbitrum’s Security Council
Froze KelpDAO Funds

A Technical Deep Dive

Agenda

  1. Incident Background
  2. Arbitrum Architecture Basics
  3. Security Council Emergency Powers
  4. The Technical Mechanism (Step-by-Step)
  5. On-Chain Evidence
  6. Why It Worked
  7. Implications & Trade-offs
  8. Key Takeaways

The KelpDAO Incident (April 2026)

  • April 18, 2026: ~$292 million exploit on KelpDAO (rsETH)
  • Attack used a forged LayerZero cross-chain message (1-of-1 DVN flaw)
  • Large portion of stolen ETH moved to Arbitrum One
  • April 20–21: Arbitrum Security Council executes emergency action
  • Result: ~30,766 ETH moved to a governance-controlled frozen wallet

Arbitrum Architecture Basics

  • Optimistic Rollup running on Ethereum (Nitro)
  • L1 → L2 messaging goes through the Delayed Inbox contract on Ethereum
  • Messages are executed on L2 with a specific sender context
  • Core contracts are upgradeable via the Upgrade Executor

Security Council Powers

Source: Arbitrum DAO Constitution

  • Consists of 12 members (multi-sig wallet)
  • Can perform Emergency Actions and Non-Emergency Actions
  • Both types of actions require 9-of-12 approval
  • Powers can be modified or removed via Constitutional AIP

Emergency Actions (Constitution)

“Performing any Emergency Action requires a 9-of-12 approval from the Security Council.

The Security Council must not use its power to perform Emergency Actions except in a true security emergency, such as a critical vulnerability that could significantly compromise the integrity, confidentiality, or availability of a chain governed by the ArbitrumDAO.”

Source: https://docs.arbitrum.foundation/dao-constitution (Section 3)

How Emergency Actions Work

  • 9-of-12 multisig approval required
  • Can execute immediately with no delay (bypasses normal timelock)
  • Typically used for urgent security responses (e.g., protocol upgrades)
  • After execution → Full transparency report must be published
  • DAO can later restrict or remove this power via Constitutional AIP

Source: Arbitrum DAO Constitution - Section 3

The Freeze Mechanism — High Level

Atomic temporary upgrade of the L1 Delayed Inbox
to impersonate the exploiter and move funds

1. Upgrade Inbox
2. Impersonate & Transfer
3. Revert Upgrade

Step 1: Temporary Upgrade of Delayed Inbox

  • Security Council triggers upgrade via the L1 Upgrade Executor
  • Upgrades the Delayed Inbox contract on Ethereum
  • Adds new function: sendUnsignedTransactionOverride
  • This function allows creating L1→L2 messages while impersonating any address

Step 2: Impersonated Cross-Chain Transfer

  • Used the new override function to create an L1→L2 message
  • Message was built to impersonate the exploiter’s address
  • L2 executed the transaction as if it came from the exploiter
  • ~30,766 ETH was transferred to the frozen wallet

Frozen Wallet: 0x0000000000000000000000000000000000000DA0

Step 3: Atomic Reversion

  • Immediately after the transfer, the Inbox was upgraded back to its original code
  • The temporary sendUnsignedTransactionOverride function was removed
  • Operation was fully atomic — no permanent protocol changes
  • Only the fund movement remained on-chain

On-Chain Evidence

Ethereum L1 Tx
(Upgrade + Impersonation)

0x079984c56c5670108f5c6f664904178f9b364340351949a42e4637d1f645f770

View on Etherscan →
Arbitrum One Tx
(Fund Transfer)

0x5618044241dade84af6c41b7d84496dc9823700f98b79751e257608dac570f6b

View on Arbiscan →

Why This Technique Worked

  • The Delayed Inbox is the trusted entry point for all L1→L2 messages
  • Temporary control of the Inbox allowed spoofing the sender address
  • L2 processed the transaction with the exploiter’s sender context
  • Native ETH could be moved because it appeared as a legitimate transaction from that address
  • Atomic upgrade-revert pattern left no permanent changes

Implications & Trade-offs

Strengths

  • Fast and targeted recovery
  • Minimal disruption to users
  • Fully transparent and documented
  • Final release requires DAO governance

Trade-offs

  • Reveals centralization in current L2s
  • Depends on honest Security Council
  • Sets precedent for future interventions
  • Stage 1 rollup limitations exposed

Key Takeaways

  1. Security Council used a temporary upgrade of the L1 Inbox
  2. They added an impersonation function to execute a transaction as the exploiter
  3. The entire operation was atomic (upgrade → transfer → revert)
  4. No permanent backdoor was left in the protocol
  5. Final movement of funds still requires DAO governance approval

Sources

  • Official Technical Disclosure
    Arbitrum Forum Post
  • Arbitrum Announcement
    X Post
  • L1 Transaction: 0x079984c56c5670108f5c6f664904178f9b364340351949a42e4637d1f645f770
  • L2 Transaction: 0x5618044241dade84af6c41b7d84496dc9823700f98b79751e257608dac570f6b
  • KelpDAO Incident Full Report: https://layerzero.network/publications/kelpdao-incident-report.pdf

Questions?

Thank you!