| [Table 2] Template for white papers for crypto-assets other than asset-referenced tokens or e-money tokens | |||||
| Template for white papers for crypto-assets other than asset-referenced tokens or e-money tokens [abstract] | |||||
| General information | |||||
| 00 Table of content | boolean true | ||||
| 01 Date of notification | date | ||||
| 02 Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114 | boolean true | ||||
| 03 Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114 | boolean true | ||||
| 04 Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114 | boolean true | ||||
| 05 Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114 | boolean true | ||||
| 06 Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114 | boolean true | ||||
| SUMMARY | |||||
| 07 Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114 | boolean true | 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 | textBlock | The Token is a fungible utility-type crypto-asset. Each unit is identical and interchangeable with another unit and carries the same rights and obligations for its holders. On the Chain, the Token is used to pay transaction and network fees, to bond and delegate stake to validators and to participate in on-chain protocol governance. The maximum supply of the Token is capped at 8,888,888,888 CTM. The characteristics of the Token are the following: a. The Token is transferable on-chain, subject to applicable law, protocol rules, wallet compatibility and any trading platform rules and fees. Admission to trading occurs on independent third-party platforms that the Company does not operate or control. b. The Token exists as a native coin on the Chain and, in addition, as an ERC-20 token on Ethereum, a BEP-20 token on BNB Chain and an SPL token on Solana. Each unit on the same network is identical and interchangeable, and the implementations across the supported networks are treated as functionally fungible versions of one economic crypto-asset, which must be assessed together. c. The Token is non-interest bearing. Holders bear the applicable network transaction fees, including gas fees or equivalent fees, when transferring or otherwise using the Token on the relevant supported network. Technical parameters of the underlying networks may change over time. d. The Token has no physical form and no intrinsic financial value or guaranteed pricing, and no person makes any representation or commitment regarding its value. The market value of the Token, if any, is determined by supply and demand on the relevant trading platforms and markets. e. The Token is non-refundable and is not redeemable for any assets of any entity or organisation, and cannot be exchanged for cash, or its equivalent value in any other digital asset, or for any payment obligation of the Company or any affiliate. f. Holding the Token does not grant any rights in or to the Company or any affiliate, or their revenues or assets, including, without limitation, any right to dividends, revenue, shares, ownership interest, equity stake, securities, distribution, redemption, liquidation, proprietary rights, intellectual-property rights, licence rights, accounts, financial statements or other financial data, the right to requisition or participate in shareholder or management meetings, the right to nominate a director, or any other financial, legal or equivalent right in or relating to the Company, its affiliates or their service providers. g. Any governance functionality associated with the Token is exercised through the on-chain governance module of the Chain and is limited to protocol-level and ecosystem-related matters, such as network parameters, fee-market parameters and protocol upgrades. It does not constitute corporate governance over the Company or any affiliated entity and confers no control over the Company, its management, treasury, revenues or assets. h. Validator rewards are paid by the protocol to validator operator accounts only, for active block signing and proposal, and require operation of a validator on the Chain and contribution to network security in accordance with the protocol rules. Delegating the Token to a validator increases that validator's share of rewards but confers no entitlement on the delegator to any part of the protocol rewards, and the protocol pays no reward directly to delegators; any sharing of rewards between a validator and its delegators is a private arrangement between them, outside the protocol, that exposes the delegator to the validator's counterparty risk. Such rewards do not arise merely from holding the Token and do not constitute dividends, interest, profit participation, revenue sharing or a guaranteed return. i. The Token does not represent a loan to, or debt of, the Company or any of its affiliates; it is not intended to represent indebtedness, and there is no expectation of profit or interest. j. The Token is not intended to represent rights under a contract for differences or under any other contract designed to secure a profit or avoid a loss. k. The Token is not electronic money or an e-money token, a payment instrument, a security, a commodity, a bond, a debt instrument, a unit in a collective investment undertaking or managed investment scheme, or any other financial instrument or investment. l. The Token is not an asset-referenced token or a stablecoin. It does not purport to maintain a stable value relative to any asset or currency; it is not pegged to, or backed by, any reserve of assets; it confers no redemption right or claim against the Company or its affiliates; and it uses no stabilisation mechanism, whether algorithmic or otherwise. The generation mechanism and the burn mechanisms described in this white paper operate according to protocol rules and are not intended to maintain a stable value or to provide any redemption right. |
|||
| 09 Further information about utility tokens | textBlock | The main utilities of the Token are the following: Network Fee and Transaction Utility: the Token is required to pay transaction and network fees on the Chain. The Chain applies an EIP-1559-style fee market in which transaction fees, comprising both the base fee and the priority fee, are burned in full. Holders may use the Token to submit valid transactions, subject to protocol rules, wallet compatibility and network conditions. Staking and Network-Security Participation: the Token may be bonded by validators or delegated by holders to validators in order to secure the Chain. Validator rewards are protocol-level rewards paid to validator operator accounts only, for active block signing and proposal in accordance with the protocol rules. Delegating the Token to a validator increases that validator's share of rewards but confers no entitlement on the delegator to any part of the protocol rewards, and the protocol pays no reward directly to delegators; any sharing of rewards between a validator and its delegators is a private arrangement between them, outside the protocol, that exposes the delegator to the validator's counterparty risk. Such rewards do not arise from mere holding of the Token and do not constitute dividends, interest, profit-sharing, revenue-sharing or a guaranteed return. Validators and delegators are exposed to slashing and jailing under the protocol rules. Protocol Governance: the Token is used to submit and vote on proposals through the on-chain governance module of the Chain, which is exposed to smart contracts through a dedicated governance precompile. Governance is limited to protocol-level and ecosystem-related matters and does not constitute corporate governance over the Company. Cross-Chain Transfer: the Token may be used as the transfer denomination in Inter-Blockchain Communication transfers initiated from the Chain, subject to the protocol-level safety controls described in Part H. Generation Mechanism: the Token may be generated by supplying a whitelisted counter-asset to the Protocol, as further described in Sections D.7 and G.13. No Other Goods or Services: based on the information provided by the Company, the Token does not provide access to any goods, services, features or benefits supplied by the Company outside the Protocol. In particular, the Token does not confer ownership, equity, creditor rights, governance rights over the Company, redemption rights, profit participation, revenue-sharing rights, issuer-asset rights or treasury rights. Restrictions on Transferability: the Token is generally transferable on the Chain and on the other supported networks, subject to applicable law, protocol rules, wallet compatibility and any restrictions imposed by trading platforms on which the Token is admitted to trading. Trading platforms may impose KYC, AML, CFT, sanctions, jurisdictional or other access restrictions in accordance with applicable law and their internal policies. The Company imposes no contractual transfer restrictions on holders of the Token. |
|||
| 10 Key information about the offer to the public or admission to trading | textBlock | This crypto-asset white paper relates to an admission to trading only. The Company is not making an offer to the public of the Token by means of this white paper and collects no funds or crypto-assets from holders in connection with the admission to trading. Any sale of the Token by existing holders on an independent third-party trading platform constitutes secondary-market trading by those holders and is not a sale by, or on behalf of, the Company. Any secondary-market price is determined by supply and demand on platforms that the Company does not operate or control. Any future offer of the Token to the public by another person, or any separate application by another person for admission of the Token to trading based on this crypto-asset white paper, would be distinct from the present admission-only structure. Such person may rely on this white paper only after the Company has expressly provided its written consent to its use in accordance with Article 5(4) of Regulation (EU) 2023/1114. Unless and until such written consent is granted, no person is authorised by the Company to use this white paper for an offer to the public or for a separate application for admission to trading. |
|||
| Part A - Information about offeror or person seeking admission to trading | |||||
| A.1 Name | text | ||||
| A.2 Legal form | text | ||||
| A.3 Registered address | |||||
| Registered addess | text | ||||
| Country | enumeration | ||||
| Sub-division | text | ||||
| A.4 Head office | |||||
| Head office | text | ||||
| Country | enumeration | ||||
| Sub-division | text | ||||
| A.5 Registration date | date | ||||
| A.6 Legal entity identifier | LEI | ||||
| A.7 Another identifier required pursuant to applicable national law | text | ||||
| A.8 Contact telephone number | text | ||||
| A.9 E-mail address | text | ||||
| A.10 Response time (days) | integer | ||||
| A.11 Parent company | text | ||||
| A.12 Members of the management body | |||||
| Member #1 | id | 1 | |||
| Identity | text | ||||
| Business address | text | ||||
| Function | text | ||||
| Member #2 | id | 2 | |||
| Identity | text | ||||
| Business address | text | ||||
| Function | text | ||||
| A.13 Business activity | textBlock | The Company's role is limited to the issuance and administration of the Token and to the support of the Protocol in connection with the operation of the Chain. |
|||
| A.14 Parent company business activity | textBlock | ||||
| A.15 Newly established | boolean | ||||
| A.16 Financial condition for the past three years | textBlock | ||||
| A.17 Financial condition since registration | textBlock | ||||
| Part B - Information about issuer, if different from offeror or person seeking admission to trading | |||||
| B.1 Issuer different from offerror or person seeking admission to trading | boolean | ||||
| B.2 Name | N/A | . | |||
| B.3 Legal form | N/A | . | |||
| B.4 Registered address | |||||
| Registered addess | N/A | . | |||
| Country | N/A | . | |||
| Sub-division | N/A | . | |||
| B.5 Head office | |||||
| Head office | N/A | . | |||
| Country | N/A | . | |||
| Sub-division | 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 | |||||
| Member #1 | N/A | . | |||
| Identity | N/A | . | |||
| Business address | N/A | . | |||
| Function | 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 | |||||
| C.1 Name | N/A | . | |||
| C.2 Legal form | N/A | . | |||
| C.3 Registered address | |||||
| Registered address | N/A | . | |||
| Country | N/A | . | |||
| Sub-division | N/A | . | |||
| C.4 Head office | |||||
| Head office | N/A | . | |||
| Country | N/A | . | |||
| Sub-division | 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 | |||||
| Member #1 | N/A | . | |||
| Identity | N/A | . | |||
| Business address | N/A | . | |||
| Function | 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 | |||||
| D.1 Crypto-asset project name | text | ||||
| D.2 Crypto-asset name | text | ||||
| D.3 Abbreviation | text | ||||
| D.4 Crypto-asset project description | textBlock | It uses CometBFT Byzantine fault tolerant proof-of-stake consensus with an expected block time of four seconds and single-block protocol finality. The Token is the native gas, staking and governance asset of the Chain. The design objective of the Protocol is trust-minimised interoperability. Inter-Blockchain Communication is the primary cross-chain mechanism, and the design avoids introducing privileged third parties such as operator committees, multi-signature arrangements or multi-party computation groups. The Chain also exposes zero-knowledge proof verification and post-quantum signature verification precompiles. Live functionality comprises the Chain itself, the native fee, staking and governance functionality of the Token, the precompile set, IBC transfer and light-client functionality with its protocol-level safety controls, the CTMScan block explorer and the public and paid node infrastructure. The mainnet is at beta stage and is designated "Mainnet Beta". Functionality that is planned, conceptual or not yet supported by published interfaces includes certain cross-chain verification components, hosted data-indexing and price-data services, and the further milestones set out in the project roadmap. Earlier descriptions of alternative consensus and cross-chain verification designs have been superseded, do not describe the current architecture of the Chain and should not be relied upon as a description of current or planned features of the Protocol. The scope, timing and availability of all planned features remain subject to technical implementation, testing, security review, regulatory developments and operational factors. No planned feature is guaranteed. |
|||
| D.5 Details of all natural or legal persons involved in implementation of crypto-asset project | |||||
| Person #1 | id | 1 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| Person #2 | id | 2 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| Person #3 | id | 3 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| D.6 Utility token classification | boolean | ||||
| D.7 Key features of goods or services for utility token projects | text | The main goods and services to which the Token gives access are the following: a. Network access and execution. The Token is required to pay transaction and network fees on the Chain. The Chain applies an EIP-1559-style fee market under which transaction fees, both the base fee and the priority fee, are burned in full; the fee-market parameters are set at protocol level and are amendable through the governance module. b. Staking and validator participation. The Token may be bonded by a validator or delegated by a holder to a validator. Validator creation and continued participation are subject to a chain-enforced minimum self-delegation. Validators are subject to commission limits, jailing for downtime and slashing for downtime and double-signing. The protocol pays block rewards to validator operator accounts only, for active block signing and proposal; such rewards do not arise merely from holding the Token. Delegating the Token to a validator increases that validator's share of rewards but confers no entitlement to any part of the protocol rewards on the delegator, and the protocol pays no reward directly to delegators. Any sharing of rewards between a validator and its delegators is a private arrangement between them, outside the protocol, and exposes the delegator to the counterparty risk of that validator. c. Protocol governance. The Token is used to deposit on, submit and vote on governance proposals through the governance module of the Chain, including proposals concerning fee-market parameters, the operator whitelists for the protocol safety controls described in Part H and the registration of pre-deployed contracts. d. Cross-chain transfer. The Token may be transferred using the Inter-Blockchain Communication functionality of the Chain, subject to the protocol-level safety controls described in Part H. e. Developer access. Contracts deployed on the Chain may call the Chain's precompiles, including staking, distribution, bank, governance, slashing, ICS-02 client and ICS-20 transfer precompiles and a set of cryptographic and hashing precompiles, using the Token to pay for execution. f. Generation. The Token may be generated by supplying a whitelisted counter-asset to the Protocol, as described in Section G.13. Access to the functionality described above requires the holder to hold the Token in a compatible wallet, to control the relevant private keys and to broadcast valid transactions to the Chain. The quantity and quality of access may vary according to network conditions, protocol parameters in force from time to time and the software used by the holder. The Token does not give holders ownership rights, profit participation, redemption rights, creditor rights, revenue-sharing rights, rights to the assets of the Company or corporate governance rights in relation to the Company or any affiliated entity. |
|||
| D.8 Plans for the token | |||||
| Description of past milestones | textBlock | The core architecture of the Protocol was designed as a multi-chain interoperability framework comprising a general message-passing framework, an asset-transfer framework and a multi-chain protocol-owned treasury. April 2025 - Independent audit of the token-generation program Hacken completed a smart contract code review and security analysis of the Solana token-generation, liquidity-provisioning and referral program of the Protocol. The final report is dated 3 April 2025. The outcome is described in Section H.9. 2025 - Public Generation and initial multi-chain deployment of CTM During 2025, the Public Generation mechanism became operational and CTM was deployed across Ethereum, BNB Chain and Solana. The project subsequently continued the development and migration of the Token infrastructure as the c8ntinuum ecosystem evolved. May 2025 - Launch of the Genesys Network The Genesys Network was launched as an early live network environment of the c8ntinuum ecosystem, enabling generated CTM to be made available on the network and supporting early ecosystem functionality. Public project communications identify 30 May 2025 as its launch date. July 2026 - Mainnet Beta launch of the Chain The mainnet genesis block of the current Chain was produced on 15 July 2026. The Chain is at beta stage and is designated "Mainnet Beta", with a published genesis file and checksum, genesis validators, public and paid node endpoints and the CTMScan block explorer available for mainnet and testnet. 2026 - Expansion of ecosystem participation functionality The project introduced the Network Score, an ecosystem contribution programme covering participation across the interoperability protocol, the Chain and cross-chain CTM liquidity. The programme is designed to extend to further activities as additional ecosystem products become available. |
|||
| Description of future milestones | textBlock | The Bridgeless Protocol is currently targeted for public release in Q4 2026. The SuperApp is being rolled out as a public-facing product layer intended to integrate functionality including holding, trading, staking, launching and earning. Other elements of the technical and product roadmap are intended to be introduced progressively as development, integration and testing advance; no fixed implementation date has been announced for those elements as of the date of this white paper. SuperApp - ongoing rollout The project is progressively rolling out the c8ntinuum SuperApp and its related functionality. Certain ecosystem features are already accessible through the c8ntinuum application, with further functionality intended to be introduced progressively. Future milestones are indicative development objectives and may evolve in scope or timing as a result of technical implementation, testing, security considerations, market conditions, regulatory developments and other operational factors. |
|||
| D.9 Resource allocation | text | The maximum supply is allocated as follows: Genesis Allocation: 50 per cent of the maximum supply, being 4,444,444,444 CTM, subdivided into a Private Investors allocation representing 10 per cent of the maximum supply, a Growth and Development allocation representing 20 per cent of the maximum supply and a Foundation allocation representing 20 per cent of the maximum supply. Public Generation: the remaining 50 per cent of the maximum supply, being 4,444,444,444 CTM, distributed over time, out of the supply issued at genesis, to persons supplying whitelisted counter-assets to the Protocol, as described in Section G.13. No CTM is minted after genesis and the inflation rate of the Chain is zero. The Token is issued as a native coin on the Chain and, in addition, in token form on Ethereum, BNB Chain and Solana. A single maximum supply covers all such representations. |
|||
| D.10 Planned use of collected funds or other tokens | text | The protocol treasury forms part of the assets of the c8ntinuum project. |
|||
| Part E - Information about offer to public of other tokens or their admission to trading | |||||
| E.1 Public offering or admission to trading | enumeration | ||||
| E.2 Reasons for public offer or admission to trading | textBlock | No trading volume, liquidity, market demand, price stability or continued platform support is guaranteed. |
|||
| E.3 Fundraising target | |||||
| Target expressed in currency | monetary | USD | |||
| Target expressed in units | decimal | ||||
| Target expressed in digital token identifier | text | ||||
| E.4 Minimum subscription goals | |||||
| Goals expressed in currency | monetary | USD | |||
| Goals expressed in units | decimal | ||||
| Goals expressed in digital token identifier | text | ||||
| E.5 Maximum subscription goals | |||||
| Goasl expressed in currency | monetary | USD | |||
| Goals expressed in units | decimal | ||||
| Goals expressed in digital token identifier | text | ||||
| E.6 Oversubscription acceptance | boolean | ||||
| E.7 Oversubscription allocation | text | ||||
| Issue price details | |||||
| E.8 Issue price | decimal | ||||
| E.9 Official currency determining issue price | enumeration | ||||
| E.9 Any other tokens determining issue price | text | ||||
| E.10 Subscription fee | |||||
| Fee expressed in currency | monetary | USD | |||
| Fee expressed in units | decimal | ||||
| Fee expressed in digital token identifier | text | ||||
| E.11 Offer price determination method | text | ||||
| E.12 Total number of offered or traded other tokens | integer | ||||
| E.13 Targeted holders | enumeration | ||||
| E.14 Holder restrictions | text | ||||
| E.15 Reimbursement notice | boolean true | ||||
| E.16 Refund mechanism | textBlock | ||||
| E.17 Refund timeline | text | ||||
| E.18 Offer phases | textBlock | ||||
| E.19 Early purchase discount | textBlock | ||||
| E.20 Time-limited offer | boolean | ||||
| E.21 Subscription period beginning | date | ||||
| E.22 Subscription period end | date | ||||
| E.23 Safeguarding arrangements for offered funds or other tokens | textBlock | ||||
| E.24 Payment methods for other token purchase | textBlock | ||||
| E.25 Value transfer methods for reimbursement | textBlock | ||||
| E.26 Right of withdrawal | textBlock | ||||
| E.27 Transfer of purchased other tokens | textBlock | ||||
| E.28 Transfer time schedule | text | ||||
| E.29 Purchaser's technical requirements | textBlock | a. reliable access to the internet; b. a suitable device (computer or mobile) to manage a digital wallet, private keys and/or a trading-platform account in order to execute transactions; c. where the Token is accessed through a centralised trading platform, opening and maintaining an account and completing the platform's onboarding and KYC/AML requirements; d. where the native Token is held in self-custody on the Chain, a wallet compatible with the Chain and with its address formats, being the 0x hexadecimal format and the c8 Bech32 format, configured with the network parameters of the Chain, and holding sufficient Tokens to cover network fees; e. where the Token is held on Ethereum, BNB Chain or Solana, a self-custodial wallet compatible with the relevant network and the relevant token standard, being ERC-20, BEP-20 or SPL respectively, holding sufficient funds in the native asset of that network to cover transaction fees; and f. sufficient understanding of private-key management, irreversible transactions, network fees and the need to select the correct network before depositing or withdrawing. |
|||
| Other token services provider characteristics | |||||
| E.30 Other token service provider (CASP) name | text | ||||
| E.31 CASP identifier | LEI | ||||
| E.32 Placement form | enumeration | ||||
| Trading platforms characteristics | |||||
| E.33 Trading platforms name | text | ||||
| E.34 Trading platforms market identifier code (MIC) | text | ||||
| E.35 Trading platforms access | text | Holders must select the correct network before depositing or withdrawing. The native Token exists on the Chain and deposits and withdrawals of the native asset must use the Chain. The Token is separately issued as an ERC-20 token on Ethereum, a BEP-20 token on BNB Chain and an SPL token on Solana, and deposits and withdrawals of each of those representations must use the corresponding network. Sending the Token to an address on the wrong network is likely to result in permanent loss. Where self-custody is used, holders must use a wallet compatible with the relevant network and remain responsible for securing private keys and verifying addresses before transacting. |
|||
| E.36 Involved costs | textBlock | The use of services offered by trading platforms on which the Token is admitted to trading may involve costs such as trading fees, withdrawal fees, listing fees and other platform-specific charges, as notified to users in advance by the respective trading platforms. These fees are determined and set solely by the trading platforms and are not controlled, influenced or governed by the Company. All on-chain transactions involving the Token are subject to network transaction fees ("gas fees"). On the Chain, fees are payable in the Token under an EIP-1559-style fee market in which transaction fees are burned in full. Transactions involving the representations of the Token on Ethereum, BNB Chain and Solana are subject to the fee models of those networks and are payable in the native asset of the relevant network. |
|||
| E.37 Offer expenses | textBlock | ||||
| E.38 Conflicts of interest | textBlock | The Genesis Allocation includes a Private Investors allocation representing 10 per cent of the maximum supply, as described in Section D.9. That allocation is a predefined and disclosed component of the tokenomics of the Token and is not a discretionary benefit granted in connection with the admission of the Token to trading on any particular trading platform. The holders of that allocation receive no preferential Token rights, no preferential pricing, no preferential liquidity arrangements and no other advantage in connection with the admission of the Token to trading. All Tokens carry the same rights and characteristics, as described in Sections F.6 and G.1. Accordingly, while that allocation gives the relevant persons a disclosed economic interest in the Token, no competing duty or interest has been identified that would impair objective decision making in connection with the admission of the Token to trading. Technical control positions The administrator and verifier keys of the token-generation contracts described in Section G.13, and the operator whitelists described in Section H.7, are held as set out in those Sections. No member of the management body of the Company holds a position under those arrangements that gives rise to a conflict of interest in relation to the admission of the Token to trading. Other conflicts The Company is not aware of any other potential conflict of interest among the members of its management body, the persons identified in Section D.5 or any affiliate with respect to the admission of the Token to trading. |
|||
| E.39 Applicable law | textBlock | ||||
| E.40 Competent court | textBlock | ||||
| Part F - Information about other tokens | |||||
| F.1 Crypto-asset type | text | ||||
| F.2 Other token functionality | textBlock | In addition, the Token may be generated by supplying a whitelisted counter-asset to the Protocol. The counter-assets so supplied are applied to a protocol treasury, of which 80 per cent funds a buyback-and-burn mechanism for the Token and 20 per cent funds referral rewards, as described in Sections D.10 and G.13. The Token does not confer dividends, interest, profit-sharing rights, revenue-sharing rights, governance rights over the Company, redemption rights, claims against the Company or any entitlement to future profits. Validator rewards are paid by the protocol to validator operator accounts only and require operation of a validator; they are not paid merely for holding the Token. Delegating the Token confers no entitlement to protocol rewards on the delegator, and any reward-sharing between a validator and its delegators is a private arrangement outside the protocol that exposes the delegator to the validator's counterparty risk. |
|||
| F.3 Planned application of functionalities | textBlock | These planned functionalities are indicative development objectives, are not yet fully live and may evolve in scope or timing as a result of technical implementation, testing, security considerations, market conditions, regulatory developments and other operational factors. No planned functionality is guaranteed to be implemented in any particular form or timeframe. |
|||
| 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 | enumeration | ||||
| F.5 Type of submission | enumeration | ||||
| F.6 Other token characteristics | textBlock | a. The Token is a fungible utility-type native protocol crypto-asset. Each unit is identical and interchangeable with another unit. b. The maximum supply of the Token is capped at 8,888,888,888 CTM. Of that maximum supply, 50 per cent, being 4,444,444,444 CTM, is the Genesis Allocation, subdivided into a Private Investors allocation of 10 per cent, a Growth and Development allocation of 20 per cent and a Foundation allocation of 20 per cent of the maximum supply; and 50 per cent, being 4,444,444,444 CTM, is the Public Generation, distributed over time, out of the supply issued at genesis, through the generation mechanism described in Section G.13. c. The Token exists as a native coin on the Chain and, in addition, as an ERC-20 token on Ethereum, a BEP-20 token on BNB Chain and an SPL token on Solana. The units issued across all supported networks represent one economic crypto-asset and must be assessed together. d. The native, Ethereum and BNB Chain implementations use 18 decimal places; the Solana implementation uses 9 decimal places. e. The Token is transferable on-chain, subject to applicable law, protocol rules, technical network functionality, wallet compatibility and any trading platform rules and fees. Admission to trading occurs on independent platforms that the Company does not operate or control. f. The Token is non-interest bearing. Holders bear network transaction fees, including gas fees or equivalent network fees, when transferring or otherwise using the Token on the relevant supported network. On the Chain, fees are charged under an EIP-1559-style fee market in which transaction fees are burned in full. g. The Token has no physical form and no intrinsic financial value or guaranteed pricing, and no person makes any representation or commitment regarding its value. The market value of the Token, if any, is determined by supply and demand on the relevant trading platforms and markets. h. The Token is non-refundable and is not redeemable for any assets of any entity or organisation, and cannot be exchanged for cash, or its equivalent value in any other digital asset, or for any payment obligation of the Company or any affiliate. i. Holding the Token does not grant any rights in or to the Company or any affiliate, or their revenues or assets, including, without limitation, any right to dividends, revenue, shares, ownership interest, equity stake, securities, distribution, redemption, liquidation, proprietary rights, intellectual-property rights, licence rights, accounts, financial statements or other financial data, the right to requisition or participate in shareholder or management meetings, the right to nominate a director, or any other financial, legal or equivalent right in or relating to the Company, its affiliates or their service providers. j. Governance functionality associated with the Token is exercised through the on-chain governance module of the Chain and is limited to protocol-level and ecosystem-related matters. It does not constitute corporate governance over the Company or any affiliated entity and confers no control over the Company, its management, treasury, revenues or assets. k. Validator rewards are paid by the protocol to validator operator accounts only and require active validation and network-security participation. Delegating the Token to a validator confers no entitlement on the delegator to any part of the protocol rewards, and any reward-sharing between a validator and its delegators is a private arrangement outside the protocol that exposes the delegator to the validator's counterparty risk. Such rewards do not arise merely from holding the Token and do not constitute dividends, interest, profit participation, revenue sharing or a guaranteed return. Bonded Tokens are subject to slashing and jailing under the protocol rules. l. The Token does not represent a loan to, or debt of, the Company or any of its affiliates; it is not intended to represent indebtedness, and there is no expectation of profit or interest. m. The Token is not intended to represent rights under a contract for differences or under any other contract designed to secure a profit or avoid a loss. n. The Token is not electronic money or an e-money token, a payment instrument, a security, a commodity, a bond, a debt instrument, a unit in a collective investment undertaking or managed investment scheme, or any other financial instrument or investment. o. The Token is not an asset-referenced token or a stablecoin. It does not purport to maintain a stable value relative to any asset or currency; it is not pegged to, or backed by, any reserve of assets; it confers no redemption right or claim against the Company or its affiliates; and it uses no stabilisation mechanism, whether algorithmic or otherwise. |
|||
| F.7 Commercial name or trading name | text | ||||
| F.8 Website of the issuer | text | ||||
| F.9 Starting date of offer to the public or admission to trading | date | ||||
| F.10 Publication date | date | ||||
| F.11 Any other services provided by the issuer | textBlock | ||||
| F.12 Language or languages of white paper | text | ||||
| 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 | text | ||||
| F.14 Functionally fungible group digital token identifier, where available | text | ||||
| F.15 Voluntary data flag | boolean | ||||
| F.16 Personal data flag | boolean | ||||
| F.17 LEI eligibility | boolean | ||||
| F.18 Home member state | enumeration | ||||
| F.19 Host member states #1 | enumerationSet | ||||
| F.19 Host member states #2 | enumerationSet | ||||
| F.19 Host member states #3 | enumerationSet | ||||
| F.19 Host member states #4 | enumerationSet | ||||
| F.19 Host member states #5 | enumerationSet | ||||
| F.19 Host member states #6 | enumerationSet | ||||
| F.19 Host member states #7 | enumerationSet | ||||
| F.19 Host member states #8 | enumerationSet | ||||
| F.19 Host member states #9 | enumerationSet | ||||
| F.19 Host member states #10 | enumerationSet | ||||
| F.19 Host member states #11 | enumerationSet | ||||
| F.19 Host member states #12 | enumerationSet | ||||
| F.19 Host member states #13 | enumerationSet | ||||
| F.19 Host member states #14 | enumerationSet | ||||
| F.19 Host member states #15 | enumerationSet | ||||
| F.19 Host member states #16 | enumerationSet | ||||
| F.19 Host member states #17 | enumerationSet | ||||
| F.19 Host member states #18 | enumerationSet | ||||
| F.19 Host member states #19 | enumerationSet | ||||
| F.19 Host member states #20 | enumerationSet | ||||
| F.19 Host member states #21 | enumerationSet | ||||
| F.19 Host member states #22 | enumerationSet | ||||
| F.19 Host member states #23 | enumerationSet | ||||
| F.19 Host member states #24 | enumerationSet | ||||
| F.19 Host member states #25 | enumerationSet | ||||
| F.19 Host member states #26 | enumerationSet | ||||
| F.19 Host member states #27 | enumerationSet | ||||
| F.19 Host member states #28 | enumerationSet | ||||
| F.19 Host member states #29 | enumerationSet | ||||
| Part G - Information on rights and obligations attached to other tokens | |||||
| G.1 Purchaser rights and obligations | textBlock | The Token confers no claim against the Company, and no equity, ownership, dividend, interest, profit-share, revenue-share, redemption or creditor right, no claim over any treasury or assets, no corporate governance or voting right over the Company and no entitlement to future profits. Governance rights are exercised at protocol level only. Validator rewards are paid by the protocol to validator operator accounts only and require active validation or the operation of a validator; they do not arise from merely holding the Token. Delegating the Token to a validator confers no entitlement to protocol rewards on the delegator, and any reward-sharing between a validator and its delegators is a private arrangement outside the protocol that exposes the delegator to the validator's counterparty risk. Holders are responsible for securing their wallets, private keys and recovery information, for paying applicable network fees, for using compatible wallets and the correct address format and network, and for complying with applicable law and any relevant trading-platform rules. Where a holder delegates the Token to a validator, the bonded amount is subject to the protocol's slashing and jailing rules and to the unbonding process; the holder bears the risk of validator misbehaviour or downtime. The maximum supply of the Token is capped at 8,888,888,888 CTM. The Token is generated against whitelisted counter-assets as described in Section G.13, and burn mechanisms operate comprising the burning in full of EIP-1559 transaction fees on the Chain and the burning of a portion of the Token acquired by the protocol treasury. Those features confer no right on a holder and are not a commitment as to supply, price or liquidity. It has not been confirmed that the stated maximum supply is enforced by the contracts deployed on each supported network; see Sections D.9, F.6 and I.3. The Chain runs open-source software under the Apache 2.0 licence, and the Company is not technically able to prevent third parties from forking that software or the network. Any reward, incentive or referral programme operated in connection with the Protocol is discretionary and activity-based, is subject to the applicable programme rules, technical availability and eligibility requirements, and does not create any claim to protocol revenues, to the assets of the Company or to any minimum level of reward. |
|||
| G.2 Exercise of rights and obligations | textBlock | Rights and features are exercised by holding the relevant private keys and broadcasting valid transactions to the Chain. Staking and delegation are performed by submitting the relevant transaction to the staking module of the Chain, directly or through the staking precompile. Governance participation is performed by submitting a proposal, deposit or vote to the governance module of the Chain, directly or through the governance precompile. Protocol rewards are paid only to validator operator accounts for active validation in accordance with the protocol rules; delegation itself confers no entitlement to protocol-level rewards. The exercise of any utility depends on the continued availability and operation of the Chain, of the relevant node infrastructure and of any third-party platform involved. The Company does not guarantee secondary-market trading or liquidity. Certain protocol-level controls described in Section H.7 may, if activated, suspend transactions on the Chain or block outbound Inter-Blockchain Communication transfers. No minimum level of utility, access, rewards, liquidity, market demand or benefit is promised or guaranteed. |
|||
| G.3 Conditions for modifications of rights and obligations | textBlock | Certain parameters may also be changed by whitelisted operator accounts without a governance vote, as described in Section H.7. Separately, the administrator of the audited token-generation contracts is able to change the issuance price and the referral and liquidity percentages, as described in Section H.9. Because the software of the Chain is open-source, the Company cannot technically prevent third parties from forking the software or the network. Protocol upgrades and material changes are expected to be announced through the project's official website, documentation and public community channels. Such changes do not create any right to compensation, redemption, reimbursement, revenue sharing or other financial claim against the Company or any affiliated entity. |
|||
| G.4 Future public offers | textBlock | The generation mechanism described in Section G.13 is currently in operation. Through that mechanism the circulating supply of the Token increases over time, as a person supplies a whitelisted counter-asset to the Protocol and Tokens are credited to that person, up to the maximum supply of 8,888,888,888 CTM. |
|||
| G.5 Issuer retained other token | integer | ||||
| G.6 Utility token classification | boolean | ||||
| G.7 Key features of goods or services utility tokens | text | The Token does not provide access to any goods, services, features or benefits supplied by the Company outside the Protocol. It does not confer dividend, interest, profit-share, revenue-share, redemption or issuer-claim rights, and it confers no governance rights over the Company. Validator rewards are paid by the protocol to validator operator accounts only and require operation of a validator; they do not arise merely from holding the Token, and delegating the Token confers no entitlement to protocol rewards on the delegator. |
|||
| G.8 Utility tokens redemption | text | Any holding, bonding, delegation or other use of the Token is operational in nature and does not create any right to repayment, interest, monetary yield, value maintenance or claim against the Company or any affiliated entity. |
|||
| G.9 Non-trading request | boolean | ||||
| G.10 Other tokens purchase or sale modalities | text | ||||
| G.11 Other tokens transfer restrictions | text | Third-party trading platforms may impose restrictions on buyers, sellers, deposits or withdrawals in accordance with applicable law and their own terms and internal policies. Such restrictions may include onboarding requirements, Know Your Customer, Anti-Money Laundering, Counter-Financing of Terrorism and sanctions checks, jurisdictional restrictions, transaction limits or suspension of services. At protocol level, the Chain includes controls that may affect transferability. A circuit-breaker module exposes a system-availability flag which, when set to unavailable by a whitelisted account, causes all transactions other than those restoring availability to be rejected, on both the Cosmos and the EVM transaction paths. A separate Inter-Blockchain Communication breaker module allows whitelisted accounts to block the initiation of outbound Inter-Blockchain Communication transfers, including transfers routed through the ICS-20 precompile, while leaving internal transfers on the Chain available. A rate-limiter extension allows the governance authority or whitelisted operators to add, update, remove or reset throughput caps on Inter-Blockchain Communication channels. Validator bonding is also subject to a chain-enforced minimum self-delegation and to an unbonding period during which bonded Tokens cannot be transferred. In addition, the administrator of the audited token-generation contracts is able to add addresses to a blacklist preventing those addresses from participating in the generation mechanism. The audited implementation contains no function to remove an address from that blacklist. |
|||
| G.12 Supply adjustment protocols | boolean | ||||
| G.13 Supply adjustment mechanisms | text | Generation. The Token is generated when a person supplies a whitelisted counter-asset to the Protocol and the Token is credited to that person by reference to the market value of the counter-asset. A minimum price applies to generation: the generation price follows the market price of the Token but cannot fall below a floor set at protocol level, and that floor increases with every 888 million CTM generated. In the audited implementation the applicable price is set by the contract administrator and each generation request must be authorised before it can be executed, as described in Section H.9. Use of counter-assets. All counter-assets supplied through the generation mechanism are applied to a protocol treasury, of which 80 per cent funds a buyback-and-burn mechanism for the Token and 20 per cent funds rewards paid under the referral programme. Section D.10 addresses the control of those assets. Buyback and burn. Tokens acquired by the protocol treasury under the buyback-and-burn mechanism are permanently removed from supply. Fee burn. On the Chain, transaction fees are burned in full on every transaction under the EIP-1559-style fee market, both the base fee and the priority fee, for EVM and native transactions. Slashing. Bonded Tokens are burned where a validator is slashed, at 1 per cent of the bonded amount for downtime and 5 per cent for double-signing. Governance deposits. A governance proposal requires a deposit in Tokens, which is burned where the proposal is rejected on a veto vote, as described in Section H.3. Validator rewards. The Chain pays rewards to validator operator accounts for participating in the production of blocks. These rewards are paid from a rewards pool funded at genesis with 16,425,000 CTM and open to further deposits, paying a fixed amount per epoch; the inflation rate of the Chain is zero and no new CTM is issued to fund them. The amounts and periods concerned are protocol parameters that may be adjusted, or paused, by governance-whitelisted accounts. The protocol pays these rewards to validator operator accounts only; delegating the Token confers no entitlement to protocol rewards on the delegator, and any reward-sharing between a validator and its delegators is a private arrangement outside the protocol. |
|||
| Other token schemes details | |||||
| G.14 Token value protection schemes | boolean | ||||
| G.15 Token value protection schemes description | textBlock | ||||
| G.16 Compensation schemes | boolean | ||||
| G.17 Compensation schemes description | textBlock | ||||
| G.18 Applicable law | textBlock | ||||
| G.19 Competent court | textBlock | ||||
| Part H – Information on underlying technology | |||||
| H.1 Distributed ledger technology (DTL) | text | The Token is a native crypto-asset of the Chain and is, in addition, issued in token form on three third-party distributed ledgers. The units issued across all supported networks represent one economic crypto-asset and must be assessed together. The c8ntinuum network (the Chain) is a public, EVM-compatible Layer-1 distributed ledger secured by CometBFT Byzantine fault tolerant proof-of-stake consensus. It is based on and extends the Cosmos EVM stack and is released as open-source software under the Apache 2.0 licence. The expected block time is four seconds and a committed block is final after one block under standard CometBFT assumptions. Every account has a dual representation, in 0x hexadecimal form and in c8 Bech32 form. The native asset of the Chain is the Token. The mainnet is at beta stage and is designated "Mainnet Beta". The distributed ledger identifier (DLI) of the c8ntinuum network is J0H9X7G5Q. The digital token identifiers (DTIs) of the Token are QCV3L1MBN on the c8ntinuum network, V8WXHQBV9 on Ethereum, DLP44V9KL on BNB Chain and CW8NMTTVR on Solana, grouped under the functionally fungible group digital token identifier 198PPJJV8. |
|||
| H.2 Protocols and technical standards | text | The Chain uses a Cosmos SDK and CometBFT stack with an Ethereum-compatible execution layer, based on and extending Cosmos EVM. Addresses are represented both in 0x hexadecimal form and in c8 Bech32 form. The execution layer is compatible with the Ethereum token standards, including ERC-20, ERC-721 and ERC-1155, and supports the standard Ethereum transaction types. A number of widely used utility contracts are available from genesis, and governance may register further contracts. The Chain exposes its Cosmos modules and a set of cryptographic functions to smart contracts through system-level interfaces, including the verification of zero-knowledge proofs and of post-quantum signatures. Interfaces for the Ethereum token standards are created dynamically from registered token pairs. Cross-chain messaging uses the Inter-Blockchain Communication protocol, through which the Chain can send assets to, and receive assets from, other blockchains. The Chain also supports zero-knowledge light clients. On the other supported networks, the Token relies on the standards applicable to each network. On Ethereum the Token follows the ERC-20 standard; Ethereum uses proof-of-stake consensus, executes smart contracts on the Ethereum Virtual Machine, derives addresses from public keys by cryptographic hashing and implements upgrades through the Ethereum Improvement Proposal process. On BNB Chain the Token follows the BEP-20 standard on an EVM-compatible Layer-1 using proof-of-staked-authority. On Solana the Token is implemented through the Solana Token Program as an SPL token; the token is not a separate executable contract but a token mint and related data accounts managed through standard Token Program instructions, with metadata capable of being stored through the Metaplex Token Metadata Program. |
|||
| H.3 Technology used | textBlock | The Chain uses a Cosmos SDK and CometBFT stack with an Ethereum-compatible execution layer, based on and extending Cosmos EVM. Live functionality comprises the following. Consensus and finality. CometBFT Byzantine fault tolerant proof-of-stake consensus with an expected block time of four seconds and single-block protocol finality, so that block reorganisations are governed by consensus finality rather than probabilistic confirmation. Exchanges and custodians may nonetheless apply their own operational confirmation policies. Staking and slashing. Validator creation and continued participation require a chain-enforced minimum self-delegation of 888,888 CTM, enforced across Cosmos transactions, API routes and the staking precompile. A validator that falls below the minimum is jailed and removed from the active set. A validator that fails to sign a substantial proportion of blocks within a defined window is temporarily removed from the active set and 1 per cent of its stake is burned; double-signing burns 5 per cent of stake and removes the validator permanently, and a tombstoned validator cannot be unjailed. Fee market. An EIP-1559-style fee market is enabled from genesis. Transaction fees are burned in full, both the base fee and the priority fee, for EVM and native transactions. Fee-market parameters are amendable through the governance module. Validator rewards. A validator-rewards module awards per-epoch points for signed blocks, and allocates the reward for each period in proportion to points. Claims are paid from a module rewards pool and fail if the pool is insufficient. Cross-chain. Inter-Blockchain Communication, subject to the safety controls described in Section H.7. Infrastructure. Public and paid node endpoints; the CTMScan block explorer for mainnet and testnet with source verification; a public testnet with a faucet; and a deployment script, peer list and release metadata served from the project's resource domain, with genesis and binary checksums verified on installation. Planned or conceptual functionality includes certain further cross-chain verification components, for which no interface is published, and hosted data-indexing and price-data services, which are not yet available. Relayers are generic off-chain actors that submit packet data and proofs; there is no dedicated relayer set, operator, software or incentive scheme. Earlier descriptions of alternative consensus and cross-chain verification designs have been superseded and should not be relied upon as current or planned features of the Protocol. Holders are responsible for choosing the correct network, using a compatible wallet or trading-platform account, securing private keys and recovery phrases, and ensuring that transfers are made to addresses compatible with the relevant network. |
|||
| H.4 Consensus mechanism | text | The Chain uses CometBFT Byzantine fault tolerant proof-of-stake consensus. Blocks are committed when validators representing more than two thirds of voting power agree, and a committed block is final after one block under standard CometBFT assumptions, rather than through probabilistic proof-of-work confirmation. The expected block time is four seconds. Finality assumes that less than one third of voting power is Byzantine and that the network can eventually make progress. The Chain does not use proof-of-work. Participation in consensus requires a validator to bond at least 888,888 CTM by way of self-delegation, and holders may delegate additional stake to validators. The active validator set holds up to 88 validators and the unbonding period is 44 days. Validators are subject to commission limits, to jailing and slashing for downtime and to slashing and tombstoning for double-signing, on the parameters set out in Section H.3. The representations of the Token on Ethereum, BNB Chain and Solana do not operate a separate consensus mechanism. Transactions in those representations are validated and settled according to the consensus mechanism of the relevant underlying network. Ethereum uses proof-of-stake, under which validators stake ETH, propose and attest to blocks and are subject to rewards, inactivity penalties and slashing. BNB Chain uses proof-of-staked-authority, under which validators are selected by staking and voting and take turns producing blocks, with a limited active validator set. Solana uses a combination of proof of history and proof of stake, under which proof of history provides a cryptographic ordering of events and validators participate in block production and validation based on stake. |
|||
| H.5 Incentive mechanisms and applicable fees | text | On the Chain, the incentive mechanism consists of validator rewards and transaction fees. Validator rewards are paid by the protocol to validator operator accounts only, for participating in the production of blocks, from a rewards pool funded at genesis and open to further deposits, and are allocated among validators according to their participation. The protocol pays no reward directly to delegators; delegating stake increases a validator's share of rewards, and any reward-sharing between a validator and its delegators is a private arrangement between them, outside the protocol, that exposes the delegator to the validator's counterparty risk. Rewards compensate active validation and network-security participation; they do not arise merely from holding the Token and do not constitute interest, dividends, profit participation, revenue sharing or a guaranteed return. Bonded Tokens are subject to slashing of 1 per cent for downtime and 5 per cent for double-signing. Fees on the Chain are payable in the Token under an EIP-1559-style fee market. Transaction fees are burned in full, both the base fee and the priority fee, for EVM and native transactions. Priority fees are burned in the same way, so that no part of a transaction fee is paid to validators, to the community pool or to any other recipient. Inter-Blockchain Communication and relayer integrations may introduce integration-specific fees outside normal execution gas. Access to the paid node endpoints is charged against an API key and is remuneration for infrastructure access rather than for any transaction in crypto-assets. All counter-assets supplied through the generation mechanism are applied to a protocol treasury, of which 80 per cent funds a buyback-and-burn of the Token and 20 per cent funds rewards paid to referrers under the referral programme, as described in Sections D.10 and G.13. Tokens acquired under the buyback-and-burn are permanently removed from supply. These mechanisms operate according to protocol rules, confer no right on a holder and do not arise merely from holding the Token. The incentives and fees of Ethereum, BNB Chain and Solana apply to the representations of the Token on those networks and are payable in the native asset of the relevant network. Those network-level incentives and fees are separate from the protocol-level and ecosystem-level mechanisms described above, are set by the relevant network and are not controlled by the Company. Ecosystem-level incentives do not arise merely from passive holding of the Token and do not constitute interest, dividends, profit participation, revenue sharing or a guaranteed return. |
|||
| H.6 Use of distributed ledger technology | boolean | ||||
| H.7 DLT functionality description | textBlock | Prospective holders should note in particular that the network is not fully autonomous. A limited number of accounts hold the technical ability, without any vote of Token holders, to (i) halt the network entirely, so that no transaction can be processed at all until those accounts restore it, (ii) block outgoing transfers of the Token to other blockchains, (iii) impose limits on the volume that may be transferred to and from other blockchains, and (iv) change or suspend the rewards paid to validators. These abilities are built into the protocol itself. If they are exercised, whether deliberately or as a result of the loss or compromise of the relevant keys, a holder may be temporarily or indefinitely unable to transact in or transfer the Token. This is a material consideration for any decision to acquire the Token and is addressed as a risk in Section I.5. The Chain is a public, EVM-compatible Layer-1 distributed ledger operated as an open network. It records transactions and account balances, executes smart contracts on an Ethereum-compatible virtual machine, exposes Cosmos SDK modules to those contracts through precompiles, and allows holders to control the Token through compatible wallet software and private keys. Blocks are proposed and committed by validators under CometBFT proof-of-stake consensus, and the Chain issues validator rewards and burns EIP-1559 transaction fees in full according to protocol rules. Transactions on the Chain are public. Amounts, balances, counterparties and transaction history are recorded on a public ledger and are visible through the CTMScan block explorer and through the public node endpoints. The Chain provides no confidentiality or shielding of transaction data. The Chain exposes cross-chain functionality directly to smart contracts. Inter-Blockchain Communication is implemented, allowing assets to be sent to, and received from, other blockchains. The stated design objective is to reduce cross-chain safety to the security assumptions of the underlying chains' consensus and the soundness of the proof system, rather than to introduce privileged third parties such as operator committees, multi-signature arrangements or multi-party computation groups. The Chain also supports zero-knowledge light clients, but publishes no interface, client type, counterparty chain or status for them. The Chain includes three protocol-level control modules which materially affect its operation and which prospective holders should note. 1. Circuit breaker. The Chain exposes a system-availability flag together with a whitelist of accounts authorised to toggle it. Whitelist membership is governance-controlled. The gate is enforced in the ante handler for both native Cosmos transactions and EVM transactions, so that raw EVM transaction submissions are also gated. When the flag is set to unavailable, every transaction other than one restoring availability is rejected. The default genesis state is an empty whitelist with the system available; an empty whitelist is rejected while the system is unavailable, so that at least one operator can always restore availability. 2. Inter-Blockchain Communication breaker. A separate module exposes an operator-controlled availability flag that blocks selected outbound Inter-Blockchain Communication initiation paths, including client creation, connection and channel opening, transfers, interchain-account registration and packet sending. Transfers routed through the ICS-20 precompile are blocked when the flag is disabled. Internal non-Inter-Blockchain Communication transfers on the Chain remain available. Only whitelisted accounts may toggle the flag, and only the governance authority may change the whitelist. 3. Inter-Blockchain Communication rate limiter. A governance-managed whitelist of operators may add, update, remove or reset rate limits on Inter-Blockchain Communication channels, expressed as maximum send and receive percentages over a defined duration. Packet enforcement remains with the rate-limiting middleware. In addition, whitelisted accounts may change the periods and amounts applicable to validator rewards and pause those rewards, in each case without a governance vote, and further contracts may be registered at protocol level. The identity of the accounts on the circuit-breaker, Inter-Blockchain Communication breaker, Inter-Blockchain Communication rate-limiter and validator-rewards whitelists on mainnet, and the identity of the configured virtual-machine authority, are not published. Because these controls allow named accounts to halt the Chain, to block outbound cross-chain transfers and to change validator reward parameters, this is a material centralisation consideration for prospective holders and is addressed as a risk in Section I.5. |
|||
| Other token audit details | |||||
| H.8 Audit | boolean | ||||
| H.9 Audit outcome | textBlock | Within that limited scope the auditor found one critical defect, which was fixed. Four further findings were not fixed but accepted by the project. Two of those are relevant to holders: the price used by the program is taken from a single third-party liquidity pool and can therefore be manipulated, and a signed request to issue Tokens can be re-used repeatedly until it expires. The auditor also recorded that a single administrator account is able to suspend the program, withdraw the assets accumulated in it, set the price of the Token, and add addresses to a blacklist which the audited code provides no means of removing an address from. The auditor states that its report does not guarantee that every vulnerability was identified. An independent smart contract code review and security analysis was carried out by Hacken. The preliminary report is dated 26 March 2025 and the final report is dated 3 April 2025. Scope. The audit covered the Solana program of the Protocol governing token generation, liquidity provisioning and referral rewards. The audited program implements a flow in which a generation request is authorised off-chain, the user submits it on-chain, the program verifies the authorisation and processes the transfer of SOL, part of the SOL is swapped for Tokens through a third-party decentralised exchange and the remaining WSOL and Tokens are applied as liquidity, the remaining Tokens are burned, and referral addresses receive a percentage of the SOL. The audit describes the implementation in the version reviewed; the generation mechanism may have evolved since, and the current mechanism is the one described in Sections D.10 and G.13. Outcome. The audit reported eight findings: one Critical, two Low and five Informational. Three findings were resolved, four were accepted by the client and one was mitigated. The Critical finding, an incorrect pool deserialisation that rendered the program unusable, was fixed. The two Low findings were acknowledged and accepted: the price of the counter-asset is derived solely from a single third-party liquidity pool and may be manipulable, and the absence of a nonce allows the same signed generation request to be replayed until its deadline. Two Informational findings concerning the blacklist design, including the absence of any function to remove an address from the blacklist, were also accepted rather than fixed. On code quality, the auditor recorded that the development environment was not configured and that tools were missing to calculate test coverage. Privileged roles identified by the auditor. The administrator of the audited program can pause and resume the program, withdraw accumulated proceeds from the vault, add addresses to a blacklist preventing participation, and set the referral percentages, the liquidity allocation and the global token price. The audited program also contains instructions permitting transfer of the administrator role and rotation of the verifier key. The verifier signs off-chain messages authorising each generation request. The auditor recorded centralisation risk in off-chain minting, verifier-compromise risk, liquidity and availability risk arising from the dependency on a third-party decentralised exchange, market-manipulation risk in the pricing source and oracle-accuracy risk among the potential risks of the system. Limitations of the audit. The audit covered the Solana program only. It did not cover the Chain, the node software, the Cosmos SDK modules described in Section H.7, the precompiles, the contracts pre-deployed at genesis or the Token contracts on Ethereum and BNB Chain. No audit of any of those components has been made public, and no public bug-bounty programme has been identified. The auditor's own report states that it contains no warranty as to the identification of all vulnerabilities and that it should not be relied on as a final or sufficient assessment of the safety of the code. The audit recorded eight findings in total, of which three were resolved, four were accepted by the project and one was mitigated. By severity, one finding was classified as Critical, none as High or Medium, two as Low and five as Informational. The preliminary report is dated 26 March 2025 and the final report 3 April 2025. The audit was carried out against a specified version of the program, and the project's remediation was subsequently reviewed. The auditor recommended that the price of the counter-asset be obtained from an independent price feed rather than from a single liquidity pool. The list of files covered by the audit does not include any instruction providing for the issuance of new units of the Token, while the risks section of the report refers to an off-chain system responsible for issuing them; the report is therefore not conclusive as to whether units are issued on demand or distributed from an existing balance; the entire supply was issued at genesis and no further units of the Token can be minted. The auditor further recorded that the development environment was not configured and that test coverage could not be measured, and that its report does not constitute an endorsement or a guarantee that the program is free from defects. |
|||
| Part I - Information on risks | |||||
| I.1 Offer-related risks | textBlock | Custodial risk: where the Token is admitted to trading, holders may hold the Token through custodial wallets or accounts provided by trading platforms or other intermediaries. In such cases there is a risk of loss of assets through hacking, insolvency, fraud, operational failure or other malicious acts affecting the relevant intermediary. Protocol dependence: the native Token is dependent on the Chain. Downtime, congestion, protocol failure, security vulnerabilities, chain reorganisations, insufficient validator participation, activation of the circuit-breaker or Inter-Blockchain Communication controls described in Section H.7, or other network-level issues may impair transfers, staking, trading or other functionality. The mainnet is at beta stage and is designated "Mainnet Beta". Blockchain dependence: the representations of the Token on Ethereum, BNB Chain and Solana are entirely dependent on those networks. Downtime, congestion or security vulnerabilities on any of them may impair transfers and trading of the relevant representation. Multi-network risk: the Token exists in four technical implementations. Any failure of the mechanism by which those implementations are backed or reconciled, or any discrepancy in supply between them, may affect the value and transferability of the Token. Human error: blockchain transactions are generally irreversible. Approving an incorrect transaction, or using the wrong network, address format or address, will most likely render funds permanently inaccessible. Smart-contract risk: the contracts governing the generation of the Token and its representations on other networks may contain bugs or vulnerabilities that could disrupt the generation or distribution of the Token. Connection and integration dependence: because trading the Token involves third-party venues, technical risks such as connection downtime, faulty code, platform outages or integration failures are possible. b. Regulatory and Compliance Risks This white paper has been prepared with due care; however, uncertainties in current regulatory requirements and future changes to regulatory frameworks could affect the legal status and tradability of the Token. There is a significant likelihood that additional laws may come into force, altering the rules for trading the Token. Such developments should be monitored and acted upon accordingly. c. Counterparty and Trading-Platform Risks Admission to trading involves reliance on third-party trading platforms and other intermediaries. Such entities may not operate to the highest standards. Events such as the failure of FTX demonstrate that, particularly in nascent industries, compliance and oversight frameworks may be incomplete or not fully enforced. Listing, suspension or delisting is subject to the internal processes and discretion of each trading platform, and delisting or refusal to list could harm or completely halt the ability to trade the Token. d. Failure of One or More Counterparties A further risk stems from the internal operational processes of the counterparties used. Beyond typical due diligence checks, there is no specific oversight guaranteeing that all counterparties adhere to best market standards. Counterparties could become insolvent, potentially resulting in a total loss of the assets held at that counterparty. e. Market and Liquidity Risks The Token is likely to be subject to high volatility and market speculation. Price fluctuations could be significant, posing a risk of substantial losses to holders. There is no guarantee that any trading platform will admit the Token to trading, that any secondary market will continue to exist, or that sufficient liquidity will be available. Liquidity depends on trading activity on decentralised and, where applicable, centralised platforms; low volumes may restrict the ability to buy or sell the Token and may result in high slippage. |
|||
| I.2 Issuer-related risks | textBlock | Crypto-assets and blockchain technologies operate within evolving and heterogeneous regulatory regimes worldwide. Requirements differ by jurisdiction and may change materially over time. Non-compliance may trigger investigations, enforcement actions, penalties, fines, sanctions, or suspension or prohibition of trading of the Token, affecting its viability and market acceptance. The Company could also face private litigation. Such developments would likely lead to changes in trading arrangements that may negatively affect the value, legality or functionality of the Token. b. Perimeter and Authorisation Risk The Protocol contemplates functionality, including wallet, swap, staking, launchpad and fiat functionality, which may constitute crypto-asset services within the meaning of Article 3(1)(16) of Regulation (EU) 2023/1114 depending on the operating flow ultimately implemented. If any group entity provides such a service to persons in the European Union without authorisation as a crypto-asset service provider, it would be in breach of Title V of that Regulation, with consequences for the entity concerned and potentially for the availability of the Protocol in the European Economic Area. c. Limited Operating History and Financial Condition Prospective holders should keep in mind that the Company is a young company with a limited operating history and no established record of profitable operations. It depends on external funding and on the continued involvement of the project's contributors in order to carry on its activities. There is no assurance that such funding will continue to be available, or that it will be available on acceptable terms. If it is not, the Company may be unable to maintain or further develop the Protocol, which may adversely affect the utility, liquidity and value of the Token. d. Key-Person and Governance Concentration The development and maintenance of the Protocol depend on a small number of individuals who hold specialised knowledge of the Chain and of its components. The Company regards those persons as important to the project and seeks to keep them involved for as long as possible. They may nevertheless cease to be involved at any time, and the Company cannot compel them to remain. Certain technical control and administrative functions in respect of the Chain and of the token-generation contracts are likewise concentrated in a limited number of persons. The departure of any such person, the loss of the knowledge held by them, disagreement between contributors, or the loss or compromise of the credentials held by them, may delay or prevent the development, maintenance and governance of the Protocol and may adversely affect the utility and value of the Token. e. Insolvency or Project Abandonment As with every other commercial endeavour, there is a risk of insolvency of the Company or of abandonment of the project. This could be caused by, but is not limited to, lack of interest from the public, lack of funding, incapacitation of key developers and project members, force majeure including pandemics and wars, or lack of commercial success or prospects. f. Competitive Ecosystem Numerous other crypto-asset projects operate in the same space, including other Layer-1 blockchains and other cross-chain interoperability protocols, which may adversely affect the project and the Token. Competition may reduce adoption, liquidity, validator participation or perceived usefulness. g. Counterparty Dependency In order to operate, the Company has most likely engaged in business relationships with one or more third parties on which it strongly depends, including infrastructure providers, wallet providers, trading platforms, auditors, legal advisers and technical contributors. The Protocol also depends on third-party decentralised exchanges and liquidity pools used by the generation mechanism and by the buyback-and-burn of the Token. Loss or changes in the leadership or key partners of the Company or of those counterparties can lead to disruptions, loss of trust or project failure. This could result in a total loss of economic value for holders of the Token. h. Reputational Risk Negative publicity, arising without limitation from operational failures, security incidents, regulatory scrutiny, failure to deliver roadmap items or association, actual or perceived, with illicit activity, can damage the reputation of the Company and, in turn, the acceptance and value of the Token. i. Operational and Residual Risks Failure to develop or maintain effective internal controls, operational processes or public communications, or any difficulties encountered in implementing or improving such controls, could harm the business of the Company, causing disruptions, financial losses or reputational damage. In addition to the risks included in this section, there may be other risks that cannot be foreseen, and additional risks may materialise as unanticipated variations or combinations of the risks discussed. |
|||
| I.3 Other tokens-related risks | textBlock | Crypto-asset prices can swing sharply, driven by sentiment, regulatory shifts, technological changes and macroeconomic conditions. Losses can occur over very short periods. This is especially true for assets without intrinsic value; holders should be prepared to lose the entire amount invested. b. Valuation and No Intrinsic Financial Value Because the Token has no intrinsic value and confers no ownership, financial, redemption, revenue-sharing or guaranteed economic rights, pricing is determined solely by supply and demand. Historically, many crypto-assets have experienced severe drawdowns and often did not produce net positive outcomes for acquirers of utility tokens. Acquisition therefore carries a high risk of partial or total loss. c. Supply and Generation Mechanics The circulating supply of the Token increases over time through the generation mechanism described in Section G.13, out of the supply issued at genesis. The maximum supply of the Token is capped at 8,888,888,888 CTM. The entire supply was issued at genesis, the inflation rate of the Chain is zero and no further units of the Token can be minted. If, contrary to the foregoing, further units were able to be issued beyond the stated maximum, holders would be exposed to dilution that this white paper does not quantify. Approximately half of the maximum supply is allocated to a Genesis Allocation whose holders, controllers and lock-up terms are not disclosed. Concentration of that allocation, or its release onto the market, may materially affect price. Holders should not assume that any burn mechanism will support price. d. Liquidity Constraints Liquidity may be limited. Limited liquidity can present difficulties when executing large trades without significantly affecting market prices, and can lead to substantial losses, particularly during periods of rapid market movement when selling may become difficult or require accepting unfavourable prices. The liquidity pools on which the generation mechanism and the mechanisms described in Section G.13 depend may be shallow. e. Asset Security and Private-Key Risk Crypto-assets face security threats, including theft from trading platforms or digital wallets, loss of private keys and failures of custodial services. Since transactions are generally irreversible, a security breach or mismanagement can result in the permanent loss of assets. f. Scams and Fake Tokens The irrevocability of blockchain transactions and the pseudonymous nature of blockchain ecosystems attract fraudsters. Typical scams include the creation of fake crypto-assets with the same name or ticker, phishing on social networks or by e-mail, fake giveaways and airdrops, and identity theft. The risk is heightened where a token exists on several networks, because a holder may be induced to acquire a counterfeit contract on a network where the genuine contract also exists. Holders should verify contract addresses only through the official sources of the Protocol and the relevant digital token identifier (DTI) records referred to in Section H.1, as contract addresses may change. g. Native Blockchain Dependency and Cross-Chain Representation Risk Any defect, outage, congestion, protocol bug, chain reorganisation, validator failure or security incident affecting the Chain may impair transferability, staking or trading of the native Token. In addition, the Token exists as separate token contracts on Ethereum, BNB Chain and Solana. If those representations are backed by a bridge, lock or custodial mechanism, holders are exposed to the failure, exploitation or misuse of that mechanism, which is one of the most frequent causes of loss in cross-chain designs. h. Proof-of-Stake and Network-Security Risks As a proof-of-stake network using CometBFT consensus, the Chain is exposed to validator concentration, insufficient bonded stake, coordinated action by validators representing more than one third of voting power, which can halt the Chain, and coordinated action by validators representing more than two thirds of voting power, which can finalise invalid state. Delegated Tokens are subject to slashing of 1 per cent for validator downtime and 5 per cent for double-signing, and to an unbonding period of 44 days during which they cannot be transferred. The active set holds up to 88 validators; the current number of validators is not published. i. Protocol Control and Centralisation Risk The Chain includes a circuit breaker that allows whitelisted accounts to reject all transactions, a breaker that allows whitelisted accounts to block outbound Inter-Blockchain Communication transfers, a rate limiter that allows whitelisted operators to cap cross-chain throughput, and a validator-rewards module that allows whitelisted accounts to change reward parameters and pause rewards. In addition, the applicable issuance price is set at protocol level or, in the audited implementation, by the contract administrator; and the administrator of the token-generation contracts can pause the contracts, set the referral and liquidity percentages, withdraw vault proceeds and add addresses to an irreversible blacklist, and a backend verifier key must sign each generation request. The holders of those privileges are not disclosed. The Protocol cannot be described as fully decentralised, and prospective holders should not assume that it is. j. Smart-Contract and Cross-Chain Vulnerabilities The contracts and programs used to issue, generate and distribute the Token, and the cross-chain infrastructure of the Chain, may contain bugs, coding errors or vulnerabilities which could be exploited, potentially leading to asset loss or unintended operational consequences. Only the Solana generation program has been audited; the Chain, its modules, its precompiles and the Ethereum and BNB Chain contracts have not. k. Cryptographic and Implementation Risks The Chain relies on elliptic-curve cryptography, on zero-knowledge proof verification and on post-quantum signature verification precompiles. These may contain design flaws, implementation bugs, incorrect assumptions or vulnerabilities. Descriptions such as post-quantum should not be understood as guarantees of immunity from future cryptographic developments or implementation failures. l. Privacy Concerns All transactions on the Chain and on the other supported networks are permanently recorded and publicly accessible. Although addresses are pseudonymous, the transparent and immutable nature of the ledger allows advanced forensic analysis, which can make it possible to link addresses to real-world identities over time. m. Regulatory Uncertainty The regulatory environment surrounding crypto-assets is constantly evolving, which can directly affect their use, valuation and legal status. Changes in regulatory frameworks may introduce new requirements relating to consumer protection, taxation and anti-money-laundering compliance. Although the Token does not create or confer any contractual or other obligations on any party, certain regulators may nevertheless qualify it as a security or other financial instrument under their applicable law, which would have drastic consequences, including the potential loss of the capital invested. This could also lead to the Company and its affiliates, directors and officers being obliged to pay fines, including civil and criminal penalties, or make the Token illegal or impossible to use, buy or sell in certain jurisdictions. Regulators could also take action against the Company and the trading platforms if they view the Token as an unregistered offering of securities. Any of these outcomes would negatively affect the value or functionality of the Token and could cause a complete loss of funds. n. Counterparty Risk Entering into agreements or storing crypto-assets on trading platforms introduces counterparty risk, including the failure of the other party to perform. Holders may face losses due to insolvency, regulatory non-compliance or fraudulent activity by counterparties. The Protocol's treasury is itself exposed to the third-party decentralised exchanges and liquidity pools through which the buyback-and-burn and the genera |
|||
| I.4 Project implementation-related risks | textBlock | From the project side, the delivery of the intended utility of the Token depends on the successful development, deployment, operation and maintenance of the Chain and of the wider Protocol. The mainnet is at beta stage and is designated "Mainnet Beta". Roadmap features may be delayed, modified, scaled back, discontinued or never implemented. In particular, the Bridgeless Protocol (targeted for public release in Q4 2026), the ongoing rollout of the SuperApp product layer, the expansion of cross-chain functionality and liquidity, and the additional staking, trading, developer-tooling and ecosystem participation and incentive mechanisms referred to in Section D.8 are not guaranteed to be implemented in any particular form or timeframe. At protocol level, certain further components are described conceptually only, without any published interface, and hosted data-indexing and price-data services are not yet available. The architecture of the Chain comprises CometBFT consensus and Inter-Blockchain Communication with light-client verification. Earlier descriptions have been superseded, and holders should not rely on any such earlier description, including any copy of it that may remain accessible from third-party sources, as a description of current or planned features of the Protocol. Only the Solana token-generation program has been independently audited. No audit of the Chain, its modules, its precompiles or the Token contracts on Ethereum and BNB Chain has been made public, and no public bug-bounty programme has been identified. If the intended utility is not delivered, or is delivered only in part, the usability, adoption and value of the Token may be materially and adversely affected, and holders have no right to compensation, redemption or refund as a result. |
|||
| I.5 Technology-related risks | textBlock | Despite best efforts to enhance security, the technological components supporting the Token, including the Chain, its node and remote procedure call infrastructure, the token-generation contracts and programs, the contracts on the other supported networks and holders' wallets, may be vulnerable to cyberattacks, malware, phishing, denial-of-service attacks and exploitation of vulnerabilities. b. Chain Dependency The native Token depends on the Chain. Outages, congestion, protocol failure, chain reorganisations, insufficient validator participation, or security incidents may interrupt transfers, staking, trading or other functions. Bootstrap metadata, including the genesis file, peer list and release binaries, is served from a single project-controlled domain, which is a single point of failure for node operators. c. Proof-of-Stake and Validator Risks The Chain may face proof-of-stake-specific risks, including validator concentration, insufficient bonded stake, liveness failure where validators representing more than one third of voting power are unavailable or act in concert, finalisation of invalid state where validators representing more than two thirds of voting power act in concert, slashing and jailing of validators to which a holder has delegated, and correlated failure where many validators use the same infrastructure provider. d. Protocol Control Risks The circuit breaker, Inter-Blockchain Communication breaker, Inter-Blockchain Communication rate limiter and validator-rewards controls described in Section H.7 can be operated by whitelisted accounts. Compromise, misuse or error in the use of those accounts could halt the Chain, block outbound cross-chain transfers, cap cross-chain throughput or alter or pause validator rewards. Compromise of the administrator or verifier keys of the token-generation contracts could allow unauthorised generation, mispricing, withdrawal of vault proceeds or irreversible blacklisting of addresses. e. Cross-Chain and Interoperability Risks Cross-chain functionality relies on light-client verification, packet relay by off-chain actors and, on other networks, on the mechanism by which the representations of the Token are backed. Light-client bugs, incorrect proofs, relayer unavailability, packet timeouts and failures of any bridge, lock or custodial mechanism may delay or prevent transfers, or in the worst case result in loss of assets or in the supply of the Token becoming unreconciled across networks. f. Smart-Contract, Precompile and Data-Account Risks The smart contracts, precompiles and data accounts used to issue, generate and distribute the Token could contain bugs, coding errors or vulnerabilities which may be exploited. In addition, the audited Solana token-generation program contains no replay protection, so that a signed request to generate Tokens may be re-used until it expires, and the price used by that program is taken from a single external liquidity pool and may be manipulated. Both findings were accepted by the project rather than remediated, as described in Section H.9. g. Wallet and Storage Risks Holders must securely manage private keys, recovery information and compatible wallets. The Chain uses two different address representations, so that a holder using the wrong address format may be unable to access funds. Holders of the representations on Ethereum, BNB Chain and Solana require wallets compatible with the relevant network and standard. Incompatibility, incorrect address formats, software bugs or loss of keys may result in permanent loss of the Token. h. Dependency on Third-Party Liquidity Infrastructure The generation mechanism and the treasury mechanisms rely on third-party decentralised exchanges and liquidity pools, and the audited implementation derives the price of the counter-asset from a single third-party pool. Liquidity shortages, outages or price manipulation on that infrastructure may affect the generation price, the treasury and the value of the Token. i. Network Security and Evolving Technology The Chain and the other supported networks may face threats such as denial-of-service attacks or exploits targeting their consensus mechanisms, which could compromise network integrity. The fast pace of innovation in blockchain technology may make the underlying standards or networks less competitive or outdated, potentially affecting the usability or adoption of the Token. Throughput and scalability constraints, including the computational overhead associated with the generation and verification of zero-knowledge proofs, may also limit transaction capacity, increase transaction costs or delay cross-chain operations as usage grows. j. Open-Source Fork Risk The software of the Chain is open-source under the Apache 2.0 licence. The Company cannot technically prevent third parties from forking the software or the network. Forks may confuse holders, dilute community attention or create competing versions of the network. |
|||
| I.6 Mitigation measures | textBlock | The Chain is built on and extends the Cosmos EVM stack and uses CometBFT consensus, the Cosmos SDK and go-ethereum components that are widely deployed and reviewed, and the contracts pre-deployed at genesis are stated to be identical or bytecode-equivalent to widely used deployments on Ethereum and major rollups. On the other supported networks, the Token uses the established ERC-20, BEP-20 and SPL standards. Relying on established components is intended to reduce, but cannot eliminate, the likelihood of undiscovered bugs or vulnerabilities. b. Protocol-level safety controls The circuit breaker, the Inter-Blockchain Communication breaker and the Inter-Blockchain Communication rate limiter are intended to allow the network to be protected against an ongoing incident, and the chain-enforced minimum self-delegation and the slashing parameters are intended to align validator incentives with network security. These controls are risk-reduction measures only. They are themselves a centralisation and misuse risk, as described in Sections I.3 and I.5, and the accounts entitled to operate them are not currently disclosed. c. Verified distribution of node software The deployment script verifies the SHA-256 checksum of the node binary and of the mainnet genesis file before installation, which reduces the risk of a tampered binary or genesis being adopted. All bootstrap metadata is nevertheless served from a single project-controlled domain. d. Independent audit of the token-generation program Hacken completed a smart contract code review of the Solana token-generation, liquidity-provisioning and referral program, with a final report dated 3 April 2025. The Critical finding was fixed. Four findings, including the single-source pricing of the counter-asset, the absence of a replay nonce and the absence of any function to remove an address from the blacklist, were accepted rather than remediated. The audit did not cover the Chain, its modules, its precompiles or the Token contracts on Ethereum and BNB Chain. No assurance can be given in respect of components that have not been audited. e. Multi-network availability The Token is available on the Chain and on three third-party networks, which may support broader technical availability. That structure also introduces network-specific risks. The Company does not control the underlying third-party networks, their validators, sequencers, fees, upgrades, outages or security models. f. Supply discipline EIP-1559 transaction fees are burned in full on every transaction on the Chain, and Tokens acquired by the protocol treasury under the buyback-and-burn mechanism are permanently removed from supply. These mechanisms may reduce the circulating supply but do not guarantee price stability, liquidity or market demand. The maximum supply of the Token is capped at 8,888,888,888 CTM. g. Vesting and lock-ups for insider allocations No cliff, lock-up or vesting arrangements applicable to the Genesis Allocation or to any insider allocation have been disclosed. Where such arrangements exist, they are intended to align the interests of the persons concerned with the longer-term development of the Protocol and to reduce the risk that a significant volume of Tokens reaches the market over a short period; but, in the absence of any disclosed arrangement, this mitigation cannot be relied upon, and the concentration and release of insider allocations remains a risk as described in Section I.3. No commitment is made as to the price, liquidity or market value of the Token. h. Transparency and communication The project maintains public technical documentation, a public source repository, a block explorer for mainnet and testnet with source verification, and public community channels through which protocol upgrades and material changes are expected to be announced. A vulnerability-disclosure address is published for security reports. Such communication is provided on a best-efforts basis and does not guarantee any particular outcome, price, level of utility, reward, liquidity or continued availability of any functionality. i. Planned further assurance Security review is treated as an ongoing process rather than a single exercise. The auditor of the token-generation program recommended that further independent audits be carried out and that a public bug-bounty programme be established, and further independent review of components not yet examined is anticipated as the Protocol develops. Any such review is a risk-reduction measure only. Until it has been completed, no assurance can be given in respect of components that have not been audited. j. Limitations The measures described above are intended to reduce risk only. They do not remove the risks described in this white paper, do not constitute any warranty, guarantee or commitment by the Company or any affiliated entity, and do not create any right to compensation, redemption, refund, reward, revenue sharing or value maintenance. |
|||
| Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts | |||||
| J.1 Adverse impacts on climate and other environment-related adverse impacts | textBlock | The c8ntinuum network, being the home network of the Token, uses CometBFT Byzantine fault tolerant proof-of-stake consensus, with an expected block time of four seconds and single-block finality. The Chain does not use proof-of-work. Consensus is carried out by an active validator set of up to 88 validators, each bonding at least 888,888 CTM by way of self-delegation, so that network security derives from bonded stake rather than from competitive computation. Accordingly, the energy consumption associated with the validation of transactions in the Token does not scale with hashing power and is limited to the operation of validator, full, sentry and RPC nodes running on standard server-class hardware in accordance with the published hardware requirements of the network. The representations of the Token on Ethereum, BNB Chain and Solana do not operate a separate consensus mechanism. Transactions in those representations are validated and settled by the consensus mechanism of the relevant underlying network, being proof-of-stake on Ethereum, proof-of-staked-authority on BNB Chain and a combination of proof of history and proof of stake on Solana. None of those networks uses proof-of-work, and each therefore presents a substantially lower emissions profile than legacy proof-of-work systems. The design features of the Chain that limit its environmental footprint are inherent in its architecture rather than the result of a dedicated mitigation programme. They comprise the use of stake-based consensus in place of mining, a bounded active validator set, single-block finality which avoids the redundant computation associated with probabilistic confirmation, and an EIP-1559-style fee market under which transaction fees are burned in full, which discourages unnecessary transaction volume. Network nodes may be operated by independent third parties, who select their own hosting arrangements and electricity supply. The Company does not operate or control all network nodes and therefore does not control the electricity sources used across the entire network. The Company does not operate a formal carbon-neutrality, offsetting or renewable-energy procurement programme in respect of the network, and does not currently publish quantified energy or greenhouse gas reduction targets. The Company has estimated the annual energy consumption of the network on the basis described in Section S.9 and intends to keep the hardware requirements and node architecture of the network under review as the network develops. Prospective holders should note that the estimated annual energy consumption disclosed in Section S.8 reflects the energy consumption attributable to the Token across the distributed ledger networks on which it is issued, including the native c8ntinuum network and the relevant attributable share of the Ethereum, BNB Chain and Solana networks. It does not include energy consumption associated with wallets, trading platforms or other intermediaries used by holders. The environmental information disclosed is based on information provided by the c8ntinuum technical team, on the published network architecture, consensus parameters and node hardware requirements of the Chain, and on publicly available energy-efficiency analyses of proof-of-stake distributed ledgers. Estimates have been used in accordance with Article 6(7) of Commission Delegated Regulation (EU) 2025/422. |
|||
| Mandatory information on principal adverse impacts on the climate and other environment-related adverse impacts of the consensus mechanism | |||||
| General information about adverse impacts | |||||
| S.1 Name | text | ||||
| S.2 Relevant legal entity identifier | text | ||||
| S.3 Name of the crypto-asset | text | ||||
| S.4 Consensus mechanism | text | ||||
| S.5 Incentive mechanisms and applicable fees | text | ||||
| S.6 Beginning of period to which disclosed information relates | date | ||||
| S.7 End of period to which disclosed information relates | date | ||||
| Mandatory key indicator | |||||
| S.8 Energy consumption | energy (kWh) | ||||
| Sources and methodologies | |||||
| S.9 Energy consumption sources and methodologies | textBlock | The figure represents estimated annual electricity consumption. The use of estimates and reasonable assumptions is made in accordance with Article 6(7) of Commission Delegated Regulation (EU) 2025/422. The methodological approach was also reviewed against the publicly available MiCA Crypto Alliance framework for the calculation of sustainability indicators under MiCA. No external sustainability data provider or independent third-party verification was used. |
|||
| 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 | percent | ||||
| S.11 Energy intensity | energy (kWh) | ||||
| S.12 Scope 1 DLT GHG emissions - controlled | GHG emissions (tCO2e) | ||||
| S.13 Scope 2 DLT GHG emissions - purchased | GHG emissions (tCO2e) | ||||
| S.14 GHG intensity | GHG emissions (tCO2e) | ||||
| Sources and methodologies | |||||
| S.15 Key energy sources and methodologies | textBlock | ||||
| S.16 Key GHG sources and methodologies | textBlock | ||||
| 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 | percent | ||||
| S.18 Energy use reduction | |||||
| Energy use reduction target (absolute value) | energy (kWh) | ||||
| Energy use reduction target (percentage) | percent | ||||
| S.19 Carbon intensity (kgCO2e/kWh) | decimal | ||||
| S.20 Scope 3 DLT GHG emissions - value chain | GHG emissions (tCO2e) | ||||
| S.21 GHG emissions reduction targets or commitments | textBlock | ||||
| S.22 Generation of waste electrical and electronic equipment (WEEE) | mass (tonnes) | ||||
| S.23 Non-recycled WEEE ratio | percent | ||||
| S.24 Generation of hazardous waste | mass (tonnes) | ||||
| S.25 Generation of waste (all types) | mass (tonnes) | ||||
| S.26 Non-recycled waste ratio (all types) | percent | ||||
| S.27 Waste intensity (all types) | mass (tonnes) | ||||
| S.28 Waste reduction targets or commitments (all types) | textBlock | ||||
| S.29 Impact of use of equipment on natural resources | textBlock | ||||
| S.30 Natural resources use reduction targets or commitments | textBlock | ||||
| S.31 Water use | volume (m3) | ||||
| S.32 Non recycled water ratio | percent | ||||
| Sources and methodologies | |||||
| S.33 Other energy sources and methodologies | textBlock | ||||
| S.34 Other GHG sources and methodologies | textBlock | ||||
| S.35 Waste sources and methodologies | textBlock | ||||
| S.36 Natural resources sources and methodologies | textBlock | ||||