# Summary of Xenea The Xenea is an EVM-compatible Layer 1 blockchain with integrated autonomous decentralized storage. Our core architecture papers have passed peer reviews in informatics societies, including the IEEE, and have been academically recognized for the robustness of the protocol. Our approach is aimed at ensuring financial inclusion and ensuring assets with value are passed down to the next generation. We foresee widespread tokenization of real world assets (RWAs) and believe tokenization through NFTs will become increasingly important. However, current tokenization with NFTs often results in real data being stored in external storage, which could lead to loss of asset data and inconsistent ownership in the future. Thus, we aim to ensure data consistency and provide an infrastructure for secure transactions, allowing assets to be passed down to future generations. Key technical features of the Xenea are as follows: * EVM Compatible: Application developers can easily deploy applications for existing EVM compatible chains on the Xenea while using the development tools they are familiar with. * PoD (Proof of Democracy) : Consensus algorithms which do not rely on token prices for security and allow for massive decentralization will enable secure trading and transfer of assets for decades to come. * DACS (Decentralized Autonomous Content Storage): The Xenea integrates autonomous decentralized storage. This ensures data persistence with data and token consistency. # Core Technology # PoD（Proof of Democracy） PoD is the Xenea's proprietary consensus algorithm consisting of Rep and Escrow nodes. The algorithm aims to solve the following problems found in each of the consensus algorithms and enable large-scale decentralization, thereby enabling secure transactions and transfers of assets for decades and centuries to come. Other Consensus Mechanism Problems: * PoS (Proof of Stake) * Security dependent on token price * Centralization of power through a “rich get richer” structure
* PoW (Proof of Work) * Consumption of large amounts of energy and natural resources * Centralization by minority groups with capital to invest in significant computing resources PoD is a hybrid consensus algorithm consisting of an authorized Escrow node and a Rep node in which anyone can participate. Usually, the Rep node refers to the user's wallet. Originally, PoD's Voting Node was designed to allow anyone to participate unconditionally, but to prevent Sybil attacks, minor conditions are imposed on the requirement to participate as a Voting Node. To reduce the probability of parties with mal intent joining the consensus, the selection of both Escrow and Rep nodes is conducted randomly. Escrow nodes are randomly selected based on a determined transaction volume. In addition, Escrow nodes receive transaction confirmation status from randomly selected Voting nodes. Rep nodes selected by Escrow nodes participate in the transaction confirmation for a period of 10 blocks (i.e., 10 minutes). Five of the seven selected Rep nodes, excluding the sending and receiving nodes, vote True/Not-True for each transaction, where the Escrow nodes determine the validity of the transaction using a decision-making formula. In the meantime, tokens are held on Escrow nodes; if the sum of the True/Not-True results reaches or exceeds 75% of the threshold, the tokens on Escrow are released and the transaction is finalized. Escrow and Rep nodes participating in PoD earn fees and block rewards for each confirmed block based on the distribution ratio specified by the protocol. The block rewards have a half-life/halving every two years.

PoD Overview Diagram

For more information on PoD, please refer to our [Whitepaper](/whitepaper/consensus-algorithm). ### **Related Articles** High Secure Mobile Wallet for Token Transfer using Escrow Account on PoA Voting Blockchain\ Voting blockchain for High Security NFT\ Implementation of Smart Contract on Autonomous Decentralized Voting Blockchain\ # DACS (Decentralized Autonomous Content Storage) DACS (Decentralized Autonomous Content Storage) provides an architecture ensuring data consistency and persistence by integrating a distributed file system on the blockchain. DACS will initially support IPFS integration, followed by an expanded set of supported file system types. All storage units have a physical life span, and keeping data in the same storage eventually leads to data loss. Therefore, DACS uses a technology called Sustainable Generation Manager (SGM) to prevent data loss and ensure data persistence. SGM refers to each storage's timestamp and data storage status, replicating the data to other DACS nodes. The data on the original DACS node is then erased. By default, storage expires 180 days after data is stored. Upon expiration, the data is replicated to a new DACS node. The destination of data replication is determined based on network distance (number of hops). To make DACS more practical, we have also incorporated FASTD (Fast Track Contents Delivery Manager), which allows content to be preferentially cached in DACS nodes.

Diagram of Data Copying between Storage Units through SGM

For more information on DACS, please refer to our [Whitepaper](/whitepaper/decentralized-storage-system). ### Related Articles Sustainable NFT Blockchain Storage for High Availability and Security
# What is XENE? XENE is the native token of the Xenea network; XENE utilities are as follows: 1. **Network Currency:** Used for transaction fees and network usage fees.
2. **Governance:** Used by holders and their agents to exercise governance over proposals in the future (e.g., parameter changes, protocol upgrades, etc.).
3. **Block Rewards:** Rewards are used to protect the network and support the PoD consensus that validates transactions on chain. Escrow and Rep nodes receive XENE rewards as an incentive to continue to secure the network. Incentives for DACS nodes that provide storage are also allocated from block rewards. Rewards to these network participants are newly issued according to rules encoded in the protocol, increasing the supply of tokens up to a defined issuance limit.
4. **Collateral for DACS:** Used as collateral to become a DACS node, which is on-chain storage; to operate a DACS node, node operators are responsible for staking XENE and storing data.
5. **Rewards for Contributors:** Used to reward ecosystem builders and community contributors. # XENE Tokenomics XENE's Tokenomics aim to build a token economy that supports the Xenea to achieve the following key outcomes: 1. **Security:** An appropriate incentive model which rewards mining activity based on protocols will encourage many ecosystem participants to operate secure nodes.
2. **Decentralization:** Future distributed nodes and communities will contribute to ecosystem expansion and governance decisions.
3. **Sustainability:** The tokenomics are designed to encourage all important processes associated with the Xenea (e.g., verification of blocks) in a sustainable manner.
4. **Ecosystem Development:** XENE is used as an incentive for dApp developers to use the Xenea for application and service development. # XENE Max Supply The maximum supply of XENE issued is 18,328,109,640 XENE, consisting of 12,016,589,640 XENE (\~65.6%) generated at the Genesis block and 6,311,520,000 XENE (\~34.4%) generated through subsequent mining. # XENE Genesis Tokens A total of 12,016,589,640 XENE will be issued in the Genesis block. The team has decided to announce the Genesis token allocation and lockup schedule shortly before official mainnet release. If any token contribution is required during the mainnet beta phase, it will be made from the team's originally envisioned allocation for ecosystem growth.
# Mining XENE with PoD The Xenea provides mining rewards to network contributors through a proprietary consensus algorithm, PoD(Proof of Democracy). Mining rewards are paid for contributions to consensus and for contributions to storage. The former encourages Escrow and Rep nodes to accelerate network decentralization and enhance security. The latter encourages DACS node operators to store data for extended periods of time with responsibility. Mining for XENE will begin with the mainnet launch of the Xenea. The token quantity allocated for mining rewards is 6,311,520,000 XENE, where no additional tokens will be issued. ### Mining Rewards Distribution Ratio There will be multiple nodes supporting the Xenea. Mining rewards are allocated to each node as each block is generated every minute. The distribution ratio of mining rewards is as follows: **Table 1: Mining Rewards Distribution Ratio** | Node Type | Distribution Ratio | Description | | ------------------ | ------------------ | ------------------------------------------------------- | | Escrow Nodes | 0.02% | Approve a transaction based on the results of Rep Nodes | | Selected Rep Nodes | 50% (\*1) | Nodes that vote True/Not-True for each transaction | | DACS Nodes | 49.98% (\*2) | Nodes that manage data for on-chain storage | \*1 The 50% of rewards allocated to the selected Rep Nodes are further distributed as follows: * Equally divided among the five selected Rep Nodes. * Of each Rep Node’s share: * 40% is distributed to Node NFT holders in proportion to their ownership share. * 60% is distributed to mobile users connected to that Rep Node. \*2 The 49.98% of rewards allocated to DACS Nodes are distributed to Node NFT holders in proportion to their ownership share. ### Halving In order to control over-inflation of XENE, PoD block rewards of XENE will have a half-life of every two years. For the first two years after mainnet launches, block rewards generated per minute is 3,000 XENE and will be halved every two years thereafter; mining of XENE will continue until all 6,311,520,000 XENE allocated as mining rewards have been mined and issued. The following table displays the amount of XENE generated in the first 10 years of the Xenea mainnet since its inception, which will exhaust 96.88% of total block rewards. **Table 2: Amount of XENE issued through mining (first 10 years)** | Year | Reward amount per a block(XENE) | Annual amount mined(XENE)\* | Cumulative Annual amount mined(XENE) | | ---- | ------------------------------: | --------------------------: | -----------------------------------: | | 1 | 3,000 | 1,577,880,000 | 1,577,880,000 | | 2 | 3,000 | 1,577,880,000 | 3,155,760,000 | | 3 | 1,500 | 788,940,000 | 3,944,700,000 | | 4 | 1,500 | 788,940,000 | 4,733,640,000 | | 5 | 750 | 394,470,000 | 5,128,110,000 | | 6 | 750 | 394,470,000 | 5,522,580,000 | | 7 | 375 | 197,235,000 | 5,719,815,000 | | 8 | 375 | 197,235,000 | 5,917,050,000 | | 9 | 187.5 | 98,617,500 | 6,015,667,500 | | 10 | 187.5 | 98,617,500 | 6,114,285,000 | \*The year is calculated as 365.25 days taking leap years into account.
**Chart 1: Amount of XENE issued through mining (first 20 years)**
Chart 1: Amount of XENE issued through mining (first 20 years)

