Sid 📿

Surely one of the most complex decisions ever made in Arbitrum governance history but a few things worth noting: 1. To all those screaming for the past few days “Arbitrum has a centralized sequencer so they can move funds”, take a few minutes to learn how Arbitrum works. The sequencer has absolutely no power to move funds and was not the one who acted here. 2. The decision to act was made entirely by the Arbitrum Security Council, a group of 12 individuals elected by the Arbitrum DAO (the annual election is currently underway — vote now!), which required 9/12 of them to agree. The council is independent from the Arbitrum Foundation and Offchain Labs (1/12 of the elected members is an OCL engineer), and came to this decision by themselves after much deliberation. You may not like the existence of security councils and you can form your own opinion on whether you agree with their actions, but this process was extremely distributed and coordinated by independent actors, and ina world where security councils exist, Arbitrum’s is a masterclass on how a truly independent security council should operate. 3. For many, the ultimate goal is to get rid of the security council entirely, but this is complicated. Technically it’s easy — the security council is elected by the DAO and operates at its pleasure, and the DAO can turn it off at any time. But the harder question is _should_ the DAO do that? L1s have the ability to hard fork. Security councils control the analogous power for the L2. If you get rid of it, you lose the ability to hard fork. You can still update the chain via DAO vote but that’s a slow process and you can no longer do fast emergency actions (which includes both actions like the security council took today as well as the ability to quickly upgrade the code in case an exploitable vulnerability in the software stack is discovered). As I’ve said many times, the best path that I see to getting rid of security councils is for the L1 itself to take on this burden for its most important L2s (as defined by objective criteria). In that case, in the case of a vulnerability or an exploit the conversation for L1 and L2 will be identical — does this warrant an L1 hard fork. I’m hopeful that we can reopen this conversation in the coming weeks.

The Arbitrum Security Council has taken emergency action to freeze the 30,766 ETH being held in the address on Arbitrum One that is connected to the KelpDAO exploit. The Security Council acted with input from law enforcement as to the exploiter’s identity, and, at all times, weighed its commitment to the security and integrity of the Arbitrum community without impacting any Arbitrum users or applications. After significant technical diligence and deliberation, the Security Council identified and executed a technical approach to move funds to safety without affecting any other chain state or Arbitrum users. As of April 20 11:26pm ET the funds have been successfully transferred to an intermediary frozen wallet. They are no longer accessible to the address that originally held the funds, and can only be moved by further action by Arbitrum governance, which will be coordinated with relevant parties.

Two days ago, Kelp DAO suffered a $292 million exploit, the largest DeFi hack of 2026. The attack is elegant in its simplicity, terrifying in its implications, and a case study in how a single misconfiguration can cascade through the entire DeFi stack. ▶ The Setup Kelp is a liquid restaking protocol. It creates rsETH -- a liquid token representing ETH restaked on EigenLayer. DeFi being DeFi, users want these tokens available across multiple chains. So Kelp uses LayerZero, a cross-chain messaging protocol, to bridge rsETH between networks. The core idea behind any cross-chain bridge is straightforward: - A user locks (or burns) tokens on Chain A - An oracle observes and verifies that transaction - The bridge mints an equivalent amount of tokens on Chain B LayerZero's oracle mechanism is its Decentralized Verifier Network (DVN), a set of independent verifiers that must agree a cross-chain message is legitimate before it is executed. The critical word here is "independent." And that's where things went wrong. ▶ The Vulnerability For reasons that remain unclear, Kelp had configured a 1-of-1 DVN setup. One verifier. No redundancy. No independent confirmation. LayerZero had explicitly warned against this configuration. Kelp ignored the warning. A single point of failure in a system securing hundreds of millions of dollars. ▶ The Attack The attackers, preliminarily attributed to North Korea's Lazarus Group, didn't need to break any smart contract. They went after the infrastructure layer. To verify blockchain state, a DVN relies on RPC nodes, the servers that synchronize and serve blockchain data. The attackers compromised two RPC nodes used by Kelp's lone DVN, then launched a DDoS attack against the remaining healthy nodes, forcing failover to the poisoned ones. From there, it was trivial. The compromised RPC nodes presented a fabricated blockchain state to the DVN, pretending that 116,500 rsETH (~18% of total circulating supply) had been legitimately deposited on the source chain. The DVN, seeing no contradicting signal from any other verifier, approved the message. The attacker retrieved 116,500 rsETH freshly minted on the destination chain. ▶ The Liquidation The attacker deposited the stolen rsETH as collateral on Aave V3 and Compound V3, then borrowed approximately $236 million in (W)ETH against it. By the time lending protocols reacted, freezing rsETH markets, halting new deposits, restricting withdrawals, the damage was done. Aave now carries an estimated $177-196 million in bad debt. Its TVL plunged from ~$26.4 billion to ~$17.7 billion as panic withdrawals exceeded $5.4 billion. Whether Aave's safety module can fully absorb the loss remains an open question. Not the decentralized and trustless ideal we went for... The Deeper Problem Poisoning a handful of RPC nodes and DDoS'ing a few others was enough to fabricate $292 million out of thin air and erodes trust across the entire DeFi ecosystem. No smart contract exploit. No zero-day. Just a misconfigured verifier and an infrastructure-level attack on the nodes it relied on. But the root cause runs deeper than Kelp's configuration. The fundamental problem is the trust model. Kelp's bridge, like most bridges and many Layer 2 rollups, relies on oracles reading blockchain state from RPC nodes and attesting that "this thing happened." The security of the entire system reduces to one question: can you trust the nodes feeding data to your verifier? The Kelp hack proves the answer is no. Not the decentralized and trustless ideal we went for... There is a fundamentally different approach: validity proofs. Instead of trusting oracles to honestly report what happened on another chain, you require a cryptographic proof, a zero-knowledge proof, that the state transition actually occurred according to the protocol's rules. The verifier on the destination chain doesn't trust any RPC node, any oracle, or any DVN. It checks the math. Either the proof is valid or it isn't. This is exactly the model ZK rollups use to settle on Ethereum. The L1 doesn't ask an oracle "did these transactions happen?" It verifies a succinct proof that they did. ▶ The Goose That Lays the Golden Eggs One could argue the attacker showed restraint. With a 1-of-1 DVN, they could have minted any amount, $292 BILLION, if they wanted. There are liquidity arguments (you can only extract what lending markets will let you borrow against) and detection arguments (the larger the mint, the faster the response). But there's a more cynical reading. The Lazarus Group and similar state-sponsored actors are in a peculiar position. They could mint an amount large enough to collapse the entire DeFi ecosystem. But doing so would kill the very system they profit from. So they calibrate, enough to fund their operations, not so much that the ecosystem loses confidence and collapses. The goose must keep laying. The DeFi ecosystem likes to talk about trustlessness and decentralization. But when a handful of poisoned RPC servers can drain nine figures and trigger a systemic crisis, we should be honest about where we actually are, and serious about the cryptographic tools that can actually get us there. Stay safe.