[Constitutional] AIP: Stylus Activation Contract

Proposals
1

[Constitutional] AIP: Stylus Activation Contract

Abstract

This Constitutional AIP proposes to resume Stylus contract activations on Arbitrum One following the Security Council’s pause of new activations: Security Council Emergency Action – 2/10/2026. This proposal authorizes a new Stylus Activation Contract and delegates to the Arbitrum Foundation the right to authorize the activation of Stylus contracts that have passed a limited security audit performed by an Arbitrum Security Program auditor (explained in further detail below) and that focuses on whether the code threatens the stability (and security) of the Arbitrum network. The ArbitrumDAO can change or revoke this delegation via a constitutional vote at any time.

Importantly, all existing and activated Stylus smart contracts are not impacted by this proposal or the Security Council action. Any user or developer can continue to use these contracts without restriction, and anyone can continue to renew them through the existing keepalive mechanism. Reactivation of an expired contract, or after a Stylus version change, follows the process in Section 4.

If approved and implemented, this AIP would:

  • Install a new Stylus Activation Contract through which developers can activate new Stylus smart contracts that carry a valid activation signature.

  • Delegate the authority to provide activation signatures for new Stylus smart contracts to a multisig controlled by the Arbitrum Foundation.

  • Preserve the DAO’s authority to change or revoke this delegation at any time via a future constitutional proposal.

The proposal applies to Arbitrum One and uses capabilities already available in ArbOS 61. It does not require an ArbOS version upgrade.

Motivation

On October 2, 2026, the Security Council paused Stylus activations on Arbitrum One and Nova. The details of that action are available at Security Council Emergency Action – 2/10/2026.

Stylus gives developers more ways to build on Arbitrum and enables chain owners to customize their networks and optimize key contracts. We remain confident in its value and want to preserve these use cases while taking preventive measures to help prevent Stylus-based attack vectors as AI-assisted attack tooling continues to quickly and impactfully evolve.

This AIP proposes a path that requires new Stylus smart contract activations to pass a limited, independent security audit before they can be activated. This allows teams who want to deploy a Stylus smart contract a path to do so while addressing risks associated with the evolving tide of AI-assisted attack vectors.

Rationale

New Stylus contract activations are currently paused following the Security Council’s action. To date, no known and reported bugs have affected or put at risk any user funds. Known bugs have affected chain liveness (denial of service).

Under this proposal, each new Stylus smart contract must pass a limited security audit by an Arbitrum Security Program auditor before it can be activated. Once a passing result is posted on the Arbitrum Forum and the conditions in Section 4 are met, the Arbitrum Foundation provides an activation signature confirming that the code is eligible for activation based on the security audit with the final step belonging to the developer that activates the contract. The limited audit confirms, among other things, that the contract was built from its source code with the standard Stylus compiler toolchain and does not contain hand crafted WASM. It is not a full audit of the smart contract’s business logic. The Arbitrum Foundation does not perform the audit and does not make its own assessment of a contract’s security.

Key Terms

  • Activation: The step that compiles deployed Stylus code so it can be executed. Deployment remains open to anyone, but a deployed Stylus contract cannot be called until it is activated.

  • Limited Audit: The limited scope security review described in Section 4, which assesses whether a Stylus contract could harm the Arbitrum protocol. It is not a review of the contract’s business logic.

  • Security Auditor: A security audit firm participating in the Arbitrum Security Program that performs limited audits.

  • Activation signature: An offchain signature by the Arbitrum Foundation confirming that the Stylus code is eligible for activation through the Stylus Activation Contract.

  • Stylus Activation Contract: The proposed contract that performs the sequence of actions needed to activate Stylus code that carries a valid activation signature.

  • Signing right: The authority to provide activation signatures under Section 4. The proposed initial holder is the Arbitrum Foundation.

Specifications

1. Affected chains

The proposal applies to Arbitrum One. Configuration of independently governed Arbitrum chains is handled separately. Arbitrum Sepolia is outside the scope of this proposal but will follow the same activation process (limited audit and activation signature). This proposal also does not apply to Arbitrum Nova because it is minimized.