Chart 1: Amount of XENE issued through mining (first 20 years)

# Introduction The rise of **AI** and **DePIN (Decentralized Physical Infrastructure Networks)** is reshaping the demands placed on blockchain infrastructure. The next generation of the Internet requires systems that can securely store, update, and inherit data across generations—supporting workloads that range from large-scale model training to distributed network coordination. **Xenea is the storage layer for the AI & DePIN era.** By combining decentralized storage with an **EVM-compatible Layer 1 blockchain**, Xenea provides a foundation where data permanence and accessibility are inseparable from the value of the digital economy. It enables **cross-generational data inheritance**, ensuring that critical datasets remain intact, verifiable, and usable long into the future. At the heart of Xenea are two key innovations: * **Proof-of-Democracy (PoD)** – a proprietary consensus algorithm that ensures fairness, energy efficiency, and resilience by leveraging randomized Rep (Escrow) nodes to coordinate secure voting. * **Decentralized Autonomous Content Storage (DACS)** – a decentralized storage layer that guarantees permanent, verifiable ownership and incentivizes storage providers to preserve data across time. Together, PoD and DACS deliver **next-generation Web3 infrastructure** that supports data of all scales and formats—from immutable archives to dynamic datasets required for AI-driven services and decentralized networks. By addressing the limitations of conventional immutable-only storage systems, Xenea not only safeguards historical records but also **powers the future of AI and DePIN applications**, making it a cornerstone for the decentralized digital economy. # Legal Disclaimer This Xenea Whitepaper (the "Whitepaper") is provided for general informational purposes only and should not be considered a prospectus, offer document, or solicitation for investment. It does not constitute an offer to sell any tokens, products, or assets (whether digital or otherwise). This information shall not constitute exhaustive data and does not contain any part of the contractual relationship. There is no guarantee regarding the accuracy or comprehensiveness of this information, and no representation, warranty, or commitment is made or implied regarding its accuracy or comprehensiveness. Where the Whitepaper includes information that has been obtained from third party sources Xenea Initiative DMCC, its affiliates and any entities involved in the production of this Whitepaper (collectively, the “Entities”) have not independently verified the accuracy or completeness of such information. Further, you acknowledge that circumstances may change and that the Whitepaper may become outdated as a result; and the Entities are not under any obligation to update or correct this document in connection therewith. For the avoidance of doubt, the contents of this Whitepaper do not constitute an offer to sell or solicit any offer to buy any tokens, including XENE Tokens (as further defined herein). Nothing in the Whitepaper constitutes any offer by the Entities to sell any XENE Tokens (as defined herein) nor shall it or any part of it nor the fact of its presentation form the basis of, or be relied upon in connection with, any contract or purchase decision. Nothing contained in the Whitepaper is or may be relied upon as a promise, representation or undertaking as to the future performance of XENE Tokens or Xenea. The agreement between any of the Entities and you, in relation to any distribution or transfer of XENE Tokens (if any), is to be governed only by the separate terms and conditions of such agreement. The information set out in the Whitepaper is for informational purposes and discussion only and is not legally binding. No person is bound to enter into any contract or binding legal commitment in relation to the acquisition of XENE Tokens, and no virtual currency or other form of payment is to be accepted on the basis of the Whitepaper. The purchase of XENE Tokens (if any) shall be governed by a separate agreement setting out the terms of such purchase. In the event of any inconsistencies between such agreement and the Whitepaper, such agreement shall prevail. The information set out herein is only conceptual, and describes the future development goals of Xenea and XENE Tokens. The Whitepaper is provided solely for informational purposes and does not constitute any binding commitment. Please do not rely on this information in deciding whether to purchase XENE Tokens because ultimately, the development, release, and timing of any products, features or functionality remains at the sole discretion of the Entities, and is subject to change. Further, the Whitepaper may be amended or replaced from time to time. There are no obligations to update the Whitepaper, or to provide recipients with access to any information beyond what is provided herein. No regulatory authority has examined or approved, whether formally or informally, of any of the information set out in the Whitepaper. No such action or assurance has been or will be taken under the laws, regulatory requirements or rules of any jurisdiction. The publication, distribution or dissemination of the Whitepaper does not imply that the applicable laws, regulatory requirements or rules have been complied with. The information in this Whitepaper does not constitute a recommendation by the Entities, or any other person, nor does it constitute advice on the merits of purchasing XENE Tokens. XENE Tokens are the native tokens of the Xenea Network. XENE Tokens have an expected future usage solely within the Xenea Network. XENE Tokens are not a security of any kind, and they do not represent any right to vote, manage, or share in the profits or proceeds of any legal entity. XENE Tokens do not represent ownership of any physical asset, and they will not be redeemable by any legal entity. The Entities do not guarantee or suggest any economic return from purchasing XENE Tokens, and you should not purchase XENE Tokens for any speculative purposes. Purchasing XENE Tokens should be without expectation of any profit, dividend, capital gain, financial yield or any other return, payment or income of any kind. No language in this Whitepaper should be understood, deemed, interpreted or construed, under the laws of any applicable jurisdiction, to equate XENE Tokens to any kind of: 1. Money, legal tender or currency, whether fiat or otherwise; 2. Equity or proprietary interest in any entity, scheme or venture; 3. Investment in any entity, common enterprise, scheme or venture, taking any form, whether equity, debt, or as a commodity (or any combination thereof, whether to be delivered in the future or otherwise); 4. Instrument, entity, scheme or venture that participates or receives any dividend, payment, profit, income, distribution or other economic returns; 5. Security, futures contract, derivative, deposit, negotiable instrument (including commercial paper), investment contract or collective investment scheme between the holder and any other person or entity; or 6. Asset or commodity (whether to be delivered in the future or otherwise), including any asset or commodity that any person or entity is obliged to repurchase or redeem. All statements contained herein may constitute forward-looking statements which can be identified by the use of forward-looking terminology such as "may", "will", "should", "expect", "anticipate", "project", "estimate", "intend", or "believe" or the negatives thereof or other variations thereon or comparable terminology (including but not limited to statements regarding intent, belief or current expectations with respect to market conditions, business strategy and plans, financial condition, specific provisions and risk management practices). You are cautioned not to place undue reliance on these forward-looking statements given that these statements involve known and unknown risks, uncertainties and other factors that may cause the actual future results to be materially different from that described by such forward-looking statements, and no independent third party has reviewed the reasonableness of any such statements or assumptions. These forward-looking statements are applicable only as of the date indicated in the Whitepaper, and the Entities and expressly disclaim any responsibility (whether express or implied) to release any revisions to these forward-looking statements to reflect events after such date. The use of any company and/or platform names or trademarks herein (save for those which relate to the Entities) does not imply any affiliation with, or endorsement by, any third party. References in the Whitepaper to specific companies and platforms are for illustrative purposes only. The Whitepaper may be translated into a language other than English for reference purpose only and in the event of conflict or ambiguity between the English language version and translated versions of the Whitepaper, the English language versions shall prevail. You acknowledge that you have read and understood the English language version of the Whitepaper. No part of the Whitepaper or the Website is to be copied, reproduced, distributed or disseminated in any way without the prior written consent of the Entities. By accepting any hard or soft copy of the Whitepaper, you agree to be bound by the foregoing limitations. # Motivation # Basic Concepts of Blockchain ## What is blockchain? A blockchain is a ledger that is shared and immutable. It aids in the process of recording transactions and keeping track of assets within a business network. Assets can be either tangible (such as a house, car, cash, or land) or intangible (such as intellectual property, patents, copyrights, or branding). Almost anything valuable can be monitored and exchanged on a blockchain network, leading to reduced risk and lower costs for everyone involved. ## Why is blockchain important? The efficiency and accuracy of a business depend on the speed and accuracy of the information it receives. Blockchain is an ideal technology for delivering this information as it offers immediate, shared, and completely transparent information stored on an unchangeable ledger that can only be accessed by authorized network members. A blockchain network can effectively track various aspects such as orders, payments, accounts, production, and more. Additionally, since all members have access to the same information, you can confidently analyze the complete details of a transaction, resulting in improved confidence, increased efficiency, and new possibilities. ## Key elements of a blockchain ### 1. Distributed ledger technology All participants in the network have access to the distributed ledger and its record of transactions that cannot be changed. This shared ledger ensures that transactions are only recorded once, eliminating the need for duplicating efforts commonly seen in traditional business networks. ### 2. Immutable records No participant is allowed to alter or manipulate a transaction once it has been recorded on the shared ledger. In case of an error in a transaction record, a new transaction must be appended to rectify the mistake, and both transactions will be visible thereafter. ### 3. Smart contracts In order to expedite transactions, a collection of regulations, known as a smart contract, is stored on the blockchain and implemented automatically. This smart contract has the ability to establish guidelines for the transfer of corporate bonds, incorporate conditions for the payment of travel insurance, and encompass various other functions. ## How blockchain works ### 1. As each transaction occurs, it is recorded as a “block” data These transactions demonstrate the transfer of either a tangible asset, such as a product, or an intangible asset, such as intellectual property. The data block has the capability to capture various types of information, including the person involved, the nature of the transaction, the time and location it occurred, the quantity or value of the asset, and even specific details like the temperature of a food shipment. ### 2. Each block is connected to the ones before and after it As an asset moves from one place to another or changes ownership, these blocks create a chain of data. The blocks verify the precise time and order of transactions, and they are securely linked together to prevent any alteration of a block or the insertion of a block between two already existing blocks. ### 3. Transactions are blocked together in an irreversible chain: a blockchain The verification of each additional block strengthens the verification of the previous block, thus enhancing the security of the entire blockchain. As a result, the blockchain becomes tamper-evident, ensuring its immutability. This eliminates the potential for tampering by malicious individuals and creates a trustworthy ledger of transactions for you and other network participants. ## Benefits of blockchain ### 1. Greater trust By utilizing blockchain technology within a restricted network of members, you can have confidence in the accuracy and timeliness of the data you receive, as well as the assurance that your private blockchain records will only be disclosed to those members whom you have specifically authorized. ### 2. Greater security All network members must reach a consensus on the accuracy of data, and validated transactions cannot be deleted as they are permanently recorded. Even a system administrator does not have the ability to delete a transaction. ### 3. More efficiencies Eliminating time-wasting record reconciliations, a distributed ledger shared among network members is utilized. Additionally, to expedite transactions, a collection of regulations, known as a smart contract, can be stored on the blockchain and executed automatically. ## Types of blockchain networks ### 1. Public blockchain networks A public blockchain, like Bitcoin, allows anyone to join and take part. However, there are drawbacks to consider, such as the need for significant computational power, lack of privacy in transactions, and relatively low security. These factors are crucial to keep in mind when it comes to using blockchain in enterprise scenarios. ### 2. Private blockchain networks A decentralized peer-to-peer network, known as a private blockchain network, operates similarly to a public blockchain network. However, the network is governed by a single organization that determines participation, executes a consensus protocol, and maintains the shared ledger. This arrangement can greatly enhance trust and confidence among participants, depending on the specific scenario. A private blockchain has the capability to operate within a corporate firewall or be hosted on premises. ### 3. Permissioned blockchain networks Businesses that establish a private blockchain typically establish a permissioned blockchain network, which should be noted as public blockchain networks can also be permissioned. This imposes limitations on individuals eligible to engage in the network and the transactions they can partake in. To join, participants must acquire an invitation or authorization. ### 4. Consortium blockchains Multiple organizations have the ability to divide the duties of upholding a blockchain among themselves. These specifically chosen organizations are the ones who decide which individuals can send transactions or retrieve the information. A consortium blockchain is advantageous for businesses in situations where every participant must be given permission and collectively be accountable for the blockchain. # Current Blockchain Issues Regardless of whether they are public, consensus, or private, blockchains have various problems such as interoperability, network latency, rising network fees, and storage risk with NFT data. Here are some of the problems with blockchains we will try to minimize in our proposed solution. ## Main issues of blockchain ### 1. Soaring Transaction Fees Due to the high computational demands necessary for transaction validation, blockchain networks can be slow and inefficient. As the volume of users, transactions, and applications grows, blockchain networks struggle to process and validate them promptly. Consequently, blockchain networks are not suitable for applications that necessitate rapid transaction processing speeds. Consensus algorithms such as Proof of Work (PoW) and Proof of Stake (PoS) are utilized by traditional blockchains like Bitcoin and Ethereum. However, these algorithms can be time-consuming and require a significant amount of resources. Consequently, these networks experience restrictions in terms of transaction throughput, frequently resulting in congestion and elevated transaction fees. Different solutions have been suggested in order to address scalability problems, such as scaling systems designed for establishing off-chain channels, which enable quicker and more economical transactions. Although blockchain experts have made some progress, the achievement of scalable, efficient, and decentralized blockchain networks remains an ongoing challenge that requires further exploration. ### 2. Network Congestion One of the scalability issues that became apparent on the Ethereum mainnet was network congestion caused by the rise of DeFi protocols and NFT marketplaces in 2020–2021. During peak activity, gas fees spiked and transaction throughput slowed significantly, highlighting the broader challenge of scaling Ethereum and similar Layer 1 blockchains. ### 3. Irreversible Transactions Transactions made on a blockchain cannot be undone or reversed once they are confirmed. Therefore, it is crucial for the sender to exercise caution and double-check that they have entered the correct recipient address for the transaction. ### 4. High Computational Costs Proof-of-Work (PoW) consensus mechanisms secure networks through high computational power. However, this approach is energy intensive and has a substantial environmental impact. Validating transactions on a PoW-based blockchain requires significant computing resources, leading to concerns over carbon emissions and sustainability. In response, many blockchain projects have adopted alternatives such as Proof-of-Stake (PoS), which consume far less energy. Ethereum, for example, completed its transition from PoW to PoS in 2022 through “The Merge,” reducing its energy consumption by more than 99%. While this marked a major milestone in sustainable blockchain design, the industry continues to explore additional innovations to further minimize energy usage and strengthen environmentally responsible practices. ### 5. Security issues with PoS While the shift to Proof-of-Stake has addressed the environmental concerns of Proof-of-Work, it also introduces different challenges. One such concern is that security risks increase when fewer validators govern the network. Specifically, if an individual or entity gains control of more than one-third of the stake, they could exert significant influence over consensus. Although this risk exists, it is considered improbable in widely distributed networks where tokens are broadly held. ### 6. NFTs and the permanent linkage of content data stored in decentralized storage A significant portion of the content linked to NFTs is not directly stored on the blockchain. Instead, it is stored in external storage systems. However, if these external storage systems become non-functional or the data stored within them is lost, the symbolic and inherent value of owning an NFT also vanishes. This means that the unique and exclusive nature of the NFT, which is derived from its symbolic data, can be jeopardized in such situations. # Xenea Blockchain Our voting-based blockchain, Xenea, is an original Layer 1 protocol developed based on peer-reviewed research (see the published articles listed at the end of this document for reference). This blockchain solution is designed to address the aforementioned challenges. Similar to Ethereum, developers can build decentralized applications (dApps) on the Xenea platform by leveraging its support for smart contracts and autonomous decentralized storage. These capabilities enable a wide range of use cases, including DeFi, NFT marketplaces, and other Web3 applications. # Objectives of Xenea The primary objectives of Xenea are to: * **Purpose and Uniqueness**\ Xenea is designed to overcome several persistent challenges faced by conventional blockchains: * **Cost efficiency** – Reduce the burden of transaction fees by providing a near-zero cost environment for transfers and smart contract execution. * **Data persistence** – Ensure the long-term availability and integrity of digital assets through autonomous decentralized storage, addressing the weakness of today’s NFT data being stored off-chain. * **User inclusiveness** – Expand participation in consensus beyond high-resource validators by enabling mobile users to join through representative nodes, increasing both accessibility and diversity of governance. * **Transaction safety** – Mitigate the risk of erroneous transfers by embedding an escrow-based confirmation mechanism at the protocol layer. These objectives form the foundation of Xenea’s architecture. The following sections will explain how its consensus mechanism (PoD), token economy, and decentralized storage (DACS) realize these goals in practice.. # Basic Functions of the Xenea This chapter describes the basic functions and the overall structure of Xenea with Figure 1.
## **1. Consensus Algorithm: Proof of Democracy (PoD)** Xenea adopts a proprietary consensus algorithm called **Proof of Democracy (PoD)**.\ PoD combines two primary node types: **Escrow Nodes** and **Rep Nodes**. * **Escrow Nodes** handle blockchain initialization, generate new blocks every 60 seconds, monitor network connectivity, and randomly select Rep Nodes as voting participants. They also hold escrow accounts, temporarily retaining tokens until transactions are validated. * **Rep Nodes** serve as voting candidates and can aggregate up to 10,000 mobile users. Acting on behalf of these users, Rep Nodes participate in the voting process and distribute rewards back to them. When a transaction is submitted, the Escrow Node randomly selects five Rep Nodes (excluding the sender and receiver) to validate it. If **75% or more** approve, the Escrow Node finalizes the block and releases tokens from escrow. This design enables both security and inclusiveness at scale. ## **2. Token Economy (XENE)** The native token of the Xenea blockchain is **XENE**, which underpins the network’s incentive model. * **Zero-cost transfers:** XENE transfers are free of gas costs, while fungible token (FT) and non-fungible token (NFT) transactions incur near-zero fees. * **Block rewards:** New blocks yield **300 XENE** at genesis, with rewards halved every two years to ensure sustainable issuance. * **Distribution:** Rewards are shared among Escrow Nodes, Rep Nodes (and their mobile participants), and DACS Nodes. This balanced allocation encourages wide participation across consensus, validation, and storage functions. * **Collateral & utility:** DACS operators must stake XENE to operate, and XENE also serves as a basis for governance and ecosystem incentives. ## **3. Decentralized Autonomous Content Storage (DACS)** To ensure persistence of on-chain content, Xenea integrates **DACS (Decentralized Autonomous Content Storage)**. Initially built on IPFS, DACS expands to support **both static and dynamic data**, enabling reliable NFT storage as well as future real-time applications. Features include: * **Sustainable Generation Manager (SGM):** Periodically replicates data to new nodes, guaranteeing long-term durability even as hardware ages. * **Dynamic data support:** Unlike conventional NFT storage limited to immutable files, DACS incorporates write-buffer mechanisms (e.g., W-Nodes) to manage dynamic content securely. * **FASTD caching:** Provides low-latency access for time-sensitive applications. Together, PoD, XENE, and DACS establish Xenea as a Layer 1 blockchain that is both sustainable and extensible. The following chapters will examine each of these components in depth. # Other Specifications The Xenea blockchain includes the following operational specifications: * **Gas Fees** * **XENE and fungible tokens:** Gas fees for transactions in XENE are set to zero, and fees for fungible tokens are set at a minimal level. * **Non-fungible tokens:** Gas fees vary depending on the complexity of the executed smart contract. * **Peer Limit**\ The network supports up to 300 peers. This parameter is set to balance scalability and stable network performance. * **Node Identification**\ Nodes are assigned flags to distinguish between Escrow Nodes and DACS Nodes. This allows Escrow Nodes to distribute rewards appropriately. * **Random Selection**\ When nodes are randomly selected for voting, Escrow Nodes and DACS Nodes are excluded from the candidate pool. This ensures that voting responsibilities are assigned only to the relevant node types. # Consensus Algorithm As previously noted, our Escrow node is a voting transaction confirmation node. Each Escrow node is randomly selected according to a determined transaction volume and receives transaction confirmation status from a randomly selected Rep node. During the 10-block generation, five Rep nodes, excluding the sending and receiving nodes from the seven selected nodes, vote on each transaction, Escrow nodes determine true or not-true of a transaction using a decision-making formula. The number of Rep nodes participating in the vote will change depending on the scale of Rep nodes joining in the future. If the sum of the transaction’'s true/not-true results are greater than or equal to 75% (the threshold value), the transaction's token is released. Figure 2 shows the flow diagram for true/not-true transactions.
## **Escrow Accounts** Escrow node escrow accounts help prevent the mistake of giving tokens to the wrong party. The Escrow node holds the tokens until the transactions in the escrow account are confirmed by selected multiple Rep nodes, and when the Escrow node confirms that the transaction is true, it releases the tokens to the recipient's wallet. ## **​​Escrow Account Determination Formula** ![](https://lh7-us.googleusercontent.com/NyfJRUfivzo69fKSUsoiFkzHBfyYalMOjfYW_aWXXwdCu-a3ICHqXDn_PotRQEEBNaMr_ZXk05aiWmNsBUy4BQajOX-A7rv9sM4qU2YNIaPypUIkZOkBqKCmF4UzRW9iZuiWhiY1X1cK8-7B3pIfWUlwLzLyHUGj) θj is the bias coefficient of the decision condition when the NFT content has comments. In the default setting example below, seven nodes were selected, five nodes responded True except for sender and receiver nodes, and one node responded Not-True. If the threshold is less than or equal to 75%, the transaction is considered a "True" transaction.
User TypeRep NodeReply SignalResultCustody
NFT buyerATTrueTrue
NFT sellerBTTrueTrue
Other userCNTTrueTrue
Other serviceDNTTrueTrue
Other userENTTrueTrue
Other serviceFTNot trueNot true
Other userGNTTrueTrue
In the above example, the result is True both when the response signal is True (lines 1 and 2) and when it is not (lines 3,4, and 5). The motivation for maintaining Xenea is it has the capability of PoD mining with a confirmation vote for each transaction. The Xenea algorithm randomly selects a number of nodes to identify the transaction nodes. If consensus is reached, all selected nodes will receive token rewards. Thus, all participating Rep nodes have the opportunity to receive rewards if they reply to the transaction confirmation within the required time frame.
# Xenea Blockchain Nodes: The Pillars of the Network The Xenea blockchain ecosystem comprises three distinct types of nodes: 1\. Escrow Node The Escrow Node serves as the genesis node, taking on the critical responsibility of initiating and managing the entire Xenea blockchain. Its functions include: * Blockchain Initialization: The Escrow Node initializes the blockchain, ensuring a smooth start to the network. * Block Generation: Every minute, the Escrow Node generates a new block, contributing to the continuous operation of the blockchain. * Node Connectivity Checks: At 10-minute intervals, the Escrow Node performs connectivity checks on connected nodes. From these, it randomly selects five nodes to function as Rep Nodes. 2\. Rep Node Rep Nodes are randomly selected by the Escrow Node to validate transactions through a voting process. Here's how they operate: * Transaction Validation: Upon any transaction within the Xenea blockchain, the Escrow Node broadcasts it to all nodes. The randomly selected Rep Nodes then cast votes on the transactions. * Vote Casting: When a Rep node casts its vote, the Escrow Node checks if 75% or more of the votes validate the transaction. If they do, the transaction gets added to the block. If not, it doesn't get added to the block. 3\. DACS Node (Decentralized Autonomous Content Storage Node) DACS Nodes play a crucial role in providing storage for Non-Fungible Token (NFT) content. Here's an in-depth look at their functionalities: * NFT Content Storage: DACS Nodes utilize a modified IPFS GUI, allowing any user to add NFT content securely. Once added, the content cannot be removed. * IPFS Daemon Operation: To facilitate secure storage, DACS Nodes operate an IPFS daemon, ensuring the integrity and accessibility of stored NFT content. # Finality ## What is finality? Finality in blockchain pertains to the irrevocable verification of a transaction or a group of transactions. In traditional financial systems, once a transaction is verified, it cannot be reversed. Similarly, achieving permanence on a blockchain network guarantees that a transaction is unalterable once it is included in the blockchain. This concept is essential for ensuring the security and authenticity of the blockchain. The use of consensus in the blockchain network enables the achievement of finality. Various consensus algorithms are utilized by different blockchain networks, each employing a distinct method to validate transactions and ensure finality. Examples of these algorithms include proof-of-work (PoW), proof-of-stake (PoS), and practical Byzantine fault tolerance. ## Finality of Xenea Blocks In Xenea, blocks are generated every 60 seconds. The finality of a transaction is reached not merely when the block is created, but when the transaction is validated and signed by an Escrow Node. At that moment, the transfer becomes irreversible. This design ensures that users can rely on the permanence of confirmed transactions while maintaining efficient block production and secure consensus.
# Token Economy # Token Allocation and Supply ### XENE Max Supply The maximum supply of XENE issued is 18,328,109,640 XENE, consisting of 12,016,589,640 XENE (\~65.6%) generated at the Genesis block and 6,311,520,000 XENE (\~34.4%) generated through subsequent mining. ### XENE Genesis Tokens Allocation A total of 12,016,589,640 XENE will be issued in the Genesis block. The team has decided to announce the Genesis token allocation and lockup schedule shortly before official mainnet release. If any token contribution is required during the mainnet beta phase, it will be made from the team's originally envisioned allocation for ecosystem growth. ### Mining XENE with PoD The Xenea provides mining rewards to network contributors through a proprietary consensus algorithm, PoD（Proof of Democracy）. Mining rewards are paid for contributions to consensus and for contributions to storage. The former encourages Escrow and Rep nodes to accelerate network decentralization and enhance security. The latter encourages DACS node operators to store data for extended periods of time with responsibility. Mining for XENE will begin with the mainnet launch of the Xenea. The token quantity allocated for mining rewards is 6,311,520,000 XENE, where no additional tokens will be issued. ### Mining Rewards Distribution Ratio There will be multiple nodes supporting the Xenea. Mining rewards are allocated to each node as each block is generated every minute. The distribution ratio of mining rewards is as follows: Table 3: Mining Rewards Distribution Ratio | Node Type | Distribution Ratio | Description | | ------------------ | ------------------ | ------------------------------------------------------- | | Escrow Nodes | 0.02% | Approve a transaction based on the results of Rep Nodes | | Selected Rep Nodes | 50% (\*1) | Nodes that vote True/Not-True for each transaction | | DACS Nodes | 49.98% (\*2) | Nodes that manage data for on-chain storage | \*1 The 50% of rewards allocated to the selected Rep Nodes are further distributed as follows: * Equally divided among the five selected Rep Nodes. * Of each Rep Node’s share: * 40% is distributed to Node NFT holders in proportion to their ownership share. * 60% is distributed to mobile users connected to that Rep Node. \*2 The 49.98% of rewards allocated to DACS Nodes are distributed to Node NFT holders in proportion to their ownership share. ### Halving In order to control over-inflation of XENE, PoD block rewards of XENE will have a half-life of every two years. For the first two years after mainnet launches, block rewards generated per minute is 3,000 XENE and will be halved every two years thereafter; mining of XENE will continue until all 631,152,000 XENE allocated as mining rewards have been mined and issued. The following table displays the amount of XENE generated in the first 10 years of the Xenea mainnet since its inception, which will exhaust 96.88% of total block rewards. Table 4: Amount of XENE issued through mining (first 10 years) | Year | Reward amount per a block(XENE) | Annual amount mined(XENE)\* | Cumulative Annual amount mined(XENE) | | ---- | ------------------------------: | --------------------------: | -----------------------------------: | | 1 | 3,000 | 1,577,880,000 | 1,577,880,000 | | 2 | 3,000 | 1,577,880,000 | 3,155,760,000 | | 3 | 1,500 | 788,940,000 | 3,944,700,000 | | 4 | 1,500 | 788,940,000 | 4,733,640,000 | | 5 | 750 | 394,470,000 | 5,128,110,000 | | 6 | 750 | 394,470,000 | 5,522,580,000 | | 7 | 375 | 197,235,000 | 5,719,815,000 | | 8 | 375 | 197,235,000 | 5,917,050,000 | | 9 | 187.5 | 98,617,500 | 6,015,667,500 | | 10 | 187.5 | 98,617,500 | 6,114,285,000 | \*The year is calculated as 365.25 days taking leap years into account. Chart 2: Amount of XENE issued through mining (first 20 years)
Chart 1: Amount of XENE issued through mining (first 20 years)

