Arbitrum voters backed a plan to reopen new Stylus smart-contract activations in a preliminary vote that closed on November 5, 2026. The Snapshot ballot recorded about 73.2 million ARB in favor and 54.5 million against, giving the proposal 57.3% support. That result advances the governance process; it does not switch activations back on.
The proposed route would add an independent security review and an Arbitrum Foundation signature before new code could become usable. For developers following Arbitrum's governance and technology, the distinction is consequential: the question is how to reopen a restricted part of the network while controlling the risks that prompted its closure.
Why the Security Council stopped new activations
The Security Council paused new Stylus activations on Arbitrum One and Nova on October 2. Its report described increasingly sophisticated, AI-assisted attacks involving manually constructed WebAssembly programs that bypassed the standard Stylus compiler toolchain. The concern was that such programs could disrupt the network's ability to keep processing transactions.
The report said previously identified Stylus problems primarily affected chain liveness, including denial of service, and that no discovered attack permitted theft of user funds. That is a bounded description of known findings, not a claim that every application or future attack is harmless.
The Council implemented the restriction by raising the activation gas requirement until new activations became prohibitively expensive. It described this as a configuration change rather than a new operating-system release. Earlier software releases had already addressed reported bugs, but the Council said additional caution was warranted.
Deployment, activation and ordinary use are different
Stylus lets developers build smart contracts with languages that compile to WebAssembly, including Rust, C and C++. Its execution environment sits alongside the Ethereum Virtual Machine, or EVM. The two can interact: a Solidity contract can call a Stylus program, and a Stylus program can call Solidity code. Developers can therefore use Stylus for part of an application without moving everything into a different programming language.
Arbitrum's documentation separates deployment from activation. Deployment puts compressed program code on the blockchain. Activation makes that code executable. A program can therefore exist at an on-chain address without being available for users to call. The pause targets the latter step, including activation of a new version of an existing application.
Already-active Stylus contracts remain callable. Their keepalive renewal mechanism also remains open to anyone, while reactivation after expiry is blocked during the pause. The default activation lifetime is 365 days. Ordinary Solidity and EVM deployment and execution are unaffected, according to the official pause notice.
Those distinctions matter when assessing restrictions on layer 2 networks: a block on introducing executable code is different from a halt to all existing applications or transactions.
The proposed gate screens code, not business logic
Offchain Labs posted the Constitutional Arbitrum Improvement Proposal on October 23. An auditor participating in the Arbitrum Security Program would review new Stylus code, with a passing result followed by a Foundation activation signature. The DAO would retain authority to replace or revoke that signing mandate through a constitutional vote.
The limited review would check for threats to the network, including whether standard tooling reproduces the submitted program. It would not certify an application's business logic. The Foundation would not receive authority under this proposal to deactivate a contract after activation.
The design therefore trades unrestricted entry for a review-and-signature dependency. The proposal acknowledges that auditor availability, signing delays or compromised signing arrangements could create problems. Its delegated authority has no automatic expiry. These are governance choices as well as engineering choices, because the people controlling access can affect when builders launch or update software.
The vote is complete, but the chain scope needs clarification
Snapshot's primary vote record shows 931 ballots and approximately 127.6 million ARB of voting power. Voting ran from October 29 to November 5, ending at 20:45 UTC. Nearly 978.4 ARB abstained. These are token-weighted totals, not a claim that 57.3% of individual voters supported the plan.
A discrepancy remains between the two proposal records. The Snapshot text lists Arbitrum One and Nova in its affected-chains section. The current forum version explicitly excludes Nova. The final on-chain proposal and execution payload need to establish the intended scope.
What must happen before activations reopen
The proposal puts implementation materials and an independent audit ahead of the on-chain vote. It gives no fixed date for that vote. Approval, governance execution and operational readiness must follow before the new activation route can be used.
Arbitrum's constitution distinguishes the preliminary poll from a binding proposal. A temperature check uses a simple majority without a participation threshold. Formal on-chain voting has separate approval and quorum requirements, and normally runs for 14 days, with a possible extension when quorum arrives late. Constitutional changes then pass through waiting and execution stages, including steps involving Ethereum.
For builders, the immediate position is unchanged: existing active programs can keep operating, but the preliminary majority is not permission to activate new code. The next substantive evidence will be the final implementation and the formal vote that authorizes it.