On April 21, 2026, at 11:26 p.m. ET, twelve people moved 30,765 ETH without the owner's keys, without the owner's consent, and without a DAO vote. The owner was a hacker. The twelve were Arbitrum's Security Council. The act was legal under Arbitrum's own constitution. What it was not, and still is not, is easy to reconcile with the premise that Arbitrum is trustless infrastructure.

Background in one paragraph

On April 19, attackers exploited a vulnerability in Kelp DAO's LayerZero-powered cross-chain bridge, draining approximately $292 million in rsETH by forging cross-chain messages through a manipulated Decentralized Validation Network configuration. Roughly 30,766 ETH — about $71 million, or just under a quarter of the total — landed in an address on Arbitrum One. That is where Arbitrum's governance apparatus entered the picture. The exploit is background; what happened next is the story.

What the Security Council is

The Arbitrum DAO Constitution, the governing document at docs.arbitrum.foundation/dao-constitution, grants "chain owner" privileges on Arbitrum One jointly to the ArbitrumDAO and to the Security Council of the Arbitrum Foundation. Those chain-owner powers include updating the contract implementation of Arbitrum's core Transparent Upgradeable Proxy contracts and adjusting system parameters.

The Council is twelve elected members, split into two cohorts with staggered one-year terms. Emergency actions require nine of the twelve to sign — a 9-of-12 multisig. That threshold, unlike every other Arbitrum governance path, carries no timelock. According to the technical overview at github.com/ArbitrumFoundation/governance, "The 9/12 Security Council should be able to make an upgrade without any delay."

The constitutional definition of an emergency action is deliberately open-ended: the Council is "responsible for making time-sensitive and emergency response decisions that protect the interests of the DAO, its members, and the broader Arbitrum community." It is subject to DAO oversight after the fact; Council members can be removed if at least 10 percent of all votable tokens participate in a removal vote and at least five-sixths favor removal.

What the Council actually did

The official forum post at forum.arbitrum.foundation/t/security-council-emergency-action-21-04-2026/30803 describes the mechanics precisely.

The Council executed an atomic transaction that:

  1. Upgraded Arbitrum One's Inbox contract on Ethereum to a modified implementation containing a new function, sendUnsignedTransactionOverride.
  2. Used that function to create a cross-chain transaction that impersonated the exploiter's address — that is, sent a transaction as if it originated from the attacker's wallet without that wallet's private key.
  3. Transferred 30,765.667501709008927568 ETH to 0x0000000000000000000000000000000000000DA0, a frozen intermediary address.
  4. Immediately reverted the Inbox contract to its original implementation.

The funds at 0x0000000000000000000000000000000000000DA0 are inaccessible without a further Arbitrum governance vote. "To release the funds," the forum post reads, "a subsequent action must be taken by Arbitrum Governance, which will be coordinated with relevant parties." The Council stated it "acted with input from law enforcement as to the exploiter's identity."

The mechanics matter because they clarify exactly what happened: this was not a freezing of an address at the sequencer level, which would be operator-layer censorship. It was a protocol-level upgrade that rewrote the rules of the chain for one atomic transaction in order to move funds without the keyholder's authorization. The contract was returned to its prior state immediately after.

The tension the Council's own documentation does not resolve

Arbitrum markets itself as a trustless rollup. Its technical documentation describes a system designed so that "once a proposal has been passed, anyone can ensure its full execution through all stages" and that proposals cannot be canceled or blocked except by the Security Council. The "exit before upgrade" guarantee — the series of timelocks giving users time to withdraw before any governance change executes — is a core part of Arbitrum's security proposition.

The 9-of-12 emergency path exists precisely as a carve-out from that system. The Arbitrum Constitution acknowledges this explicitly: the Security Council "can bypass the slow voting process and take fast action in the case of security emergency." The Arbitrum One chain has two owners, and one of them can rewrite any contract with no delay, no DAO vote, and no exit window.

What the documentation does not address is the question the Kelp intervention raises: can the Security Council move funds not just to protect the chain's infrastructure, but to adjudicate property rights between specific addresses? The April 21 action did not patch a protocol vulnerability. It moved assets from one address to another, on the basis of the Council's determination — with law enforcement input — about who rightfully owned them. That is a materially different use of the emergency power than patching a critical bug in a bridge contract.

