Arbitrum’s Security Council has temporarily disabled new Stylus contract activations on Arbitrum One and Arbitrum Nova after security research identified conditions capable of threatening network liveness.
No attack occurred.
No user funds were affected.
Those two facts are explicit in Arbitrum’s official security notice and are important because the emergency intervention should not be described as an exploit.
The restriction applies specifically to Stylus activation. Developers currently cannot activate new Stylus contracts or reactivate expired ones.
Existing activated contracts remain callable until their activation expires, and developers can renew active contracts using Stylus’ keepalive mechanism.
Ordinary Solidity and EVM contract deployment is unaffected. Arbitrum Docs
Stylus allows developers to write Arbitrum smart contracts using WebAssembly-compatible languages such as Rust rather than relying exclusively on Solidity and the EVM.
The Security Council’s intervention followed findings involving specially constructed WASM programs. Arbitrum says reviewed findings posed denial-of-service risk to chain liveness rather than direct loss-of-funds risk.
The Foundation plans to work with ArbitrumDAO on a method for reopening activations while restricting hand-crafted WASM programs capable of triggering the problematic behavior. Arbitrum Docs
TOKEN RECON ASSESSMENT
Preventive security interventions deserve different treatment from exploits.
There is no evidence of stolen funds here, and describing the action as an Arbitrum hack would be wrong.
The more useful signal is that Arbitrum’s emergency governance machinery acted before a disclosed liveness weakness became an active network incident.
Stylus’ broader execution environment is one of Arbitrum’s technical differentiators, so the eventual fix matters. A rapid reopening with narrow restrictions would suggest the issue was successfully contained without compromising the larger Stylus architecture. A prolonged pause or broader redesign would indicate a more consequential engineering problem.
