| [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 | a. BLUAI is transferable on-chain, subject to applicable law, technical network functionality, wallet compatibility and any trading-platform rules and fees. The admission to trading occurs on independent platforms that the issuer does not operate or control. b. BLUAI is fungible within each supported implementation, as each unit on the same network is identical and interchangeable. The BLUAI implementations across the supported networks are treated as functionally fungible versions of the same crypto-asset. c. BLUAI is non-interest bearing and holders bear applicable network fees, including gas fees or equivalent transaction fees, when transferring or otherwise using BLUAI on the relevant supported networks. Technical parameters of the underlying networks may change over time. d. BLUAI is intended to provide access to certain features, services and functionalities of the Bluwhale AI ecosystem, including AI/data services, automation and analytics tools, ecosystem-level gas, access or fee mechanisms for AI queries and agent/tool invocation, node-related services, verifier-node participation, infrastructure-access mechanisms and, where implemented, Agent App Store, marketplace or proprietary infrastructure functionalities. Such utility is operational and ecosystem-specific and does not constitute a financial, ownership, redemption, profit-participation or revenue-sharing right. e. 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 BLUAI, if any, is determined by supply and demand on the relevant trading platforms and markets. f. BLUAI is non-refundable and 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 issuer or any affiliate. g. Holding BLUAI does not grant any rights in or to the issuer 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 Bluwhale Foundation, its affiliates or their service providers. h. Any governance, voting, signalling or community-participation functionality associated with BLUAI is limited to protocol-level or ecosystem-related matters and does not constitute corporate governance over the Bluwhale Foundation or any affiliated entity. It does not confer control over the issuer, its management, treasury, revenues or assets. i. BLUAI does not represent a loan to, or debt of, the issuer or any of its affiliates; it is not intended to represent indebtedness, and there is no expectation of profit or interest. j. BLUAI 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. BLUAI 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. BLUAI is not an asset-referenced token or 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 issuer or its affiliates; and it uses no stabilisation mechanism, whether algorithmic or otherwise. |
|||
| 09 Further information about utility tokens | textBlock | The main utilities of BLUAI are the following: AI and Data Services: BLUAI may be used as an access, gas or ecosystem-level fee mechanism for AI-powered data processing, automation, analytics, AI queries, interaction with the AI intelligence layer, invocation of AI agents, tools or workflows and similar digital services made available within the Bluwhale AI ecosystem. These services may include the processing of user-permissioned financial, wallet or similar data and privacy-preserving data workflows, where such functionalities are implemented and available. The availability, quantity and quality of access may depend on the relevant application, product tier, technical capacity, network availability, eligibility requirements and the rules applicable to the relevant functionality from time to time. Agent App Store and Developer Economy: Where implemented, BLUAI may be used in connection with an Agent App Store or similar marketplace functionality, allowing developers or creators to publish AI agents, workflows, tools or applications and monetise actual usage through per-use fees, subscriptions, performance-based fees or other programme-based mechanisms. Any such monetisation depends on actual use, invocation or applicable programme rules and does not arise merely from holding BLUAI. Node and Network Services: BLUAI may be used in connection with node-related functionalities, including registration, activation, delegation, participation or interaction with node infrastructure, where such functionalities are made available within the ecosystem. Node-related services may include verifier-node functionality, including Master Nodes and Common Nodes, verification of Trusted Execution Environment attestations and other activity intended to support data integrity, reliability, availability, accuracy and privacy-preserving compute for AI processing and inference. Node-related incentives, where available, are intended to reward or support active and useful participation in the network and do not arise merely from passive holding of BLUAI. Infrastructure Access: BLUAI may be used in connection with infrastructure-access mechanisms within the Bluwhale AI ecosystem, including access to technical features related to data queries, automation tasks, analytics workflows, compute, storage, bandwidth, network resources and other ecosystem functionalities made available from time to time. The exact access mechanism may depend on the relevant application, interface, smart contract, technical infrastructure or ecosystem rule in force at the relevant time. Ecosystem Incentives and Contribution Programmes: BLUAI may be used in connection with ecosystem incentives, community participation, grants, developer support, user adoption initiatives and other programmes intended to support the development, security and availability of the Bluwhale AI ecosystem. Any incentives or rewards are usage-based or activity-based, including where applicable data contributions, agent invocations, node verification jobs, compute, storage or other verifiable ecosystem contributions. Such incentives are subject to applicable programme rules, technical availability and eligibility requirements, and do not create any claim to protocol revenues, issuer revenues, foundation assets or any minimum level of reward. Proprietary Infrastructure and Governance: The Bluwhale AI roadmap includes the development of proprietary technical infrastructure, including a potential roll-up or similar infrastructure layer. If and when implemented, BLUAI may be used in connection with access, participation, fees, node-related functionality, infrastructure use or other technical functions connected with that infrastructure. Any governance, voting, signalling or community-participation functionality associated with BLUAI is limited to protocol-level or ecosystem-related matters, such as technical parameters, fee schedules, supported data sources, oracle sources, application rules, marketplace parameters or node and verification parameters. It does not constitute corporate governance over the Bluwhale Foundation or any affiliated entity and does not confer control over the issuer, its management, treasury, revenues or assets. Restrictions on Transferability: BLUAI is generally transferable on the supported networks, subject to applicable law, network functionality, wallet compatibility and the rules of the relevant trading platforms. Trading platforms may impose KYC, AML, CFT, sanctions, jurisdictional or other access restrictions in accordance with applicable law and their internal policies. Temporary technical transfer restrictions may also apply where BLUAI is committed to a smart contract, used for access to ecosystem services or otherwise subject to application-specific rules. |
|||
| 10 Key information about the offer to the public or admission to trading | textBlock | ||||
| 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 | Cayman Islands KY1-1206 |
|||
| Country | enumeration | ||||
| Sub-division | text | ||||
| A.4 Head office | |||||
| Head office | text | Cayman Islands KY1-1206 |
|||
| 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 | ||||
| Member #3 | id | 3 | |||
| Identity | text | ||||
| Business address | text | ||||
| Function | text | ||||
| A.13 Business activity | textBlock | ||||
| 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 | As at the date of this white paper, the Foundation is not aware of any material outstanding liabilities, debts or financial commitments that would materially affect its current activities as described in section A.13. The above information is provided for disclosure purposes only and should not be read as a guarantee of future revenue, profitability, liquidity or ability to fund future development. The Foundation's financial condition may be affected by market, regulatory, technical and operational factors, including the risk factors described in this white paper. |
|||
| 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 | The project is structured around decentralised network participation, technical infrastructure development, ecosystem contribution mechanisms and long-term support for the growth and security of the Bluwhale AI ecosystem. Core project components include AI/data services, automation and analytics tools, agent and workflow functionality, node participation, verifier-node infrastructure, ecosystem incentives, technical integrations, security measures, grants and treasury-supported development. The ecosystem may also include, where implemented, an Agent App Store or similar marketplace through which developers and creators can publish AI agents, workflows, tools or applications and receive usage-based fees, subscription fees, performance-based fees or programme-based compensation when such agents or tools are actually used. Node-related functionality may include verifier nodes, including Master Nodes and Common Nodes, supporting data integrity, Trusted Execution Environment attestation verification, availability, accuracy and privacy-preserving compute for AI-related services. The scope, timing and availability of the project's functionalities depend on technical implementation, regulatory developments, market adoption and other operational factors. Future developments cannot be guaranteed, and the practical role, availability and impact of BLUAI within the ecosystem may evolve over time. |
|||
| 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 | ||||
| Person #4 | id | 4 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | Floor Whitehall House, 238 North Church Street, George Town, Cayman Islands KY1-1206 |
|||
| Domicile of company | enumeration | ||||
| Person #5 | id | 5 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | Floor Whitehall House, 238 North Church Street, George Town, Cayman Islands KY1-1206 |
|||
| 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 BLUAI gives access are the following: a. AI and data services: BLUAI may be used as an access, gas or ecosystem-level fee mechanism for AI-powered data processing, automation, analytics, AI queries, interaction with the AI intelligence layer, invocation of AI agents, tools or workflows and similar digital services available through the Bluwhale AI ecosystem. These services are intended to support users in processing data, automating workflows and interacting with AI-enabled infrastructure, including user-permissioned financial, wallet or similar data and privacy-preserving workflows where implemented. b. Node and network services: BLUAI may be used to access node-related functionalities, including registration, activation, delegation, participation or interaction with node infrastructure, where such functionalities are made available within the ecosystem. Node-related services may include verifier-node functionality, including Master Nodes and Common Nodes, validation of Trusted Execution Environment attestations and other activity intended to support data integrity, network availability, reliability, accuracy and privacy-preserving compute for AI processing and inference. c. Infrastructure and resource-access services: BLUAI may be used as an access or coordination mechanism for infrastructure resources, including compute, bandwidth, storage, data queries, automation tasks, analytics workflows, agent invocations and other technical resources made available through the Bluwhale AI ecosystem. d. Agent App Store and ecosystem application features: BLUAI may be used to access application features, user tiers, premium functionalities, priority access, community programmes, agent marketplace features or other facilities integrated into Bluwhale AI applications. Where implemented, developers and creators may publish AI agents, workflows, tools or applications and monetise actual usage through per-use fees, subscriptions, performance-based fees or other programme-based mechanisms. e. Ecosystem incentives: BLUAI may be used in connection with ecosystem incentive mechanisms, node participation, community programmes, grants, developer support, user adoption initiatives and other technical or operational mechanisms designed to support the development, security and availability of the Bluwhale AI ecosystem. Any rewards or incentives are usage-based or activity-based, subject to programme rules, eligibility requirements and technical availability, and do not arise merely from passive holding of BLUAI. f. Proprietary infrastructure features: BLUAI may be used in connection with any proprietary infrastructure layer, roll-up or similar technical component developed or supported by the Bluwhale AI ecosystem, including for access, registration, fees, node participation, resource allocation or other technical functions connected with that infrastructure. Access may require holders to hold, spend, lock, stake, delegate or otherwise commit BLUAI, depending on the relevant service, application, smart contract or ecosystem rule. The quantity and quality of access may vary according to the amount of BLUAI used or committed, the applicable product tier, service availability, technical capacity, network conditions and the rules of the relevant functionality. BLUAI does not give holders ownership rights, profit participation, redemption rights, creditor rights, revenue-sharing rights, rights to issuer assets or corporate governance rights in relation to the Bluwhale Foundation or any affiliated entity. |
|||
| D.8 Plans for the token | |||||
| Description of past milestones | textBlock | 2024-2025 — Development of the Bluwhale AI infrastructure model: Bluwhale AI developed its core architecture as an AI-driven decentralised infrastructure ecosystem designed to support data processing, automation, analytics, AI intelligence-layer interactions, network-efficiency applications and node participation. This phase included the structuring of the main ecosystem components, including AI/data services, agent and workflow functionality, node participation, community contribution mechanisms and foundation treasury support for ongoing development and grants. Multi-chain BLUAI deployment and tokenomics finalisation 2025 — BLUAI token deployment and tokenomics finalisation: BLUAI was technically deployed across Ethereum, Solana, Arbitrum, BNB Smart Chain, Base and SUI, with a fixed maximum supply of 10,000,000,000 BLUAI. The project also established the main allocation categories, including nodes / network security, foundation and treasury, ecosystem development, team and advisors, airdrops, fundraising rounds, liquidity and market-making. DTI / FFG identification and multi-network token mapping 2025 — DTI / FFG identification: BLUAI was identified in the Digital Token Identifier framework, including through the Functionally Fungible Group Digital Token Identifier CSVDS945S. This milestone supports the treatment of BLUAI as one economic crypto-asset across its multiple technical implementations on the supported networks. |
|||
| Description of future milestones | textBlock | 2026 — Admission-to-trading process: Bluwhale Foundation is seeking admission to trading of BLUAI on Payward Global Solutions Limited (Kraken), with additional trading platforms not excluded in the future. This process is intended to support compliant market access, broader token circulation and accessibility for prospective ecosystem participants, including users, developers, node operators, data contributors and agent creators. Expansion of BLUAI utility and Agent App Store functionality 2026 — Expansion of BLUAI utility and ecosystem functionalities: the project is continuing to develop and implement BLUAI-related ecosystem functionalities, including AI/data services, automation and analytics tools, AI queries, agent and workflow invocation, Agent App Store or marketplace functionality, node-related services, ecosystem incentives and infrastructure-access mechanisms. The timing, scope and availability of these functionalities remain subject to technical, commercial, legal and regulatory developments. Verifier-node and privacy-preserving infrastructure development 2026-2027 — Development of verifier-node and privacy-preserving infrastructure: the project is continuing to develop node-related infrastructure, including verifier-node functionality, Master Nodes and Common Nodes, Trusted Execution Environment attestation verification and privacy-preserving data or compute mechanisms, where implemented. This work is intended to support reliability, availability, accuracy and data integrity within the Bluwhale AI ecosystem. Proprietary infrastructure and roll-up development 2026-2027 — Development of proprietary infrastructure: the project is continuing to develop proprietary technical infrastructure, including a potential roll-up or similar infrastructure layer. This work is intended to support the scalability, efficiency and technical development of the Bluwhale AI ecosystem, although the timing, scope and final impact of such infrastructure remain subject to technical, commercial, legal and regulatory developments. |
|||
| D.9 Resource allocation | text | Foundation and treasury: 21.00%; Ecosystem: 8.80%; Team and advisors: 7.00%; Initial airdrop: 6.00%; Future airdrops: 1.00%; Exchange marketing: 2.00%; Partner marketing: 1.00%; Affiliate marketing: 0.20%; Seed round: 9.16%; Private A round: 6.57%; Pre-seed round: 4.28%; Public sale: 2.00%; KOL round: 1.00%; Liquidity: 3.00%; Market-making: 2.00%. |
|||
| D.10 Planned use of collected funds or other tokens | text | The admission of BLUAI to trading aims to promote circulation and distribution of the token among potential ecosystem participants, including users, developers, agent creators, node operators, data contributors and other persons seeking to access or participate in Bluwhale AI's AI-driven decentralised infrastructure, data processing, automation, analytics, agent, node and network-efficiency functionalities. Admission to secondary-market trading is also intended to enhance the accessibility and potential liquidity of BLUAI, without any guarantee of trading volume, price stability, market demand, ecosystem adoption or token value. |
|||
| 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 | The admission of BLUAI to trading aims to promote circulation and distribution of the token among potential ecosystem participants, including users, developers, node participants and other persons seeking to access or participate in Bluwhale AI's AI-driven decentralised infrastructure, data processing, automation, analytics and network-efficiency functionalities. Admission to secondary-market trading is also intended to enhance the accessibility and potential liquidity of BLUAI, without any guarantee of trading volume, price stability or market demand. |
|||
| E.3 Fundraising target | |||||
| Target expressed in currency | monetary | EUR | |||
| Target expressed in units | decimal | ||||
| Target expressed in digital token identifier | text | ||||
| E.4 Minimum subscription goals | |||||
| Goals expressed in currency | monetary | EUR | |||
| Goals expressed in units | decimal | ||||
| Goals expressed in digital token identifier | text | ||||
| E.5 Maximum subscription goals | |||||
| Goasl expressed in currency | monetary | EUR | |||
| 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 | EUR | |||
| 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. Having reliable access to internet; b. Using a suitable device (computer or mobile) to manage their digital wallet, private keys, and/or trading platform account in order to execute transactions; c. If listed on a centralised exchange (CEX), holders must open an exchange account, complete the platform's onboarding/ KYC; and d. If traded on a decentralised exchange (DEX) operating on any of the supported networks (Ethereum, Arbitrum, Solana, BNB Smart Chain, Base or SUI), holders need a compatible self-custodial wallet that supports the relevant network and holds sufficient funds to cover transaction fees. |
|||
| Other token services provider characteristics | |||||
| E.30 Other token service provider (CASP) name | text | Kraken (Payward Global Solutions LTD): MIC – PGSL |
|||
| 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 | Kraken (Payward Global Solutions LTD): MIC – PGSL LEI: 9845003D98SCC2851458 |
|||
| E.35 Trading platforms access | text | ||||
| E.36 Involved costs | textBlock | These fees are determined and set solely by the trading platforms and are not controlled, influenced, or governed by the Bluwhale Foundation. All on-chain transactions involving BLUAI are subject to network transaction fees ("gas fees"). |
|||
| E.37 Offer expenses | textBlock | ||||
| E.38 Conflicts of interest | textBlock | ||||
| E.39 Applicable law | textBlock | The United Nations Convention on Contracts for the International Sale of Goods (CISG) is expressly excluded and shall not apply. |
|||
| E.40 Competent court | textBlock | ||||
| Part F - Information about other tokens | |||||
| F.1 Crypto-asset type | text | ||||
| F.2 Other token functionality | textBlock | BLUAI may also be used in connection with verifier-node participation, including Master Nodes and Common Nodes, Trusted Execution Environment attestation verification, ecosystem incentives, community participation, grants and other technical or operational mechanisms designed to support the security, availability, accuracy and development of the Bluwhale AI network. Where technically implemented in the relevant application or protocol layer, BLUAI may also be used through holding, spending, staking, locking, delegation or similar mechanisms. Where implemented, BLUAI may be used in connection with an Agent App Store or similar marketplace functionality, allowing developers or creators to publish AI agents, workflows, tools or applications and monetise actual usage through per-use fees, subscriptions, performance-based fees or other programme-based mechanisms. Such creator or node-related rewards are usage-based or activity-based and do not arise merely from passive holding of BLUAI. BLUAI may further be used in connection with proprietary infrastructure, including any roll-up or similar technical layer developed or supported within the ecosystem. Any governance, voting or community-participation functionality associated with BLUAI is limited to protocol-level or ecosystem-related matters and does not constitute corporate governance over the Bluwhale Foundation or any affiliated entity. BLUAI does not confer ownership, equity, dividend, redemption, creditor, revenue-sharing or profit-participation rights. |
|||
| F.3 Planned application of functionalities | textBlock | ||||
| 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 total supply is capped at 10,000,000,000 BLUAI. No further minting beyond this maximum supply is intended to occur. b. BLUAI is a utility crypto-asset, or utility token. It is fungible within each supported implementation, as each unit of BLUAI on the same network is identical and interchangeable. The BLUAI implementations across the supported networks are treated as functionally fungible versions of the same crypto-asset. c. BLUAI is issued and transferable on multiple supported networks, including Ethereum, Solana, Arbitrum, BNB Smart Chain, Base and SUI. The total number of BLUAI tokens issued across all supported networks represents one economic crypto-asset and must be assessed together. d. BLUAI is transferable on-chain, subject to applicable law, technical network functionality, wallet compatibility and any trading platform rules and fees. The admission to trading occurs on independent platforms that the issuer does not operate or control. e. BLUAI is non-interest bearing. Holders may bear network transaction fees, including gas fees or equivalent network fees, when transferring or otherwise using BLUAI on the relevant supported networks. f. 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 BLUAI, if any, is determined by supply and demand on the relevant trading platforms and markets. g. BLUAI is non-refundable and 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 issuer or any affiliate. h. Holding BLUAI does not grant any rights in or to the issuer 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 Bluwhale Foundation, its affiliates or their service providers. i. Any governance, voting, signalling or community-participation functionality associated with BLUAI is limited to protocol-level or ecosystem-related matters and does not constitute corporate governance over the Bluwhale Foundation or any affiliated entity. It does not confer control over the issuer, its management, treasury, revenues or assets. j. BLUAI does not represent a loan to, or debt of, the issuer or any of its affiliates; it is not intended to represent indebtedness, and there is no expectation of profit or interest. k. BLUAI 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. l. BLUAI 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. m. BLUAI is not an asset-referenced token or 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 issuer 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 | Holding BLUAI does not confer ownership, equity, profit participation, redemption rights, revenue-sharing rights, creditor rights, intellectual-property rights or any claim over the assets, revenues or treasury of the Bluwhale Foundation or any affiliated entity. Any governance, voting or community-signalling functionality associated with BLUAI is limited to protocol-level or ecosystem-related matters and does not constitute corporate governance over the Bluwhale Foundation or any affiliated entity. Holders are responsible for securing their wallets and private keys, paying applicable network fees on the supported networks, paying any applicable ecosystem-level fees where BLUAI is used for access to services, and complying with applicable laws and the terms of any relevant applications, wallets, trading platforms or ecosystem services. Participation in any node-related, agent-related, data-related, incentive or ecosystem programme does not create any guaranteed reward, redemption right, value-maintenance obligation or claim to protocol revenues, issuer revenues, foundation assets or treasury assets. |
|||
| G.2 Exercise of rights and obligations | textBlock | Access to BLUAI-related functionalities may include AI/data services, AI queries, automation and analytics tools, agent or workflow invocation, Agent App Store or marketplace features, node-related services, verifier-node participation, network participation, infrastructure-access mechanisms or other ecosystem features made available from time to time. The availability, scope and quality of such functionalities may depend on the relevant application, technical capacity, network conditions, eligibility requirements, geographic restrictions and any additional terms or programme rules imposed by the relevant provider or by law. BLUAI may also be used in connection with ecosystem incentive mechanisms, node participation, agent creator programmes, data contribution programmes, community programmes, grants or other technical and operational mechanisms designed to support the development, security and availability of the Bluwhale AI ecosystem. 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 | Any governance, voting or community-signalling mechanisms associated with BLUAI, if made available, are limited to protocol-level or ecosystem-related matters and do not constitute corporate governance rights over the issuer or any affiliated entity. Material changes to the utility, access mechanisms or other relevant features of BLUAI will be communicated through the project's official channels, where appropriate. Such changes do not create any right to compensation, redemption, reimbursement, revenue sharing or other financial claim against the Bluwhale Foundation or any affiliated entity. |
|||
| G.4 Future public offers | textBlock | ||||
| G.5 Issuer retained other token | integer | ||||
| G.6 Utility token classification | boolean | ||||
| G.7 Key features of goods or services utility tokens | text | AI and Data Services: BLUAI may be used as an access, gas or ecosystem-level fee mechanism for AI-driven data processing, automation, analytics, AI queries, interaction with the AI intelligence layer, invocation of AI agents, tools or workflows and related digital services made available within the Bluwhale AI ecosystem. These services are intended to support users in interacting with AI-enabled decentralised infrastructure, processing user-permissioned financial, wallet or similar data, automating workflows and using analytics or other application features integrated into the ecosystem. The availability, quantity and quality of access may depend on the relevant application, technical capacity, service tier, eligibility requirements and rules applicable from time to time. Agent App Store and Developer Economy: Where implemented, BLUAI may be used in connection with an Agent App Store or similar marketplace functionality, allowing developers or creators to publish AI agents, workflows, tools or applications and monetise actual usage through per-use fees, subscriptions, performance-based fees or other programme-based mechanisms. Any such monetisation depends on actual use, invocation, programme rules and technical availability, and does not create any guaranteed income or claim against Bluwhale Foundation or its affiliates. Node and Network Services: BLUAI supports node participation and network-related activity within the Bluwhale AI ecosystem. Holders may use BLUAI in connection with node participation, verifier-node services, Master Nodes, Common Nodes, Trusted Execution Environment attestation verification, network security, availability, reliability, accuracy and other contribution mechanisms. Node-related incentives, where available, are intended to reward or support useful active participation in the network and do not arise merely from passive holding of BLUAI. Infrastructure Access and Resource Coordination: BLUAI may be used as an access or coordination mechanism for infrastructure-related functionalities within the ecosystem, including data queries, automation tasks, analytics workflows, agent invocations, compute or data-processing capacity, storage, bandwidth, network resources and other technical features made available through Bluwhale AI applications or infrastructure. Depending on the relevant application or protocol layer, access may require holding, using, spending, locking, staking or otherwise committing BLUAI. Ecosystem Incentives and Contribution Programmes: BLUAI may be used in connection with ecosystem incentives, community participation, grants, developer support, user adoption initiatives and other programmes intended to support the development, security and availability of the Bluwhale AI ecosystem. Any incentives or rewards are usage-based or activity-based and are subject to the applicable programme rules, technical availability and eligibility requirements. They do not create any claim to protocol revenues, issuer revenues, foundation assets or any minimum level of reward. Proprietary Infrastructure and Roll-Up Functionality: The Bluwhale AI roadmap includes the development of proprietary technical infrastructure, including a potential roll-up or similar infrastructure layer. If and when implemented, BLUAI may be used in connection with access, participation, fees, node-related functionality, infrastructure use or other technical functions connected with that infrastructure. The scope, timing and availability of these functions remain subject to technical, commercial, legal and regulatory developments. Governance and Community Participation: BLUAI may enable holders to participate in non-corporate, protocol-level governance, community signalling or other ecosystem-participation mechanisms concerning technical or ecosystem-related matters. Any such functionality is limited to the configuration and development of the Bluwhale AI ecosystem and does not constitute voting rights in the Bluwhale Foundation or any affiliated entity, does not confer control over the issuer or its treasury, and does not authorise revenue sharing, distributions or participation in issuer assets. |
|||
| G.8 Utility tokens redemption | text | BLUAI may be used to access or support the ecosystem services and functionalities described above, where such access is made available through compatible wallets, applications, interfaces, smart contracts or other technical mechanisms within the Bluwhale AI ecosystem. Any holding, locking, staking, delegation or other use of BLUAI is operational in nature and does not create any right to repayment, interest, monetary yield, value maintenance or claim against the Bluwhale Foundation 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 | ||||
| G.12 Supply adjustment protocols | boolean | ||||
| G.13 Supply adjustment mechanisms | text | ||||
| 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 | The United Nations Convention on Contracts for the International Sale of Goods (CISG) is expressly excluded and shall not apply. |
|||
| G.19 Competent court | textBlock | ||||
| Part H – Information on underlying technology | |||||
| H.1 Distributed ledger technology (DTL) | text | Ethereum is a public Layer-1 blockchain using Proof-of-Stake consensus and the Ethereum Virtual Machine for smart-contract execution. Arbitrum and Base are Layer-2 networks built on Ethereum; they process transactions on Layer 2 and ultimately rely on Ethereum Layer 1 for settlement and security. BNB Smart Chain is an EVM-compatible Layer-1 blockchain using a Proof-of-Staked-Authority consensus model. Solana is a high-throughput Layer-1 blockchain using the Solana Token Program for fungible tokens. SUI is a Layer-1 blockchain based on the Move programming language and an object-centric data model. |
|||
| H.2 Protocols and technical standards | text | Ethereum: BLUAI on Ethereum follows Ethereum-compatible token and transaction standards, including the ERC-20 token standard. Ethereum uses a decentralised peer-to-peer protocol, with nodes communicating through Ethereum networking protocols. Transactions and smart-contract execution are secured through Proof-of-Stake consensus. The Ethereum Virtual Machine executes smart contracts using bytecode. Ethereum addresses are derived from public keys through cryptographic hashing, and Ethereum supports several transaction types, including legacy transactions, access-list transactions and EIP-1559 dynamic-fee transactions. Ethereum upgrades are implemented through the Ethereum Improvement Proposal process, including upgrades that support account-abstraction and data-availability improvements. Arbitrum: Arbitrum is an optimistic roll-up Layer-2 network built on Ethereum. Arbitrum supports ERC-20 compatible tokens and Ethereum-compatible smart-contract interactions. Layer-2 transactions do not have an independent Layer-1 consensus mechanism. Instead, transactions are processed by the Layer-2 execution environment, bundled by a sequencer and periodically posted to Ethereum Layer 1, where they benefit from Ethereum's Proof-of-Stake security once written to Layer 1. Arbitrum supports EVM compatibility and additional virtual-machine functionality designed to increase efficiency and reduce transaction costs. Solana: BLUAI on Solana is implemented through Solana's Token Program, part of the Solana Program Library. Tokens created under this model are commonly referred to as SPL tokens. The token itself is not a separate executable smart contract, but a token mint and related data accounts managed through the Solana Token Program. Interactions with the token are made through standard Token Program instructions, including functions for creating a mint, minting tokens, burning tokens, transferring tokens, approving delegated spending and setting authorities. The Token Program is developed in Rust. Metadata, such as name, symbol and URI information, may also be stored through the Metaplex Token Metadata Program, without altering the token's core functionality. BNB Smart Chain: BLUAI on BNB Smart Chain follows the BEP-20 standard. BNB Smart Chain is an EVM-compatible Layer-1 blockchain using Proof-of-Staked-Authority, combining features of Proof-of-Stake and Proof-of-Authority. This model is designed to provide fast transaction times and comparatively low fees while maintaining network security through validator selection, staking and delegation. Base: Base is a Layer-2 network introduced by Coinbase and developed using the OP Stack. Base supports ERC-20 compatible tokens and Ethereum-style smart-contract interaction. Base transactions do not have a separate Layer-1 consensus mechanism. They are processed on Layer 2, bundled by a sequencer and periodically posted to Ethereum Layer 1, whose Proof-of-Stake consensus indirectly secures the transactions once recorded on Layer 1. SUI: BLUAI on SUI relies on SUI's Move-based token framework and object-centric data model. SUI's architecture differs from account-based EVM systems and allows certain independent transactions to be processed in parallel. These standards are comparatively newer than Ethereum-style standards and may involve different wallet, integration, tooling and long-term support considerations. In addition to the underlying network infrastructure described above, the Bluwhale AI ecosystem may use ecosystem-level technical components supporting AI queries, agent and workflow invocation, data processing, automation, analytics, Agent App Store or marketplace functionality, verifier-node services and privacy-preserving data or compute mechanisms. Where implemented, these components may include verifier nodes, including Master Nodes and Common Nodes, Trusted Execution Environment attestation verification, zero-knowledge or similar privacy-preserving mechanisms, and other technical processes designed to support data integrity, reliable execution, availability, accuracy and privacy-preserving AI processing or inference. The precise availability, scope and implementation of these ecosystem-level technical components may evolve over time and remain subject to technical, commercial, legal and regulatory developments. |
|||
| H.3 Technology used | textBlock | Ethereum: Ethereum acts as a decentralised ledger recording token transfers and ownership. BLUAI holders interacting with Ethereum must use Ethereum-compatible wallets and securely manage their private keys and recovery phrases. Ethereum uses elliptic-curve cryptography, including ECDSA with the secp256k1 curve for signatures, Keccak-256 hashing for address generation and BLS signatures for validator aggregation under Proof-of-Stake. Arbitrum: BLUAI on Arbitrum is supported by wallets compatible with the Ethereum Virtual Machine, such as common Web3 wallets. Arbitrum maintains a Layer-2 ledger for recording transactions, while final transaction data is periodically posted to Ethereum Layer 1. Arbitrum supports ERC-20 token functionality, EVM-compatible execution and roll-up-based scalability intended to support higher throughput and lower fees than Ethereum Layer 1. Solana: BLUAI on Solana is supported by Solana-compatible wallets and the Solana Token Program. Solana records token transactions on a decentralised ledger, while token balances and token accounts are handled through the SPL token architecture. Solana is designed for high throughput and low transaction costs. Holders must use compatible wallets and securely manage their private keys and recovery phrases. Solana uses cryptographic mechanisms to validate and secure transactions within its network architecture. BNB Smart Chain: BLUAI on BNB Smart Chain is supported by BSC-compatible wallets and EVM-compatible interfaces. BNB Smart Chain maintains its own decentralised ledger for recording token transactions. The BEP-20 standard governs token functionality on BNB Smart Chain, while the network's PoSA design is intended to support fast block times, low fees and high transaction throughput. Base: BLUAI on Base is supported by Base-compatible EVM wallets. Base operates as a Layer-2 network on Ethereum and maintains its own Layer-2 transaction record, with final transaction data periodically posted to Ethereum Layer 1. Base supports ERC-20 compatible token functionality and is designed to provide lower-cost and higher-throughput transactions through roll-up infrastructure. SUI: BLUAI on SUI is supported by SUI-compatible wallets and infrastructure using the Move programming language and SUI's object-based architecture. SUI's object model allows certain independent transactions to be executed in parallel, which may improve throughput and latency. However, this architecture also introduces specific integration requirements, potential technical uncertainty, and reliance on a developer ecosystem familiar with Move-based infrastructure. 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 | Ethereum: Ethereum uses Proof-of-Stake. Validators stake ETH, propose and attest blocks, and are subject to rewards, inactivity penalties and slashing for malicious behaviour. Blocks are proposed in slots, and finalisation occurs through Ethereum's Proof-of-Stake finality mechanism. The Beacon Chain coordinates validators, and Ethereum uses fork-choice and finality rules to determine the canonical chain. Arbitrum: Arbitrum is a Layer-2 optimistic roll-up on Ethereum and does not operate a separate Layer-1 consensus mechanism. Transactions are processed on Layer 2, bundled by a sequencer and posted to Ethereum Layer 1. Ethereum's Proof-of-Stake consensus indirectly secures Arbitrum transactions once the relevant data is recorded on Ethereum. Solana: Solana uses a combination of Proof of History and Proof of Stake. Proof of History provides a cryptographic ordering of events, while validators participate in block production and validation based on stake. Validators process transactions, generate ordered transaction sequences, produce blocks and participate in finalisation. Validators and delegators may earn rewards, while dishonest or faulty behaviour may lead to penalties according to the applicable network rules. BNB Smart Chain: BNB Smart Chain uses Proof-of-Staked-Authority. Validators are selected based on staking and voting mechanisms and take turns producing blocks. Delegators may delegate BNB to validators and share in rewards. BNB Smart Chain operates with a limited active validator set and a pool of candidate validators, which supports fast block production and short finality times but also creates centralisation considerations. Base: Base is a Layer-2 network using optimistic roll-up infrastructure based on the OP Stack. It does not operate an independent Layer-1 consensus mechanism. Transactions are processed by the Layer-2 execution environment, sequenced, bundled and posted to Ethereum Layer 1. Ethereum's Proof-of-Stake consensus indirectly secures Base transactions once they are recorded on Layer 1. SUI: SUI uses a delegated Proof-of-Stake model together with its own transaction-ordering and execution architecture. Independent transactions may be processed through mechanisms designed for efficient ordering and execution, while more complex interactions rely on validator-based consensus. This structure is designed to improve efficiency, but may also involve centralisation, governance or validator-coordination risks. |
|||
| H.5 Incentive mechanisms and applicable fees | text | Ethereum: Ethereum validators stake ETH and earn rewards for proposing blocks, attesting to valid blocks and participating in network security. Users pay transaction fees in ETH. Under Ethereum's fee model, transaction fees may include a base fee, which is burned, and a priority fee paid to validators. Validators may face slashing or inactivity penalties for improper conduct or failure to perform. Arbitrum: Arbitrum transactions are bundled by a sequencer and submitted to Ethereum Layer 1. This allows multiple Layer-2 transactions to share the cost of a Layer-1 transaction, reducing the average cost per transaction. Moving assets between Arbitrum and Ethereum may involve bridge or withdrawal mechanisms. Withdrawals to Layer 1 may be subject to a challenge or dispute period, with economic incentives designed to support correct behaviour by participants. Solana: Solana validators earn rewards in SOL for producing and validating blocks, and may also receive transaction fees. Token holders may delegate SOL to validators and share in staking rewards. Solana fees are generally paid in SOL. Solana may also charge rent or storage-related fees for on-chain state, and fees for deploying or interacting with programs depend on the computational resources required. BNB Smart Chain: Validators and delegators on BNB Smart Chain may earn rewards and transaction fees in BNB. Validators are selected based on stake and votes received from delegators. Transaction fees on BNB Smart Chain are paid in BNB and may vary according to congestion and transaction complexity. BNB Smart Chain may also involve cross-chain fees and smart-contract interaction fees where applicable. Base: Base transactions are bundled by a sequencer and settled on Ethereum Layer 1. This structure is intended to reduce average transaction costs compared with direct Ethereum Layer-1 transactions. Moving assets between Base and Ethereum may involve bridge or withdrawal mechanisms, and withdrawals may be subject to challenge or fault-proof procedures designed with economic incentives for correct behaviour. SUI: SUI uses a delegated Proof-of-Stake incentive model, under which validators stake SUI and delegators may participate through delegation. Rewards are distributed according to stake and network rules. Transaction fees are generally paid in SUI and may include charges for long-term storage of on-chain data. SUI also supports sponsored transactions, where one address may pay the gas fee for another address's transaction, which may facilitate user onboarding but can also affect incentive structures. The network-level incentives and fees described above are separate from BLUAI-specific ecosystem fees, access mechanisms and incentive programmes. At ecosystem level, BLUAI may be used as an access, gas or fee mechanism for AI queries, interaction with the AI intelligence layer, agent or workflow invocation, data processing, automation, analytics, node-related services, verifier-node activity, infrastructure access or marketplace functionality, where such functionalities are implemented. BLUAI-specific incentives, where available, are intended to reward or support active and verifiable ecosystem participation, such as node verification jobs, Trusted Execution Environment attestation verification, data contribution, compute or storage provision, agent invocation, workflow usage or other activity that measurably supports the Bluwhale AI ecosystem. These incentives are separate from the consensus incentives of the underlying networks and do not alter the network-level validation or fee models described in this section. They do not arise merely from passive holding of BLUAI and do not constitute interest, dividends, profit participation, revenue sharing or guaranteed return. |
|||
| H.6 Use of distributed ledger technology | boolean | ||||
| H.7 DLT functionality description | textBlock | ||||
| Other token audit details | |||||
| H.8 Audit | boolean | ||||
| H.9 Audit outcome | textBlock | ||||
| Part I - Information on risks | |||||
| I.1 Offer-related risks | textBlock | Custodial risk: When the token is admitted to trading, there is a risk of loss of clients' assets due to hacks or other malicious acts, as tokens may be held in custodial wallets on behalf of customers. Blockchain dependence: The token is entirely dependent on the blockchain on which the crypto-asset is issued. Issues such as downtime, congestion, or security vulnerabilities may impair the token's functionality. Human error: Given the irrevocability of blockchain transactions, approving incorrect transactions or using wrong networks/addresses will most likely render funds no longer accessible. Data contract risks: Data contracts governing the token may contain hidden bugs or vulnerabilities that could disrupt the token offering or distribution processes. Connection/integration dependence: Because trading the token involves other venues, technical risks, such as connection downtime or faulty code, are possible. b. Regulatory and Compliance This white paper has been prepared with utmost caution; however, uncertainties in current regulatory requirements and future changes to regulatory frameworks could affect the token's legal status and tradability. 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 As admission to trading involves connections to other trading venues, counterparty risks arise. These include, but are not limited to, the following: General trading-platform risk: Platforms may not operate to the highest standards. Events such as FTX demonstrate that, particularly in nascent industries, compliance and oversight frameworks may be incomplete or not fully enforced. Listing/delisting risks: Listing or delisting is subject to each trading partner's internal processes. Delisting at connected trading partners could harm or completely halt the ability to trade the token. d. Failure of One or More Counterparties Another 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 go bankrupt, potentially resulting in a total loss of clients' assets held at that counterparty. e. Market and Liquidity The token will likely be subject to high volatility and market speculation. Price fluctuations could be significant, posing a risk of substantial losses to holders. Liquidity depends on trading activity on decentralised exchanges (DEXs) and, where applicable, centralised exchanges (CEXs). Low volumes may restrict the ability to buy or sell the token. f. Liquidity The token's liquidity can vary, especially when overall trading activity is limited. This may result in high slippage when trading the token. |
|||
| I.2 Issuer-related risks | textBlock | Cryptocurrencies 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/prohibition of trading of the crypto-asset, affecting its viability and market acceptance. The issuer 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 crypto-asset. b. Insolvency or Project Abandonment As with every other commercial endeavour, the risk of insolvency of the issuer or its abandonment of the project is given. 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. c. Competitive ecosystem Numerous other crypto-asset projects operate in the same space, which may adversely affect the project and the crypto-asset. d. Counterparty Dependency In order to operate, the issuer has most likely engaged in different business relationships with one or more third parties on which it strongly depends on. Loss or changes in the leadership or key partners of the issuer and/or the respective counterparties can lead to disruptions, loss of trust, or project failure. This could result in a total loss of economic value for the crypto-asset holders. e. Reputational Risk Negative publicity, arising, without limitation, from operational failures, security incidents, or association (actual or perceived) with illicit activity, can damage the issuer's reputation and, in turn, the acceptance and value of the crypto-asset. f. Operational Failure to develop or maintain effective internal control, or any difficulties encountered in the implementation of such controls, or their improvement could harm the issuer's business, causing disruptions, financial losses, or reputational damage. g. Unforeseen/Residual Risks In addition to the risks included in this section, there might be other risks that cannot be foreseen. Additional risks may also materialize 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, tech changes, and macro conditions. Losses can occur over very short periods. This is especially true for assets without intrinsic value; investors should be prepared to lose the entire amount invested. b. Valuation Because the crypto-asset 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 investors or acquirers of utility tokens. Investment therefore carries a high risk of partial or total loss. c. Liquidity Constraints Some crypto-assets suffer from limited liquidity, which can present difficulties when executing large trades without significantly impacting market prices. This lack of liquidity can lead to substantial financial losses, particularly during periods of rapid market movements, when selling assets may become challenging or require accepting unfavourable prices. d. Asset Security Crypto-assets face unique security threats, including the risk of theft from exchanges or digital wallets, loss of private keys, and potential failures of custodial services. Since crypto transactions are generally irreversible, a security breach or mismanagement can result in the permanent loss of assets, emphasizing the importance of strong security measures and practices. e. Scams The irrevocability of transactions executed using blockchain infrastructure, as well as the pseudonymous nature of blockchain ecosystems, attracts scammers. Therefore investors in crypto-assets must proceed with a high degree of caution when investing in if they invest in crypto-assets. Typical scams include, but are not limited to, the creation of fake crypto-assets with the same name, phishing on social networks or by email, fake giveaways/airdrops, identity theft, among others. f. Blockchain Dependency Any downtime, congestion, or security issues of the underlying blockchain can disrupt transfers, trading, or token functionality. g. Smart Contract/data account Vulnerabilities The smart contract/data account used to issue the crypto-asset could include bugs, coding errors, or vulnerabilities which could be exploited by malicious actors, potentially leading to asset loss, unauthorized data access, or unintended operational consequences. h. Privacy Concerns All transactions on the blockchain are permanently recorded and publicly accessible, which can potentially expose user activities. Although addresses are pseudonymous, the transparent and immutable nature of blockchain allows for advanced forensic analysis and intelligence gathering. This level of transparency can make it possible to link blockchain addresses to real-world identities over time, compromising user privacy. i. Regulatory Uncertainty The regulatory environment surrounding crypto-assets is constantly evolving, which can directly impact their usage, valuation, and legal status. Changes in regulatory frameworks may introduce new requirements related to consumer protection, taxation, and anti-money laundering compliance, creating uncertainty and potential challenges for investors and businesses operating in the crypto space. Although the crypto-asset do not create or confer any contractual or other obligations on any party, certain regulators may nevertheless qualify the crypto-asset as a security or other financial instrument under their applicable law, which in turn would have drastic consequences for the crypto-asset, including the potential loss of the invested capital in the asset. Furthermore, this could lead to the sellers and its affiliates, directors, and officers being obliged to pay fines, including federal civil and criminal penalties, or make the crypto-asset illegal or impossible to use, buy, or sell in certain jurisdictions. On top of that, regulators could take action against the issuer as well as the trading platforms if the regulators view the token as an unregistered offering of securities or the operations otherwise as a violation of existing law. Any of these outcomes would negatively affect the value and/or functionality of the crypto-asset and/or could cause a complete loss of funds of the invested money in the crypto-asset for the investor. j. Counterparty risk Engaging in agreements or storing crypto-assets on exchanges introduces counterparty risks, including the failure of the other party to fulfill their obligations. Investors may face potential losses due to factors such as insolvency, regulatory non-compliance, or fraudulent activities by counterparties, highlighting the need for careful due diligence when engaging with third parties. k. Reputational concerns Crypto-assets are often subject to reputational risks stemming from associations with illegal activities, high-profile security breaches, and technological failures. Such incidents can undermine trust in the broader ecosystem, negatively affecting investor confidence and market value, thereby hindering widespread adoption and acceptance. l. Technological Innovation New technologies or platforms could render the design of the supported networks, namely Ethereum, Arbitrum, Solana, BNB Smart Chain, Base and SUI, less competitive or even break fundamental parts (i.e., quantum computing might break cryptographic algorithms used to secure the network), impacting adoption and value. Participants should approach the crypto-asset with a clear understanding of its speculative and volatile nature and be prepared to accept these risks and bear potential losses, which could include the complete loss of the asset's value. m. Community and Narrative As the crypto-asset has no intrinsic value, all trading activity is based on the intended market value is heavily dependent on its community and the popularity of the project narrative and usage of the token. Declining interest or negative sentiment could significantly impact the token's value. n. Interest Rate Change Historically, changes in interest, foreign exchange rates, and increases in volatility have increased credit and market risks and may also affect the value of the crypto-asset. Although historic data does not predict the future, potential investors should be aware that general movements in local and other factors may affect the market, and this could also affect market sentiment and, therefore most likely also the price of the crypto-asset. o. Taxation The taxation regime that applies to the trading of the crypto-asset by individual holders or legal entities will depend on the holder's jurisdiction. It is the holder's sole responsibility to comply with all applicable tax laws, including, but not limited to, the reporting and payment of income tax, wealth tax, or similar taxes arising in connection with the appreciation and depreciation of the crypto-asset. p. Anti-Money Laundering/Counter-Terrorism Financing It cannot be ruled out that crypto-asset wallet addresses interacting with the crypto- asset have been, or will be used for money laundering or terrorist financing purposes, or are identified with a person known to have committed such offenses. q. Market Abuse It is noteworthy that crypto-assets are potentially prone to increased market abuse risks, as the underlying infrastructure could be used to exploit arbitrage opportunities through schemes such as front-running, spoofing, pump-and-dump, and fraud across different systems, platforms, or geographic locations. This is especially true for crypto-assets with a low market capitalization and few trading venues, and potential investors should be aware that this could lead to a total loss of the funds invested in the crypto-asset. r. Timeline and Milestones While the white paper has been prepared with due diligence and legal guidance from Stănescu, Vasile & Asociații (Lexters Law Firm), a digital/crypto-assets specialized EU law firm servicing worldwide clients and advising across the full lifecycle of Web3 projects and institutional initiatives, the execution of the project roadmap remains subject to uncertainty. Future r |
|||
| I.4 Project implementation-related risks | textBlock | In addition, from the project side, the delivery of BLUAI's intended utility depends on the successful design, development, deployment and maintenance of the Bluwhale AI ecosystem, including AI and data services, AI queries, automation and analytics tools, agent and workflow functionality, Agent App Store or marketplace features, node and verifier-node services, infrastructure-access mechanisms, ecosystem incentive programmes, privacy-preserving data or compute mechanisms and any proprietary infrastructure or roll-up layer described in this white paper. There is a risk that some or all of these functionalities are delayed, modified, scaled back, discontinued or never implemented, or that technical, operational, security, funding, personnel, adoption or regulatory factors prevent BLUAI from being used as described. Functionalities such as agent monetisation, verifier-node rewards, Trusted Execution Environment attestation verification, zero-knowledge or privacy-preserving data mechanisms, fee mechanisms or proprietary infrastructure may be dependent on third-party integrations, user adoption, technical reliability, regulatory permissibility and continued development capacity. If the intended utility is not delivered, or is delivered only in part, the usability, adoption and value of BLUAI 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 BLUAI token, including its blockchain infrastructure, smart contracts and data accounts, and wallets, may be vulnerable to cyberattacks. b. Blockchain Dependency Risks Network Downtime: Potential outages or congestion on any of the supported networks, namely Ethereum, Arbitrum, Solana, BNB Smart Chain, Base and SUI, could interrupt on-chain token transfers, trading, and other functions. Scalability Challenges: Despite the comparatively high-throughput design of certain supported networks, unexpected demand or technical issues on any of the supported networks might compromise their performance. c. Data Contract Risks Vulnerabilities: The smart contracts or data accounts governing the token could contain bugs or vulnerabilities that may be exploited, affecting token distribution or vesting schedules. d. Wallet and Storage Risks Private Key Management: Token holders must securely manage their private keys and recovery phrases to prevent permanent loss of access to their tokens, which include Trading Venues, who are a prominent target for dedicated hacks. Compatibility Issues: The tokens require wallets compatible with the relevant supported network, namely Ethereum, Arbitrum, Solana, BNB Smart Chain, Base or SUI, for storage and transfer. Any incompatibility or technical issues with these wallets could impact token accessibility. e. Network Security Risks Attack Risks: The supported networks, namely Ethereum, Arbitrum, Solana, BNB Smart Chain, Base and SUI, may face threats such as denial-of-service (DoS) attacks or exploits targeting their consensus mechanisms, which could compromise network integrity. Evolving Technology Risks: The fast pace of innovation in blockchain technology may make the technology used or the BLUAI token standard on any supported network appear less competitive or become outdated, potentially impacting the usability or adoption of the token. f. Ecosystem Technology Risks The Bluwhale AI ecosystem may rely on AI intelligence-layer infrastructure, agent and workflow functionality, marketplace interfaces, verifier-node infrastructure, Trusted Execution Environment attestation verification, zero-knowledge or similar privacy-preserving mechanisms, data integrations, compute or storage resources and other ecosystem-level technical components. These components may contain vulnerabilities, may not operate as intended, may depend on third-party infrastructure, may be delayed or modified, and may be affected by security incidents, integration failures, incorrect data, faulty attestations, oracle errors, privacy failures or regulatory restrictions. g. Agent Marketplace and Data-Processing Risks Where Agent App Store, agent marketplace, data contribution or user-permissioned data functionalities are implemented, their operation may depend on the availability, accuracy and lawful use of relevant data, the reliability of agents or workflows, user adoption, developer participation and continued technical support. Agent creators, data contributors, node operators or other ecosystem participants may not receive any expected level of usage, fees or rewards, and no such outcome is guaranteed by Bluwhale Foundation or any affiliated entity. |
|||
| I.6 Mitigation measures | textBlock | BLUAI is implemented using established token standards or frameworks on each supported network, namely the ERC-20 standard on Ethereum, Arbitrum and Base, the BEP-20 standard on BNB Smart Chain, the SPL token standard on Solana and the Move-based token framework on SUI. Relying on standard token frameworks is intended to reduce, but cannot eliminate, the likelihood of undiscovered bugs or vulnerabilities. b. Multi-Network and Infrastructure Design BLUAI is issued and transferable on multiple supported networks, namely Ethereum, Arbitrum, Solana, BNB Smart Chain, Base and SUI. This multi-network structure may support broader technical availability, but it also introduces network-specific risks. The issuer does not control the underlying networks, their validators, sequencers, fees, upgrades, outages or security models. c. Verifier-Node and Privacy-Preserving Mechanisms Where implemented, verifier-node infrastructure, Trusted Execution Environment attestation verification, zero-knowledge or similar privacy-preserving mechanisms and other technical controls are intended to support data integrity, reliability, privacy-preserving processing and accurate ecosystem activity. These mechanisms are risk-reduction measures only and may not prevent all vulnerabilities, failures, incorrect attestations, data errors or security incidents. d. Transparency and Communication The project intends to communicate material developments affecting BLUAI and the Bluwhale AI ecosystem through its official channels, where appropriate, to support informed decision-making by holders. 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. e. Security Practices The project intends to apply reasonable security practices in connection with the development and maintenance of BLUAI-related smart contracts, data accounts, ecosystem applications, node infrastructure and supporting infrastructure. No security measure can fully prevent cyberattacks, exploitation of vulnerabilities, loss of assets, incorrect execution, data errors or service interruption. Holders remain responsible for securing their own wallets, private keys and recovery phrases, and for verifying networks and addresses before transacting. f. Scope and Limitations of Mitigation The measures described above are risk-reduction measures only. They do not remove the risks described in this white paper, do not constitute any warranty, guarantee or commitment by the Bluwhale Foundation 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 | BLUAI is issued and transferable on multiple supported networks, namely Ethereum, Arbitrum, Solana, BNB Smart Chain, Base and SUI. These networks rely on different consensus and execution models, including Ethereum Proof-of-Stake, Layer-2 roll-up infrastructure secured by Ethereum for Arbitrum and Base, Solana's Proof of History and Proof-of-Stake model, BNB Smart Chain's Proof-of-Staked-Authority model, and SUI's delegated Proof-of-Stake architecture. These consensus mechanisms involve energy consumption, greenhouse-gas emissions and other environment-related impacts. However, the supported networks do not rely on legacy Proof-of-Work mining for BLUAI transactions and are generally designed to be more energy-efficient than Proof-of-Work systems. Arbitrum and Base further process transactions through Layer-2 batching and settlement mechanisms, which may reduce the per-transaction environmental impact compared with direct Layer-1 execution. |
|||
| 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 | Where BLUAI-specific empirical data is not available, the calculation relies on reference values, comparable network data and conservative assumptions, taking into account the technical structure, consensus mechanism, functional purpose and field of application of the supported networks. Ethereum: For the calculation of energy consumption, the "bottom-up" approach is used. Nodes and validators are considered the central factor for the energy consumption of the Ethereum network. These assumptions are made on the basis of empirical findings through the use of public information sites, open-source crawlers and crawlers developed in-house. The main determinants for estimating the hardware used within the network are the requirements for operating Ethereum client software. The energy consumption of the hardware devices was measured in certified test laboratories. When calculating energy consumption, the Functionally Fungible Group Digital Token Identifier is used, where available, to determine all implementations of the asset in scope, and mappings are updated regularly based on data of the Digital Token Identifier Foundation. Arbitrum: Energy consumption is calculated by reference to Arbitrum's Layer-2 roll-up architecture and its reliance on Ethereum Layer 1 for settlement and security. The calculation takes into account Layer-2 processing, sequencer-related activity, data posting to Ethereum and the Ethereum settlement component. The indicators are based on assumptions and estimates provided under the relevant MiCA sustainability methodology. Solana: For the calculation of energy consumption, the "bottom-up" approach is used. Validators are considered the central factor for the energy consumption of the Solana network. These assumptions are made on the basis of empirical findings through the use of public information sites, open-source crawlers and crawlers developed in-house. The main determinants for estimating the hardware used within the network are the requirements for operating Solana validator software. The energy consumption of the hardware devices was measured in certified test laboratories. When calculating energy consumption, the Functionally Fungible Group Digital Token Identifier is used, where available, to determine all implementations of the asset in scope, and mappings are updated regularly based on data of the Digital Token Identifier Foundation. BNB Smart Chain: For the calculation of energy consumption, the "bottom-up" approach is used. Nodes and validators are considered the central factor for the energy consumption of BNB Smart Chain. These assumptions are made on the basis of empirical findings through the use of public information sites, open-source crawlers and crawlers developed in-house. The main determinants for estimating the hardware used within the network are the requirements for operating the relevant client software. The energy consumption of the hardware devices was measured in certified test laboratories. When calculating energy consumption, the Functionally Fungible Group Digital Token Identifier is used, where available, to determine all implementations of the asset in scope, and mappings are updated regularly based on data of the Digital Token Identifier Foundation. Base: Energy consumption is calculated by reference to Base as a Layer-2 network built on Ethereum. The calculation takes into account Base-layer activity, Layer-2 execution, sequencing and the Ethereum settlement layer. Publicly available MiCA sustainability data for Base-layer activity is used as the reference point for this disclosure. SUI: Energy consumption is calculated by reference to SUI's Proof-of-Stake architecture and validator infrastructure. The indicators are based on assumptions and estimates provided under the relevant MiCA sustainability methodology, including assumptions on validator activity, hardware, network participation and energy use.For all supported networks, the information regarding the hardware used and the number of participants in the network is based on assumptions verified with best efforts using empirical data. In general, participants are assumed to be largely economically rational. As a precautionary principle, assumptions are made conservatively, i.e. leaning towards higher estimates of potential adverse impacts where uncertainty remains. |
|||
| 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 | Arbitrum: Renewable energy use is estimated by reference to Arbitrum Layer-2 infrastructure and the relevant Ethereum Layer-1 settlement component. The calculation considers Layer-2 processing, sequencer activity, data posting to Ethereum and the electricity mix applicable to the relevant infrastructure and settlement layer. Solana: To determine the proportion of renewable energy usage, the locations of Solana validators are determined using public information sites, open-source crawlers and crawlers developed in-house. If no information is available on geographic distribution, reference networks comparable in terms of incentivisation structure and consensus mechanism are used. This geo-information is merged with public electricity-mix data, including renewable-energy data from Our World in Data, Ember and the Energy Institute. Energy intensity is calculated as the marginal energy cost of one additional transaction. BNB Smart Chain: Renewable energy use is estimated from validator geolocation and electricity grid mix. Energy calculations rely on public validator information, the active and candidate validator set, public information sources and reference values applicable to Proof-of-Staked-Authority networks. Base: Renewable energy use is estimated by reference to Base-layer activity and Ethereum settlement infrastructure. The methodology takes into account Layer-2 execution, sequencing and the electricity mix applicable to the infrastructure used for Base activity and Ethereum settlement. SUI: Renewable energy use is estimated from validator geolocation and electricity grid mix. Energy calculations rely on assumptions and estimates regarding SUI validator infrastructure, Proof-of-Stake participation and public or third-party network data. For all supported networks, where direct geographic distribution is unavailable, reference networks are used which are comparable in terms of incentivisation structure and consensus mechanism. The geo-information is merged with public electricity-mix data. Energy intensity is calculated as the marginal energy cost of one additional transaction. |
|||
| S.16 Key GHG sources and methodologies | textBlock | Arbitrum: GHG emissions are determined by combining Arbitrum Layer-2 activity, sequencer-related assumptions and the relevant Ethereum Layer-1 settlement component with electricity-grid carbon-intensity data. Solana: GHG emissions are determined by combining Solana validator energy-use assumptions with validator geolocation and electricity-grid carbon-intensity data. The intensity is calculated as the marginal emission of one additional transaction. BNB Smart Chain: GHG emissions are determined by combining BNB Smart Chain validator energy-use assumptions with validator geolocation and electricity-grid carbon-intensity data. The intensity is calculated as the marginal emission of one additional transaction. Base: GHG emissions are determined by combining Base-layer activity, sequencer-related assumptions and the relevant Ethereum settlement component with electricity-grid carbon-intensity data. SUI: GHG emissions are determined by combining SUI validator energy-use assumptions with validator geolocation and electricity-grid carbon-intensity data. For all supported networks, the same geolocation and reference-network approach described in S.15 is used. The geo-information is merged with public carbon-intensity data, including data from Our World in Data, Ember and the Energy Institute. Scope 1 emissions are treated as 0.00000 tCO2e/a because Bluwhale Foundation does not operate the supported networks. Scope 2 emissions are estimated by reference to purchased electricity associated with the relevant network infrastructure. |
|||
| 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 | ||||