2. Activation mechanism

The Security Council pause raised the activation gas requirement using ArbOwner.setWasmActivationGas, preventing ordinary activation calls from succeeding.

This proposal will authorize a Stylus Activation Contract to perform the following sequence atomically onchain:

  1. Verify that the caller is authorized to activate the submitted contract.

  2. Temporarily lower the Stylus activation gas requirement.

  3. Activate the approved Stylus contract.

  4. Restore the restrictive activation gas requirement before the transaction completes.

The proposed implementation is designed so that successful calls to the Stylus Activation Contract restore the restriction and unsuccessful calls revert without leaving activation open. The contract will also prevent an authorized activation from being used to activate additional, unapproved code. Any new or upgraded code will require a new limited audit and activation signature.

Final contract details (source code, deployment addresses, configuration, and the governance payload) will be published in this thread after the forum discussion and before the on-chain vote.

3. Arbitrum Foundation’s delegated authority

Item

Proposed arrangement

Signing-right holder

Arbitrum Foundation, through a multisig whose address and signer configuration will be published before the on-chain vote

Scope

Provide activation signatures for deployed Stylus code that meets the conditions in Section 4, so that the developer can activate it via the Stylus Activation Contract

Duration

Ongoing from implementation, until changed or revoked by the DAO; no automatic expiry

DAO control

The DAO can change or revoke the delegation through governance

The DAO is the sole administrator of the Stylus Activation Contract: only the DAO can grant, revoke, or reassign the signing right or change the contract’s configuration. The Arbitrum Foundation manages its own signers within its multisig. Final configuration and addresses will be published before the on-chain vote.

4. Activation process

The proposed activation process is based on a limited, independent security audit. A developer would submit the source code and build configuration for their contract, together with the information reasonably requested by the Arbitrum Foundation and accept the Arbitrum Foundation’s activation terms. A security auditor would then perform a limited audit to assess whether the contract could harm the Arbitrum protocol. At a minimum, the security auditor would confirm the following: rebuild the program with cargo stylus from the submitted commit, confirming the bytecode matches the deployed codehash. Finally, the security auditor will post the result (pass or fail) on the Arbitrum governance forum. If the security auditor posts a passing result, the Arbitrum Foundation would provide the developer with an activation signature and the developer would then activate the contract by submitting the activation transaction through the Stylus Activation Contract. The Arbitrum Foundation does not conduct or verify the business logic of the audit and shall rely on the security auditor’s posted result.

This limited audit is intended to reduce exposure to malicious, hand-crafted WASM. It is not a comprehensive application audit or an assurance that a contract’s business logic is free of bugs. The Arbitrum Foundation does not own, operate or control any activated contract and is not being granted any power to deactivate a contract after it is activated.

Submissions would be processed on a reasonable efforts basis rather than on a fixed schedule; turnaround will depend on submission volume, security auditor capacity and the complexity of the code to be audited.

Developers will be able to submit a request by contacting the Arbitrum Foundation at activations@arbitrum.foundation. If the proposal is approved by the ArbitrumDAO, the Foundation will post the full details of the Stylus Activation Contract Terms of Use here: The Arbitrum Foundation Documents | Arbitrum DAO - Governance docs

5. Existing contracts and future changes

What stays the same

  • Solidity (EVM) contract deployment and execution are unaffected by this activation change.

  • Using/calling any activated Stylus contract, existing or activated through the new process, remains open to all users and developers.

  • Already-active Stylus contracts continue to execute until they expire (365 days after their last activation or renewal on Arbitrum One).

  • Anyone can renew an active Stylus contract through the existing keepalive mechanism. This is unaffected by the pause.

What goes through the activation process

  • New Stylus code that requires activation, including new versions of existing contracts.

  • Reactivating a contract that has expired or needs updating after a Stylus version change.

