Introduction
In mid-September, an update to Moonbeam’s strategic direction was announced, indicating plans to explore opportunities to bring Moonbeam’s strengths—interoperability, Ethereum compatibility, and efficient cross-chain integrations—into the restaking ecosystem.
Since this announcement, extensive research has taken place with key players across the nascent restaking ecosystem. This includes engaging with core restaking protocols Eigenlayer and Symbiotic, LRTs such as Ether.Fi, Renzo and Mellow; and leading AVSes including E-Oracle, Witness Chain, AvailDA, AltLayer and other Ethereum experts.
The purpose of this research was two-fold:
-
Identifying Ecosystem-Wide challenges: To develop a broader understanding of the restaking ecosystem’s current state (including AVSes, restaking protocols, rollups, operators, etc) and surface common pain points or gaps that Moonbeam could potentially help with.
-
Moonbeam’s Value Proposition: To explore ways in which Moonbeam (or some variant) could provide significant value to the restaking/AVS/rollup ecosystems.
Our research is ongoing, with more meetings planned at DevCon and beyond, but a clear direction is starting to take shape. While this can and undoubtedly will be further refined, we want to honor our commitment to the community in keeping people informed and engaged along the way.
In addition, Moonbeam’s product and engineering teams have been looking at what an AVS deployment of Moonbeam may look like from a technology perspective, and have made clear progress in that regard as well.
Restaking Ecosystem Key Challenges
AVS deployment complexity
Deploying Actively Validated Services (AVSes) is a complex process, often made more challenging by limited documentation and support. Additionally, AVSes vary widely in hardware and software requirements, making it difficult for operators to deploy nodes consistently and reliably. As a result, operators face frequent challenges with deployment and encounter inconsistent performance even when nodes are successfully launched.
Operator Transparency and Metrics
A lack of transparency surrounding operator performance is a recurring concern that came up repeatedly. Projects consistently mentioned the difficulty in assessing an operator’s reliability, commitment to different restaking solutions, and overall effectiveness. Although none of the major restaking protocols have implemented slashing to date, it remains a critical requirement for securing the economic model of restaking, which will require this level of insight. Additionally, essential metrics—such as uptime, hardware capabilities, geographic distribution, and the number of supported AVSes—are currently not readily accessible.
Beyond that, AVSes are very heterogeneous in nature and AVSes are struggling with how to correctly measure how operators are performing their respective tasks and how to reward them accordingly.
Point systems vs Reward tokens
To date, very few AVS projects have launched dedicated AVS reward tokens. Teams are currently using “points” as provisional reward mechanisms, leaving operators to take a leap of faith that these points will eventually hold value. Eigenlayer is currently augmenting these points with their own EIGEN token and other restaking protocols like Symbiotic and Karak are expected to follow suit, but it seems clear to everyone in the space that this is not sustainable long-term.
System Complexity: Understanding the intricacies of the restaking ecosystem, with its interplay of vaults, operators, rewards, and eventual slashing mechanisms, poses a significant challenge for new participants on all sides. Frameworks for building the AVSes themselves are immature, leaving project teams without a solid base to start from. These complexities and uncertainties pose a challenge to both operators, retail investors and AVS projects themselves as they try to navigate the gamut of options available to them.
AVS Token Utility Beyond Security
AVSes are currently being very careful with sharing exactly how token systems will work and how these will match with point systems, but they are clear in stating that they want to create additional utility for these tokens; as there needs to be demand for these to have lasting value.
Gaps in Range of AVS Services
There are many project teams aiming to provide decentralized services to support a modular, composable ecosystem with L2s/Rollups at the core including DA, sequencers, bridges, zk co-processors, oracles, and so on. While there are many competing teams for these categories, gaps remain in terms of the key primitives needed by web-based applications. Perhaps most notably, there doesn’t seem to be anyone focused on a robust, decentralized storage solution deeply integrated into the ethereum ecosystem.
Potential Opportunities for Moonbeam
Moonbeam as an AVS Defi Hub
With its foundational strengths in interoperability, Ethereum compatibility, and cross-chain integration, Moonbeam might be well-positioned to serve as a DeFi hub for the Actively Validated Services ecosystem, addressing several of the key challenges facing AVS projects in the foreseeable future. This go-to-market strategy includes creating an environment that supports sustainable token utility, deeper liquidity, and a range of DeFi applications for AVS project tokens.
Some of the areas where Moonbeam could help AVSes include:
-
Incentivizing Liquidity Depth for AVS Project Tokens
-
Building out features and Dapps to support AVS Token Reward Distribution
-
Liquidity Routing and Aggregation through Moonbeam Routed Liquidity (MRL)
-
Native Cross Chain AVS tokens by adopting the xERC20 Standard via a Glacis Deployment
-
Lower Gas Fees for claiming AVS Rewards (as compared to Mainnet)
-
Building an ecosystem of applications Tailored to AVS Needs to support Defi and AVS Token Reward Distribution
Moonbeam as an AVS Providing Decentralized Storage
As mentioned earlier, decentralized storage seems to be an obvious gap in terms of the line-up of AVS services that are launching on Eigenlayer and Symbiotic. Storage is a key primitive needed in one way or another by every web-based application.
While storage is not a core capability of Moonbeam today, the Moonbeam Foundation has discussed with several teams how an integrated storage capability that can be interacted with via an EVM interface (including x-chain support via GMP protocols) could be a compelling capability for many use cases. Digital assets associated with NFT collections and storage of dapp front end UI assets are the most obvious use cases but several other opportunities exist across the key verticals of Gaming, DePIN and RWAs.
Substrate remains one of the most robust frameworks upon which to build web3 services, and storage is a good example of an infrastructure service that can’t be served from a vanilla EVM implementation. Substrate’s modularity, extensibility and vast library of pallets allows for rapid innovation to develop capabilities that can be optimized for the storage use case. Combining a powerful, decentralized storage solution directly within Moonbeam’s EVM with pre-compiles will allow Moonbeam to uniquely serve use cases that traditional rollups can’t serve, while also allowing Moonbeam to provide storage natively as an Ethereum-secured service to dapps deployed on rollups.
Moreover, current offerings require data to be stored in a completely separate network with proprietary protocol stacks and different trust assumptions than their execution environment. The link between the smart contract network and storage network is weak and managed at the client dapp layer. Ownership rights and permissions must be maintained in two completely separate environments. These are all weaknesses that a storage solution powered by Moonbeam could improve upon in the Ethereum context.
Other opportunities
In addition to the Moonbeam’s role as a DeFI Hub/cross-chain gateway for AVS tokens and as a Storage Solution for the Ethereum ecosystem, two other potential opportunities came up in our research:
Re-Staking of Polkadot Assets
Moonbeam’s existing deployment within the Polkadot ecosystem presents a unique opportunity to bridge XCM assets into the restaking ecosystem. There is a clear interest from restaking protocols to gain access to security collateral beyond ETH, and Moonbeam’s position as a central XCM hub for the Polkadot ecosystem would allow it to bring assets from Polkadot and the parachains to be used in securing AVS operations. This approach would not only enhance the collateral base for AVSes but also create new cross-chain utility for XCM-compatible assets, supporting further liquidity and interoperability within both the Moonbeam and broader Polkadot ecosystems.
Enhanced Operator Transparency and Monitoring Tools
Operator performance transparency is a critical challenge within the restaking ecosystem. While Moonbeam has not traditionally focused on this area, there is a significant opportunity to attract advanced monitoring and analytics tools to the network by providing a flexible smart contract execution environment.
This setup could unlock opportunities for, for example, automated portfolio rebalancing across multiple chains, allowing restaked assets to be redistributed based on changing operator performance. However, this seems more like a dapp-based solution rather than an EVM chain so it’s unclear how Moonbeam would provide differentiation here.
Conclusion
Our research highlights several promising paths for Moonbeam to expand within the Ethereum ecosystem. Restaking is a nascent and quickly evolving landscape, and we see numerous options for Moonbeam to explore, positioning it as a distinctive player. Furthermore, these opportunities aren’t mutually exclusive and it may be possible to combine some of them into a single product offering.
Moonbeam v2: AVS Chain deployment
From a technical perspective, Moonbeam is exploring several different architectures for a new deployment, for now referred to as “Moonbeam v2”.
As described in the original forum post, deploying as a Substrate chain would allow Moonbeam to retain all the custom pallets that have been developed for the existing Moonbeam implementation. This includes the BatchPrecompile and CallPermit pallets which have proven to be very popular with teams deploying to Moonbeam, cross chain asset and messaging functionality, randomness precompiles, and the OpenGov governance system that allows for forkless runtime upgrades to name a few.
The most straightforward way for Moonbeam v2 to become part of the Ethereum security domain is to integrate with a restaking protocol such as EigenLayer or Symbiotic. We have been researching and exploring different approaches and designs for making this integration work. The end result would be that Moonbeam is running as a Substrate-based chain, but that it is secured by re-staked assets on Ethereum.
The Moonbeam v2 deployment will offer an opportunity to revisit the consensus mechanism and look at alternatives to the GRANDPA finality protocol used by Polkadot. For example, AlephBFT is another sovereign PoS consensus for Substrate. Using this consensus implementation may allow for much faster blocktimes. If the GRANDPA consensus mechanism is retained, Moonbeam v2 blocktimes would be similar to the existing Moonbeam v1. However, it would have the advantage of allowing for the creation of native, trustless bridges back to Moonbeam v1 including the support of XCM. In addition, GRANDPA would allow the use of BEEFY for a native bridge to Ethereum.
The implementation of Moonbeam V2 also presents an opportunity to potentially switch from Frontier to a different EVM implementation such as Revm which would yield performance improvements and lower maintenance costs in terms of maintaining EVM compatibility.
Based on the technical research to date, we don’t see any technical blockers that prevent an implementation path for Moonbeam v2.
The Path Forward
In the coming weeks, we’ll be laser focused on refining Moonbeam’s new product market-fit, while our engineering team is already diving into the technical details of what an AVS deployment could look like for the platform. We don’t want to just meet the current needs of the restaking ecosystem - we want to position Moonbeam as a key player for gaps that people are only now just starting to realize. To achieve this, we’re also starting to evaluate the types of ecosystem partnerships that will be crucial in amplifying our impact, whether through collaborative projects, technological integrations, or cross-chain alliances.
To ensure we’re building a future that meets real-world needs, community feedback will be invaluable. We’re eager to hear from you on which of our proposed solutions resonates most strongly and aligns with your vision of Moonbeam’s future. Additionally, we invite you to share insights on any unmet needs or existing challenges that Moonbeam could tackle. Whether it’s in transparency, infrastructure, or token utility, we want to know where Moonbeam can make a meaningful difference.
Your input will guide us in fine-tuning our strategic and technical roadmap, ensuring that Moonbeam’s growth is directly shaped by the voices within its community. Let’s work together to create a future where Moonbeam not only supports but helps drive forward a stronger, more interconnected restaking ecosystem.
