Welcome Move to Arbitrum

On February 5th, we opened the Move compiler for Stylus, a feature of the Arbitrum platform that enables builders to write smart contracts in programming languages that compile to WASM, including Rust, C, and C++.The Rather Labs team has been developing this project throughout 2025, and we are finally proud to open this repository for everyone to use this new tool for the Arbitrum ecosystem. Click here to access it.

The Move compiler will enable developers that are familiar with Move to create new applications or port existing ones with minimal effort onto the Arbitrum platform. The base Move implementation used is the one by the SUI blockchain as SUI is one of the main ecosystems using the Move language. Despite being in its beta phase, the compiler offers an excellent chance to begin exploring the potential of the Move language within an EVM environment.

Why Move?

Designed by Meta, Move is the language that was created for the Diem blockchain before the project was discontinued. It takes its name from the Rust’s Move semantics. The language is specifically designed to manage digital resources, making it an excellent choice to build new onchain applications as it helps the programmer create more robust and secure smart contracts by catching errors in compile time and enabling patterns such as Hot Potato or Capability.

The Compiler

The compiler has three main components:

• The compiler: this is a library that compiles the Move code to WASM.
• The CLI: a move-to-Stylus command line interface that makes working with the compiler easier.
• The Stylus Framework: A Move library that provides all the utilities needed to interact with the EVM environment.

The challenges

Developing this compiler posed several challenges, namely, the objective of maintaining compatibility with Move’s resource-centric model while compiling the language to a completely different environment.

The object model

One of the most challenging features was how to represent the SUI Move object model in an EVM environment, while respecting its semantics and maintaining compatibility.

In a nutshell, the SUI’s object model mandates that everything that can be saved in storage must be an object with an identifier, and those must have an owner: an account, shared ownership (everyone can read and write the object) and read only ownership (known as frozen object).

Importantly,  SUI objects are global, meaning that any contract can reference any object by its id, but in EVM, an object is part of the contract’s storage. This is a limitation that we can’t overcome, because it is part of the blockchain architecture. Additionally, to implement the object model, we divided the storage into namespaces: one for the objects belonging to an account (each account has its own namespace), one for the shared objects, and one for the frozen objects.

Conceptually, the storage is represented by the following Solidity mapping:

mapping(bytes32 => mapping(bytes32 => Object<T>)) public Objects;

This nested approach serves two primary purposes:

• Ownership Partitioning: The outer mapping is keyed by the owner identifier. This can be an account address or an object UID (or precomputed NamedId) in the case of wrapped objects.
• Object Retrieval: The inner mapping is keyed by the unique Object UID (or precomputed NamedId), ensuring that data for specific assets can be retrieved effortlessly.

Namespacing objects also guarantee that only the owner is allowed to interact with their objects.

Maintaining compatibility with EVM

This compiler can interact seamlessly with other Move and Solidity contracts. To accomplish this feat, we introduced several new features that were not present in the original implementation. To name a few of them:

NamedIds

Every object is identified by a unique identifier represented by the UID object. To interact with objects, one needs to pass the object ID as an argument to the function you want to call. This restriction made the implementation of contracts that follow standard interfaces such as ERC-20 or ERC-721 a real challenge.

The solution was to add a generic struct NamedId<T>. This struct is used when the storage location of an object must be deterministic and predictable and allows the system or other contracts to retrieve an object without requiring the user to manually provide its UID on every transaction.

Cross contract calls

Move’s native mechanism to perform cross contract calls is completely different from the EVM’s one. To achieve this, a whole new module in the Stylus Framework was developed to allow common calls in addition to delegated calls.

An important thing to have in mind is that it is not recommended to use delegate calls with contracts that are not developed with this compiler, since the storage layout is different from a Solidity’s one.

To explore more EVM specifics, you can explore the Rather Labs documentation.

Implementation

Translating from Move Bytecode to WASM is not as straightforward as it looks like. There are several hidden details that make the task specially challenging. For example, WASM does not allow unstructured control flow (i.e.: jumping to arbitrary points in the code) but Move Bytecode does. Therefore, the solution required the implementation of Emscripten’s relooper algorithm.

Final thoughts

We believe that incorporating languages like Move into the Arbitrum platform will help drive adoption from external ecosystems while improving the security of blockchain application development. Just like the Linux kernel adopted Rust, blockchain technology can benefit from adopting languages that provide extra safety to help catch errors before they are deployed.