XGR MiCAR- Whitepaper
XGR.Network GmbH
LEI: 391200JHCS27EPI8VE61
General Information
| Nr. | Content |
|---|---|
| 00 Table of content |
|
| 01 Date of notification |
|
| 02 Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114 |
|
| 03 Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114 |
|
| 04 Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114 |
|
| 05 Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114 |
|
| 06 Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114 |
|
Summary
| Nr. | Content |
|---|---|
| 07 Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114 |
This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto –asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law. |
| 08 Characteristics of the crypto-asset |
XGR is the native utility token of the XGRChain. The network is compatible with common Ethereum applications. Transactions are confirmed quickly; energy-intensive "mining" does not take place. XDaLa – Automating processes. XDaLa is a layer between RPC and the blockchain. It evaluates predefined rules and automatically executes the associated steps. Inputs may include user inputs, data from external interfaces (APIs), and values from smart contracts – including those on other EVM-compatible blockchains. Results are recorded on-chain. Rules and data can be end-to-end encrypted; keys remain with the user. What XGR is used for. XGR pays transaction and execution fees (including XDaLa validations) and serves as a unit of account within the ecosystem. XGR does not confer ownership, profit-sharing, or creditor rights in the issuer and does not constitute deposit, insurance, or compensation claims. Fee and donation model. Fees are charged per unit of gas consumed. In addition, a fixed amount of 1,000 Gwei (equivalent to 0.000001 XGR) is permanently burned per transaction. The remaining fees are distributed 85% to validators and 15% to a donation smart contract ("donation by default"). MiCAR classification. XGR is classified as an "other crypto-asset" (Art. 3(1) No. 5 MiCAR); it is neither an asset-referenced token (ART) nor an e-money token (EMT). Supply and circulation. Approximately 3.14 billion XGR are available for public offering; release is gradual (currently up to 17 million per month). Additional holdings (e.g., treasury) are earmarked for specific purposes. About 1.38 billion XGR are allocated to a pre-sale (not a public offering); the remaining balance serves as a strategic reserve (not a public offering). Total supply and allocation (informational; partly not publicly offered): * Total supply: approx. 6.6 billion XGR * Public offering: approx. 3.14 billion XGR (gradual release) * Founders/Team: approx. 1.38 billion XGR (not a public offering) * Treasury/Reserve (remaining): not a public offering, earmarked |
| 09 Further information about utility tokens |
XGR provides access to network-based functionalities of the XGRChain, in particular to the use of the XDaLa engine (validation and process execution). Access is usage-based: XGR covers transaction and execution fees according to the applicable fee model (EVM gas plus XDaLa fees). There is no entitlement to any specific amount of computational resources, transactions, validations, or throughput per XGR; effective usage depends on network load, rule complexity, and parameter settings. Operations are conducted on a best-effort basis; target metrics (e.g., short block times, rapid finality) are non-binding and may vary due to maintenance, third-party APIs, security measures, or force majeure. Service levels (SLAs) are not guaranteed. Changes to the fee model, limits, or quotas may occur in accordance with protocol/governance rules. Restrictions on Transferability Legal/sanctions requirements (e.g., embargoes, AML/CFT obligations, distribution restrictions in certain jurisdictions)., Contractual/technical restrictions (e.g., vesting/lock-ups, escrow arrangements, temporary hold flags in process smart contracts)., Abuse-prevention/security measures at protocol or contract level (e.g., temporary limitations to mitigate spam or attacks)., XGR does not confer ownership, profit-sharing, or creditor rights and is not redeemable or repayable by the issuer. |
| 10 Key information about the offer to the public or admission to trading |
Issue Price (Start): EUR 0.000001 per XGR. Method of Price Determination After Start: The issue price for each monthly tranche is determined using a fixed, deterministic formula (see Section E.11; applies until the first listing on a trading venue). Total Number of Crypto-Assets Offered: up to 3,141,592,653.58 XGR (current release plan up to 17 million XGR per month). Target Group: Retail and professional investors. Payment Method: SEPA bank transfer (OTC) to XGR.Network GmbH; the purchaser must specify the destination wallet address (EVM-compatible). Safekeeping Arrangements for Funds (Withdrawal Period): Until the expiration of the withdrawal right under Art. 13 MiCAR, incoming funds are held at a CRR credit institution (institution: Sparkasse Chemnitz, BIC CHEKDE81XXX, IBAN DE10 8705 0000 0710 1118 27). Transfer of Tokens: On-chain to the specified wallet. Technical Requirements: EVM-compatible wallet (e.g., MetaMask) with XGRChain network configuration; XDaLa-related payloads are decrypted client-side with separate data keys (no wallet-level decryption). Risk Notice (Brief Overview): Price/liquidity risks; technical risks (network operation/validators, external APIs); user risks (wallet/keys); project-related risks (future development of XDaLa). Detailed information is provided in Section "I – Risks." |
Part A - Information about offeror or person seeking admission to trading
| Nr. | Feld | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| A.1 Name |
|
||||||||||||
| A.2 Legal form |
|
||||||||||||
| A.3 Registered address | N/A | ||||||||||||
| A.4 Head office | N/A | ||||||||||||
| A.5 Registration date |
|
||||||||||||
| A.6 Legal entity identifier |
|
||||||||||||
| A.7 Another identifier required pursuant to applicable national law |
|
||||||||||||
| A.8 Contact telephone number |
|
||||||||||||
| A.9 E-mail address |
|
||||||||||||
| A.10 Response time (days) |
|
||||||||||||
| A.11 Parent company |
|
||||||||||||
| A.12 Members of the management body |
|
||||||||||||
| A.13 Business activity |
Infrastructure Software Development and operation of XGRChain (EVM-compatible Layer-1 blockchain using IBFT) and the XDaLa engine as a process engine (orchestration + validation + execution) between RPC and the EVM. Provision of accompanying components (explorer, SDKs, APIs, CLI, developer tools) for building and running distributed applications. Tooling (Authoring & Management) for Rule-Based Smart Contracts We do not host rules ourselves; rules are deployed on-chain as smart contracts (XRC-137 standard). We provide tools (e.g., rule builder, deployment helpers, console, monitoring) that enable third parties to create, configure, and manage such contracts. Encrypted content remains under the users' control. Platform / Infrastructure Services (PaaS/IaaS, optional) Provision and operation of non-custodial infrastructure components (e.g., test/dev networks, nodes, CI/CD pipelines) for partners and projects, including integration, architecture support, security, and training. Services Technical consulting, interface and process integration (structured data flows), custom software development, and support with documentation, testing, and audits. Program Operations Execution of the public offering of the XGR utility token (public sale) and operation of related on-chain mechanisms (including the donation smart contract "donation by default" and token burns according to the fee model). Management of Own Assets Management of the company's own assets (including acquisition, holding, and disposal of real estate, equity interests, and securities) within the framework of self-administration. Delimitation No regulated banking, financial, or payment services are offered; activities are limited to the development and provision of software/IT infrastructure. There is no custody of client funds, account management, payment processing, or brokerage. |
||||||||||||
| A.14 Parent company business activity |
|
||||||||||||
| A.15 Newly established |
|
||||||||||||
| A.16 Financial condition for the past three years |
|
||||||||||||
| A.17 Financial condition since registration |
Period: since registration on 2025-11-06. Business development and operations: Development of the XGRChain (EVM, IBFT) and the XDaLa engine (validation/process execution). Focus on software development, infrastructure, compliance documentation (MiCAR whitepaper), and preparation of the public sale program. Earnings situation: The provider is in an early-stage (pre-revenue) phase. No revenue from operational activities was generated during the reporting period. Future income may arise from token sales under the public offering and from service activities; the amount is currently not reliably foreseeable. Expense situation: Key expenses relate to product/software development, infrastructure/hosting, legal and consulting services, and general administration (finance/operations). Variations occur due to milestone events (e.g., releases, audits, launch preparation). Financing and liquidity: Financed through shareholders' equity. Liquidity is monitored on an ongoing basis; priority is given to development, security, and compliance expenditures. No commitments for future funding exist; continued operations depend, among other factors, on the successful progress of the program and prevailing market conditions. Asset situation: Mainly characterized by intangible assets (software/development outputs). Tangible assets are limited. Liabilities exist within the ordinary course of business (e.g., service contracts); no material extraordinary liabilities are known. Material changes & causes: No material changes in the financial position during the reporting period beyond typical early-stage volatility. Variations primarily result from development progress, audit/compliance efforts, and launch preparation. Adequacy & risks: The analysis is appropriate given the early stage and complexity of the business. Key risks include market risk, technology/security risks, regulatory changes, and dependence on successful product rollout and program demand. |
Part B - Information about issuer, if different from offeror or person seeking admission to trading
| Nr. | Content |
|---|---|
| B.1 Issuer different from offerror or person seeking admission to trading |
|
| B.2 Name | N/A |
| B.3 Legal form | N/A |
| B.4 Registered address | N/A |
| B.5 Head office | N/A |
| B.6 Registration date | N/A |
| B.7 Legal entity identifier | N/A |
| B.8 Another identifier required pursuant to applicable national law | N/A |
| B.9 Parent company | N/A |
| B.10 Members of the management body | N/A |
| B.11 Business activity | N/A |
| B.12 Parent company business activity | N/A |
Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
| Nr. | Content |
|---|---|
| C.1 Name | N/A |
| C.2 Legal form | N/A |
| C.3 Registered address | N/A |
| C.4 Head office | N/A |
| C.5 Registration date | N/A |
| C.6 Legal entity identifier | N/A |
| C.7 Another identifier required pursuant to applicable national law | N/A |
| C.8 Parent company | N/A |
| C.9 Reason for crypto-asset white paper preparation | N/A |
| C.10 Members of the management body | N/A |
| C.11 Operator business activity | N/A |
| C.12 Parent company business activity | N/A |
| C.13 Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | N/A |
| C.14 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | N/A |
Part D - Information about other token project
| Nr. | Content | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| D.1 Crypto-asset project name |
|
||||||||||||||||
| D.2 Crypto-asset name |
|
||||||||||||||||
| D.3 Abbreviation |
|
||||||||||||||||
| D.4 Crypto-asset project description |
Fee model (summary): Fees are fixed per unit of gas; 1,000 Gwei are burned per transaction. The remaining fees are distributed 85% to validators and 15% to a donation smart contract ("donation by default"). |
||||||||||||||||
| D.5 Details of all natural or legal persons involved in implementation of crypto-asset project |
|
||||||||||||||||
| D.6 Utility token classification |
|
||||||||||||||||
| D.7 Key features of goods or services for utility token projects |
|
||||||||||||||||
| D.8 Plans for the token | |||||||||||||||||
| Description of past milestones |
|
||||||||||||||||
| Description of future milestones |
|
||||||||||||||||
| D.9 Resource allocation |
Initial Token Allocation At launch, the pre-mined 6.626076 billion XGR were distributed across three primary categories:
Founders / Team: Allocation of 1.38 billion XGR with a structured annual unlock of approx. 25%. These tokens are held in private wallets of the founders and team members and are not owned by XGR.Network GmbH. Public Sale: A total of 3.14 billion XGR is designated for the public offering. Release occurs in monthly tranches (up to 17 million XGR per month) based on a deterministic issuance formula (see E.11). These tokens are reserved exclusively for sales under this whitepaper and are not held for the issuer’s own account. Treasury / Reserve: 2.10 billion XGR reserved for ecosystem development, partnerships, technical operations and strategic initiatives. These tokens remain under the control of XGR.Network GmbH, are purpose-bound and are not part of the public offering. |
||||||||||||||||
| D.10 Planned use of collected funds or other tokens |
Infrastructure/operations (operations, monitoring, scaling) Compliance/documentation (e.g., MiCAR, technical/organizational measures) Partner and ecosystem development, developer support Reserves for operations and strategic initiatives |
||||||||||||||||
Part E - Information about offer to public of other tokens or their admission to trading
| Nr. | Content | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| E.1 Public offering or admission to trading | ||||||||||||||||||||||
| E.2 Reasons for public offer or admission to trading |
|
|||||||||||||||||||||
| E.3 Fundraising target | 0 | |||||||||||||||||||||
| E.4 Minimum subscription goals | 0 | |||||||||||||||||||||
| E.5 Maximum subscription goals | 3141592654 | |||||||||||||||||||||
| E.6 Oversubscription acceptance |
|
|||||||||||||||||||||
| E.7 Oversubscription allocation |
|
|||||||||||||||||||||
| E.8 Issue price |
|
|||||||||||||||||||||
| E.9 Official currency determining issue price | EUR | |||||||||||||||||||||
| E.9 Any other tokens determining issue price | N/A | |||||||||||||||||||||
| E.10 Subscription fee | ||||||||||||||||||||||
| Fee expressed in currency |
|
|||||||||||||||||||||
| Fee expressed in units |
|
|||||||||||||||||||||
| E.11 Offer price determination method |
Scope (pre-listing): This rule applies until the first public exchange listing (CEX/DEX). From first listing onward, the offer price for any future offering phases will be based on the prevailing market price and disclosed before the start of each offering phase. Offering phase definition: Each offering phase comprises 17,000,000 XGR and lasts 30 calendar days. Within an offering phase, the issue price is fixed and does not change in response to sales progress within that same offering phase. Price variables:
Fixed parameters:
Note: Constants 0.02 (base uplift), 9 (maximum uplift), and 0.30 (downward factor) are inserted directly into the formulas to reduce variables. Auxiliary variables:
Deterministic rule per offering phase n → n+1: Formula – sold-out case (s = 1): Pₙ₊₁ = Pₙ · ( 1 + 0.02 + (9 − 0.02) · d · (P₀ / Pₙ)0.5 ) Explanation – sold-out case: If the offering phase is fully sold (considering the de minimis residual), the next phase price increases. A faster sell-out (higher d) leads to a larger percentage increase. At higher price levels, the tapering term (P₀/Pₙ)0.5 becomes smaller, which dampens the increase. Formula – undersubscribed case (s < 1) with floor: Pₙ₊₁ = max( P₀ ; Pₙ · ( 1 − 0.30 · u · (P₀ / Pₙ)0.5 ) ) Explanation – undersubscribed case: If the offering phase is not fully sold, the next phase price decreases in proportion to the undersubscription ratio u. The tapering term (P₀/Pₙ)0.5 limits downward moves at higher price levels. The max function enforces a hard floor at P₀. Data basis (on-chain): All inputs are derived from the public-sale smart contract. M_sold is the sum of primary sales (tokens issued) within the offering phase. DAYS_SOLD_OUT is calculated from block timestamps as floor((t* − t₀) / 86,400), where t₀ is the UTC timestamp at offering phase start and t* is the UTC timestamp when M_sold first reaches ≥ 17,000,000 − δ. Rounding and publication: Price figures are rounded to six decimal places (commercial rounding). After each offering phase, M_sold, DAYS_SOLD_OUT, and the resulting Pₙ₊₁ are published. Determinism: All inputs are defined ex ante. There is no dependence on intra-period sales dynamics within the same 30-day window; the price within an offering phase remains constant. The price of an offering phase depends solely on on-chain data of the preceding offering phase. Plain-language summary: If an offering phase sells out, the next phase becomes more expensive — and the faster it sells out, the stronger the increase. If a phase does not sell out, the next phase becomes cheaper, but never below P₀. |
|||||||||||||||||||||
| E.12 Total number of offered or traded other tokens |
|
|||||||||||||||||||||
| E.13 Targeted holders | ||||||||||||||||||||||
| E.14 Holder restrictions |
Implementation (self-declaration): Before each subscription, buyers must confirm via checkbox that (i) no prohibitions/restrictions apply in their country of residence, and (ii) they are not listed on any sanctions list. This declaration becomes part of the offering terms/General Terms & Conditions. |
|||||||||||||||||||||
| E.15 Reimbursement notice |
|
|||||||||||||||||||||
| E.16 Refund mechanism |
The received amount is refunded to the sender's original bank account. After allocation: The buyer sends the allocated XGR back to the published Public Sale contract address. After confirmed on-chain receipt, the originally paid amount is refunded to the same originating bank account. The returned XGR are transferred back into the general pool. Inevitable network/transaction fees are non-refundable. |
|||||||||||||||||||||
| E.17 Refund timeline |
|
|||||||||||||||||||||
| E.18 Offer phases |
Phase length: exactly 30 days (30 × 24 h) per phase; phases roll over without gaps. Subscription window: the entire 30‑day phase. Phase cap / acceptance policy: tokens may be reserved for a limited period; orders are accepted only up to the remaining amount minus outstanding reservations. Orders above that limit are not accepted. Phase price: as per E.11 (Pₙ with n counting completed 30‑day phases since T₀). Phase transparency: the start and end of each phase are clearly shown on the public offer page. |
|||||||||||||||||||||
| E.19 Early purchase discount |
|
|||||||||||||||||||||
| E.20 Time-limited offer |
|
|||||||||||||||||||||
| E.21 Subscription period beginning |
|
|||||||||||||||||||||
| E.22 Subscription period end |
|
|||||||||||||||||||||
| E.23 Safeguarding arrangements for offered funds or other tokens |
The XGR designated for sale are held in the Public Sale smart contract until allocation; returned tokens are transferred back into the general pool. No custody of customer keys takes place. |
|||||||||||||||||||||
| E.24 Payment methods for other token purchase |
|
|||||||||||||||||||||
| E.25 Value transfer methods for reimbursement |
|
|||||||||||||||||||||
| E.26 Right of withdrawal |
|
|||||||||||||||||||||
| E.27 Transfer of purchased other tokens |
|
|||||||||||||||||||||
| E.28 Transfer time schedule |
|
|||||||||||||||||||||
| E.29 Purchaser's technical requirements |
|
|||||||||||||||||||||
| E.30 Other token service provider (CASP) name |
|
|||||||||||||||||||||
| E.31 CASP identifier |
|
|||||||||||||||||||||
| E.32 Placement form | ||||||||||||||||||||||
| Trading platforms characteristics | ||||||||||||||||||||||
| E.33 Trading platforms name |
|
|||||||||||||||||||||
| E.34 Trading platforms market identifier code (MIC) |
|
|||||||||||||||||||||
| E.35 Trading platforms access |
|
|||||||||||||||||||||
| E.36 Involved costs |
|
|||||||||||||||||||||
| E.37 Offer expenses |
|
|||||||||||||||||||||
| E.38 Conflicts of interest |
Mitigation measures: Pre-published, uniform tranche terms (fixed price per tranche, no oversubscription, no individual discounts), separated pools (public sale vs. strategic reserve), and on-chain documentation of material reserve transfers. |
|||||||||||||||||||||
| E.39 Applicable law |
|
|||||||||||||||||||||
| E.40 Competent court |
|
Part F - Information about other tokens
| Nr. | Content |
|---|---|
| F.1 Crypto-asset type |
|
| F.2 Other token functionality |
XGR serves as the sole fee unit for transactions on XGRChain as well as for validation and process steps in XDaLa (rule execution under XRC-137, API/state checks, persistence). Fees are fixed per gas unit and provide a meaningful anti-spam effect. Fixed fees per gas = predictability: The price per gas unit is constant (not load-dependent). As a result, execution costs are deterministically known in advance (gas required × fixed price) and can be reliably budgeted by users and enterprises (predictable for quotations, cost calculators). Access & billing within the ecosystem: Use of network/middleware functions (XDaLa sessions, developer tooling, SDKs/APIs) is usage-based and denominated in XGR. No ownership/income feature: XGR does not grant ownership rights, profit participation, or creditor claims against the issuer, nor does it create any redemption or repayment obligation; it is not an ART/EMT within the meaning of MiCAR. |
| F.3 Planned application of functionalities |
|
| A description of the characteristics of the other token, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article | |
| F.4 Type of crypto-asset white paper | |
| F.5 Type of submission | |
| F.6 Other token characteristics |
Name / ticker: XGR. Type: Native coin of the XGRChain, used as a fungible digital asset within the network. Intended use: XGR is used to pay network fees (gas) and to access services in the XGR / XDaLa environment, for example for running validation and execution processes on business rules and workflows. Divisibility: XGR can be divided into very small units (up to 18 decimal places), so that also small payments and fees can be processed. Excluded rights: Holding XGR does not give any rights to dividends, interest, redemption into legal tender, ownership in the issuer, or voting / governance rights. Value stability: XGR is not designed to maintain a stable value; its price can move up or down depending on supply and demand on trading venues. Network and compatibility: XGR runs on XGRChain, an EVM-compatible Layer-1 network. Standard EVM wallets and tools (for example MetaMask and common explorers) can be used once the network configuration (RPC endpoint, chain ID, explorer URL) has been published. Transferability: XGR can be transferred between compatible wallets on XGRChain. Legal or contractual restrictions may apply based on the applicable law and the issuer’s terms and conditions. Plain-language glossary:
|
| F.7 Commercial name or trading name |
|
| F.8 Website of the issuer |
|
| F.9 Starting date of offer to the public or admission to trading |
|
| F.10 Publication date |
|
| F.11 Any other services provided by the issuer |
Development and operation of XGRChain (Layer 1, EVM) and XDaLa (validation/process engine), including releases, monitoring, and security/compatibility updates. Developer Tooling: SDKs/APIs, CLI, rule builder/deployment helper, explorer/indexing; manuals/documentation, sample applications, and testing environments. Integration & Engineering: Architecture and integration support (interfaces, structured data flows), training/workshops, assistance with testing/audits. Support: Technical support for partners/developers (e.g., issue handling, roadmap communication). No regulated financial services: No banking, payment, or securities-regulated services; no custody of customer funds or keys. |
| F.12 Language or languages of white paper |
|
| F.13 Digital token identifier code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available |
|
| F.14 Functionally fungible group digital token identifier, where available | N/A |
| F.15 Voluntary data flag |
|
| F.16 Personal data flag |
|
| F.17 LEI eligibility |
|
| F.18 Home member state | |
| F.19 Host member states #1 | |
| F.19 Host member states #2 | |
| F.19 Host member states #3 | |
| F.19 Host member states #4 | |
| F.19 Host member states #5 | |
| F.19 Host member states #6 | |
| F.19 Host member states #7 | |
| F.19 Host member states #8 | |
| F.19 Host member states #9 | |
| F.19 Host member states #10 | |
| F.19 Host member states #11 | |
| F.19 Host member states #12 | |
| F.19 Host member states #13 | |
| F.19 Host member states #14 | |
| F.19 Host member states #15 | |
| F.19 Host member states #16 | |
| F.19 Host member states #17 | |
| F.19 Host member states #18 | |
| F.19 Host member states #19 | |
| F.19 Host member states #20 | |
| F.19 Host member states #21 | |
| F.19 Host member states #22 | |
| F.19 Host member states #23 | |
| F.19 Host member states #24 | |
| F.19 Host member states #25 | |
| F.19 Host member states #26 | |
| F.19 Host member states #27 | |
| F.19 Host member states #28 | |
| F.19 Host member states #29 | |
| F.19 Host member states #30 | |
Part G - Information on rights and obligations attached to other tokens
| Nr. | Content |
|---|---|
| G.1 Purchaser rights and obligations |
Delivery: Right to the transfer of the purchased XGR to the specified EVM receiving address after confirmed receipt of payment (see E.27/E.28). Withdrawal/Refund: Right of withdrawal under Art. 13 MiCAR within the statutory period and refund in accordance with E.16 (after allocation, subject to returning the XGR to the published contract address). Information: Access to the published crypto-asset whitepaper and to subsequent updates/amendment notices. Buyer's Obligations Payment: Payment of the purchase price via SEPA transfer to the published IBAN, including the order ID. Address/Keys: Provision of a valid EVM receiving address and secure management of the associated keys/recovery phrase. Withdrawal after allocation: Return of the received XGR to the published Public Sale contract address as a prerequisite for refund (see E.16). Legal compliance: Confirmation via checkbox that no local prohibitions/restrictions apply (see E.14); compliance with applicable laws. No claim: XGR does not grant ownership, profit-participation, or creditor rights and does not create any redemption or repayment claim against the issuer. |
| G.2 Exercise of rights and obligations |
Payment via SEPA transfer to the published IBAN, including the order ID. After bank reconciliation, the on-chain transfer of XGR is executed from the Public Sale smart contract to the specified wallet. Timeline see E.27/E.28. Withdrawal/Refund (Art. 13 MiCAR): Exercise within the statutory period via the provided web form or by email, including the order ID and wallet address. Before allocation: refund of the paid amount to the original payment account (SEPA). After allocation: the buyer returns the received XGR to the published Public Sale contract address; after confirmed on-chain receipt, the originally paid amount is refunded to the same payment account. Inevitable network/transaction fees are non-refundable. Address/Data Obligations: The buyer provides a valid EVM receiving address and manages the associated keys securely. Incorrect declarations under E.14 may lead to rejection. Communication/Deadline Compliance: Text form is sufficient; timely dispatch within the withdrawal period is enough to meet the deadline. Confirmations are issued electronically. |
| G.3 Conditions for modifications of rights and obligations |
Material changes will be published before taking effect and—where required—notified to the competent authority; the whitepaper will be updated accordingly (NEWT/MODI/CORR/ERROR pursuant to F.5). |
| G.4 Future public offers |
|
| G.5 Issuer retained other token |
|
| G.6 Utility token classification |
|
| G.7 Key features of goods or services utility tokens |
Quality/quantity: usage-based, with no commitment to fixed throughput; availability depends on network/operational conditions. |
| G.8 Utility tokens redemption |
General use: XGR is used to pay the network fees for transactions on XGRChain and to run XDaLa sessions (validation and execution of business rules and workflows). When XGR is spent for these services, it is consumed as a fee and cannot be “redeemed back” into money. Simple transactions (like on Ethereum): For normal blockchain actions – for example sending XGR between wallets or interacting with a smart contract – the fee calculation works in the same way as on Ethereum. The user’s wallet shows an estimated network fee (“gas”) before the transaction is sent, so the user can see in advance how much XGR will be charged for this single transaction. XDaLa sessions (multiple steps): For more complex processes, the user can start an XDaLa session. Such a session may contain several steps (for example checks, API calls, and smart-contract interactions). For each step, the expected fee can be estimated in advance in a similar way to a normal transaction. Session permit and spending limit: Because the exact sequence of steps can depend on the data and decisions during the process, the total cost of the whole session cannot always be calculated exactly in advance. To protect the user, every XDaLa session is started with a “session permit”. In this permit the user defines a maximum total gas amount (spending limit in XGR) that must not be exceeded. If the session would need more than this limit, it is stopped and no further steps are executed. |
| G.9 Non-trading request |
|
| G.10 Other tokens purchase or sale modalities |
|
| G.11 Other tokens transfer restrictions |
|
| G.12 Supply adjustment protocols |
|
| G.13 Supply adjustment mechanisms |
|
| G.14 Token value protection schemes |
|
| G.15 Token value protection schemes description |
|
| G.16 Compensation schemes |
|
| G.17 Compensation schemes description |
|
| G.18 Applicable law |
|
| G.19 Competent court |
|
Part H – Information on underlying technology
| Nr. | Content |
|---|---|
| H.1 Distributed ledger technology (DTL) |
|
| H.2 Protocols and technical standards |
Network protocol and compatibility: XGRChain is an account-based blockchain similar to Ethereum. It uses the Ethereum Virtual Machine (EVM), which means that smart contracts and transactions follow the same basic rules as on Ethereum. Nodes provide a standard interface called JSON-RPC (a simple web API used by Ethereum clients, for example the eth_ methods), so common tools such as wallets, explorers and backend services can connect in a familiar way. Cryptographic standards: XGRChain uses well-known building blocks from the Ethereum ecosystem. Accounts and validator keys are based on elliptic-curve cryptography (ECDSA on the curve secp256k1), which is also used by Bitcoin and Ethereum. Transaction hashes and block identifiers are created with Keccak-256, a standard hash function in the Ethereum family. These standards are widely used, tested and supported by existing libraries and hardware wallets. Address format and tooling: XGRChain uses the common 40-character hexadecimal address format that is also known from Ethereum, usually written with a 0x prefix (for example 0xabc123…). This makes it easy to integrate XGRChain into existing Ethereum-compatible wallets and tools such as MetaMask and common blockchain explorers. Network-specific parameters (chain ID, RPC endpoint, explorer URL) are published by the issuer so that users can safely add the network in their wallet. |
| H.3 Technology used |
Consensus and finality (IBFT): XGRChain uses a consensus protocol called Istanbul Byzantine Fault Tolerance (IBFT). In simple terms, a group of validator nodes proposes and signs each block. Once at least two thirds of the active validators have signed a block, it is final and cannot be replaced by another chain. For users this means that a confirmed transaction is final within a few seconds and does not need many additional blocks to be considered irreversible. Node roles and software: Validator nodes store the full blockchain, validate transactions and produce new blocks by running the project’s Go-based client software. Non-validator nodes provide read and write access for users and applications (for example via JSON-RPC) and are often used by wallets, explorers and backend systems. This separation allows the network to scale access for many users without overloading the validator set. Execution environment and smart contracts: All smart contracts on XGRChain run in the Ethereum Virtual Machine (EVM). Contracts are typically written in the Solidity programming language and can be verified on the public explorer so that users can review the source code. Because the EVM is standardised, many existing Ethereum tools (development frameworks, libraries and auditing tools) can be re-used on XGRChain. Process engine (XDaLa): On top of the base blockchain, the project operates a process engine called XDaLa (XGR Data Layer). XDaLa can connect several steps into a single automated process, for example checks, API calls and smart-contract interactions. The internal rule formats are referred to as XRC-137 and XRC-729. These are smart-contract standards that define how rules and process flows are stored, linked and executed on XGRChain. Application developers use these standards to design and manage XDaLa sessions. End users typically interact through a simple session interface in their wallet or application: they select the desired process, approve a maximum total gas amount and start the session, while the engine executes the defined steps in the background. Data handling and security: Where needed, XDaLa can work with encrypted payloads, so that sensitive data is only readable for authorised parties. Decryption keys remain under the control of the user and are not stored on the blockchain. For transparency and audit purposes, the system emits structured logs and receipts so that processes can be reconstructed and verified later without exposing confidential data on-chain. |
| H.4 Consensus mechanism |
|
| H.5 Incentive mechanisms and applicable fees |
|
| H.6 Use of distributed ledger technology |
|
| H.7 DLT functionality description |
|
| Other token audit details | |
| H.8 Audit |
|
| H.9 Audit outcome |
|
Part I - Information on risks
| Nr. | Content |
|---|---|
| I.1 Offer-related risks |
SEPA transfers may be delayed; incorrect payment references/order IDs or mismatches between name and IBAN can delay allocation or result in a refund. Jurisdiction/compliance risks: Offering the product across the EU requires compliance with country-specific requirements (language/marketing). Confirmations via checkbox mitigate risks but do not replace statutory prohibitions/sanctions; orders may be rejected. Tranching and allocation: Fixed price per tranche with a limited monthly volume. In the case of high demand, non-allocation or later allocation in subsequent tranches is possible; subsequent tranches may have different prices/terms. Refund process: Prior to allocation, refunds are made to the original payment account; after allocation, refunds are only possible against return of the XGR to the published contract address. Bank/network fees may not be refundable. Operational/uptime risks: Temporary unavailability of the website, bank, public sale contract, or RPC may delay orders; phishing/lookalike sites pose a fraud risk. |
| I.2 Issuer-related risks |
Limited operating history and dependence on key individuals; delays in development, audits, documentation, or operations are possible. Treasury and allocation control: Decisions regarding strategic reserves and partner allocations lie with the issuer (transparent pools, but discretionary decisions). Misallocation can negatively impact reputation and adoption. Operational dependencies: Third parties (cloud providers, payment banks, infrastructure providers) may cause disruptions. Regulation: Changes in the legal framework (EU and non-EU) may affect the offering, marketing, reporting, or required technical measures; additional effort and evidentiary obligations may arise. |
| I.3 Other tokens-related risks |
XGR prices may be highly volatile; liquidity can vary depending on the market and trading pair. No redemption or return entitlement: XGR does not confer ownership, profit, or creditor rights; there is no redemption claim against the issuer. Distribution and concentration risks: Movements of larger holdings (pre-sale/reserve) may affect market prices. Address/key risk: Loss or theft of private keys or recovery phrases leads to irreversible loss; incorrect address entries are irreversible. Taxes and transparency: Transactions are pseudonymous and traceable on-chain; tax obligations remain the responsibility of holders. Ecosystem/contract risk: Third-party smart contracts/bridges/dApps may contain bugs or security vulnerabilities; interoperability creates additional attack surfaces. |
| I.4 Project implementation-related risks |
Expanding the functionality of XGRChain/XDaLa (including tooling, orchestration, SDKs) is complex; delays may occur due to quality assurance, dependencies, or limited personnel resources. Partner and adoption risks: Lower-than-expected participation from developers/companies or the absence of strategic integrations may limit the use of XGR. Audit and security process: External audits may identify issues; remediation can consume time and resources. |
| I.5 Technology-related risks |
PoA with IBFT finality relies on a permissioned validator set. Coordination failures, network partitions, or collusion (e.g., censorship/halts) can impair operations; misconfiguration or key compromise of individual validators increases overall risk. Performance and capacity: Because the gas price per unit is constant (no algorithmic congestion pricing), load spikes can lead to backlogs and longer waiting times until block space becomes available. XDaLa-specific (engine/orchestration): Faulty rules (XRC-137), incorrect orchestrations (XRC-729), unsuitable fallbacks, external API outages, or inconsistent off-/on-chain data can block processes or produce incorrect outcomes. Complex sessions may result in high gas consumption. Dependence on external sources: Latency, rate limits, or schema changes of external interfaces (APIs) directly affect validation results and execution times. Cryptography/confidentiality: Loss of client-side decryption material renders encrypted artifacts/logs unreadable; however, metadata (timestamps/sizes) may still reveal recognizable patterns. Software defects: Client, node, or smart-contract bugs (including public sale or donation contracts) may occur despite testing and can necessitate patching or rollback measures. Network attacks: DDoS attacks on public endpoints/validators, mempool flooding, or replay/phishing scenarios can harm availability and users (despite common EVM safeguards such as chain ID binding). |
| I.6 Mitigation measures |
The network operates with a curated validator set based on clear criteria for admission, supervision and, where necessary, deactivation. Validator key management follows established security practices (including optional HSM integration), supported by continuous monitoring, alerting, and defined response procedures for exceptional situations. XDaLa Engine Design: The orchestration and execution logic is designed with fail-closed semantics, deterministic behavior (XRC-729), and validated step definitions (XRC-137). Defined fallback mechanisms, timeouts, complexity limits and quota controls ensure predictable and secure processing. Encryption & Access Control: The system employs end-to-end encryption, with key material derived from users' wallets. Access to confidential data is governed through a granular grant & scope model, while private keys remain fully under the user's control at all times. Development & Quality Assurance: New features undergo a multi-stage review and release process, including testnet deployments, peer reviews, and third-party assessments before being moved to production. System changes follow a traceable, documented procedure for approval and, if needed, rollback. Fees & Cost Structure The platform applies a stable gas-price model to ensure predictable cost planning. Technical rate limits and load-management mechanisms contribute to maintaining orderly operation even under varying usage levels. Financial & Operational Processes Fiat inflows and outflows are handled via an account at a regulated credit institution. A standardised and auditable refund process is in place for both pre-allocation and post-allocation scenarios, supported by a multi-person approval principle. Transparency: Key system parameters, relevant smart contract addresses/ABIs and status information are published and verifiable, including protocol-level logging on-chain. Tranche parameters and operational data are documented in a transparent manner. User Hygiene: The platform provides clear guidance for key management, verification of official domains, and address validation. No custody or brokerage services are offered by the issuer. |
Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts
| Nr. | Content |
|---|---|
| J.1 Adverse impacts on climate and other environment-related adverse impacts | Mainnet consensus layer (PoA with IBFT finality), i.e. validator nodes only. The testnet (e.g. VC-4-16) is not included in the calculation. Topology (as of 2025-11-10): 5 validators (VM class VC8-32, Strato). Method (reasoned estimate): Annual consumption [kWh] = Σ(IT power per validator [W]) × PUE × 8,760 h ÷ 1,000 IT power per VC8-32 (assumption): 90 W (conservative, estimated in the absence of provider-side measurements) PUE (data centre overhead): 1.6 (cautious standard value) Calculation: 5 × 90 W × 1.6 × 8,760 h ÷ 1,000 ≈ 6,300 kWh/year Assessment: The estimated consumption is well below 500,000 kWh/year; the basic indicator is therefore sufficient. An extended disclosure is not currently required. Note on data quality: The assumptions are chosen conservatively. If location- or provider-specific power/PUE values become available, or if there are material topology changes (e.g. number/size of validators), the estimate will be updated accordingly. Context: PoA/IBFT does not require mining; environmental impacts arise primarily from data centre electricity consumption (Scope 2) and the hardware lifecycle (Scope 3). Further breakdowns (e.g. emission factors) are optional and will only be added if needed |
Part S - Mandatory information on principal adverse impacts on the climate and other environment-related adverse impacts of the consensus mechanism
| Nr. | Content |
|---|---|
| General information about adverse impacts | |
| S.1 Name |
|
| S.2 Relevant legal entity identifier |
|
| S.3 Name of the crypto-asset |
|
| S.4 Consensus mechanism |
A deterministic, BFT-based Proof-of-Authority consensus mechanism without competitive mining. |
| S.5 Incentive mechanisms and applicable fees |
BaseFee for network stability Validator execution fee for operational cost recovery Donation fee directed to social-impact beneficiaries No mining, no block rewards — IBFT does not require energy-intensive validator competition. |
| S.6 Beginning of period to which disclosed information relates |
|
| S.7 End of period to which disclosed information relates |
|
| Mandatory key indicator | |
| S.8 Energy consumption (kWh) |
|
| Sources and methodologies | |
| S.9 Energy consumption sources and methodologies |
Methodology: Provider wattage × 8,760 annual operating Location: Germany (renewable-energy infrastructure) No mining, no hardware beyond cloud servers |
| Supplementary information on principal adverse impacts on climate and other environment-related adverse impacts of consensus mechanism | |
| Supplementary key indicators | |
| S.10 Renewable energy consumption |
|
| S.11 Energy intensity (kWh) |
|
| S.12 Scope 1 DLT GHG emissions - controlled (tCO2e) |
|
| S.13 Scope 2 DLT GHG emissions - purchased (tCO2e) |
|
| S.14 GHG intensity (tCO2e) |
|
| Sources and methodologies | |
| S.15 Key energy sources and methodologies |
Evidence: Strato electricity mix certification Methodology: Provider data + annual consumption estimation Geographic region: Germany |
| S.16 Key GHG sources and methodologies |
Scope 2: None. All electricity consumed by Strato data centres is 100% renewable (market-based emissions factor: 0 g CO₂/kWh). Scope 3: Minimal. Indirect lifecycle emissions related to cloud infrastructure (manufacturing, maintenance, end-of-life of servers) are estimated to be below 0.1 tCO₂e per year. |
| Optional information on principal adverse impacts on the climate and on other environment-related adverse impacts of the consensus mechanism | |
| Optional indicators | |
| S. 17 Energy mix | |
| S.18 Energy use reduction | |
| Energy use reduction target (absolute value) (kWh) |
|
| Energy use reduction target (percentage) |
|
| S.19 Carbon intensity (kgCO2e/kWh) |
|
| S.20 Scope 3 DLT GHG emissions - value chain (tCO2e) |
|
| S.21 GHG emissions reduction targets or commitments |
|
| S.22 Generation of waste electrical and electronic equipment (WEEE) (tonnes) |
|
| S.23 Non-recycled WEEE ratio |
|
| S.24 Generation of hazardous waste (tonnes) |
|
| S.25 Generation of waste (all types) (tonnes) |
|
| S.26 Non-recycled waste ratio (all types) |
|
| S.27 Waste intensity (all types) (tonnes |
|
| S.28 Waste reduction targets or commitments (all types) |
|
| S.29 Impact of use of equipment on natural resources |
|
| S.30 Natural resources use reduction targets or commitments |
|
| S.31 Water use (m3) |
|
| S.32 Non recycled water ratio |
|
| Sources and methodologies | |
| S.33 Other energy sources and methodologies |
|
| S.34 Other GHG sources and methodologies |
|
| S.35 Waste sources and methodologies |
|
| S.36 Natural resources sources and methodologies |
|