Welcome Move to Arbitrum

On February 2nd 2026, we opened the Move compiler for the Stylus platform. A project that we've been working on during the entire 2025 year. This project will allow developers that are familiar with the language to create new projects or port existing ones with minimal effort onto Arbitrum’s rich ecosystem. 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 for starting new projects 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 itself: this is a library that compiles the Move code to WASM.
• The move-stylus CLI: a CLI tool that makes working with this 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, since the objective was to maintain compatibility as much as we could while porting everything 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, respecting its semantics while 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).

The first thing to take into account is that in 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. Then , to implement the object model, we divided the storage in 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. This involved introducing several new features that were not present in the original implementation we used as a foundation. 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 impossible. 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 whereas 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 check the 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 these technologies into the EVM space will help make the space more secure and will bring developers from other spaces to collaborate. Just like the Linux kernel adopted Rust, blockchain technology can benefit from adopting languages that provide an extra layer of security and help catching errors before they are deployed.