Arbitrum Pauses New Stylus Contracts in Emergency Security Action

Arbitrum Stylus pause blocks activation, not existing execution

The official pause notice says new and expired Stylus contracts cannot be activated while the restriction remains. Active contracts can still be called, and their keepalive renewal mechanism remains available before expiry.

That creates a practical distinction for application teams: an existing service can keep working even though its next Stylus version cannot become callable. Solidity contracts using the Ethereum Virtual Machine retain their deployment and execution paths.

Arbitrum’s Stylus introduction explains why activation is a separate step. Developers compile programs into WebAssembly and post that code on-chain. Activation then prepares it for execution and adds checks for resource use, including computation and memory.

Stylus supports languages such as Rust, C and C++, with Rust having the most developed tooling. Its second execution environment works alongside the EVM, allowing Solidity and Stylus contracts to call one another. The performance benefit is concentrated in computation-heavy workloads rather than ordinary storage operations.

Those distinctions mean a published contract address alone does not demonstrate that a newly deployed Stylus application is usable. The program also needs an active execution status. Builders face an interruption to that activation path, rather than a blanket ban on all Arbitrum development.

An activation normally lasts 365 days, and keepalive has a default minimum age of about 31 days. Teams maintaining active applications therefore need to distinguish renewal before expiry from reactivation after it, which the pause blocks.

The difference between application and network restrictions also appeared in Ostium’s trading halt. An application incident on Arbitrum does not by itself establish that the underlying network has stopped; here, the restriction originates at the protocol level but targets a specific developer operation.

BoLD guard can delay unconfirmed Ethereum withdrawals

The second measure installs a permissionless guard for Arbitrum One’s one-step proof. Anyone can present two conflicting answers to the same challenged step. If the proof accepts both, the guard can pause settlement to Ethereum while the Security Council prepares a fix.

Arbitrum says local transaction processing would continue under that condition, but unconfirmed messages to Ethereum, including withdrawals, would wait. Installing the mechanism does not itself establish that it has fired or that ordinary withdrawals have been suspended.

The BoLD documentation describes the wider dispute system. Validators post claims about chain state, challenge invalid claims and participate in confirming correct ones on the parent chain. BoLD stands for Bounded Liquidity Delay.

The protocol replaced a dispute model limited to approved validators with permissionless participation. Its design bounds the time needed to resolve disputes, reducing the ability of an adversary to prolong confirmation through repeated challenges.

The new guard adds a response to contradictory accepted proofs. Analytically, it trades uninterrupted settlement for time to correct a demonstrated inconsistency. A running application and a withdrawal finalized on Ethereum remain different operational milestones.

That is also distinct from Blast’s announced shutdown, which carries an exit timetable and an interface cutoff. Arbitrum has announced a temporary feature restriction and a conditional safety mechanism, not a network wind-down deadline.

Stylus reopening awaits ArbitrumDAO’s next steps

Arbitrum has used emergency configuration changes before. Its October 13, 2025 report described a Stylus bug triggered on the Sepolia test network that could produce chain divergence through inconsistent gas consumption.

That response changed a maximum stack-depth parameter on One and Nova. The council said funds had not been at risk. The earlier event provides operational precedent, but it does not establish that the October 2026 restriction addresses the same bug.

The Security Council’s governance documentation describes a 12-member elected body authorized to address critical protocol risks through emergency and non-emergency actions. It remains subject to DAO oversight, including mechanisms for removing members.

For developers, the next useful disclosure is a reopening plan with clear requirements for which programs can activate. For users, the separate issue is whether settlement remains available and whether any conditional pause is actually triggered. Neither can be answered by the presence of a new guard alone.

Source: Alternative.me, checked October 3. Its Bitcoin-focused index fell from 72 to 67 and remains in Greed; it is not an Arbitrum security or loss measure.

The Foundation says it will work with ArbitrumDAO on reopening activations while restricting hand-crafted WebAssembly attack paths. No reopening date was disclosed. The next material developments are that decision, evidence of any triggered settlement pause, and independently supported changes to the loss-impact picture.