Stylus Contract Deployments list, Move language on Arbitrum Stylus overview
Stylus Saturdays, 14th July 2025
Hey everyone! Bayge (Farcaster) here. In this week we’ll touch on the following topics:
🗄️ A Stylus smart contract tracker: A new ingestor and web application that tracks the deployment of Stylus on several chains, and can be used to plot the growth on each chain!
⏱️ Moving Stylus by Rather Labs: An in-depth overview of the taking Move to Stylus project by Rather Labs, including some discussion of Move and the team’s development.
Read on, and as always, if you have any feedback about the newsletter, you can share it here:
To recap, Stylus is a Arbitrum technology for building smart contracts in Rust, Zig, C, and C++. Stylus lets you build smart contracts that are 10-50x more gas effective than Solidity smart contracts, with a much broader range of expressiveness from these other languages! Contracts can be written with no loss of interopability with Solidity!
Click here to learn more: https://arbitrum.io/stylus
You can get started very quickly at https://stylusup.sh or by using the official resources at https://docs.arbitrum.io/stylus/gentle-introduction!
Stylus Contract Deployments
I’m pleased to share that I’ve tracked every contract deployment of Stylus on several chains, and made it available as a TSV download using the Superposition in-house ingesting stack. You can find it at https://stylus.fluiditylabs.io! I’ll be having this keep itself up to date and possible to download at any time for everyone to use.
The networks tracked are:
Arbitrum One and Arbitrum Sepolia
Superposition Mainnet and Testnet
It includes everything emitted by the precompile for contract activation, including the codehash, the creation timestamp, the transaction hash, the chain id, etc.
You can register a new chain easily by simply making a pull request to https://github.com/fluidity-money/stylus.fluiditylabs.io/blob/trunk/chains.tsv.
You can download the list at https://stylus.fluiditylabs.io/contracts.tsv.
There are a few interesting facts we can discuss from the data here:
More than 10,000 contracts have been deployed!
10844 contracts have been deployed at the time of writing!
The overwhelming majority of deployments took place on Arbitrum Sepolia, and following that, Superposition Testnet. Superposition Testnet saw several deployments during a period of competition for the ETH Bucharest hackathon, and our internal team regularly uses the testnet, so it would be important to examine this data in the future by examining the unique deployer addresses additionally. Excluding testnet, mainnet deployments across Superposition Mainnet, and Arbitrum One, total 842.
Arbitrum One sees a median of 8 Stylus contracts deployed a week!
Very exciting! We need a good growth indicator of developer awareness to accompany this in the future.
Arbitrum Sepolia sees the bulk of Stylus deployments
Which makes sense. Sepolia is the testing environment where developers can quickly deploy to to test their built Stylus contracts, which our friends The Wizard make very easy to deploy to (and developers have a natural interest to do so). Perhaps a good step would be to improve access to the testnet for developers?
We haven’t recorded interest within the other Orbit chains with Stylus
Stylus is still a new technology and we’re all trailblazers, and frankly, if you’re reading this newsletter, congratulations on being early! From what we’ve seen so far, none of the Orbit chains (except for Superposition) are making use of Stylus, with no deployments recorded on their mainnets. This is a shame, because Stylus’ strengths lies in its range of expressiveness once you understand the range of what you can build with it!
The end of last year was the peak of mainnet deployments per month
The beginning of this year was the peak window of deployments taking place to testnet. Interestingly enough, the last month of last year was when the most deployment activity was recorded for mainnet. I wonder why? From my perspective, our community is only growing.
Move on Stylus, an implementation overview
Rather Labs is bringing the programming language Move to Stylus! Move is a programming language invented at Facebook as a part of the Libra project. It’s a VERY secure programming language, where capabilities are expressed using UTXO-like coins, which are also used to support explicit parallelism in the Move blockchains. The compiler has a type checking stage which can be used to statically enforce access controls. This level of granularity means much safer code than we otherwise have access to!
Let’s break down these concepts:
Capabilities and coins
In a Solidity contract, permissions and ownership might look like this:
contract DogWalker {
address public owner;
constructor() {
owner = msg.sender;
}
event IWalkTheDog();
function walkTheDog() external {
require(msg.sender == owner, "not the dog owner");
emit IWalkTheDog();
}
}Ownership and permissions are stored in the contract storage which is read from, and compared with, the sender. But what if there were a better way? Move’s approach is to give users a “object”, a coin which can be spent to express a capability:
module dog_walker::dog_walker;
use sui::event::emit;
public struct IWalkTheDog has copy, drop {}
public struct CanWalkDogCap has key { id: UID }
fun init(ctx: &mut TxContext) {
transfer::transfer(
CanWalkDogCap { id: object::new(ctx) },
tx_context::sender(ctx)
);
}
entry fun walk_the_dog(_: &CanWalkDogCap) {
emit(IWalkTheDog{});
}In this example, the contract once its initialised, gives the sender the capability object CanWalkDogCap, a object that must be provided to invoke the function walk_the_dog.
Note the ampersand (&) in the function signature and the decorator denoting its an entrypoint function? This designates that the function can be called into by someone invoking the contract, and that the function is dependent on, but must not consume, the coin we received earlier, CanWalkDogCap! So imagine going to call a function, and it’s dependent on you having a token, pretty great! You could drop the & to make it that the coin must be consumed, after which the object would be considered spent, and gone from the user’s account!
You could imagine mocking a complex series of interactions this way, and implementing complex semantics using the capabilities object model. Move even supports the ability to denote that a coin cannot be destroyed by the sender, in that it must be returned to the contract, using a pattern titled the “Hot Potato”. Move has a very expressive landscape for type-annotated programming this way.
Objects and parallelism
With the Move blockchains (Aptos, Sui), spending coins like this tells the nodes how to perform a “pipelining” of operations, where it’s possible to batch execution of smart contracts and transactions in a way where they are processed as they arrive, not sequentially, making better use of the node’s execution compute and database resources. This means potentially a higher throughput when it comes to transaction processing, and it’s baked into the type system! This form of type-enabled high throughput execution is a form of “explicit parallelism”, where the nodes are explicitly told with some information users provide how to execute transactions.
It’s an open question whether ultra high high throughput chains are a victim of the problems associated with filling blocks, or “block stuffing” Block stuffing is where a block must be filled to a certain extent for the node operators to extract enough gas fee compensation to justify their ongoing operation costs. Solana suffers from this problem and subsidises its validator set by diluting the SOL token to send to their validator set on a constant inflationary schedule. Some chains that bill themselves as performance orientated use a method of optimistic parallelism, where the chains optimistically try to batch transactions together, or use a method of hinting to themselves beforehand what things should be. EVM chains like this include Monad, and Pharos.
Arbitrum has a single sequencer model, and does not feature (to my understanding) any explicit or implicit parallelism on the node level. You might argue that it’s not needed, since Arbitrum itself has soft confirmation of transactions, but not instant bundling and execution of them to have a more sustainable model of transaction inclusion, and having a single sequencer means the potential pool of rewards for transactions are maximised for the node. My mind is that OCL’s approach to scaling Arbitrum isn’t to scale the execution of the blocks coming in, but to provide developers with the ability to spin up Orbit chains with their own rules to resolve this issue themselves.
I would say that to have end user visible high throughput, we should focus on executing transactions using alt signature execution methods, and having optimistic transaction inclusion. Which is the approach we can take today with the Orbit chains, and natively on Arbitrum One in a compute efficient way, thanks to Stylus.
Rather Labs and Move on Stylus
Rather Labs are building an Intermediate Representation (IR) compiler from Move bytecode provided by the Sui Move toolchain to WASM. This way, we can deploy Move smart contracts ourselves to Arbitrum!
They’ve been so kind to write a writeup for us documenting their approach, and they’ve been writing consistent status updates, which we’ll paraphrase here.
Move Bytecode
Move Bytecode, from what I gather, in its high level form looks like the following:
Unlike WASM, some of Sui-relevant operations are natively available to the programmer in the operation set, meaning a more bespoke and potentially complex optimisation pipeline, but to the benefit of less code on-chain, assuming the optimisation pipeline does its job. Also unlike WASM, Move’s bytecode format supports static jumps, which was one of the focal points of the Ethereum EOF conversation recently. The intent behind static jumps in the EOF was to support a more obvious control flow in the smart contracts, making static analysis easier. There are some operations access gating mutable and immutable access to objects, which makes sense considering the access control that are needed for the coins we discussed above. The equivalent in a reduced instruction set might be a system call, or a call to a foreign function interface in WASM, which would be needed to perhaps load a specific register before an operation.
Move conversion code
So we’ve established here that the Rather Labs team must surely support a conversion stage that determines the location of the jumps and converts them to relative ones, one that converts some of the high level access control operations to the calling of Rather Labs written stub functions. It seems this is the case, with their pipeline looking like the following:
This approach seems solid, since the Move bytecode could be translated literally into a series of stubs and access control methods baked directly into the contract, since it’s a simple instruction set. The Move-specific functions could be replaced with the using of local functions. This approach also lets the developers build WASM-specific optimisation code themselves, and benefit from an extra optimisation pass post WASM code creation if that’s feasible.
Current status
According to their last update, they’ve supported the basic operations and the entrypoint! A reference repository lives at https://github.com/rather-labs/move-stylus-poc.
I’ve seen from reading their code that they’ve supported local conversion of the Move types to the Ethereum ABI, so the code will be compatible with any Solidity interfaces you might want to use it with.
I’m super excited for how things are going with this project! The Rather Labs team is obviously super talented and extremely qualified to be building something like this.
To stay up to date with their progress, make sure to star their repo here:
Stylus Saturdays is brought to you by… the Arbitrum DAO! With a grant from the Fund the Stylus Sprint program. You can learn more about Arbitrum grants here: https://arbitrum.foundation/grants
Follow me on X: @baygeeth and on Farcaster!
Side note: I develop Superposition, a defi-first chain that pays you to use it. You can check our ecosystem of dapps out at https://superposition.so!
