XEN Token State Bloat Report
1. Summary
This report provides an in-depth analysis of the XEN project, focusing on its impact on the Evmos blockchain and other EVM networks. Recent concerns have arisen within the web3 ecosystem regarding the significant footprint of XEN in blockchain network states and state growth. The report delves into the mechanics of XEN, its performance implications, and community discussions surrounding its large state requirements.
The analysis shows that, on Evmos, the XEN token accounts for 96% of all the contract storage space (~55GB) with more than 651,081,927 state entries. Additionally, all the XEN project contracts represent 149GB of disk space with over 70M empty accounts created. XEN has a negative impact on the performance of processes that use the chain state, such as state sync, state export, and snapshot creation, thus increasing the cost of running the network infrastructure.
2. Context
For a while now, Evmos blocks have regularly included transactions from the XEN token. It is normal for XEN transactions to create 100+ contracts within one transaction (example transaction).
The XEN white paper introduces a Proof of Participation (PoP) scheme that has raised concerns among some users and journalists due to its “possibly unsustainable model” (source, source). In the past, this token’s activity has also raised concerns amongst the Evmos community about the significant gas price increase during peak utilization, as some dApp frontends on Evmos used a hardcoded gas price parameter.
Currently, XEN is present in 16 chains, and a few of these published how it is spamming their chain.
The research presents an investigation of how XEN Crypto works and reports the current state and impact of the XEN project in the Evmos chain and other EVM networks.
3. What is XEN?
XEN is a project designed to be inclusive and accessible to all, aiming to foster a community of like-minded individuals in the crypto space. Unlike many existing cryptocurrencies, XEN focuses on fair launch principles, avoiding issues such as pre-mining and whale accumulation by founding teams. It operates on the Ethereum network as an ERC-20 token, utilizing smart contracts for minting and distribution.
Key aspects of XEN include:
- Supply: There is no initial coin supply. Instead, coins are generated through participation in the Proof of Participation (PoP) protocol.
- Tokenomics: XEN has no maximum cap on supply and follows a unique distribution model where participants mint their own coins using their own compatible wallets. The token has no utility.
- Operations: XEN operates “without a controlling or management team”, relying on immutable smart contracts secured by the blockchain.
- Proof of Participation (PoP): XEN employs a PoP mechanism where participants have ownership rights through self-custody, and rewards are based on participation and contribution to the ecosystem. The value of XEN is tied to its scarcity, similar to Bitcoin, as more participants join and mint coins, making it more difficult to generate new tokens.
- Staking: Participants can stake XEN for APY rewards within a specified period, with rewards decreasing over time.
Overall, XEN claims to “uphold the core principles of blockchain technology, such as decentralization and transparency, while offering a fair and accessible cryptocurrency for mass adoption”.
Finally, a project called DBXen build on top of XEN, which gamifies the burning of the XEN token by earning rewards when doing so. For additional context, see DBXen X’s account and Telegram.
4. How Does XEN Work?
The backbone of the XEN project is the XENFT — XEN Torrent (XENT) protocol. XEN Torrent automates the execution of a series of on-chain transactions, maximizing XEN (ERC-20) mint by virtualizing Ethereum addresses used to claim cRanks (aka Virtual Minting Units, or VMUs), controlled by a user via XEN Torrent smart contract.
The smart contract that defines the protocol is the XENFT.sol. XEN Torrent also has two phases:
- set of VMUs (smart contracts) is created, whose number is controlled by the
countparameter set by a user. Upon creation, each VMU calls the original XEN Crypto smart contract withclaimRankfunction, initiating the XEN minting. Thetermparameter forclaimRankis also set by the user. These VMU contracts are deleted (i.e viaselfdestroy) after callingclaimMintReward. - XEN minting controlled by XEN Torrent Protocol reaches maturity. Once the maturity is reached, XEN Torrent Protocol user can perform a bulk
claimMintRewardoperation via controlled VMUs (created on the initial phase). XEN tokens minted during this operation are then transferred to a user-designated address (which could be user’s original address, or any other address on the network).
The reader should note that, according to the validation logic, the count parameter used in phase 1 should always be higher than 99. This is the count of smart contracts that will be created per transaction. See this transaction provided as an example. The bulkClaimRankLimited method is called and creates multiple contracts (count of contracts linked to the count param) by calling the _bulkClaimRank method.
5. XEN in Evmos
Currently, in Evmos the XEN project has more than 113M active minters (VMUs). These smart contracts work as a proxy and do use EVM contract storage. However, an account for each of these is created in the x/auth module that stores all the Evmos accounts, significantly increasing the contract accounts state.
The coXEN token is deployed at 0x2AB0e9e4eE70FFf1fB9D67031E44F6410170d00e. At the time of writing, this contract storage has 651,081,927 entries, which accounts for ~55GB of raw data. This accounts for 96% of the total disk space used by smart contracts EVM storage (total of 57.65GB).
The XENFT — XEN Torrent contract was deployed in at least 2 instances, with addresses 0x4c4CF206465AbFE5cECb3b581fa1b508Ec514692 and 0x9ec1c3dcf667f2035fb4cd2eb42a1566fd54d2b7. The first address has 7,922,208 contract storage entries, resulting in additional ~673MB of disk space used. This contract is the third biggest contract in storage size (showed in yellow in the figure below). The later contract is not verified and has only 9,700 storage entries.
6. Performance and Scalability Impact
6.1. Storage Spam
During the internal testing, we found that exporting a genesis file without the XEN token data resulted in a genesis file of 36 GB.
Adding up all the accounts/smart contracts created by XEN to the auth module, results in 13 GB more. On top of that, adding up all the smart contracts created by XEN to the EVM module represents 100 GB more.
Note that the usage in the database will be lower because the genesis file adds padding to some structures and also adds string keys and indenting to the file.
6.2. Performance Degradation
The team observed performance degradation in processes that deal with the whole state of the blockchains: genesis export/import, state-sync and snapshots creation.
Having a contract with more than 650M entries in the storage is causing all the processes that need to iterate the EVM module to require a lot of memory and making it slow. So the impact of these contracts are not just the amount of disk space used, but also the impact to the chain’s effectiveness to generate and apply snapshots when trying to synchronize a new node via state-syc or export the genesis file as JSON.
Impact on Network Upgrades
The amount of accounts added to the auth module means that additional resources are spent for upgrade migrations of the Evmos network. This is specially the case for large migrations that need to iterate through the account state. The XEN project has deployed at least 70,866,869 empty smart contract accounts (i.e no balance and zero nonce). These accounts are easily identifiable through the bytecode. As a result of the large number of accounts, network upgrades have become computationally intensive and slow, thus requiring multi-step upgrades to be able to iterate over all the accounts without having major downtimes, as in the case of the upcoming Single Token Representation v2 upgrade.
Genesis Export
The team performed a test exporting the current state of the chain using the evmosd export command with and without the coXEN contract. The operation was limited to read the values of the EVM module without creating the JSON file:
- 3 hs 37 min with the coXEN contract
- 33 min without the contract.
Consequently, this single project is responsible for most of the chain resources requirements, both for validators and node operators.
Genesis Import
Our team managed to export a genesis file for the Evmos state that was 76% smaller (36GB instead of 149GB) by removing all the XEN contracts.
Nevertheless, the process to import the genesis file to a new chain to try the state-sync and state-snapshots still failed because the Cosmos SDK code doesn’t work with genesis files bigger than 4GB. For this process to work, the team would need to adapt the cometbft/node.saveGenesisDoc to support larger genesis files and test with real data the state-sync process. Our team decided to not pursue these fixes for the time being due to time limitations to get this report published for our community.
State-Sync and State Snapshots
Another idea to test the state-sync process impact was to use the delete functions from the Cosmos SDK modules and then create a snapshot, but the process to remove all the entries from the EVM module and auth accounts was extremely slow and used a large amount of memory on the servers. However, this process would have taken several days without any guarantees that the process won’t run out of memory.
6.3 Gathering Data
All the performance problems listed above make the process of gathering the data extremely slow.
To be able to get the data for this report, our team spent two weeks due to the high requirements of the servers. Not even a machine with 350GB of RAM was able to handle the scripts to read the chain’s database. Additionally, every time that data analysis process was required, the process lasted at least 8 hours (overnight).
If you want to read more about the problems faced while getting the chain analytics, check out this post by our core team here.
6.4 Hardware Cost Impact
The most expensive hardware is the one that is running an archival node due to the database growth, which at the time of writing continues to increase by 1TB per month. Right now, running a RPC archive node cost at least 1,000 USD per month. If we can reduce the reset the state and prevent the state spam, the costs of running archive nodes will significantly drop and thus stop increasing each month.
For validators and RPC with pruned nodes, the costs can also be reduced because the node will not require extra memory to execute all the contract calls. As a result, the node’s database will be smaller, not only reducing the amount of disk usage but also reenabling state-sync (and smaller snapshots) to ensure fast recovery in case of failure.
With the small genesis file that we were able to export, an Evmos validator node could be run using the smallest Hetzner dedicated server (~€44.39 x month). Moreover, this setup would leave enough CPU, Memory and Disk Space free to run additional tooling on the same server.
7. XEN In Other EVM Networks
As mentioned previously, XEN project is present in 16 networks at the moment of writing this report. In numerous cases, this project represents a significant portion of their blockchain state, as per the independent analysis by Paradigm. The footprint is more notorious in networks with lower fees.
In Ethereum, the XEN ERC-20 contract takes 3.5% of the state (about 8.6GiB), being the largest contract in this chain by far (the second largest is USDT with 1.8GiB).
According to an independent research by Paradigm, XEN represents 68% of Base chain state, peaking at around 85% back in October 2023.
8. Conclusion
Our on-chain and off-chain investigation determined that the XEN project:
- Uses a vast majority of the Evmos’ EVM state (96%)
- Significantly degrades the performance of crucial tools for node operators to catch up (state sync and snapshot creation)
- Slows down all the processes related to reading and analyzing on-chain state
- Negatively impacts network UX for end-users by increasing the transaction fee (
BASEFEE) in periods of high demand (spam) of XEN - Makes the upgrades significantly more complex and cumbersome due to amount of empty accounts created by XEN (>70M)
- Significantly increases the cost for all infrastructure providers on Evmos: validators, archival nodes, indexer services and RPC nodes
- The project not only negatively impacts Evmos state but also a large number of EVM networks in the ecosystem such as Ethereum and Base
We encourage discussion from the Evmos Community based on this information for how to proceed with the large state requirements from XEN. The Evmos Core team will work on a set of short, medium, and long-term solutions with the aim to address the general issue of state growth on Evmos.
9. References
- Official XEN Whitepaper: https://xensource.gitbook.io/www.xenpedia.io/about-xen/whitepaper
- Official XENFT Litepaper: https://faircrypto.org/xenft_litepaper.pdf
- XEN Community Report (30 Nov, 2022): https://www.xencrypto.io/wp-content/uploads/2022/12/Community-Report-1.pdf
- Careful, XEN crypto is a pyramid scheme? (but ty for burning 1k+ gas per day): https://www.reddit.com/r/ethereum/comments/y06fmb/careful_xen_crypto_is_a_pyramid_scheme_but_ty_for/
- Why would anyone even buy XEN token?: https://www.reddit.com/r/xencrypto/comments/12rqxxs/why_would_anyone_even_buy_xen_token/
- ETH Deflation XEN: https://thedefiant.io/eth-deflation-xen
- How To Raise The Gas Limit: https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1
- XEN Network A Social Experiment On Crypto: https://medium.com/huobi-research/xen-network-a-social-experiment-of-crypto-43eada0de0c3
- Meet XEN Crypto: A New Hype Project that Turned Eth Deflationary https://coinpaper.com/620/meet-xen-crypto-a-new-hype-project-that-turned-eth-deflationary
About Evmos
Evmos is an interoperable EVM blockchain designed for cross-chain dApp development.
With groundbreaking roadmap features, such as Outposts and the Evmos dApp Store, Evmos gives developers the freedom to take advantage of the IBC and connect their smart contracts to the Cosmos Ecosystem. This revolutionary technology frees developers from the confines of today’s siloed blockchains.
The future is cross-chain.
Helpful Resources
🎮 Evmos dApp Store: https://store.evmos.org
🖥 Evmos Website: https://evmos.org
💻 Developer Documentation: https://docs.evmos.org
👾 Official Discord: https://discord.gg/evmos
🐙 GitHub: https://github.com/evmos/evmos
📯 Telegram: @EvmosOrg
📄 Blog: https://blog.evmos.org
🌋 Evmos Careers: https://evmos.org/careers
evmOS is the EVM stack for building natively cross-chain decentralized applications.
DISCLAIMER: None of this is financial advice. This content is strictly for educational purposes. It’s not investment advice or a solicitation to buy or sell any assets.
