0x685390da6853…685390d7
Arbitrum Security Council Halts New Stylus Activations in Emergency Action
Arbitrum's Security Council blocked new Stylus activations on One and Nova on October 2, citing AI-assisted WebAssembly attack risks. Active apps keep running; Solidity is unaffected.

Outputs
Arbitrum's Security Council blocked new Stylus activations on Arbitrum One and Nova in an October 2 emergency action, executed on-chain around 15:30–15:31 UTC.
The Council cited AI-assisted attacks using hand-crafted WebAssembly programs outside the standard Stylus toolchain; known bugs threaten chain liveness, not user funds.
The pause blocks fresh activations and reactivations but not Solidity contracts, active Stylus apps, or permissionless keepalive renewals before expiry; the Arbitrum Foundation will set a restoration timeline with ArbitrumDAO.
Arbitrum's Security Council temporarily blocked new Stylus contract activations on Arbitrum One and Nova in an emergency action executed on October 2, according to the Council's action report published on the Arbitrum forum. The restriction limits new programs and application updates that require fresh activation, while already-active Stylus applications continue to run and ordinary Solidity contract deployment and execution remain unaffected.
The Council attributed the precaution to increasingly sophisticated AI-assisted attacks involving hand-crafted WebAssembly programs built outside the standard Stylus compiler toolchain. It said known Stylus bugs primarily threaten chain liveness, including denial-of-service risk, and that no attack permitting theft of user funds had been discovered as of the report.
On-chain records confirm the timing. Transaction logs on Ethereum, Arbitrum One and Nova show successful execution of the emergency action on October 2, between roughly 15:30 and 15:31 UTC.
What the pause actually covers
The operational distinction for developers is between storing code and making it executable. Stylus contracts run WebAssembly programs that require an activation step before they can execute — a step Arbitrum's documentation separates from deployment, which merely stores code on-chain. New contract instances reusing identical program code can rely on an existing, still-valid activation.
A new application version requiring fresh activation cannot become executable during the pause. The Council also blocked reactivation of expired programs and of programs needing reactivation after a Stylus version change. The scope is activation, not a blanket prohibition on deploying new contract instances.
Existing programs remain callable until expiration. Developers can extend an active program's lifetime through the permissionless keepalive renewal mechanism before it expires, per the official pause notice. Renewal stays available; reactivation of an already-expired program does not.
Technically, the Council implemented the restriction by raising the activation gas requirement to a prohibitively expensive level. It characterized the move as a configuration change requiring no upgrade to ArbOS, the network's operating software — meaning the pause can be lifted without a coordinated software rollout across validators.
A separate settlement guard on Arbitrum One
The same emergency action installed a second safeguard concerning BoLD's one-step proofs on Arbitrum One. Under the guard, anyone can present two conflicting answers to the same step of an open challenge; if the one-step proof accepts both, the guard suspends One's settlement to Ethereum.
Arbitrum says One would continue processing transactions normally during such a suspension. However, messages from One to Ethereum that have not yet been confirmed — including withdrawals — would have to wait while the Council deploys a fix and resumes settlement. Installing the guard does not itself pause withdrawals; any delay depends on the conflicting-proof condition actually being met.
Business consequences and next steps
For teams building on Stylus, the immediate consequence is a release freeze on upgrades that need new activations, while deployed applications keep serving users. Teams with programs approaching expiration face a harder constraint: keepalive renewals must happen before expiry, because reactivation is off the table for now.
The reopening timeline remains open. The October 2 report and the developer notice give no restoration date, stating only that the Arbitrum Foundation will work with ArbitrumDAO on the timeline and manner of resuming activations — leaving builders awaiting a governance-level decision on when the activation path reopens.
via forum.arbitrum.foundation (Original)
More from Daniel Okafor
Show full bio
Correspondent covering industry trends and analytics at Mempool Brief.
435 articles