98.5% of Moonbeam's contracts are generated by a mysterious token
Story about how solving high gas fees challenge can bring in new activity but also make your ecosystem measurements completely inaccurate.
This time was exciting as well because of the numerous bridges that Moonbeam has (namely Axelar & XCM) and the first look into our raw SQL tables didn't uncover anything suspicious. After a few days of transforming the data, a closer look revealed that the chain has almost 18 million smart contracts – which of course is a lot for 1.3 million users – but hey, it’s the biggest parachain out there. You won't see these contracts on Subscan however - it's tailored more for Substrate-based data and lacks the functionality to access EVM traces. EVM traces are vital for identifying contracts that have been deployed by other contracts, revealing a layer of interaction not captured by Subscan explorer.
After some detailed data analysis, we made an interesting discovery: a vast majority, specifically 17,746,636 of all 17,991,729 ever created smart contracts on Moonbeam, were deployed by just two addresses — amounting to approximately 98.64% of all contracts on the chain! This unusual concentration of activity warranted further investigation, leading us to these addresses:
- 0x9Ec1C3DcF667f2035FB4CD2eB42A1566fd54d2B7 - XEN Batch Minter, deployed 9,832,559 contracts, making up 54.65% of all smart contracts ever created on Moonbeam. [Moonscan Link]
- 0x94d9E02D115646DFC407ABDE75Fa45256D66E043 - XEN Torrent (mbXENT), was responsible for deploying 7,914,077 contracts, which is about 43.99% of all smart contracts ever created on Moonbeam. [Moonscan Link]
98.5% of Moonbeam contracts were deployed by 2 addresses
Our investigation traced the origin of the majority of Moonbeam's smart contracts to the XEN project. XEN is a mintable token with no initial supply. To mint XEN, users incur native currency gas fees, but the token itself can be created without direct purchase. The unique aspect of XEN lies in its minting reward structure, which is governed by two key factors: the chosen duration of the mint term and the cumulative number of accounts that have interacted with the contract prior to a user's minting action.
As more users (accounts) engage with the XEN contract between the time you initiate minting and when you claim your tokens, the global rank increases. This increase in global rank, signifying a broader userbase, leads to greater rewards for all participants. In essence, an expanding number of accounts in the XEN network enhances the potential rewards you can receive.
I guess you’re slowly getting the point. We did as well but had to be sure what the purpose was here – especially that the current price of this interesting token dropped around 40x from its ATH.
How does it work?
Now, let's delve into the role of the two addresses in question. The first address 0x9Ec1C3DcF667f2035FB4CD2eB42A1566fd54d2B7 is associated with a tool known as the XEN Batch Minter. This contract facilitates the creation of multiple accounts for minting XEN in a single transaction, streamlining the account creation process compared to manual methods. For those interested in the deeper technical details, the contract code is available for viewing here.
Exploring this contract reveals some key functionalities:
- Functions t and _t for account creation and interaction with the XEN contract. Despite their nondescript names, these functions facilitate the batch creation of new accounts. See an example transaction using these functions.
- Function f for claiming mint rewards. This function is a vital part of the reward claiming process. Here's an example of this function in action.
The second notable address, 0x94d9E02D115646DFC407ABDE75Fa45256D66E043, is linked to the XEN Torrent (mbXENT), an ERC-721 based protocol developed by the Fair Crypto Foundation (the founders of XEN). This protocol employs NFTs for the batch minting of XEN tokens. Unique features of these NFTs include future minting capabilities and, in specific categories, the ability to burn XEN to manage supply.
The XEN Torrent, while facilitating contract creation in a manner similar to the XEN Batch Minter, stands out as an official component of the XEN ecosystem, offering its unique approach to token minting.
How to cut through the noise?
While this system appears to encourage active participation and expansion of the network, it's important to distinguish between authentic network growth and the proliferation of addresses created by individuals. In practice, a significant portion of this activity stems from users creating numerous addresses with the primary aim of minting tokens and potentially profiting from them. This phenomenon, while technically within the rules of the system, may not necessarily reflect a genuine increase in diverse user engagement or the organic growth of the XEN network. It underscores a critical aspect of blockchain ecosystems, where the metrics of growth and user participation can sometimes be influenced by strategies that focus more on individual financial incentives rather than the collective development of the network.
Tokenguard offers automated ecosystem mapping based on machine learning algorithms. Ecosystem manager can simply turn off measuring smart contracts belonging to a specific dApp or deployer in one click to see the real preview of his on-chain activity.
Thanks to that, you can preview which dApps bring in most activity to your protocol and what bridges are the best for your ecosystem growth. You don’t need verified smart contracts in your explorer to see what’s important and what’s not. You’re not going to have 100% of them verified anyway.