Future changes

  • Protocol-level activation controls and the ability to deactivate a Stylus contract are planned for a later ArbOS proposal. This AIP does not authorize those changes.

Risks and Tradeoffs

  • Activation dependency: Builders would rely on the availability of the security auditors and the Arbitrum Foundation for new activations. Audit or signing delays, refusals, or loss of access to the signer could delay launches and updates. The ongoing mandate has no automatic expiry, so changing the holder requires governance action.

  • Security limits: The limited audit adds a safeguard but cannot guarantee that every activated contract is safe. A compromised signer could provide an activation signature for harmful code. This proposal does not add a contract deactivation mechanism.

  • Stylus Activation Contract: The Stylus Activation Contract requires chain-owner permissions. Its access controls, callable functions, upgradeability, and handling of the temporary gas change need to enforce the stated scope. These properties are within the scope of the third-party audit, and the published audit report will cover them.

  • Transition period: New activations remain paused until governance execution of this AIP and operational readiness. A vote against this proposal would not itself reverse the Security Council’s parameter change, and a different activation policy would require a separate governance action.

Steps to Implement and Timeline

  1. Forum discussion: An AIP outlining the proposed activation mechanism and process, and delegated authority is posted to the ArbitrumDAO forum for discussion (this post)

  2. Temperature check: Submit the proposal to Snapshot.

  3. Implementation and review: The Stylus Activation Contract and governance payload are finalized and tested. A security audit of the Stylus Activation Contract is conducted by a third-party (Trail of Bits) and the audit report is published for public consumption before the on-chain vote, alongside the source code and deployment addresses.

  4. On-chain vote: Following a successful temperature check and completion of the implementation materials, submit the Constitutional AIP for an on-chain vote.

  5. Governance execution: If approved, complete the required governance waiting periods and execute the proposal to authorize and configure the activation mechanism on each affected chain.

Activations through the new mechanism can begin only after the governance process is executed and the activation process is operational.

Overall Cost

This proposal does not require any new funding from the ArbitrumDAO. The engineering work for the Stylus Activation Contract, and the coordination of its security audit, will be owned by the Arbitrum Foundation and its service providers.

Voting Options

  • FOR: Approve the activation mechanism and delegate the signing right to Arbitrum Foundation on the terms described above.

  • AGAINST: Reject this proposal. This vote does not automatically lift the Security Council’s pause on new activations.

  • ABSTAIN: Participate without supporting or opposing the proposal.

1 Like
Stylus Sprint Retrospective
2

Before the on-chain vote, could the Foundation publish the proposed activation Terms of Use, or at least the criteria for issuing or withholding signatures, a target turnaround after a passing audit, and an appeal or escalation path? The post says the full Terms will be published if the AIP is approved, while the signing delegation has no automatic expiry. Seeing the operating rules before voting would help delegates weigh the chain-liveness benefit against the access and delay costs for builders.

3

Hi @alex17hourslab, thank you for the question. The Foundation will issue an activation signature once a Security Auditor confirms the contract has passed the limited audit and the developer has cleared basic due diligence. The Foundation will publish the Terms of Use shortly and will aim to issue signatures promptly once both steps are complete, on a reasonable-efforts basis. Developers can contact activations@arbitrum.foundation for activation requests.

1 Like
4

I support this proposal, this AIP is directionally reasonable, but it should be discussed as a narrow, revocable safety mechanism rather than a broader governance model. The core issue is not whether Stylus is valuable, it is that the protocol is operating under a specific threat model in which malicious or hand-crafted WASM could threaten chain stability or liveness.

A targeted activation gate is a defensible response to that risk.

The proposed activation framework is a meaningful step toward a safer Stylus reactivation path.

It addresses the most direct protocol-level concern by limiting activation to contracts that pass a limited audit and are approved via a trusted signature flow.

However, it does not remove all risk.

It reduces one class of risk while introducing a new operational dependency on signer discipline and audit quality.

For this reason, the implementation should be treated as a temporary, narrowly scoped safeguard rather than a comprehensive security guarantee.

