XRPL EVM v9.0.0: Migration from Evmos to Cosmos EVM v0.4.1

Overview

The XRPL EVM sidechain is upgrading from the unmaintained Evmos dependency to Cosmos EVM v0.4.1, a fully supported fork. Key benefits include:

• Long-term sustainability: Evmos lacked active maintenance; Cosmos EVM ensures ongoing compatibility with Cosmos and Ethereum ecosystems
• Future-proof development: Continuous integration of Ethereum standards (EIPs) and protocol upgrades
• Extended functionality: New ERC-20 capabilities including mint, burn, and ownership transfer
• Ecosystem alignment: Better integration with Cosmos SDK chains, IBC modules, and interoperability upgrades

Newly Supported EIPs and Opcodes

Shanghai Upgrade

• ✅ EIP-3855: PUSH0 instruction
• ✅ EIP-3860: Initcode limits and metering
• ⚠️ EIP-3651: Coinbase address warm (partial support)

Cancun Upgrade

• ✅ EIP-1153: Transient storage opcodes
• ✅ EIP-5656: MCOPY memory copying instruction
• ✅ EIP-7516: BLOBBASEFEE opcode
• ⚠️ EIP-6780: Restricts SELFDESTRUCT (partial support)

Prague Upgrade

• ✅ EIP-2537: Precompile for BLS12-381 curve operations

Technical details

Cosmos SDK

The upgrade to Cosmos/EVM v0.4.1 required upgrading to Cosmos SDK v0.53.4. The primary change involved app wiring: "the x/auth module needed to be registered as a pre-blocker within the application's module manager."

Optional deferred features include the ProtocolPool module, Epochs module, and unordered transaction support—reserved for future upgrades.

IBC Go

Migration from IBC-Go v8.1 to v10.0 required updating the rate-limiting module. Key changes applied:

• Middleware integration into the transfer stack
• Manager wiring in the IBC Manager
• Blocker order insertion for proper execution during block lifecycle
• Params integration for configuration persistence

Optional features deferred:

• Transfer Stack V2
• WASM Light Clients

evmos to cosmos/evm

Migrate erc20 custom capabilities

Custom ERC-20 features were ported to maintain Evmos compatibility:

• Mint – allows token creation by authorized accounts
• Burn – supports token destruction (Burn, Burn0, BurnFrom)
• TransferOwnership – enables ownership transfer of token contracts

Updates included:

• Solidity interfaces for precompile functionality
• Extended ERC-20 precompile with custom transactions, queries, and updated ABI
• New wrapped ERC-20 precompile (werc20)
• Regenerated protobuf definitions
• Integration and Solidity test infrastructure
• Expanded x/erc20 module with new keeper methods and CLI commands

Node

Cosmos EVM Breaking Changes

The migration required significant refactoring. Key modifications:

Ante Handler

• Moved to dedicated Go package (/app/ante)
• Updated to support CosmosAnteHandler and MonoEVMAnteHandler
• Preserved legacy key support for ethsecp256k1.PubKey from Evmos

EVMAppOptions

• Enforces eth-format chain IDs
• Maps chain-specific denominations using whitelisted chain ID mapping
• Supports mainnet, testnet, devnet, localnet, and simulation

Encoding and Interface Registry

• Replaced Evmos's MakeConfig with Cosmos/EVM's codec builder
• Included compatibility shims supporting both pre-upgrade (Evmos) and post-upgrade (Cosmos/EVM) types
• Registered legacy messages to prevent transaction decoding breaks

Genesis FeeMarket Fix

• Patched genesis state initialization for the feemarket module due to sdkmath library changes

Precompiles Wiring

• Updated NewAvailableStaticPrecompiles to reflect Cosmos/EVM's precompile model

EVM Mempool

The new evm-mempool package remains experimental with limited production exposure. XRPL EVM deliberately excluded this component to avoid consensus layer instability. Integration is planned for a future upgrade once maturity is demonstrated.

Upgrade Handler

The migration required multiple state transitions across the ERC20, EVM, and Auth modules.

ERC20 Module Migration

The upgrade handler implements store migration to handle IBC-derived ERC-20s and precompiles:

1. Iterates over legacy DynamicPrecompiles and re-inserts using Cosmos/EVM's SetDynamicPrecompile
2. Iterates over legacy NativePrecompiles and re-inserts using SetNativePrecompile
3. Cleans up legacy store keys

EVM Module Migration

Evmos stored ExtraEIPs as strings ("ethereum_3855"), while Cosmos/EVM expects integers (3855). The migration handler:

• Unmarshals legacy Evmos params
• Sanitizes and converts string-formatted EIPs to integer IDs
• Rebuilds AccessControl configuration
• Writes new Cosmos/EVM-compatible Params to state

EthAccounts → BaseAccounts Migration

Evmos embedded CodeHash in EthAccount; Cosmos/EVM decouples these, moving code hash to the EVM module's VM store. The upgrade handler:

1. Iterates through all accounts
2. Identifies legacy EthAccount types
3. Extracts CodeHash for contract-associated accounts and stores in EVM module
4. Replaces EthAccount with embedded BaseAccount

Keys

A conflict emerged between cosmos.evm key types (new) and legacy evmos key types in validator keyrings and user wallets. To avoid forced key migration, the encoding registry was modified to "prioritize the legacy Evmos key types over the Cosmos EVM ones," ensuring backward compatibility.

Supported EIPs

• Shanghai
• Deneb
• Cancun
• Prague

Conclusion

The migration from Evmos to Cosmos EVM v0.4.1 ensures long-term sustainability and aligns XRPL EVM with actively maintained infrastructure. Expanded ERC-20 functionality, upgraded IBC support, and latest Ethereum standard compatibility position the chain as "a future-proof environment for building scalable, interoperable applications."