Move Meets Arbitrum Stylus: Rather Labs Deploys First ERC-20

For the first time, a fully functional ERC-20 contract written in Move can be compiled and executed natively on Arbitrum Stylus.

This achievement marks a major milestone in the Move-to-Stylus Compiler project, led by Rather Labs with the support of the Arbitrum DAO grant program, and represents a concrete step toward a future where Move developers can deploy their contracts directly on Arbitrum, without friction or rewrites.

‍

Why It Matters

Move, originally designed for the Diem (Meta) ecosystem, introduces a resource-oriented programming model that ensures digital asset safety and ownership rules at compile time.

Stylus, on the other hand, enables contracts compiled to WASM (Rust, C++, and now Move) to run alongside Arbitrum’s EVM ecosystem, combining Solidity compatibility with greater efficiency and expressiveness.

Bringing Move to Stylus expands the language’s reach into the most active Layer-2 environment, unlocking new possibilities for developers, tools, and protocols to coexist under a unified runtime.

‍

An ERC-20 Written in Move

As the latest milestone, the Rather Labs team successfully compiled and deployed a standard ERC-20 contract, fully implemented in Move, within the Stylus environment.

The contract follows the same interface and behavior expected by any EVM-compatible dApp or service, from wallets to explorers, demonstrating full interoperability between Move and Solidity at the ABI and execution level.

This outcome validates the compiler’s maturity and establishes the foundation for building a Move SDK for Stylus, paving the way for more complex contracts and native financial protocols.

‍

Move on Stylus vs. EVM: The Essentials in Two Code Snippets

To better understand what makes this achievement unique, let’s look at two core fragments that highlight how Move integrates with the EVM world through Stylus, maintaining full compatibility while leveraging Move’s stronger type system and resource model.

VM-Compatible Events and Transaction Context

In Stylus, #[ext(event)] maps directly to EVM logs with indexed topics, while TxContext.sender() acts as Move’s equivalent of msg.sender.

The #[ext(event)] attribute is used to inform the compiler that the decorated structure will be used as an event. It also specifies how many of the arguments will be indexed topics, replicating the ERC-20 standard behavior and ensuring full compatibility with the EVM ecosystem’s indexers, wallets, and explorers.

Key takeaway:

• #[ext(event)] → emits EVM-compatible events (Transfer, Approval, etc.).
• TxContext.sender() → fully equivalent to msg.sender, allowing Solidity logic to port naturally into Move.

use stylus::tx_context::TxContext;
use stylus::event::emit;

#[ext(event, indexes = 2)]
public struct Transfer has copy, drop {
    from: address,
    to: address,
    value: u256
}

public fun transfer(
    recipient: address,
    amount: u256,
    tx_context: &TxContext,
    balance: &mut Balance,
): bool {
    let sender = tx_context.sender();
    let s_bal = field::borrow_mut<BALANCE_, address, u256>(&mut balance.id, sender);
    if (*s_bal < amount) { abort(EInsufficientFunds) };
    *s_bal = *s_bal - amount;

    if (field::exists_(&balance.id, recipient)) {
        let r_bal = field::borrow_mut(&mut balance.id, recipient);
        *r_bal = *r_bal + amount;
    } else {
        field::add(&mut balance.id, recipient, amount);
    };

    emit(Transfer { from: sender, to: recipient, value: amount });
    true
}

‍

Typed Storage: dynamic_field and Table Instead of Mappings

To ensure compatibility with EVM interfaces, the concept of NamedId is introduced.
Unlike UIDs, which are always unique and generated dynamically, NamedIds are statically computed values known by the compiler.

This means that contract functions receiving objects identified by a NamedId don’t need that ID to be passed explicitly as a parameter, the compiler already knows the value and where to locate the corresponding object, allowing the argument to be omitted from the function signature.

For dynamic data storage in state, while Solidity uses structures such as mapping(address ⇒ ...), Move relies on dynamic fields.
Dynamic fields, natively supported in SUI Move through the SUI Framework and adapted in Stylus’ Move framework, allow modeling balances as dynamic fields whose key is the owner’s address and whose value corresponds to the actual balance.

Meanwhile, allowances are represented using the Table structure as the value of these dynamic fields, conceptually equivalent to Solidity’s double mapping.

use stylus::object::NamedId;
use stylus::dynamic_field_named_id as field;

public struct BALANCE_ has key {}
public struct Balance has key { id: NamedId<BALANCE_> }

public fun balance_of(account: address, balance: &Balance): u256 {
    if (field::exists_(&balance.id, account)) {
        *field::borrow<BALANCE_, address, u256>(&balance.id, account)
    } else { 0 }
}

‍

Key takeaway:

• NamedId + dynamic_field → equivalent to mapping(address ⇒ uint256), but with Move’s compile-time ownership and type guarantees.
• The ABI remains unchanged (address, u256), so EVM tooling, wallets, indexers, SDKs, works out of the box.

In short, Stylus allows Move developers to tap into the EVM ecosystem without compromising Move’s resource-based safety guarantees.

This milestone is just the beginning of a true bridge between the Move and EVM worlds, powered by open-source collaboration and the Arbitrum DAO’s support.

With the compiler reaching its Alpha stage of maturity and the first ERC-20 fully operational, the next steps for the project include:

• Building a SDK and CLI for Move on Stylus developers.
• Integrating testing and debugging tools.
• Exploring synergies with Move ecosystems that could deploy on Arbitrum.

Rather Labs continues to strengthen its role as one of the key technical innovators within the Arbitrum ecosystem.

From infrastructure to applied research, we remain committed to bridging languages, ecosystems, and communities, enabling new ways to build at the frontier of blockchain development.