I have a few governance concerns that I think need explicitly addressing before this can be considered a durable policy:

Recommendation, Proceed only with:

explicit scope limits.

public auditor criteria and published outcomes.

robust signer controls and key-management standards.

public contract and governance payload disclosure before vote.

and a formal review mechanism for the delegated authority.

This keeps the policy aligned with the stated purpose, to restore Stylus safely without creating a broad or permanent centralization of protocol control.

5

I support this temperature check.

A controlled reopening of Stylus activations is a reasonable response to the chain-liveness risks that prompted the pause.

Before final onchain approval, the independent audit should be published with sufficient time for community review, alongside clear approval criteria for developers.

1 Like
6

Voting FOR. Pausing Stylus made sense, and opening it again is always scary, we get to see all the hacks all the time with AI. I’m voting for because we also can’t live and grow on fear. I think the Foundation’s terms are the right approach to bring this back.

Pass/fail on the forum though, I don’t think it’s the right approach. I’d like Arbitrum to do it like most big open source projects (Linux, Bitcoin Core, Ethereum clients, etc) keep a bug private until it’s fixed, then publish the full report.

7

Merlyn Labs is voting FOR this proposal. It’s a balanced way to resume stylus with added security checks + it keeps DAO control.

8

Given how much surface area there is for attack and how few users of stylus there is… IMO we should just leave it deactivated.

It is hard to let go of a product… but sometimes you have to.

Stylus is super cool, but in the end who really uses it?

It is a waste a resources to review it hunt for bugs IMO. i just don’t see enough adoption and usage for it to make sense

1 Like
9

Voting AGAINST (snapshot) in the proposal’s current form. I believe as is, the proposal is missing a few things:

  • Information about the nature of the current vulnerability(s): what is the nature of Stylus’s DOS vulnerabilities such that WASM generated via the compiler is safe, but otherwise-generated WASM is potentially insecure? What level of certainty do we have that running compiled code is safe (without fixing the underlying issue?) If part of the current thinking is that publishing the details of the vulnerability would itself put the system at more risk, I believe that itself may be reason to not yet reactivate Stylus, even in a permissioned state.

  • Future roadmap plans: is the thinking that this is a temporary stopgap while an upgrade to fix Stylus’s vulnerabilities is worked on in parallel, or is the idea that permissioned contract deployment will be the long term state of Stylus? If the former, I would suggest a rough timeline estimate. If the later, I’m not sure it’s worth it to reactivate Stylus in this form, giving the technical risk, operational overhead in manual audits, and even (potential) liability issues. I’m open to being convinced, but I think that discussion should happen here.

2 Likes
DZack23.eth Delegate Communications thread
10

We’ve voted For this temp check as a logical safeguard given the potential vulnerabilities.

One point to carry into the later on-chain vote is how many activation requests have been submitted while the pause has been in effect. That count shows whether builders are actually waiting, and how heavy the queue is likely to be once signing begins.

11

Entropy voted FOR this temperature check.

@Griff raises a fair point on the current state of Stylus adoption. As we outlined in the Stylus Sprint retrospective, the foundational tooling for Stylus is now in place, but demand remains unproven and Stylus has yet to anchor a widely used application. The largest blocker for builders, the 24KB contract size limit, was lifted by ArbOS 61 in August. With activations paused a few weeks later, there was not enough time to gather real evidence of demand under the new size limit. Since every new activation requires an audit with the result posted on the forum, delegates will have a public record of teams building seriously on Stylus, and a much clearer picture of real demand over the coming months.

3 Likes
12

While Cornell Blockchain commends the proactive efforts to unblock Stylus activations, we are voting AGAINST this Constitutional AIP.

