This AIP outlines a path toward activating Stylus on Arbitrum One and Arbitrum Nova. Stylus is an upgrade that introduces a new virtual machine that runs alongside the EVM. This enables developers to write smart contracts in new programming languages, like Rust, that are more efficient than Solidity smart contracts.
Stylus is a first-of-its-kind technology resulting from breakthrough engineering efforts in the Arbitrum ecosystem. Unlike other alternative VMs, Stylus is purely additive to the EVM. This means that Stylus contracts and EVM contracts are fully interoperable.
Some defining features of Stylus include:
Preferred Languages: There are estimated to be roughly 20k Solidity developers, compared to 3.5 million Rust developers and 10 million C++ developers. Developers can use their preferred programming language, all interoperable with each other, on any Arbitrum chain with Stylus. Scaling to the next billion users requires onboarding the next million developers.
EVM+: Stylus brings the best of both worlds. Developers still get all of the benefits of the EVM, including the ecosystem and liquidity, while getting efficiency improvements and access to existing libraries in Rust, C, and C++ — without changing anything about how the EVM works. EVM equivalence is no longer the ceiling; it's the floor.
Cheaper Execution: Stylus is a more efficient execution environment than the EVM, leading directly to gas savings for complex smart contracts. Computation can be over 10x cheaper, and memory can be over 100x cheaper. Cryptography libraries can be deployed as custom application layer precompiles, permissionlessly. Use cases that are impractical in the EVM are now possible in Stylus.
Safer By Design: Stylus doesn't just improve on cost and speed. WASM programs are also safer. Reentrancy is a common vulnerability that developers can only attempt to mitigate in Solidity. Stylus provides cheap reentrancy detection, and using the Rust SDK, reentrancy is disabled by default, unless intentionally overridden.
Fully Interoperable: Solidity programs and WASM programs are completely composable. If working in Solidity, a developer can call a Rust program or rely on another dependency in a different language. If working in Rust, all Solidity functionalities are accessible out of the box. This means your Rust smart contracts can rely on primitives and infrastructure (such as oracles) that were built using Solidity.
Several exciting teams have been building their apps on the Stylus testnet for the past few months. These apps would simply not be possible on Arbitrum without the added efficiency or new language support. Stylus can onboard (1) the next generation of developers from alternate VM ecosystems and (2) new use cases that users cannot experience on EVM chains.
This proposal is aligned with the Arbitrum community’s mission and values:
Ethereum-Aligned: Stylus does not change anything about how the EVM works. Rather than replacing, Stylus is completely additive and extends what is possible in the EVM.
Sustainable: More efficiency at the execution layer can give Arbitrum chains long-term competitive advantages by allowing higher throughput, cheaper costs, and new use cases that are not possible on other EVM chains.
Accessibility: Arbitrum can become the home for new types of developers who don’t know Solidity. This includes Rust, C, C++, and any other programming language that compiles to WebAssembly.
Inclusivity: The Stylus SDK is 100% open-source, meaning developers are free to fork, modify, and contribute to the core patterns that the SDK represents.
Empowerment: The parameters defined in Stylus are fully configurable by the Arbitrum DAO (for Arbitrum One and Arbitrum Nova) and individual Orbit chains. These customizations can supercharge Stylus by, for example, dropping activation prices, increasing contract size limits, and lowering opcode pricing.
Stylus: A new programming environment, including a WebAssembly-based virtual machine, a CLI, and a canonical SDK that defines the patterns and frameworks for writing smart contracts.
WebAssembly (WASM): WebAssembly is a modern binary format used in significant web standards, browsers, and companies to speed up computation. Built to be fast, portable, and secure.
Virtual Machine (VM): The software that executes smart contracts and processes transactions.
The Stylus VM and fraud prover have been developed as a fork of the Nitro codebase. These repositories will be merged into the main branch of Nitro if the Arbitrum DAO approves the AIP:
The Stylus VM is not a replacement for the EVM. Instead, the two VMs work together to facilitate state transitions, each playing their part in executing their respective bytecode. EVM contracts written in Solidity still use Geth’s EVM exactly as before, ensuring EVM equivalence. In other words, Stylus is entirely additive — a paradigm called EVM+.
Stylus contracts can be written using the Stylus SDK, which employs Solidity-equivalent ABIs and storage patterns to ensure cross-language interoperability. For example, existing Solidity DEXs can list Rust tokens without modification. New SDKs for additional programming languages can be added over time. Current SDK repositories:
If you would like to better understand the lifecycle of a Stylus contract, head over to A Gentle Introduction: Stylus.
There are some relevant components of Stylus that are outlined below:
Stylus contracts can access state or perform operations, which are not possible in pure WASM using Host I/Os. For example, a contract might query the runtime for information about its balance, emit logs, or even call out to other contracts. In these cases the Stylus VM provides Host Input / Output operations, aka Host I/Os, for interacting with the contract’s environment. They are called via standard WASM ABI, which means they are available in all programming languages. For standardization purposes, types are also denoted in Rust form, which can be found in the SDK. Some host I/Os require accessing the EVM, which cannot be implemented entirely on the Rust side. For these, a special system of callbacks (an API) connects Rust to Go.
Stylus introduces a novel VM that provides an opportunity to improve upon the EVM’s quadratic memory model. Rather than using a per-call quadratic memory model, Stylus programs use a global, exponential memory pricing policy. The maximum memory footprint per block is currently set to 8 MB. This footprint reflects all programs ever executed during a transaction rather than being isolated to a per-call-context basis and does not include EVM contracts.
Proving fraud over untrusted WASMs presents novel challenges to the design of the dispute protocol. Arbitrum fraud proofs consist of two phases.
The bisection protocol, wherein the parties narrow down to a single WAVM opcode.
The One Step Proof, wherein L1 contracts emulate that single instruction.
Stylus does not change the bisection protocol or its implementation. All changes are compatible with BOLD and the current system. However, there is one conceptual difference: instead of bisecting over the vanilla replay machine’s execution of a block, user programs are dynamically linked in and out throughout execution.
There are two primary costs when activating user programs: compute and storage.
Activated Stylus programs expire after 1 year. The original compressed WASM is kept around for future reactivation. Like all Stylus parameters, the Arbitrum DAO can configure this expiration period. This policy has two benefits. First, it decreases state bloat by only keeping information necessary for the long term, pruning short-lived contracts over time. Second, the Stylus VM can charge less for activated contract code. Today, the EVM charges 200 gas per byte of contract code, which makes sense for permanent state, but leaves an opportunity to cut costs for Stylus.
The Stylus VM provides 120Mb of temporary storage per hour for activated contract code. If demand for this temporary storage exceeds this limit, the price rises, eventually to a value that exceeds 200 gas per byte.
Stylus is designed to withstand powerful adversaries that can censor Ethereum for up to a week, buy the entirety of Arbitrum’s blockspace indefinitely, or similar worst-case assumptions. Stylus defaults to a configuration intended for this extreme environment, with generous error margins usually exceeding 100%.
Under this configuration, nodes will never exceed 1TB of activated contract code. In practice, the state size will be over an order of magnitude smaller, due to the generous error margins used and realistic user demand.
Along with the data fee for temporary storage, users must also pay for compute when activating a program. This compute component pays for the work done instrumenting the contract and lowering it to the node’s local assembly. For most contracts, this is about 2 million gas, though in some unusual circumstances, the costs may be higher.
This means deploying a Stylus contract end-to-end will generally cost more than in the EVM. However this is only true for the first time a contract is deployed. If multiple contracts share the same code hash, only the first needs to pay for activation. Additionally, for most onchain applications, these economics work out since after a contract has been activated, compute becomes over an order of magnitude cheaper than in the EVM.
Opcode pricing is similar to activation: each opcode takes an amount of time to run, the length of which determines the price. Unlike activation, opcode execution is measured in fractions of a nanosecond and is highly variable. This pricing table for opcodes is informed by the benchmarking numbers found via the benchmarks and runtime crates of the aforementioned ‘stylus-pricer-benchmarks’ branch. Another way pricing has been checked for correctness is by generating trillions of gas worth of instructions and then trying to sync nodes from scratch. In practice, on representative hardware, it was found that almost 360 million gas per second can be synced, or 50x faster than our current speed limit. This implies many opcodes are being overcharged, the prices of which can drop over time as confidence is gained in the model.
Host I/O pricing is more straightforward. Through benchmarking and static analysis, clear bounds on VM affordances can be determined. This file benchmarks all the Rust-only Host I/Os.
If the Arbitrum DAO approves the AIP, the path would consist of:
Stylus is rapidly progressing toward being production-ready. Once it is, ideally the upgrade can take place on Arbitrum Sepolia, and Arbitrum One and Arbitrum Nova afterwards. An onchain vote for this AIP will only occur once there is a public audit report.
NOTE: If this vote passes on Snapshot, the tentative plan is to upgrade Arbitrum Sepolia to arbOS 30 the week of June 10th.
If Arbitrum Sepolia upgrades to arbOS 30, there will be an ecosystem-wide plan to ensure non-breaking compatibility of infrastructure and applications with Stylus, which will take several weeks or months. The ultimate goal is that the experience for EVM developers remains as unchanged as possible if arbOS reaches mainnet. Once enough confidence is reached, there will be an onchain vote to upgrade Arbitrum One and Nova to arbOS 30. The Arbitrum community will be informed of any significant updates as they arise.
This AIP outlines a path toward activating Stylus on Arbitrum One and Arbitrum Nova. Stylus is an upgrade that introduces a new virtual machine that runs alongside the EVM. This enables developers to write smart contracts in new programming languages, like Rust, that are more efficient than Solidity smart contracts.
Stylus is a first-of-its-kind technology resulting from breakthrough engineering efforts in the Arbitrum ecosystem. Unlike other alternative VMs, Stylus is purely additive to the EVM. This means that Stylus contracts and EVM contracts are fully interoperable.
Some defining features of Stylus include:
Preferred Languages: There are estimated to be roughly 20k Solidity developers, compared to 3.5 million Rust developers and 10 million C++ developers. Developers can use their preferred programming language, all interoperable with each other, on any Arbitrum chain with Stylus. Scaling to the next billion users requires onboarding the next million developers.
EVM+: Stylus brings the best of both worlds. Developers still get all of the benefits of the EVM, including the ecosystem and liquidity, while getting efficiency improvements and access to existing libraries in Rust, C, and C++ — without changing anything about how the EVM works. EVM equivalence is no longer the ceiling; it's the floor.
Cheaper Execution: Stylus is a more efficient execution environment than the EVM, leading directly to gas savings for complex smart contracts. Computation can be over 10x cheaper, and memory can be over 100x cheaper. Cryptography libraries can be deployed as custom application layer precompiles, permissionlessly. Use cases that are impractical in the EVM are now possible in Stylus.
Safer By Design: Stylus doesn't just improve on cost and speed. WASM programs are also safer. Reentrancy is a common vulnerability that developers can only attempt to mitigate in Solidity. Stylus provides cheap reentrancy detection, and using the Rust SDK, reentrancy is disabled by default, unless intentionally overridden.
Fully Interoperable: Solidity programs and WASM programs are completely composable. If working in Solidity, a developer can call a Rust program or rely on another dependency in a different language. If working in Rust, all Solidity functionalities are accessible out of the box. This means your Rust smart contracts can rely on primitives and infrastructure (such as oracles) that were built using Solidity.
Several exciting teams have been building their apps on the Stylus testnet for the past few months. These apps would simply not be possible on Arbitrum without the added efficiency or new language support. Stylus can onboard (1) the next generation of developers from alternate VM ecosystems and (2) new use cases that users cannot experience on EVM chains.
This proposal is aligned with the Arbitrum community’s mission and values:
Ethereum-Aligned: Stylus does not change anything about how the EVM works. Rather than replacing, Stylus is completely additive and extends what is possible in the EVM.
Sustainable: More efficiency at the execution layer can give Arbitrum chains long-term competitive advantages by allowing higher throughput, cheaper costs, and new use cases that are not possible on other EVM chains.
Accessibility: Arbitrum can become the home for new types of developers who don’t know Solidity. This includes Rust, C, C++, and any other programming language that compiles to WebAssembly.
Inclusivity: The Stylus SDK is 100% open-source, meaning developers are free to fork, modify, and contribute to the core patterns that the SDK represents.
Empowerment: The parameters defined in Stylus are fully configurable by the Arbitrum DAO (for Arbitrum One and Arbitrum Nova) and individual Orbit chains. These customizations can supercharge Stylus by, for example, dropping activation prices, increasing contract size limits, and lowering opcode pricing.
Stylus: A new programming environment, including a WebAssembly-based virtual machine, a CLI, and a canonical SDK that defines the patterns and frameworks for writing smart contracts.
WebAssembly (WASM): WebAssembly is a modern binary format used in significant web standards, browsers, and companies to speed up computation. Built to be fast, portable, and secure.
Virtual Machine (VM): The software that executes smart contracts and processes transactions.
The Stylus VM and fraud prover have been developed as a fork of the Nitro codebase. These repositories will be merged into the main branch of Nitro if the Arbitrum DAO approves the AIP:
The Stylus VM is not a replacement for the EVM. Instead, the two VMs work together to facilitate state transitions, each playing their part in executing their respective bytecode. EVM contracts written in Solidity still use Geth’s EVM exactly as before, ensuring EVM equivalence. In other words, Stylus is entirely additive — a paradigm called EVM+.
Stylus contracts can be written using the Stylus SDK, which employs Solidity-equivalent ABIs and storage patterns to ensure cross-language interoperability. For example, existing Solidity DEXs can list Rust tokens without modification. New SDKs for additional programming languages can be added over time. Current SDK repositories:
If you would like to better understand the lifecycle of a Stylus contract, head over to A Gentle Introduction: Stylus.
There are some relevant components of Stylus that are outlined below:
Stylus contracts can access state or perform operations, which are not possible in pure WASM using Host I/Os. For example, a contract might query the runtime for information about its balance, emit logs, or even call out to other contracts. In these cases the Stylus VM provides Host Input / Output operations, aka Host I/Os, for interacting with the contract’s environment. They are called via standard WASM ABI, which means they are available in all programming languages. For standardization purposes, types are also denoted in Rust form, which can be found in the SDK. Some host I/Os require accessing the EVM, which cannot be implemented entirely on the Rust side. For these, a special system of callbacks (an API) connects Rust to Go.
Stylus introduces a novel VM that provides an opportunity to improve upon the EVM’s quadratic memory model. Rather than using a per-call quadratic memory model, Stylus programs use a global, exponential memory pricing policy. The maximum memory footprint per block is currently set to 8 MB. This footprint reflects all programs ever executed during a transaction rather than being isolated to a per-call-context basis and does not include EVM contracts.
Proving fraud over untrusted WASMs presents novel challenges to the design of the dispute protocol. Arbitrum fraud proofs consist of two phases.
The bisection protocol, wherein the parties narrow down to a single WAVM opcode.
The One Step Proof, wherein L1 contracts emulate that single instruction.
Stylus does not change the bisection protocol or its implementation. All changes are compatible with BOLD and the current system. However, there is one conceptual difference: instead of bisecting over the vanilla replay machine’s execution of a block, user programs are dynamically linked in and out throughout execution.
There are two primary costs when activating user programs: compute and storage.
Activated Stylus programs expire after 1 year. The original compressed WASM is kept around for future reactivation. Like all Stylus parameters, the Arbitrum DAO can configure this expiration period. This policy has two benefits. First, it decreases state bloat by only keeping information necessary for the long term, pruning short-lived contracts over time. Second, the Stylus VM can charge less for activated contract code. Today, the EVM charges 200 gas per byte of contract code, which makes sense for permanent state, but leaves an opportunity to cut costs for Stylus.
The Stylus VM provides 120Mb of temporary storage per hour for activated contract code. If demand for this temporary storage exceeds this limit, the price rises, eventually to a value that exceeds 200 gas per byte.
Stylus is designed to withstand powerful adversaries that can censor Ethereum for up to a week, buy the entirety of Arbitrum’s blockspace indefinitely, or similar worst-case assumptions. Stylus defaults to a configuration intended for this extreme environment, with generous error margins usually exceeding 100%.
Under this configuration, nodes will never exceed 1TB of activated contract code. In practice, the state size will be over an order of magnitude smaller, due to the generous error margins used and realistic user demand.
Along with the data fee for temporary storage, users must also pay for compute when activating a program. This compute component pays for the work done instrumenting the contract and lowering it to the node’s local assembly. For most contracts, this is about 2 million gas, though in some unusual circumstances, the costs may be higher.
This means deploying a Stylus contract end-to-end will generally cost more than in the EVM. However this is only true for the first time a contract is deployed. If multiple contracts share the same code hash, only the first needs to pay for activation. Additionally, for most onchain applications, these economics work out since after a contract has been activated, compute becomes over an order of magnitude cheaper than in the EVM.
Opcode pricing is similar to activation: each opcode takes an amount of time to run, the length of which determines the price. Unlike activation, opcode execution is measured in fractions of a nanosecond and is highly variable. This pricing table for opcodes is informed by the benchmarking numbers found via the benchmarks and runtime crates of the aforementioned ‘stylus-pricer-benchmarks’ branch. Another way pricing has been checked for correctness is by generating trillions of gas worth of instructions and then trying to sync nodes from scratch. In practice, on representative hardware, it was found that almost 360 million gas per second can be synced, or 50x faster than our current speed limit. This implies many opcodes are being overcharged, the prices of which can drop over time as confidence is gained in the model.
Host I/O pricing is more straightforward. Through benchmarking and static analysis, clear bounds on VM affordances can be determined. This file benchmarks all the Rust-only Host I/Os.
If the Arbitrum DAO approves the AIP, the path would consist of:
Stylus is rapidly progressing toward being production-ready. Once it is, ideally the upgrade can take place on Arbitrum Sepolia, and Arbitrum One and Arbitrum Nova afterwards. An onchain vote for this AIP will only occur once there is a public audit report.
NOTE: If this vote passes on Snapshot, the tentative plan is to upgrade Arbitrum Sepolia to arbOS 30 the week of June 10th.
If Arbitrum Sepolia upgrades to arbOS 30, there will be an ecosystem-wide plan to ensure non-breaking compatibility of infrastructure and applications with Stylus, which will take several weeks or months. The ultimate goal is that the experience for EVM developers remains as unchanged as possible if arbOS reaches mainnet. Once enough confidence is reached, there will be an onchain vote to upgrade Arbitrum One and Nova to arbOS 30. The Arbitrum community will be informed of any significant updates as they arise.
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/34?u=tane
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/34?u=tane
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/33?u=maxlomu
https://forum.arbitrum.foundation/t/savvy-dao-delegate-communication-thread/21266/47?u=savvydao
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/32
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/31?u=blockworksresear
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/29?u=ocandocrypto
Stylus is a virtual machine, but will not alter the EVM aspect of Arbitrum One and Arbitrum Nova. Because of this, it provides an additional
Improving the DevEx by providing more tools and languages options will help to expand the dev pool interested and capable of building on Arb
Easy yes, giving developers better tolling (WASM) is never a bad idea, and obv OCL can do it safely
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/23?u=0x_ultra
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/20?u=jojo
Activating Stylus broadens developer access and enhances smart contract efficiency while maintaining EVM interoperability.
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/19?u=bob-rossi
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/18?u=larva
Strengthening the DAO's governance capabilities and community trust, I have always believed that Arbitrum leads the entire web3 community in
We definitely love a new kind virtual machine, especially it in one the kind.
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/33?u=maxlomu
https://forum.arbitrum.foundation/t/savvy-dao-delegate-communication-thread/21266/47?u=savvydao
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/32
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/31?u=blockworksresear
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/29?u=ocandocrypto
Stylus is a virtual machine, but will not alter the EVM aspect of Arbitrum One and Arbitrum Nova. Because of this, it provides an additional
Improving the DevEx by providing more tools and languages options will help to expand the dev pool interested and capable of building on Arb
Easy yes, giving developers better tolling (WASM) is never a bad idea, and obv OCL can do it safely
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/23?u=0x_ultra
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/20?u=jojo
Activating Stylus broadens developer access and enhances smart contract efficiency while maintaining EVM interoperability.
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/19?u=bob-rossi
https://forum.arbitrum.foundation/t/aip-activate-stylus-and-enable-next-gen-webassembly-smart-contracts-arbos-30/22970/18?u=larva
Strengthening the DAO's governance capabilities and community trust, I have always believed that Arbitrum leads the entire web3 community in
We definitely love a new kind virtual machine, especially it in one the kind.
OpenZeppelin audited the Stylus SDK developed by Offchain Labs. You may read our report on the OpenZeppelin blog or on this forum here: https://forum.arbitrum.foundation/t/stylus-sdk-audit/26674
OpenZeppelin audited the Stylus SDK developed by Offchain Labs. You may read our report on the OpenZeppelin blog or on this forum here: https://forum.arbitrum.foundation/t/stylus-sdk-audit/26674
Super excited to see this proposal, and to see how far Stylus has come now! Fluidity Labs (https://fluidity.money) is building Long Tail AMM, a "fee negative" AMM that pays you to use it. It's currently in testnet, and we've done extensive gas analysis here https://medium.com/@Superpositionso/arbitrums-cheapest-amm-welcome-to-long-tail-33f2b52c4b9f . With Stylus, this concentrated liquidity AMM is 4x less expensive than the alternatives. We also feel very positively about the potential for it to be cheaper than the equivalent on other chains in real USD spent, though this needs review. We're also building https://superposition.so, a Orbit Layer 3 exclusively with Stylus.
Stylus is a game changing technology for the entire Arbitrum ecosystem. Not only can the ecosystem benefit from the effectiveness of the existing rigorous Rust supplychain, it can also benefit from the EVM composability that many existing WASM/Rust solutions suffer with. Having been deep in the weeds with the technology since it became public we're super bullish on the future with this, and are super excited to see this come along in its current state! Congrats to all the technical heavy lifters who are making this feasible!
Chris, founder of Renegade here — we're strongly in favor of the Stylus upgrade!
Renegade is building an "on-chain dark pool", essentially a "zkDEX" that hides all information about the state of the exchange behind zero-knowledge proofs.
Chris, founder of Renegade here — we're strongly in favor of the Stylus upgrade!
Renegade is building an "on-chain dark pool", essentially a "zkDEX" that hides all information about the state of the exchange behind zero-knowledge proofs.
By leveraging ZKPs and MPC for trade privacy, Renegade eliminates front-running, statistical arbitrage, and wallet tracking. In addition to our privacy guarantees, orders in Renegade are "midpoint-pegged", meaning that all trades are guaranteed to clear at Binance prices.
For more information on our system, our docs are a great resource.
Renegade is currently in testnet and has been built for Stylus.
We love the cross-compatibility of the EVM and WASM bytecode; it allows us to leverage pre-existing EVM primitives like builtins and proxies, while maintaining the flexibility to write accelerated ZK verifiers in Rust.
Given that we're verifying zero-knowledge proofs on Arbitrum, the Stylus upgrade will drive our gas usage down by multiple orders of magnitude; without Stylus, Renegade would not be practical.
Stylus is pushing the boundaries of what's possible; we're strongly in favor!
Going beyond the EVM should be considered a groundbreaking innovation in the Ethereum space imho.
We've tested Stylus' performance against the standard EVM for ERC20 functions and ED25519 verification and Stylus provides significant (81%) savings in the latter. Link to the benchmark.
Excited to see this moving forward and contribute towards better devex and adoption.
Interested in Stylus? Check Artela!
https://twitter.com/Artela_Network
They are also doing EVM+WASM, but beyond that! Wasm here is allowed for building native extensions, which means Wasm has more base layer resource and can be injected in the whole execution flow. So Developers can customize the entire transaction and realize more and new functionalities.
Interested in Stylus? Check Artela!
https://twitter.com/Artela_Network
They are also doing EVM+WASM, but beyond that! Wasm here is allowed for building native extensions, which means Wasm has more base layer resource and can be injected in the whole execution flow. So Developers can customize the entire transaction and realize more and new functionalities.
https://artela.network/explore/aspect-hub
We already have Artela ecosystem developers built lots lof interesting use cases with real codes!
Arbitrum continues to be a leader in attracting the most top notch developing teams in all of crypto-- stylus is a huge step forward towards onboarding even more developers. I've been following the development of stylus pretty closely and will do my part supporting discussion around the advancement as I lack in technological knowledge to advocate for specifics about implementation. Arbitrum is freedom and Boop is love 🧡💙
Our team is building a decentralised derivatives exchange CVEX with a VaR margin and other complex stuff on the Arbitrum blockchain. Efficiency and low costs that come with it is a must have for us to be competitive in this niche. That’s why Stylus play a crucial role in our development. Congrats to the Stylus team on this proposal, let’s make this happen!
Super excited to see this proposal, and to see how far Stylus has come now! Fluidity Labs (https://fluidity.money) is building Long Tail AMM, a "fee negative" AMM that pays you to use it. It's currently in testnet, and we've done extensive gas analysis here https://medium.com/@Superpositionso/arbitrums-cheapest-amm-welcome-to-long-tail-33f2b52c4b9f . With Stylus, this concentrated liquidity AMM is 4x less expensive than the alternatives. We also feel very positively about the potential for it to be cheaper than the equivalent on other chains in real USD spent, though this needs review. We're also building https://superposition.so, a Orbit Layer 3 exclusively with Stylus.
Stylus is a game changing technology for the entire Arbitrum ecosystem. Not only can the ecosystem benefit from the effectiveness of the existing rigorous Rust supplychain, it can also benefit from the EVM composability that many existing WASM/Rust solutions suffer with. Having been deep in the weeds with the technology since it became public we're super bullish on the future with this, and are super excited to see this come along in its current state! Congrats to all the technical heavy lifters who are making this feasible!
Chris, founder of Renegade here — we're strongly in favor of the Stylus upgrade!
Renegade is building an "on-chain dark pool", essentially a "zkDEX" that hides all information about the state of the exchange behind zero-knowledge proofs.
Chris, founder of Renegade here — we're strongly in favor of the Stylus upgrade!
Renegade is building an "on-chain dark pool", essentially a "zkDEX" that hides all information about the state of the exchange behind zero-knowledge proofs.
By leveraging ZKPs and MPC for trade privacy, Renegade eliminates front-running, statistical arbitrage, and wallet tracking. In addition to our privacy guarantees, orders in Renegade are "midpoint-pegged", meaning that all trades are guaranteed to clear at Binance prices.
For more information on our system, our docs are a great resource.
Renegade is currently in testnet and has been built for Stylus.
We love the cross-compatibility of the EVM and WASM bytecode; it allows us to leverage pre-existing EVM primitives like builtins and proxies, while maintaining the flexibility to write accelerated ZK verifiers in Rust.
Given that we're verifying zero-knowledge proofs on Arbitrum, the Stylus upgrade will drive our gas usage down by multiple orders of magnitude; without Stylus, Renegade would not be practical.
Stylus is pushing the boundaries of what's possible; we're strongly in favor!
Going beyond the EVM should be considered a groundbreaking innovation in the Ethereum space imho.
We've tested Stylus' performance against the standard EVM for ERC20 functions and ED25519 verification and Stylus provides significant (81%) savings in the latter. Link to the benchmark.
Excited to see this moving forward and contribute towards better devex and adoption.
Interested in Stylus? Check Artela!
https://twitter.com/Artela_Network
They are also doing EVM+WASM, but beyond that! Wasm here is allowed for building native extensions, which means Wasm has more base layer resource and can be injected in the whole execution flow. So Developers can customize the entire transaction and realize more and new functionalities.
Interested in Stylus? Check Artela!
https://twitter.com/Artela_Network
They are also doing EVM+WASM, but beyond that! Wasm here is allowed for building native extensions, which means Wasm has more base layer resource and can be injected in the whole execution flow. So Developers can customize the entire transaction and realize more and new functionalities.
https://artela.network/explore/aspect-hub
We already have Artela ecosystem developers built lots lof interesting use cases with real codes!
Arbitrum continues to be a leader in attracting the most top notch developing teams in all of crypto-- stylus is a huge step forward towards onboarding even more developers. I've been following the development of stylus pretty closely and will do my part supporting discussion around the advancement as I lack in technological knowledge to advocate for specifics about implementation. Arbitrum is freedom and Boop is love 🧡💙
Our team is building a decentralised derivatives exchange CVEX with a VaR margin and other complex stuff on the Arbitrum blockchain. Efficiency and low costs that come with it is a must have for us to be competitive in this niche. That’s why Stylus play a crucial role in our development. Congrats to the Stylus team on this proposal, let’s make this happen!
Please see responses to the following questions -
Please see responses to the following questions -
The audit and any additional code changes will be wrapping up in the coming weeks. After some further testing, there will be a snapshot vote to enable arbOS 30 on Arbitrum Sepolia.
On app prototypes, ses, several projects building with Stylus like Renegade have commented on this forum post.
Stylus is part of the arbOS 30 upgrade. Nodes are required to upgrade to the latest version of arbOS and will have sufficient time to do so. Please see https://docs.arbitrum.io/run-arbitrum-node/arbos-releases/overview for more information on how arbOS upgrades work.
Hey all, here's the link to the recording of the governance call - https://drive.google.com/file/d/1jZrjdvxp43eTNaw4cUpN2ktZj3rV63Xx/view?usp=sharing
Hey everyone, we will be organizing a governance call to walk through this proposal, as well as answer any questions from the DAO.
Date: 9 Apr 2024, Tuesday Time: 5:00 pm UTC Link to join: https://meet.google.com/cvk-duuf-pma
This event has also been shared on the ArbitrumDAO Governance Community Calendar.
Please see responses to the following questions -
Please see responses to the following questions -
The audit and any additional code changes will be wrapping up in the coming weeks. After some further testing, there will be a snapshot vote to enable arbOS 30 on Arbitrum Sepolia.
On app prototypes, ses, several projects building with Stylus like Renegade have commented on this forum post.
Stylus is part of the arbOS 30 upgrade. Nodes are required to upgrade to the latest version of arbOS and will have sufficient time to do so. Please see https://docs.arbitrum.io/run-arbitrum-node/arbos-releases/overview for more information on how arbOS upgrades work.
Hey all, here's the link to the recording of the governance call - https://drive.google.com/file/d/1jZrjdvxp43eTNaw4cUpN2ktZj3rV63Xx/view?usp=sharing
Hey everyone, we will be organizing a governance call to walk through this proposal, as well as answer any questions from the DAO.
Date: 9 Apr 2024, Tuesday Time: 5:00 pm UTC Link to join: https://meet.google.com/cvk-duuf-pma
This event has also been shared on the ArbitrumDAO Governance Community Calendar.
I would like to clarify if this is enough for normal contract compatibility? Is there another way to solve this problem other than to indicate that it is in the documentation.
I would like to clarify if this is enough for normal contract compatibility? Is there another way to solve this problem other than to indicate that it is in the documentation.
DAOplomats voted in favor on Snapshot.
Opening the doors to developers building with other programming languages is a good initiative. We also like the fact that the stylus and EVM contracts are interoperable; that will come in really handy. Great work!
Additional feedback here.
We voted for this proposal, Stylus definitely opens doors for more developers by supporting more languages, boosting efficiency and cutting costs. Understanding next steps for the community to jump into Stylus as a whole plan will expand Arbitrum’s builders community.
Additional feedback here.
We voted for this proposal, Stylus definitely opens doors for more developers by supporting more languages, boosting efficiency and cutting costs. Understanding next steps for the community to jump into Stylus as a whole plan will expand Arbitrum’s builders community.
Adding link to the reasoning and some feedback here: https://forum.arbitrum.foundation/t/savvy-dao-delegate-communication-thread/21266/46?u=savvydao
Michigan Blockchain favors this proposal because of the benefit this provides to developers, who have the option to continue using standard Solidity smart contracts or switching to Rust, which is operationally more efficient. Stylus will massively increase the amount of developers that can develop on the Arbitrum chain, and this benefit can be passed down to the user and the whole ecosystem overall.
The Princeton Blockchain Club is voting FOR activating Stylus!
As mentioned before, we at PBC are very excited to see the EVM+ approach come to life! Allowing folks to use a whole new execution environment while also being compatible with the Ethereum Virtual Machine is a game changer. Already seeing some awesome designs that make use of all the performance improvements / cost-savings that Stylus gets us.
We vote FOR the proposal on its Snapshot.
Stylus is an ambitious, yet rational innovation that Offchain Labs has developed to make Arbitrum even more attractive to Rust and C++ developers. We’d hope that the technology will be integrated into other L2 chains so that the smart contract composability will remain as we have on the EVM platforms.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’re voting FOR this proposal.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’re voting FOR this proposal.
Stylus is a long-awaited upgrade which, when activated on Arbitrum One and Arbitrum Nova, will open the gates to non-solidity developers and enable them to write smart contracts in other, more efficient languages. We appreciate the EVM+ approach and hope to see more initiatives in the future have a similar approach.
Blockworks Research will be voting FOR this proposal on Snapshot.
This is a no-brainer for us. We’re particularly excited about increasing accessibility for new developers, which is crucial for growing the already vast ecosystem and ultimately attracting new users.
Stylus significantly improves Arbitrum by supporting Rust, C, and C++, expanding the developer community, enhancing performance, reducing costs, and improving security, all while maintaining EVM compatibility. This fosters innovation without disruption, ensuring Arbitrum's success. So we will vote FOR this proposal.
I decided to vote FOR this proposal.
Stylus is becoming an important framework to bring new developers from the traditional world into this ecosystem. Therefore, in my understanding, it aligns with the future of Arbitrum and benefits everyone.
Enabling Stylus and other WebAssembly smart contracts like Rust to operate alongside the EVM will increase developer engagement and allow for a broader range of protocols, thus significantly expanding our audience.
Voted "for"... This upgrade reduces costs, enhances security, and expands developer accessibility, making Arbitrum more inclusive and competitive. Stylus retains full interoperability with existing EVM contracts, fostering innovation without disrupting current operations.
DAOplomats voted in favor on Snapshot.
Opening the doors to developers building with other programming languages is a good initiative. We also like the fact that the stylus and EVM contracts are interoperable; that will come in really handy. Great work!
Additional feedback here.
We voted for this proposal, Stylus definitely opens doors for more developers by supporting more languages, boosting efficiency and cutting costs. Understanding next steps for the community to jump into Stylus as a whole plan will expand Arbitrum’s builders community.
Additional feedback here.
We voted for this proposal, Stylus definitely opens doors for more developers by supporting more languages, boosting efficiency and cutting costs. Understanding next steps for the community to jump into Stylus as a whole plan will expand Arbitrum’s builders community.
Adding link to the reasoning and some feedback here: https://forum.arbitrum.foundation/t/savvy-dao-delegate-communication-thread/21266/46?u=savvydao
Michigan Blockchain favors this proposal because of the benefit this provides to developers, who have the option to continue using standard Solidity smart contracts or switching to Rust, which is operationally more efficient. Stylus will massively increase the amount of developers that can develop on the Arbitrum chain, and this benefit can be passed down to the user and the whole ecosystem overall.
The Princeton Blockchain Club is voting FOR activating Stylus!
As mentioned before, we at PBC are very excited to see the EVM+ approach come to life! Allowing folks to use a whole new execution environment while also being compatible with the Ethereum Virtual Machine is a game changer. Already seeing some awesome designs that make use of all the performance improvements / cost-savings that Stylus gets us.
We vote FOR the proposal on its Snapshot.
Stylus is an ambitious, yet rational innovation that Offchain Labs has developed to make Arbitrum even more attractive to Rust and C++ developers. We’d hope that the technology will be integrated into other L2 chains so that the smart contract composability will remain as we have on the EVM platforms.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’re voting FOR this proposal.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’re voting FOR this proposal.
Stylus is a long-awaited upgrade which, when activated on Arbitrum One and Arbitrum Nova, will open the gates to non-solidity developers and enable them to write smart contracts in other, more efficient languages. We appreciate the EVM+ approach and hope to see more initiatives in the future have a similar approach.
Blockworks Research will be voting FOR this proposal on Snapshot.
This is a no-brainer for us. We’re particularly excited about increasing accessibility for new developers, which is crucial for growing the already vast ecosystem and ultimately attracting new users.
Stylus significantly improves Arbitrum by supporting Rust, C, and C++, expanding the developer community, enhancing performance, reducing costs, and improving security, all while maintaining EVM compatibility. This fosters innovation without disruption, ensuring Arbitrum's success. So we will vote FOR this proposal.
I decided to vote FOR this proposal.
Stylus is becoming an important framework to bring new developers from the traditional world into this ecosystem. Therefore, in my understanding, it aligns with the future of Arbitrum and benefits everyone.
Enabling Stylus and other WebAssembly smart contracts like Rust to operate alongside the EVM will increase developer engagement and allow for a broader range of protocols, thus significantly expanding our audience.
Voted "for"... This upgrade reduces costs, enhances security, and expands developer accessibility, making Arbitrum more inclusive and competitive. Stylus retains full interoperability with existing EVM contracts, fostering innovation without disrupting current operations.
Voting for Stylus will enable the next step in Arbitrum's development. I can't wait to see what will be built with this technology!
Voted FOR. Improving the DevEx by providing more tools and languages options will help to expand the dev pool interested and capable of building on Arbitrum.
In favor of this as previously stated.
Can't wait to see Stylus live!
Stylus is the way to move forward and to onboard the next 1 gazzillion devs.
I am just a cow, and even I know C++. No reason to vote against, knowing that OCL will go for the robust path of testing and auditing that so far has guaranteed the success of arbitrum tech wise.
Decise "for" on Stylus.
Voting "For"
Stylus is a clear quality of life upgrade to the Arbitrum network and something that can help set Arbitrum apart from other projects. I see no reason to vote against this and look forward to the audits / inclusion in the upcoming upgrade.
I agree with others that it may be worth looking into ways to message this feature to the broader space.
We think is a no brainer and super easy yes. Our positive support is in line with much of the prior comments.
One things that we want to consider and ask about is, is it worth thinking about how we want to onboard devs that are familiar in rust and other languages over to Arbitrum? There are vast pools of talent and the quicker we can outreach, the quicker we can accelerate on this front.
On behalf of the UADP:
Stylus is an incredible improvement and allows devs from different ecosystems get more involved with the DAO. This is truly one of the most exciting recent innovations in the DAO and we're excited to see what comes out of this. An important focus now will be marketing and onboarding new projects, of which we're interested in what's been done?
Voting For
Stylus is an incredibly exciting development for Arbitrum, can't wait to see more developers adopting it.
Voting "For"
Activating Stylus broadens developer access and enhances smart contract efficiency while maintaining EVM interoperability.
Voting for Stylus will enable the next step in Arbitrum's development. I can't wait to see what will be built with this technology!
Voted FOR. Improving the DevEx by providing more tools and languages options will help to expand the dev pool interested and capable of building on Arbitrum.
In favor of this as previously stated.
Can't wait to see Stylus live!
Stylus is the way to move forward and to onboard the next 1 gazzillion devs.
I am just a cow, and even I know C++. No reason to vote against, knowing that OCL will go for the robust path of testing and auditing that so far has guaranteed the success of arbitrum tech wise.
Decise "for" on Stylus.
Voting "For"
Stylus is a clear quality of life upgrade to the Arbitrum network and something that can help set Arbitrum apart from other projects. I see no reason to vote against this and look forward to the audits / inclusion in the upcoming upgrade.
I agree with others that it may be worth looking into ways to message this feature to the broader space.
We think is a no brainer and super easy yes. Our positive support is in line with much of the prior comments.
One things that we want to consider and ask about is, is it worth thinking about how we want to onboard devs that are familiar in rust and other languages over to Arbitrum? There are vast pools of talent and the quicker we can outreach, the quicker we can accelerate on this front.
On behalf of the UADP:
Stylus is an incredible improvement and allows devs from different ecosystems get more involved with the DAO. This is truly one of the most exciting recent innovations in the DAO and we're excited to see what comes out of this. An important focus now will be marketing and onboarding new projects, of which we're interested in what's been done?
Voting For
Stylus is an incredibly exciting development for Arbitrum, can't wait to see more developers adopting it.
Voting "For"
Activating Stylus broadens developer access and enhances smart contract efficiency while maintaining EVM interoperability.
I voted FOR this proposal on Snapshot. Stylus makes Arbitrum accessible to a new, huge community of developers while ALSO improving performance. Stylus is one of the most exciting recent innovations in crypto.
Glad to see the pace of shipping innovative solutions from OCL.
This is the type of 0 to 1 innovation that I love to see, and the fact that Stylus is purely additive to the EVM is just mind blowing.
Kudos to the Offchain Labs team and all teams that contributed to this, I'll be looking forward to seeing what type of projects will be building with Stylus.
This is the type of 0 to 1 innovation that I love to see, and the fact that Stylus is purely additive to the EVM is just mind blowing.
Kudos to the Offchain Labs team and all teams that contributed to this, I'll be looking forward to seeing what type of projects will be building with Stylus.
I'd love to discuss how, as a DAO, we can bring more awareness of this to both non-web3 devs and existing Rust-built projects on other ecosystems.
This proposal enables developers to write smart contracts in new programming languages, like Rust, that are more efficient than Solidity smart contracts. This has important implications for the Arbitrum ecosystem to thrive. I've voted FOR!
This is quite good for all the reasons posted by others.
What probably we want to do is to match this initiative with specific marketing campaigns, specifically on twitter but also in other communities, to advertise this novelty. It can be the best thing after bread and butter but if others don't know it exists is not gonna be effective.
I looked at this proposal attentively. Great idea. I have questions about implementation:
Extremely excited to see Stylus finally getting put to vote! The EVM+ approach is a great middle ground between making small improvements to the EVM, and completely swapping it out for a different execution environment.
We have a few Rustaceans in the club experimenting with Stylus, and we can't wait to see what developers can do with all these performance improvements!
Really amazing to see the fruition of this long-running project
Super excited about stylus and all it has to offer. The proposal has my full support and can't wait to see how it performs in action
Will also be worth having support programs for dapps building on stylus or integrating with it in some way
I voted FOR this proposal on Snapshot. Stylus makes Arbitrum accessible to a new, huge community of developers while ALSO improving performance. Stylus is one of the most exciting recent innovations in crypto.
Glad to see the pace of shipping innovative solutions from OCL.
This is the type of 0 to 1 innovation that I love to see, and the fact that Stylus is purely additive to the EVM is just mind blowing.
Kudos to the Offchain Labs team and all teams that contributed to this, I'll be looking forward to seeing what type of projects will be building with Stylus.
This is the type of 0 to 1 innovation that I love to see, and the fact that Stylus is purely additive to the EVM is just mind blowing.
Kudos to the Offchain Labs team and all teams that contributed to this, I'll be looking forward to seeing what type of projects will be building with Stylus.
I'd love to discuss how, as a DAO, we can bring more awareness of this to both non-web3 devs and existing Rust-built projects on other ecosystems.
This proposal enables developers to write smart contracts in new programming languages, like Rust, that are more efficient than Solidity smart contracts. This has important implications for the Arbitrum ecosystem to thrive. I've voted FOR!
This is quite good for all the reasons posted by others.
What probably we want to do is to match this initiative with specific marketing campaigns, specifically on twitter but also in other communities, to advertise this novelty. It can be the best thing after bread and butter but if others don't know it exists is not gonna be effective.
I looked at this proposal attentively. Great idea. I have questions about implementation:
Extremely excited to see Stylus finally getting put to vote! The EVM+ approach is a great middle ground between making small improvements to the EVM, and completely swapping it out for a different execution environment.
We have a few Rustaceans in the club experimenting with Stylus, and we can't wait to see what developers can do with all these performance improvements!
Really amazing to see the fruition of this long-running project
Super excited about stylus and all it has to offer. The proposal has my full support and can't wait to see how it performs in action
Will also be worth having support programs for dapps building on stylus or integrating with it in some way
