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.
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.
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.
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 count parameter set by a user. Upon creation, each VMU calls the original XEN Crypto smart contract with claimRank function, initiating the XEN minting. The term parameter for claimRank is also set by the user. These VMU contracts are deleted (i.e via selfdestroy) after calling claimMintReward.
XEN minting controlled by XEN Torrent Protocol reaches maturity. Once the maturity is reached, XEN Torrent Protocol user can perform a bulk claimMintReward operation 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.