Intro
2024 was a defining year for the Moonbeam and Moonriver ecosystems, marked by major strides in reducing friction for both developers and users. Focused investments in user experience, asset management, Ethereum compatibility, and scalability led to faster block times, more seamless cross-chain asset movement, and significantly improved developer tooling.
Key highlights included the continued evolution of MRL (Moonbeam Routed Liquidity), an 8x increase in throughput, and a complete rebranding of all Moonbeam and Moonriver websites and apps. These changes have reinforced Moonbeam’s position as the premier EVM-compatible destination within the Polkadot ecosystem.
The 2025 roadmap continues to build on these same themes and also introduces a major new element: decentralized storage. While the Ethereum-aligned DataHaven project has already begun to generate buzz in the community, what’s less widely known is that similar capabilities are being developed natively within Moonbeam and Moonriver. This marks a pivotal expansion of scope—from an EVM compatibility hub to a fully integrated platform for next-generation web3 applications. One that combines storage, liquidity, governance, and smart contracts, all optimized for Polkadot.
Let’s dive into some of the details across these key elements of the roadmap.
Storage
Moonbeam will integrate StorageHubGo to page https://github.com/Moonsong-Labs/storage-hub to bring decentralized storage to its execution layer as part of the Polkadot web3 cloud. This fills a major gap in the application stack and positions Moonbeam as both a liquidity and storage hub for the ecosystem. Storage nodes will hold user data, while EVM and Substrate transactions coordinate storage bucket management and payments.
As Polkadot Hub begins to play more of a coordination role, other key services such as identity, co-processors, and storage can be leveraged to form a complete stack for the next generation of applications. Storage native to Polkadot remains a key gap in the stack and the integration of StorageHub presents a unique opportunity for Moonbeam to serve as the decentralized storage solution of choice for the ecosystem.
The addition of StorageHub to Moonbeam will introduce a network of storage nodes integrated with Moonbeam’s execution environment. In short, the storage network is where the actual data is stored while the management of storage buckets and brokering payments with storage nodes will be coordinated via EVM and Substrate transactions. Moonbeam will not only be a liquidity hub for the ecosystem, but also a storage hub.
More technical details will be shared as the project progresses.
EVM Compatibility
One of Moonbeam’s core strengths Moonbeam is its EVM compatibility. Although Polkadot Hub will be adding smart contracts and will be Ethereum-compatible, it still won’t have the unparalleled level of EVM compatibility that makes Moonbeam the preferred destination within Polkadot for EVM developers. (More on Ethereum compatibility versus EVM compatibility can be found in this articleGo to page https://moonbeam.network/news/polkadot-hub-vs-moonbeam-what-s-the-difference/.)
Work in this area is ongoing, but here are a few highlights of our 2025 initiatives:
“EVM Native” Foreign Assets
Three years ago, Moonbeam pioneered the XC-20 token standard—a format that allows tokens to function seamlessly in cross-chain scenarios across the Polkadot ecosystem while also acting as regular ERC-20s on Moonbeam for easy integration into DeFi applications. This standard applies to tokens originating on Moonbeam as well as those created on other Polkadot rollups (aka parachains). Over time, the XC-20 standard has evolved and played a central role in establishing Moonbeam as Polkadot’s interop hub, enabling innovations like Moonbeam Routed Liquidity (MRL).
“Foreign Assets” refer specifically to XC-20s that represent tokens whose canonical ledger exists on another Polkadot rollup or the relay chain—such as DOT being registered on Moonbeam as xcDOT. These assets are automatically assigned ERC-20-compatible addresses. However, these addresses are not backed by smart contracts but by special pre-compiles, which limits compatibility with tools like Tenderly, Hardhat, and Foundry that expect standard EVM behavior.
In order to address this, a multi-phase initiative began in late 2024 to transition foreign assets from pre-compiles to actual EVM bytecode, making them fully “EVM native.” The process started with RT3400, which changed how new assets are registered. RT3501 followed with changes to unify asset management under pallet-xcm and phase out xTokens. RT3600 introduces a tool to migrate existing assets to the new model.
The final step in this initiative will be to update Moonbeam and Moonriver to remove support for the old model and related pallets.
Pectra Compatibility
The upcoming Ethereum Pectra upgrade introduces several Ethereum Improvement Proposals (EIPs) aimed at streamlining validator operations, reducing network congestion, and enhancing the usability of Ethereum accounts. Moonbeam and Moonriver will implement the relevant elements of the Pectra upgrade to ensure continued EVM compatibility with minimal delay. This demonstrates Moonbeam’s ongoing commitment to being a fully EVM-compatible chain.
In particular, the following EIPs will be implemented:
- EIP-2537Go to page https://eips.ethereum.org/EIPS/eip-2537: Adds functionality for efficient BLS12-381 curve operations, such as BLS signature and SNARK verifications.
- EIP-7702Go to page https://eips.ethereum.org/EIPS/eip-7702: Introduces a new transaction type that allows externally owned accounts (EOAs) to attach executable code to a transaction, enabling them to temporarily function like smart contracts while still being able to initiate transactions.
- EIP-7623Go to page https://eips.ethereum.org/EIPS/eip-7623: Increases the gas cost for transactions that use high amounts of calldata. In short, the goal is to optimize network allocation by charging more for transactions that are primarily used for DA without impacting regular user operations.
Scalability and Polkadot Roadmap Alignment
Elastic Scaling
In 2024, a considerable amount of the roadmap was focused on the transition to Asynchronous Backing, representing a significant change in Polkadot’s consensus protocol that dramatically improved the speed, scalability, and efficiency of the network.
Moonbeam and Moonriver leverage a special consensus framework called NimbusGo to page https://docs.moonbeam.network/learn/features/consensus/, which enhances decentralization but required considerable adaptation to support asynchronous backing. These changes were achieved through a series of runtime upgrades, leading to an 8x increase in throughput—achieved by quadrupling the gas limit and reducing block times from 12 seconds to 6 seconds.
In 2024, Polkadot and Kusama also adopted Agile CoretimeGo to page https://polkadot.com/agile-coretime/, a more flexible model for parachains to use validation services with predictable costs, eliminating the need for parachain auctions. Moonriver transitioned to Agile Coretime in August of 2024, and Moonbeam will follow suit in Q2 of 2025.
Taking things a step further, Kusama and Polkadot will be updated to support Elastic ScalingGo to page https://polkadot.com/blog/elastic-scaling-streamling-growth-on-polkadot/ later in 2025. This will allow Polkadot rollups to utilize multiple cores to meet additional demand and shorten the block inclusion interval (block times).
In order for Moonbeam and Moonriver to fully leverage this, their consensus protocols will need further adjustments, which are scheduled for Q4 of 2025. This will allow both networks to decrease block times to 2 seconds, greatly increasing transaction throughput.
Polkadot SDK Stable2412
To continue operating effectively as Polkadot rollups and take advantage of ongoing improvements in Kusama and Polkadot protocols, it’s crucial for Moonbeam and Moonriver to stay aligned with changes to the Polkadot SDK. Moreover, staying current with the latest Polkadot SDK releases is what allows Moonbeam to benefit from features like Asynchronous Backing and Elastic scaling (albeit with some updates to Moonbeam’s consensus).
This sounds straightforward but oftentimes, a number of changes are required within the Moonbeam runtime, particularly if the changes impact Moonbeam pre-compiles that expose substrate functionality through the EVM.
In Q1, Moonriver and Moonbeam were successfully updated to the Stable2409 release. In Q3, both networks will be upgraded to Stable2412. Stable2412 includes various bugfixes and improvements including:
- XCM v5: Simplifies the developer and end-user experience with better fee estimation, new instructions, enhanced documentation, and seamless cross-chain interoperability.
- Fork-aware transaction pool: Improves transaction handling in case of chain splits.
- PoV limit improvements: On the client side for better performance.
- Bridge-related improvements: Enhances cross-chain functionality.
- Warp SyncGo to page https://spec.polkadot.network/chap-sync#sect-sync-warp fixes: Especially for large chains.
Asset Hub Migration
As part of a broader initiative to reduce the relay chain's workload and transition to JAM, the Polkadot community will migrate user functionality—such as staking, governance, and balances—to Asset Hub (see forum postGo to page m.polkadot.network/t/asset-hub-migration-2025/11129). This migration is scheduled for Q2 and Q3 of 2025 for Kusama and Polkadot, respectively.
In 2024, Moonbeam and Moonriver were modified to support both the relay chain and Asset Hub as the “reserve chain” for KSM and DOT. This change enabled xcDOT and xcKSM to be transferred seamlessly between the relay chain and Asset Hub.
However, additional changes will be necessary for Moonbeam and Moonriver applications and core protocols to complete the migration. For example, Stellaswap will need to adjust their stDOT implementation to be backed by Asset Hub instead of the relay chain for staking. Additionally, Moonbeam will need to modify its protocol to no longer consider the relay chain as a reserve chain, and sovereign account balances will need to be moved to Asset Hub.
These updates will be planned and executed throughout Q2 and Q3 in alignment with the corresponding changes to Kusama and Polkadot.
Asset Management
Moonriver <> Moonbeam Bridge
Moonriver has been without a bridge for a few years, but once Axelar launches its permissionless onboarding for EVM chains into their Amplifier protocol, the process will begin to connect Moonriver with a wide range of other chains and ecosystems.
However, the Moonriver community has been waiting for this development for nearly a year and a half (see this forum postGo to page https://forum.moonbeam.network/t/update-on-moonriver-axelar-integration/2029 for more details), and it remains unclear when Axelar will achieve its goal of permissionless EVM onboarding.
In the meantime, work has started on a trustless, native bridge between Moonbeam and Moonriver using the Polkadot-SDK bridging solution. This will provide an alternative and backup route to move liquidity between ecosystems. The bridge will support cross-chain communication via XCM, and the same technology will be used for the native, trustless bridge between Moonbeam and DataHaven.
The target is to have the native bridge live following the deployment of RT3800 to Moonbeam in August. Initially, only GLMR and MOVR will be supported for cross-chain token transfers, with other assets to be added later in the year.
Deposits for Foreign Asset Creation
A long-standing complaint from other Polkadot rollup teams has been the time it takes to register their Foreign Assets on Moonbeam, making them available for use in Moonbeam applications and flows.
Previously, asset registration required a governance proposal, which could take about two weeks to pass—too long for teams looking to quickly develop and deploy new features. In response, the “Fast General Admin” track was introduced in 2024 to shorten this cycle to one week.
However, teams still had to navigate through complex XCM calls, select the correct track, post proposals both on-chain and in the forum, and find a sponsor for the decision deposit. If any mistakes were made in the XCM, the process would need to be restarted from scratch.
With RT3600, a new change allows teams to permissionlessly register their assets on Moonbeam and Moonriver by posting a deposit, eliminating the need for the lengthy cross-chain governance process.
Treasury Spends in Stables
Both Moonbeam and Moonriver have on-chain treasuries where teams can request funding for critical ecosystem infrastructure, such as RPC nodes and block explorers.
However, the process from posting a request in the forum to receiving funds can take several weeks. Teams with real costs tied to fiat currencies are required to convert their requests to GLMR and/or MOVR, assuming the associated market volatility risks. Furthermore, they often need to liquidate the awarded GLMR/MOVR promptly to cover their costs.
Wouldn’t it be better if teams could be paid directly in stables instead? There are two main blockers to this.
First, the on-chain treasuries lack sufficient reserves of stablecoins. To address this, the Treasury Council has proposed initiating a DCA strategy to accumulate USDC over time, conducting small transactions to avoid market impact.
The second issue is that while the on-chain treasuries can hold stablecoins, the Moonbeam and Moonriver runtimes currently do not support treasury proposals being made or paid out in assets other than the native token. This capability is under development and is targeted for release in Q3.
UX
“Snappy” RPC
No one likes waiting around for transactions to be included in a block and confirmed. In RT3400, Moonriver and Moonbeam introduced a new client block import strategy that allows them to operate in a low-latency mode. In this setup, the "best" block is derived from the most recent imported block, rather than the included blocks.
While this might sound complicated, the result is quite simple: a significantly faster, more "snappy" end-user experience. Users submitting transactions will notice much less time spent staring at their wallet or dApp waiting for confirmation.
This change was initially client-side and required RPC providers to opt in for testing. In RT3600, this option will be enabled by default, ensuring that all Moonriver and Moonbeam users experience the improved performance.
Passkey Support
Moonbeam will be enhanced to support the signature scheme used for passkeys (secp256r1 curve support), which is a requirement for supporting passkey-based smart wallets, as outlined in the ERC-4337 improvement proposal. This will greatly enhance the overall user experience.
With passkeys, users no longer need to remember a mnemonic or private key. Instead, wallets can be secured with a passkey that is encrypted and protected by biometrics. Onboarding new users will be simplified through Google or Apple authentication.
A prototype, including a precompile for passkeys, was developed in 2024. However, the process remains prohibitively expensive in terms of gas cost because verification occurs within Moonbeam's runtime. Once verification is integrated into the Polkadot SDK, this can proceed. There is a Polkadot feature request hereGo to page https://github.com/OpenZeppelin/polkadot-runtime-templates/issues/267—please comment if you would like to help push this forward.
Gas & POV Optimizations
In 2024, Moonriver and Moonbeam transitioned to Asynchronous Backing, which enabled them to quadruple the block size and cut block times in half. However, there was a caveat: the PoV size remained constrained to 5MB.
So, what the heck is PoV anyway? PoV stands for “Proof of Validity.” Basically, a Polkadot rollup proves that its state transitions are valid without burdening the main relay chain with full state storage. This is done by creating Proofs of Validity, which validators check to ensure that the rollup's block transitions are accurate.
The issue is that if we quadruple the block size but leave the max PoV size unchanged, transactions have to be priced to ensure the block doesn’t exceed the limit. Thus, operations that require a larger proof size essentially became 4x more expensive.
To address this annoyance for users and dapp operators in our ecosystem, several optimizations are planned. To provide immediate relief, the minimum gas price was reduced by a factor of 4 in January 2025. While this temporarily reduced transaction costs for users, it also reduced the amount of GLMR being burned by 70%. As such, this adjustment will likely be reverted in a future release.
Since blocks will be rejected by the relay chain if they exceed the PoV limit, it’s crucial to be conservative when estimating the impact of PoV for a given operation, though this can lead to higher fees for users. Improvements to PoV estimation are underway, with some already released this year and others planned for later.
Most importantly, following lobbying efforts from the Moonbeam core development team (and others), Kusama and Polkadot have recently doubled the max PoV size to 10MB. Moonriver and Moonbeam will adapt to this change later this year, helping to strike a better balance between base fees and fees based on proof size.
Treasury Flow
A new Treasury Flow has been created to align with both Polkadot OpenGov and Moonbeam’s model, where treasury proposals are approved by a special council. The new process simplifies the funding request procedure, as Treasury Council members now handle the creation of the on-chain proposal.
In the new flow, teams submit their funding requests to the Moonbeam forum, where the community and Treasury Council members provide feedback. Once positive feedback is received, a Treasury Council member submits the proposal on-chain on behalf of the beneficiary, after which the Treasury Council members vote on it.
Dapp UX Improvements
The Moonbeam dApp is a primary interface for many users interacting with the network. Over the past year, several improvements have been made, including adding MRL (Moonbeam Routed Liquidity) to the "Bridging" section and updating the dApp to reflect new branding. Additional improvements to the dApp’s navigation and styling have already been made this year.
Later in 2025, the dApp will also support bridging between Moonbeam and Moonriver, as well as the new Storage capabilities (see above).
Conclusion
The 2025 roadmap marks a pivotal year for Moonbeam and Moonriver, as it not only deepens our commitment to seamless UX, robust asset management, and unmatched EVM compatibility, but also expands our role within the Polkadot ecosystem through the introduction of decentralized storage. By integrating StorageHub and aligning with emerging standards like Elastic Scaling and Agile Coretime, we are positioning Moonbeam and Moonriver as foundational infrastructure for the next generation of web3 applications. With continued protocol improvements, increased community participation, and a forward-looking approach to interoperability and scalability, the path ahead is one of innovation, resilience, and greater decentralization.