DAO reaction and the post-hoc vote

The broader community debate was described as active but not producing formal dissent in the form of a removal vote or a constitutional challenge. Justin Sun, per public reports, questioned whether the Council's composition was sufficiently decentralized. Discussion threads on the Arbitrum governance forum in May 2026 included a post titled "Should DAO Security Councils Include a Non-Technical Member Role?" — a thread directly traceable to the Kelp action.

The more significant governance signal came afterward: the ArbitrumDAO passed a proposal to release the frozen 30,765 ETH for a coordinated victim recovery effort. The DAO vote was the required second step; the Council's emergency action had put the funds in a position where they could be redirected, but only by a DAO vote. In practice, the full sequence ran: Council intervenes unilaterally → DAO votes on disposition of the seized funds. The "trustless" layer handled final allocation; the "trusted" layer handled the seizure that made allocation possible.

A separate legal complication: according to reporting citing a Monday filing in U.S. federal court, Aave LLC contested a court restraining notice that could have blocked the transfer, arguing it was "causing immediate and irreparable harm to users" and seeking a $300 million bond.

The same mechanism exists elsewhere

Arbitrum is not an outlier. Every major Ethereum L2 retains some version of an upgrade key.

Optimism has a Security Council with its own charter at gov.optimism.io. Its upgrade key structure is documented under the Optimism Collective's governance materials, with the Council holding the power to execute emergency upgrades.

Base, which uses the Optimism Stack, inherits its parent's upgrade key architecture. The Superchain model centralizes some of these controls at the OP Labs level.

ZKsync completed a transfer of upgrade authority to its on-chain ZKsync Nation governance in late 2025, but retains a Security Council under ZIP-15, with parameters governing its intervention powers.

L2BEAT's risk framework catalogs these controls chain by chain under the category of "upgrade keys" — addresses that can modify core contracts. For most production L2s, including all of the above, some such key exists. The security model is explicitly hybrid: cryptographic enforcement for most operations, human judgment for emergencies.

What this means structurally

The Arbitrum Security Council's intervention was within its documented powers. The Council was elected, the threshold was met, the mechanism was disclosed in public governance documentation before the attack occurred.

What the Kelp case clarified is the outer boundary of what "within its powers" means in practice. The Constitution gives the Council broad authority to protect "the interests of the DAO, its members, and the broader Arbitrum community." Seizing an attacker's funds and holding them pending a DAO vote falls within a defensible reading of that mandate. But the mechanism used — impersonating a wallet address to transfer its funds — is a chain-level capability that could in principle be applied to any address on Arbitrum One, not only one connected to an identified attacker.

The DAO has no formal process to pre-authorize specific types of emergency action or to define the limits of what counts as an emergency. That absence is what the governance forum discussion reflects: the community is now working through, after the fact, what constraints the Council should operate under when it decides that someone else's property should move.

The Arbitrum Foundation did not claim the intervention was uncontroversial. Its forum post stated that "The Council weighed its responsibility for the safety and integrity of the Arbitrum community" and "did not take this decision lightly." Those are the words of an institution that knows it crossed a threshold it expects to be examined.

The examination is now underway.

Sources: Arbitrum Security Council Emergency Action post, forum.arbitrum.foundation/t/security-council-emergency-action-21-04-2026/30803; Arbitrum DAO Constitution, docs.arbitrum.foundation/dao-constitution; Arbitrum governance technical overview, github.com/ArbitrumFoundation/governance/blob/main/docs/overview.md; Arbitrum Security Council conceptual overview, docs.arbitrum.foundation/concepts/security-council; Optimism Security Council Charter, gov.optimism.io/t/security-council-charter-v0-1/6884; ZKsync ZIP-15, forum.zknation.io/t/zip-15-update-zksync-security-council-parameters/966; The Defiant, Arbitrum DAO Security Council election coverage; secondary reporting from CoinDesk, BitcoinKE, TradingView cited for corroboration of public statements only.