Chart 1: Amount of XENE issued through mining (first 20 years)

### XENE Burning Mechanism Some of the gas fees collected by the network may be burned through future changes, in which case XENE may become deflationary. # Halving ### What is a halving? In the Xenea network, a **halving** takes place every two years. A halving refers to the scheduled reduction in block rewards—meaning the amount of Xenea distributed to nodes for validating transactions or securing the network is reduced by 50%. As a result, the pace at which new Xenea enters circulation gradually slows over time. This event is not random; it is a **protocol-level rule** embedded in the blockchain’s code and is transparent to all participants. The mechanism ensures a predictable issuance schedule, providing long-term clarity for network participants and developers alike. ### Why does a Xenea halving occur? Xenea halvings occur as part of the protocol’s **monetary design**. Their purpose is not to guarantee price movements or enforce deflation, but rather to **manage issuance and align incentives** over the lifetime of the network. Key objectives include: * **Controlled issuance**\ By gradually reducing rewards, halvings prevent unlimited inflation of supply. The total issuance curve becomes smoother and more predictable, which is critical for long-term economic planning. * **Incentive realignment**\ As rewards diminish, the network gradually shifts reliance away from new issuance toward **transaction fees** as a primary incentive for validators. This transition supports the sustainability of the network in the long run. * **Economic discipline**\ Regular halvings encourage efficiency among validators. Operators are incentivized to optimize infrastructure, reduce costs, and maintain competitiveness as rewards change. ### Market considerations While halvings often attract attention in crypto markets, **their impact on price is indirect**. Reduced issuance does not automatically translate into scarcity-driven appreciation. Market value is ultimately determined by broader factors, including: * Adoption of the Xenea ecosystem * Demand for storage and compute resources * Overall liquidity and macroeconomic conditions It is important to emphasize that halvings are **a supply-side mechanism only**. They do not guarantee price increases, nor do they alone determine the asset’s economic trajectory. # Decentralized Storage System This chapter introduces the proposal of DACS and Sustainable Generation Manager (SGM) to maintain storage availability on Xenea. Also presented is the system architecture and its implementation along with its parameters. Inside the payload of Xenea, a hash value of the stored data is input. Therefore, the Layer 1 blockchain with the capability to store the hash value along with the NFT contents is required. The proposed system architecture allows for long-term and secure storage of large amounts of NFT content. ## **Decentralized Autonomous Contents Storage (DACS)** Decentralized Autonomous Contents Storage (DACS) is an architecture for integrating distributed file systems into blockchains. DACS enables sustainable content storage by linking IPFS and other hash-based file systems across multiple nodes on the network. Each DACS node can input a user's NFT content or its payload as transactions onto blocks of Xenea multiply. Users store their NFT content in these nodes without losing their NFT data. ## **Network design and conditions for DACS nodes** DACS nodes connect storage devices to Xenea and contribute to maintaining the Xenea network; DACS nodes are designed to add only the necessary storage space on Xenea and not increase the unnecessary on the Xenea network, thereby stabilizing the mining process. DACS nodes can acquire storage operating rights and accept additional XENE staking. The amount of staking is proportional to the amount of physical storage in the DACS node. ## DACS node operating conditions: The storage features of the DACS node will be operated under the responsibility of its owner, however, in Phase 1, until the Xenea network is stable and sufficiently decentralized, Xenea will operate the Decentralized Autonomous Contents Storage (DACS) mining pool in the form of cloud mining, as well as the maintenance of the physical storage space of the DACS nodes. When the number of DACS nodes is sufficiently decentralized to enter Phase 2 or beyond, each DACS node can operate and manage its own physical storage by satisfying the DACS node's operational requirements. To become a DACS node owner, one must have storage and a collateral XENE. XENE held in collateral will be deducted in the event of a failure of the DACS node's network, depending on the severity of the failure. The XENE collateral will be returned to the DACS node at the end of the contract term, but may remain as collateral if the DACS node is to continue to operate. # Sustainable Generation Manager (SGM) Phase-I **Sustainable Generation Manager (SGM)** is a technology developed to ensure that data stored on Xenea lasts perpetually, preventing data loss over the lifetime of the storage device and other risks. SGM also eliminates the excessive decentralization of data, avoiding the increase in data volume caused by unnecessary encrypted and decentralized data. DACS alone cannot guarantee the sustainability of each storage device to store data permanently for 100 or 200 years on its own. Therefore, it must be maintained at the system level. SGM keeps and references the timestamp of each storage, then replicates the data or NFT with its contents to other DACS nodes. The default storage expiration date is every 180 days from the end of the day on which the data was stored. When the storage lifetime expires, the DACS node is replicated and restored to a new DACS node. The 1st generation node then expires and all the data on it is deleted. After the deletion, the node may be reused as storage space for new content; SGM replicates the data of the 1st generation DACS node to the free space of the 2nd generation. Once the replication is complete, the 1st generation storage space is freed up as storage space for new content.
**SGM Parameters** First, data is stored on the storage node, then the date of the last updated storage is stored on the mainnet; if more than 180 days have passed, SGM searches for a new storage node at the closest network distance (number of node hops), and selects the target storage node. The target node will store the data of the storage node that is over 180 days old with a P2P connection. The main parameters include: 1. Last modified date of the storage node 2. Timestamp measurement of each storage node's update date and time 3. Search for new storage node candidates by nearest pops 4. Data replication by copy command. The table below shows the list of conditional parameters:
FunctionParameters
Date of the last update of the storage node.YearMonthDate