We strongly support the structural governance design of the Stylus Activation Contract. Designating the DAO as the sole administrator—with explicit, ongoing authority to modify or revoke the Foundation’s signing delegation at any time via constitutional governance—upholds the standard of decentralized protocol ownership, a tenet we consistently and deeply support. However, we believe that the operational and structural security risks introduced by the interim gatekeeping architecture outweigh the immediate benefits. Beyond rebuilding the code via cargo stylus to verify bytecode codehashes, the proposal leaves the evaluation criteria for what constitutes a network stability risk ambiguous. Without public, deterministic technical specifications for what auditors are screening, the pass/fail determination is too subjective for our comfort. The AIP also lacks an explicit dispute resolution or appeals framework for builders whose contracts are rejected or delayed by participating auditors. This also introduces a single point of failure – if the Foundation multisig faces key loss, internal signer delays, or operational paralysis, the entire new-deployment pipeline for Stylus is frozen

Tldr: Protocol stability and developer trust are better served by keeping activations paused until comprehensive, protocol-native activation and deactivation safeguards can be implemented at the ArbOS layer, or until we can get more information about the process in this proposal.

13

Thanks @Griff and @dzack23.

Why keep Stylus: It’s most valuable for chain owners who customize and optimize key contracts; however, we see value for future Arbitrum One developers too. We’re also exploring ways to make it a more core primitive, such as native Stylus precompiles. Past issues have been chain liveness (DoS) issues; no known issues put user funds at risk. Offchain Labs believes gated activation could significantly reduce this risk and keep the ongoing security and maintenance work manageable.

Why compiler output is expected to be safer: Contracts built with cargo stylus only use a narrow, well-tested subset of WASM. Every issue we’ve seen needed hand-crafted WASM with patterns the compiler never emits. The limited audit, among other tests, rebuilds each contract from source and confirms it matches the deployed codehash, which should close that path.

Long-term? Ultimately it is up to the DAO, which can change or revoke the delegation at any time. Offchain Labs’ view is that gated activation is likely the right long-term path, not a stopgap.

1 Like
14

An independently audited report has now been published for this proposal- https://docs.arbitrum.io/audit-reports/2026_11_06_trail_of_bits_stylus_permissioned_deployer_summary_report.pdf

15

@offchain thanks for publishing the Trail of Bits summary. You wrote that the DAO can change or revoke the delegation at any time, and I think it is worth saying how long “any time” is. Counting the delays the AIP points to (3 days before a vote, 14 of voting, 8 in the Arbitrum One Timelock, about 6.4 for the L2 to L1 challenge period and 3 in the Ethereum Timelock, with 12 second blocks), I get at least 34 days. By comparison, on 2 October the Security Council’s emergency Safe (9 of 12) raised the Stylus activation gas to the maximum in one transaction, with no vote, and a simulated call shows it can still make that call today (I checked on chain: Arbitrum One block 521884286 and Ethereum block 26357903, two nodes each, read-only). That is a much faster brake than a DAO vote, so it matters whether it stays available once the new contract exists. The audit summary covers the contract code and, from what I read, says nothing on who signs, the threshold or how signing can be stopped. If the Foundation’s signing key were compromised after this AIP, is the emergency path meant to be the way to stop it, or only a constitutional vote?

1 Like
16

The following reflects the views of ETHBEAT’s governance team, composed of @krst and @Manugotsuka, and is based on their combined research, fact-checking, and discussion.

We voted AGAINST.

We initially saw this proposal as a reasonable way to reopen Stylus while adding some safeguards. After looking further into the current situation, though, we are not convinced there is enough reason to introduce this new activation model right now.

The pause does not affect existing Stylus contracts, and there is still limited information on how much demand there actually is for new activations. Even the recent Stylus Sprint retrospective points to the need for more time to understand organic usage and adoption.

There are also security questions that we think should be answered first. The proposed audits reduce the risk from handcrafted WASM, but they do not fix the underlying issues that led to the pause. At the same time, developers would now depend on an auditor and the Foundation to activate new code, with no automatic end to that setup.

Given that there is no clear urgency to reopen activations, we would rather keep the pause for now and revisit this once there is a clearer technical path for Stylus and a better understanding of the demand for it.