gzeon.eth

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.

@hosseeb @stonecoldpat0 @arbitrum Not entirely, ArbitrumUnsignedTxType is pre-existing and can be sent by anyone from L1 to control their own aliased account on L2. The Security Council overridden msg.sender restriction via an atomic contract upgrade to allow sender impersonation.

@stonecoldpat0 @arbitrum Is Claude incorrect/hallucinating?

Claude explains the $71M @arbitrum clawback: What this transaction is Tx: 0x5618...0f6b on Arbitrum, block 454686044, April 21, 2026 03:35 UTC From: 0x5d39...7Ccc — labeled on Arbiscan as “Kelp DAO Exploiter 1” To: 0x0000000000000000000000000000000000000DA0 — a special system/recovery sink (not the normal 0x...dEaD burn address) Value: 30,765.667 ETH (~$71M) — effectively the entire Arbitrum-side balance of the attacker’s hub wallet Tx type: ArbitrumUnsignedTxType (EIP-2718 type 0x65 / 101) The “type 101” is the key. That is not a user-signed transaction — a normal EOA physically cannot produce one. ArbitrumUnsignedTxType is an ArbOS system transaction that only the chain itself (via the sequencer / ArbOS upgrade path controlled by the Arbitrum Security Council) can inject. It bypasses the attacker’s private key entirely. The remediation (this tx): Arbitrum’s Security Council used its emergency powers to inject an ArbitrumUnsignedTxType that forcibly moved the attacker’s full 30,765 ETH from the hub address into a protocol-controlled recovery sink (0x...0DA0). Why it’s “extraordinary” Arbitrum did not perform a reorg or historical rewrite — the chain’s ordering is intact. Instead, the Security Council used a privileged state-override transaction type that is part of ArbOS but has essentially never been used before. It is functionally a state-level clawback: the attacker’s private key still signs txs, but that address’s ETH was moved by the chain itself. This is the mechanism Arbitrum’s progressive-decentralization docs reserve for “catastrophic” emergencies (12-of-N Security Council action), and this is one of the clearest public demonstrations of it being invoked. Note that it only recovered the Arbitrum leg of the theft — the ~75,700 ETH on Ethereum is outside Arbitrum’s control and remains with the attacker, which is why Aave is still facing up to ~$230M of potential bad debt on the Ethereum side. Sources: Arbiscan tx: arbiscan.io/tx/0x561804424… Arbitrum Docs — ArbOS / Sequencer forced inclusion: docs.arbitrum.io/run-arbitrum-n… Arbitrum Foundation — progressive decentralization & Security Council: docs.arbitrum.foundation/state-of-progr…

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.

ICYMI: the Robinhood Chain testnet is now live for developers and users. This launch follows @RobinhoodApp’s Stock Tokens debut on Arbitrum One and kicks off a phased roadmap towards their migration to their own Arbitrum stack chain. Start building now: robinhood.com/chain

Arbitrum Security Council Member Election has started, looking forward to your vote! tally.xyz/gov/arbitrum/c…

We've acquired @zerodev_app! One of the most talented teams in crypto building next-gen smart accounts. This reinforces our commitment to solving the hardest onchain problems and building a unified development platform for all teams, regardless of their mandate. 🧵

@0xren_cf From decompilation there does NOT seems to be a whitelist feature, the token makes external call to 0x7ba8 "registry" contract `isBlocked(address)` which appears to be a blacklist only. I am also able to make a transfer from and to arbitrary address in a fork.

Just decompiled Robinhood's tokenized stock contracts. It's a walled garden, every transfer checks a registry of approved wallets (kyc/aml) It's unlikely these tokens can interact with defi It's very possible cefi with distribution just outcompetes existing defi protocols

Working with the @RobinhoodApp team has been an incredible journey. We believe the launch of their tokenized stocks on @Arbitrum today is just the beginning of what will be the rails that powers finance all around the world with their soon to be Robinhood Layer 2 blockchain. 🧵

Robinhood is now onchain with Arbitrum! Arbitrum will serve as @RobinhoodApp's rails to merge DeFi and TradFi in what is a 0 -> 1 moment for the entire industry. All while onboarding millions of net-new users into crypto. Arbitrum Everywhere. 🧵

You didn’t think we’d just announce new products, did you? The Robinhood Chain is currently being built on @arbitrum to power the future of asset ownership. #RobinhoodPresents rbnhd.co/ToCatchaToken

Applications are now open for the ArbitrumDAO Security Council's March election on @tallyxyz! Think you're a good fit or know someone who is? Registration ends on March 22nd. 👇

Introducing Onchain Labs, in partnership with @arbitrum. While we continue to innovate scaling infra, today we also look to empower the Arbitrum app layer. 👇

imo a lot of bad takes, you can’t design a system with single point of failure and blame that single point failed

@hrkrshnn Like, don’t blind sign?

Tell me your best tips to avoid another multisig hack. After Safe's disclosure I can confidently tell that 99% of multisigs would have fallen for the same attack.

@stonecoldpat0 You might need newer firmware but ledger live / mm extension can show the full EIP712 payload on the screen of a ledger hardware wallet before signing. Not sure about older device without eink screen but iirc it show the hash you are signing which can be verified with tools.

The inability to verify a simple SAFE transfer in a hardware device UI is the single biggest failure that led to the bybit hack & what terrifies me on a daily basis. 2025 and hardware wallets UX sucks still.

Bounty amounts are irrelevant here, no company in the world would incentivize everyone to phish their employees 😂

2/ First up, @arbitrum BoLD. BoLD introduces permissionless validation, which means that any node operator can submit a fraud proof to challenge the state of the chain. This is a huge decentralization unlock that heightens the security of Arbitrum One. x.com/arbitrum/statu…

You would thought every organization that have a serious Safe setup would be using some tool like this, a private Safe UI instance, etc. Not sure we should blame the UX or signers should just have been more careful.

Today, BoLD delivers permissionless validation, making the Arbitrum ecosystem more secure and more decentralized than ever. Anyone can defend Arbitrum. Stage 2 soon.