Measure of each storage node date with timestamp.YearMonthDate


Search the new candidate of the new storage node by nearest pops.1 hop2 hops3 hops


Duplication date parameters are set from 1 day to 365 days.1 day1 week1 month3 months6 months12 months
Figure 4 shows the data replication process flow chart of SGM: SGM agent continuously observes all storage nodes and selects the next candidate storage node for the new region of NFT data. Old storage after 180 days (default value) moves its data to the new storage and will be used for new data. Storage that has lost capacity due to physical damage can also be utilized on a per-size basis. Thus, eventually, these older storages can also be maintained as active nodes, with the storage node owners keeping their mining rewards for the storage space held by the DACS node.
# Fast Track Contents Delivery Manager (FASTD) **FAST Track Contents Delivery Manager (FASTD)** is a system that can preferentially cache content on DACS nodes, allowing content to be managed in a designated cache area and accessible with low latency. For example, some financial NFT content requires low-latency time access; using FASTD, content organizers can select these content as FAST Tracks. In addition, the use of Data Transmission System (DTS) can greatly expand CPU cache storage space.

# Governance The governance of Xenea has a predetermined process for changing protocols. It is important to note here that this process is not relevant to how people or applications use the protocol. Once mainnet has been released, Xenea is open for participation of on-chain activities. During development, there were no restrictions on incorporating escrow functions utilizing Escrow nodes or sending transactions. Anyone can build applications on the Xenea. There is a process to propose changes to the Xenea core protocol, which is the foundation for these applications to operate.The process should be done carefully, as any change to the core protocols could affect any behavior of Xenea. In order to ensure that changes are made safely and supported by the entire ecosystem, exceptionally high hurdles are set for the change process. Comparison of On- and Off-chain governance 1\. On-chain governance On-chain governance means that proposed protocol changes are determined by votes of stakeholders who are the holders of governance tokens, and the voting takes place on the blockchain. 2\. Off-chain governance Off-chain governance means that decisions on protocol changes are made in an informal process of discussion and, if approved, implemented in code. The change of the Xenea core protocol employs the off-chain governance described in (2). It is carefully implemented through a defined process from proposal to decision. However, while the Xenea governance is off-chain at the protocol layer, applications built on Xenea may use on-chain governance for each. And in the future, if on-chain governance is passed by the XKP, it is possible that the XENE could be used as a governance token to move to on-chain governance. **Stakeholders** The Xenea community has a variety of stakeholders, each with their own role in the governance process. Listed in order from the stakeholder remotest from the protocol are: ・XENE owner: An owner of XENE ・Application user: A user who uses applications on the Xenea ・Rep node: A voting node participating in the consensus of the Xenea. Voting nodes are randomly selected for each transaction ・Application/tool developers: Developers of decentralized applications running on the Xenea (Defi, NFT marketplace, etc.) or tools such as wallets and systems interacting with the network ・Escrow Node: A node which is randomly selected based on the volume of transactions and receives transaction confirmations from a randomly selected Rep node to determine the authenticity of transactions ・DACS Node: A node providing storage for the Xenea ・Xenea Kaizen Proposal (XKP) Drafter: Proposes changes to the protocol in the form of a Xenea Kaizen Proposal (XKP) ・Protocol Developers (a.k.a. "Core Developers"): Protocol Developers performing various implementations on the Xenea **What is a Xenea Kaizen Proposal (**XKP**)** One of the key processes used in the governance of Xenea is the XKP. This process does not eliminate the possibility of moving to on-chain governance in the future, but initially it is a process for making suggestions to the protocol developers; the XKP is a standard that defines new features and processes for the Xenea and can be created by anyone in the community. **Official Process** The official process for making changes to the Xenea protocol is as follows: Improvement Proposal: To formally propose a change to the Xenea, it must first be detailed in the Core XKP. If accepted, it becomes an official specification of the XKP to be implemented by the protocol developer. Presentation of a XKP to the protocol developer: After a XKP is created, it is presented to the protocol developers for discussion. Discussions may already be taking place in parallel in the Xenea Discord. Possible outcomes at this stage include the following: ・The XKP will be considered for future network upgrades ・Request for technical changes will be made ・Rejected if low priority or if the improvement effect is not impactful compared to the development effort Iterate on the final proposal: After receiving feedback from stakeholders and the community, changes will probably need to be made from the initial proposal to improve security or to meet various needs. Once the XKP reflects all changes deemed necessary, it will be presented again to protocol developers. They may then proceed to the next step, or new concerns may arise and the proposal may be iterated again. Included in the Network Upgrade: If the XKP is approved, tested, and implemented, it will be included as part of the network upgrade. Since a network upgrade requires the entire network to be upgraded at the same time, the XKP is typically combined with the timing of the upgrade. Network Upgrade Activation: Once the network upgrade is activated, the XKP will go live on the Xenea network. Note: Network upgrades are typically performed on the test net before being activated on the mainnet. This flow is very simplified, but outlines the key steps to enable protocol changes on the Xenea. Informal elements of this process categorized in detail: **Informal Process** ・Understanding of past work XKP drafters must have a good understanding of past work and proposals so that they can seriously consider deploying them in the Xenea mainnet before preparing a XKP. This will allow them to bring in new proposals that have not been rejected in the past. To find out about past XKPs, please check the main XKP repository, Xenea Forum. ・Working group The first XKP drafts are rarely implemented on the Xenea mainnet without edits and changes. Typically, XKP drafters work with a subset of protocol developers to hammer out, implement, test, iterate, and finalize proposals. In the case of Ethereum, these working groups required months (sometimes even years) of work. Similarly, XKP drafters making such modifications need to engage relevant application/tool developers early on to gather end-users’ feedback and mitigate deployment risks. ・Community consensus While some XKPs are simple technical improvements with minimal differences, some are more complex with inherent trade-offs, affecting different stakeholders in different ways. Therefore, some XKPs may be controversial within the community. At the moment, there is no clear manual on how to handle contentious proposals. Protocol developers do not have the means to force people to upgrade their networks and will usually avoid implementing proposals that would outweigh the interests of the community as a whole. XKP drafters are expected to seek feedback from all relevant stakeholders. If you are the XKP drafter in a contentious XKP, you will need to address objections in order to gain consensus on your proposal. Given the size and diversity of the Ethereum community, there is no single metric (such as coin voting) that can be used to measure community consensus, and XKP drafters must be flexible in dealing with the status of their proposals. In addition to the security of the Xenea network, the protocol developers emphasize the value of application/tool developers and users. This is due to the perspective application/tool developers and users on Xenea make the ecosystem more attractive to other stakeholders. Furthermore, the XKP needs to be implemented for all clients managed by different teams. Therefore, as part of this process, it is important to convince and gain buy-in from protocol developers and community members of the valuable protocol changes which will help end users while solving security issues. Currently, Xenea will adopt a policy of not intervening in the event of a bug in a contract or loss of funds in order to maintain the trusted neutrality of the system. \*The XKP process began # XENEA Wallet XENEA Wallet is an original compatible cryptocurrency wallet designed for the two-layered Xenea ecosystem. It features a cryptocurrency wallet layer and a Voting module, which implements an automated response program based on a voting system. One of its key characteristics is the user-friendly experience it offers by liberating users from the stress of managing private keys, utilizing Xenea's proprietary patented technology. Additionally, XENEA Wallet enables users to participate in the mining process by PoD. The following features will be implemented in a phased manner: **Phase 1 (At the time of mainnet launch):** Initiate mining on a limited number of node servers. **Phase 2:** Launch Voting mining pools on node servers. Enable users to connect their wallets, such as MetaMask, to the Voting mining pools and participate in mining. **Phase 3:** Release XENEA Wallet to the public. Upon wallet import, users will automatically connect to the mining pool and be able to participate in the mining pool directly from XENEA Wallet. **Phase 4:** Implement a decentralized wallet that eliminates the need for private key storage, leveraging Xenea's unique international patented technology.(Patent Number: 2019-052099) This comprehensive and phased approach ensures the smooth integration and functionality of XENEA Wallet within the Xenea ecosystem, providing users with an efficient, secure, and user-friendly experience as they participate in the network's mining and voting processes.The development timeline is described in the Development Roadmap below. XENEA Wallet functions as a Rep node and, as shown in the escrow account determination formula above, automatically replies True/Not-True to confirm the transaction as a smart contract, and a randomly selected node returns the validity to the Escrow node. If the selected Rep node is online, it can participate in the Xenea mining and receive mining rewards in return. The energy used by the node in this process is as low as a push notification. This mechanism maintains a voting blockchain involving all XENEA Wallet users. The figure below shows the XENEA Wallet layers. ![](/files/da1NrwkGYVhaxwMqaSV7) **Patented technology for private key generation and storage** Typical crypto wallets today require users to hold their own private keys. However, this method is considered to have a high hacking risk because the private key is controlled by the individual. Hard wallets developed to alleviate this risk without connecting to an autonomous decentralized network, which is conventionally used for secure operation of crypto data, have limitations in terms of convenience. Xenea has developed a technology to solve this problem and achieve secure and convenient operations in the financial technology market, and obtained a patent (patent number: 2019-052099). **Patent Information** Electronic Allotment Type Storage Method and its Operation System **Specifications** The autonomous decentralized network is connected to multiple users' node computers and a group of monitoring node computers. The users' node computers are equipped with an autonomous decentralized electronic certificate wallet execution program that serves as a means of storing cryptographic assets. The autonomous decentralized electronic certificate wallet execution program generates and splits a private key consisting of ciphers to protect the stored crypto currency data, and each part of the split private key is distributed and stored in several anonymous node computers randomly selected from a group of monitored node computers and regenerated at the time of use.
# Network Resources This reference guide provides the detail of Xenea Testnet and public RPC endpoints. ## Xenea Ubusuna Testnet ### Network details | Parameter | Value | | --------------- | ------------------------------------ | | Network Name | Xenea Ubusuna Testnet | | Chain ID | 1096 | | Currency Symbol | TXENE | | Explorer | | | Public RPC URL | | # Deploy a Contract This guide walks through deploying a Solidity contract to **Xenea** with [Foundry](https://book.getfoundry.sh/), then verifying the source code on XENEA Scan. Xenea currently provides the **Ubusuna Testnet**. Additional networks will follow the same workflow. Look up the chain ID, RPC URL, and explorer URL in [Network Resources](/development/network-resources). Get testnet tokens from [Claim Ubusuna Testnet XENE](/development/claim-ubusuna-testnet-xene). This guide uses the `xenea_ubusuna` alias in its examples. *** ### Prerequisites * [Foundry](https://book.getfoundry.sh/getting-started/installation) installed * Native token balance in your deployer wallet on the target network (testnets provide a faucet — see [Claim Ubusuna Testnet XENE](/development/claim-ubusuna-testnet-xene)) *** ### Scaffold a project Initialize a new Foundry project: ```bash forge init xenea-dapp-sandbox cd xenea-dapp-sandbox ``` This generates a sample `src/Counter.sol`, `script/Counter.s.sol`, and `test/Counter.t.sol`. This guide uses the generated `Counter` contract as the deployment target. *** ### Configure Foundry Edit `foundry.toml` to add a Xenea profile and one or more RPC endpoints: ```toml [profile.default] src = "src" out = "out" libs = ["lib"] evm_version = "paris" [rpc_endpoints] xenea_ubusuna = "https://rpc-ubusuna.xeneascan.com/" # xenea_mainnet = "" ``` Throughout the rest of this guide, `xenea_ubusuna` is used as the example alias. Replace it with whichever entry you want to deploy to. > ⚠️ **Set `evm_version = "paris"`.** Xenea runs the Paris EVM. Without this setting, Solidity 0.8.20+ defaults to Shanghai and emits the `PUSH0` opcode, and your deployment will revert. *** ### Prepare a deployer wallet Import your private key into a Foundry keystore (encrypted on disk): ```bash cast wallet import xenea-deployer --interactive ``` You'll be prompted for the private key (a `0x`-prefixed 64-char hex string) and a password to encrypt the keystore. The keystore is saved to `~/.foundry/keystores/xenea-deployer`. Get the address: ```bash cast wallet address --account xenea-deployer ``` Check the balance on your target network: ```bash cast balance --rpc-url xenea_ubusuna --ether ``` *** ### Build and test ```bash forge build forge test -vvv ``` *** ### Deploy Deploy `Counter` with `forge create`: ```bash forge create src/Counter.sol:Counter \ --rpc-url xenea_ubusuna \ --account xenea-deployer \ --legacy \ --broadcast ``` > ⚠️ **Always pass `--legacy` on Xenea.** Xenea uses legacy (Type 0) transactions. Forge commands that broadcast transactions — `forge create`, `forge script`, `cast send` — need this flag. You'll be prompted for the keystore password. On success you'll see: ``` Deployer: 0x7D34...cD2 Deployed to: 0x073e...8185 Transaction hash: 0xb877...a481 ``` Save the `Deployed to` address — you'll need it for the next steps. #### Using `forge script` instead If your deployment involves multiple contracts or post-deploy calls, a `Script` contract is the standard Foundry approach. On Xenea, pass `--legacy` and `--slow` so broadcasts wait for each receipt before moving on: ```bash forge script script/Counter.s.sol:CounterScript \ --rpc-url xenea_ubusuna \ --account xenea-deployer \ --sender \ --legacy \ --broadcast \ --slow ``` *** ### Confirm deployment Check that bytecode exists at the deployed address: ```bash cast code --rpc-url xenea_ubusuna ``` A long `0x…` blob confirms the contract is on-chain. A bare `0x` usually means the contract is not present at that address on the selected network. *** ### Interact with the contract Use `cast call` for read-only functions and `cast send` for state-changing ones: ```bash export ADDR= # Read (free, no gas) cast call $ADDR "number()(uint256)" --rpc-url xenea_ubusuna # Write (consumes gas, needs --legacy) cast send $ADDR "increment()" \ --rpc-url xenea_ubusuna \ --account xenea-deployer \ --legacy # Read again — value should have incremented cast call $ADDR "number()(uint256)" --rpc-url xenea_ubusuna ``` > 💡 **If `cast send` hangs while waiting for a receipt**, add `--async` to return immediately with the tx hash, then confirm later with `cast receipt --rpc-url xenea_ubusuna`. *** ### Verify the contract XENEA Scan accepts verification through the web UI using Standard JSON Input generated by Foundry. #### 1. Generate Standard JSON Input ```bash forge verify-contract \ \ src/Counter.sol:Counter \ --show-standard-json-input > counter-standard-input.json ``` `--show-standard-json-input` writes the solc Standard JSON Input to stdout without making a network request. #### 2. Look up the compiler version Open `out/Counter.sol/Counter.json` in your editor and search for `compiler.version`. Copy the value exactly. For example: ```json "compiler":{"version":"0.8.31+commit.f0907708"} ``` You will enter this on the explorer as `v0.8.31+commit.f0907708`. #### 3. Submit on XENEA Scan Open the dedicated **Verify Contract** page for Ubusuna Testnet: Choose **Via Standard Input JSON** and fill in: | Field | Value | | ------------------- | -------------------------------------------------------- | | Contract Address | `` | | Contract Name | `Counter` | | Compiler | the version from step 2 (e.g. `v0.8.31+commit.f0907708`) | | Standard Input JSON | upload `counter-standard-input.json` | Click **Verify & Publish**. After success, the contract page on XENEA Scan will show the source code, ABI, and Read/Write Contract UI. Use `src/Counter.sol:Counter` only in the Foundry command. On the explorer form, enter `Counter`. *** ### Troubleshooting #### `cast code` returns `0x` The contract is not present at that address on the selected network. Check these first: * You passed `--legacy` on broadcast commands * Your deployer has enough native tokens * Your RPC alias points to the intended network * You are checking the correct deployed address #### Deployment reverts with opcode errors Set `evm_version = "paris"` in `foundry.toml`. Solidity 0.8.20+ otherwise emits `PUSH0`, which Xenea does not support. #### Verification fails on the explorer Check that these values match your build exactly: * Contract name, such as `Counter` * Compiler version from `out/Counter.sol/Counter.json` * Standard JSON Input generated from the same build If the compiler version does not match the build you want to verify, rebuild the project with the intended compiler version and generate the Standard JSON Input again. *** ### Appendix: Command cheatsheet Replace `xenea_ubusuna` with whichever `[rpc_endpoints]` alias you registered for your target network. | Command | Purpose | | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | | `forge build` | Compile contracts | | `forge test` | Run local tests | | `forge create --rpc-url xenea_ubusuna --account --legacy --broadcast` | Deploy a single contract | | `forge script :