| N | Field | Content |
|---|---|---|
| 00 | Table of contents |
Part A: Information about the offeror or the person seeking admission to trading Part B: Information about the issuer, if different from the offeror or person seeking admission to trading 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 Part D: Information about the crypto-asset project Part E: Information about the offer to the public of crypto-assets or their admission to trading Part F: Information about the crypto-assets Part G: Information on the rights and obligations attached to the crypto-assets Part H: Information on the underlying technology Part I: Information on the risks Part J: Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts |
| 01 | Date of notification |
|
| 02 | Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114 |
The person seeking admission to trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper. |
| 03 | Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114 |
|
| 04 | Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114 |
|
| 05 | Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114 |
|
| 06 | Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114 |
|
| 07 | Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114 |
This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other 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 |
$LION serves multiple in-ecosystem functions, including acting as the native token of Loaded Lions. It is also a payment token which is currently integrated with Crypto.com Pay, Solana Pay, and Portal Pay., giving holders access to various reward tiers and loyalty bonuses when locked into designated vaults. The total supply of LION is 100,000,000,000. LION is classified as a non-utility token under the MiCA Regulation, as its stated utilities do not involve accessing goods or services provided by an identifiable issuer. |
| 09 |
|
|
| 10 | Key information about the offer to the public or admission to trading |
This admission would allow existing holders to trade $LION on a regulated EU venue,including Kraken where it is already listed globally outside the EU, ensuring transparent price discovery and stronger market depth. It also supports broader token distribution, which is essential for decentralised governance and wider stakeholder participation in ecosystem decisions. |
| N | Field | Content | ||||||
|---|---|---|---|---|---|---|---|---|
| A.1 | Name |
|
||||||
| A.2 | Legal form | N/A as LEI is provided in A.6 | ||||||
| A.3 | Registered address | N/A as LEI is provided in A.6 | ||||||
| A.4 | Head office | N/A as LEI is provided in A.6 | ||||||
| A.5 | Registration date |
|
||||||
| A.6 | Legal entity identifier |
|
||||||
| A.7 | Another identifier required pursuant to applicable national law | N/A as LEI is provided in A.6 | ||||||
| A.8 | Contact telephone number |
|
||||||
| A.9 | E-mail address |
|
||||||
| A.10 | Response time (Days) |
|
||||||
| A.11 | Parent company | N/A as LEI is provided in A.6 | ||||||
| A.12 | Members of the management body |
|
||||||
| A.13 | Business activity |
|
||||||
| A.14 | Parent company business activity |
|
||||||
| A.15 | Newly established |
|
||||||
| A.16 | Financial condition for the past three years |
|
||||||
| A.17 | Financial condition since registration |
|
| N | Field | Content |
|---|---|---|
| B.1 | Issuer different from offerror or person seeking admission to trading |
|
| B.2 | Name | N/A |
| B.3 | Legal form | N/A |
| B.4 | Registered address | N/A |
| B.5 | Head office | N/A |
| B.6 | Registration date | N/A |
| B.7 | Legal entity identifier | N/A |
| B.8 | Another identifier required pursuant to applicable national law | N/A |
| B.9 | Parent company | N/A |
| B.10 | Members of the management body | N/A |
| B.11 | Business activity | N/A |
| B.12 | Parent company business activity | N/A |
| N | Field | Content |
|---|---|---|
| C.1 | Name | N/A |
| C.2 | Legal form | N/A |
| C.3 | Registered address | N/A |
| C.4 | Head office | N/A |
| C.5 | Registration date | N/A |
| C.6 | Legal entity identifier | N/A |
| C.7 | Another identifier required pursuant to applicable national law | N/A |
| C.8 | Parent company | N/A |
| C.9 | Reason for crypto-asset white paper Preparation | N/A |
| C.10 | Members of the management body | N/A |
| C.11 | Operator business activity | N/A |
| C.12 | Parent company business activity | N/A |
| C.13 | Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | N/A |
| C.14 | Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | N/A |
| N | Field | Content | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| D.1 | Crypto-asset project name |
|
||||||||||||||||
| D.2 | Crypto-asset name |
|
||||||||||||||||
| D.3 | Abbreviation |
|
||||||||||||||||
| D.4 | Crypto-asset project description |
The project originated as a 10,000-piece NFT collection on the Crypto.com NFT platform and has since evolved into a broader interactive universe powered by the $LION token. $LION is the native token of the Loaded Lions ecosystem and serves as a staking asset, giving holders access to various reward tiers, and loyalty bonuses when locked into designated vaults. It is also a payment token which is currently integrated with Crypto.com Pay, Solana Pay and Portal Pay. The project has shared a five-year roadmap structured around three core pillars, the $LION Economy, Gaming, and Growth. |
||||||||||||||||
| D.5 | Details of all natural or legal persons involved in implementation of crypto-asset project |
|
||||||||||||||||
| D.6 | Utility Token Classification |
|
||||||||||||||||
| D.7 | Key Features of Goods/Services for Utility Token Projects | N/A | ||||||||||||||||
| D.8 | Plans for the token |
In Q1 and Q2 of 2025, the Loaded Lions ecosystem launched the $LION token across multiple chains, such as Cronos, Solana, and Arbitrum, accompanied by the introduction of staking tiers. Official listings on selected centralised and decentralised exchanges were completed. Additional exchange listings followed, along with the activation of token-based rewards and benefits within the Crypto.com ecosystem. In Q3 and Q4 of 2025, the $LION token was integrated into the Solana Pay and Portal Pay, enabling additional real-world utility for token holders. The initial phase of the DAO and governance framework was introduced, where token holders will be able to participate in governance discussions, vote on proposals through the DAO structure, strengthening community participation and supporting transparent decision-making across the ecosystem. |
||||||||||||||||
| D.8 | Plans for the token |
In 2026, the project will integrate $LION into Loaded Lions: Mane City, unlocking additional value for token holders and expand token functionality. Additionally, a limited-release Loaded Lions debit card will be introduced, expanding the practical use cases of the ecosystem. The DAO pilot programme will continue to evolve, alongside the introduction of new token utilities and the release of a new NFT collection. A new blockchain-based game title with $LION integration will also enter development. The project plans to host Mane City, World Series III, roll out Season 4 content, and expand its AI-powered NPC system within the game. In 2027, the project will begin expanding its physical and lifestyle brand presence through global meet-ups. The broader roadmap includes VR/AR experimental features and creator-focused incubator programmes. Looking ahead to Q1 and Q2 of 2028, the full DAO formation is expected to take place, alongside the expansion of the card programme and additional creator and community incentives. The project will culminate this phase of development with the launch of the annual Lion Summit, serving as a flagship global event for holders, partners, and contributors. |
||||||||||||||||
| D.9 | Resource allocation |
15% of the supply is allocated to an ecosystem reserve, which supports future technical development, project expansion, and token-based governance mechanisms, including the formation and funding of the DAO treasury. The remaining 10% is assigned to operations and marketing, covering infrastructure costs, product development, brand collaborations, and marketing campaigns. |
||||||||||||||||
| D.10 | Planned use of Collected funds or crypto-Assets |
|
| N | Field | Content |
|---|---|---|
| E.1 | Public offering or admission to trading | |
| E.2 | Reasons for public offer or admission to trading |
|
| E.3 | Fundraising target | N/A |
| E.4 | Minimum subscription goals | N/A |
| E.5 | Maximum subscription goals | N/A |
| E.6 | Oversubscription acceptance | N/A |
| E.7 | Oversubscription allocation | N/A |
| E.8 | Issue price | N/A |
| E.9 | Official currency or any other crypto-assets determining the issue price | N/A |
| E.9 | Any other tokens determining issue price | N/A |
| E.10 | Subscription fee | N/A |
| E.11 | Offer price determination method | N/A |
| E.12 | Total number of offered/traded crypto-assets | |
| E.13 | Targeted holders | |
| E.14 | Holder restrictions | N/A |
| E.15 | Reimbursement notice | N/A |
| E.16 | Refund mechanism | N/A |
| E.17 | Refund timeline | N/A |
| E.18 | Offer phases | N/A |
| E.19 | Early purchase discount | N/A |
| E.20 | Time-limited offer | N/A |
| E.21 | Subscription period beginning | N/A |
| E.22 | Subscription period end | N/A |
| E.23 | Safeguarding arrangements for offered funds/crypto-Assets | N/A |
| E.24 | Payment methods for crypto-asset purchase | N/A |
| E.25 | Value transfer methods for reimbursement | N/A |
| E.26 | Right of withdrawal | N/A |
| E.27 | Transfer of purchased crypto-assets | N/A |
| E.28 | Transfer time schedule | N/A |
| E.29 | Purchaser's technical requirements |
|
| E.30 | Crypto-asset service provider (CASP) name |
|
| E.31 | CASP identifier | N/A |
| E.32 | Placement form | |
| E.33 | Trading platforms name |
|
| E.34 | Trading platforms market identifier code (MIC) |
|
| E.35 | Trading platforms access |
|
| E.36 | Involved costs |
|
| E.37 | Offer expenses |
|
| E.38 | Conflicts of interest |
|
| E.39 | Applicable law |
|
| E.40 | Competent court |
|
| N | Field | Content |
|---|---|---|
| F.1 | Crypto-asset type |
|
| F.2 | Crypto-asset functionality |
Under the DAO framework, $LION will allow holders to submit proposals to the community within four main areas: the allocation and management of DAO funds, the development and use of the Loaded Lions brand and intellectual property, any other DAO-related proposals, and informational matters relevant to the community. Holders of $LION tokens also have the power to vote on these proposals, with one token corresponding to one vote. Token holders can vote with the options ‘In favor’, ‘Against’ or ‘Abstain’. Proposals that receive a majority of ‘In favor’ votes move forward to implementation, while proposals that are rejected or receive no votes (or result in a tie) are marked as ‘Stalled’ and may be resubmitted. The token will be integrated into the Crypto.com Visa Card platform, allowing token holders to link their $LION holdings to real-world payments and benefits. This integration is expected to enable spending incentives, merchant partnerships, and lifestyle perks tied to on-chain activity. Presently, the $LION token can be staked through vaults that offer tiered rewards and bonuses, with higher tiers granting higher multipliers. The token is fungible, transferable, and deployed across Cronos, Solana, and Arbitrum networks, with cross-chain operability maintained through official bridge infrastructure. |
| F.3 | Planned application of functionalities |
|
| F.4 | Type of crypto-asset white paper | |
| F.5 | The type of submission | |
| F.6 | Crypto-asset characteristics |
LION serves multiple in-ecosystem functions, firstly as a staking asset, giving holders access to various reward tiers and loyalty bonuses when locked into designated vaults, and as a governance token giving access to token holders to vote on ecosystem decisions. |
| F.7 | Commercial name or trading name | N/A as DTI is provided in F.13. |
| F.8 | Website of the issuer |
|
| F.9 | Starting date of offer to the public or admission to trading |
|
| F.10 | Publication date |
|
| F.11 | Any other services provided by the issuer |
|
| F.12 | Language or languages of the crypto-asset white paper |
|
| F.13 | Digital token identifier code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available |
Solana: 6728MTJH0 Arbitrum: FP20NXW1P |
| F.14 | Functionally fungible group digital token identifier, where available |
|
| F.15 | Voluntary data flag |
|
| F.16 | Personal data flag |
|
| F.17 | LEI eligibility |
|
| F.18 | Home Member State | |
| F.19 | Host Member States |
| N | Field | Content |
|---|---|---|
| G.1 | Purchaser rights and obligations |
As reflected in the governance framework made available on the Loaded Lions website (https://loadedlions.com/governance/) as of the date of this white paper, it is expected that $LION holders will eventually receive DAO governance non-contractual functional rights, which are further described as crypto-asset functionalities in F.2. |
| G.2 | Exercise of rights and obligations |
As part of the planned DAO governance framework, holders wishing to participate in the decision-making of the Loaded Lions ecosystem must follow the proposal process starting from the initial drafting of the idea. While there is no formal requirement for a specific format, it is strongly recommended that each proposal be structured using a comprehensive template. This template should include an executive summary outlining all relevant information, context explaining the origin of the idea and the problem the proposal aims to address, a team description identifying those responsible for implementation, key terms clarifying the main elements, and key benefits for the Loaded Lions, highlighting how the proposal benefits the community. Additionally, the proposal should specify an implementation timeline, the required budget, the expected economic impact in terms of revenue or profit, and an assessment of risks associated with execution. Once the first draft is submitted, the proposal is shared with the community for feedback and subsequently moves to the voting phase, where a majority of ‘In favor’ votes leads to implementation. $LION holders are solely responsible for safeguarding their wallets and private keys. Loss or compromise of keys results in irreversible loss of access. |
| G.3 | Conditions for modifications of rights and obligations |
|
| G.4 | Future public offers |
|
| G.5 | Issuer retained crypto-assets |
|
| G.6 | Utility Token Classification |
|
| G.7 | Key features of goods/services of utility tokens |
|
| G.8 | Utility tokens redemption |
|
| G.9 | Non-trading request |
|
| G.10 | Crypto-assets purchase or sale modalities |
|
| G.11 | Crypto-assets transfer restrictions |
|
| G.12 | Supply adjustment protocols |
|
| G.13 | Supply adjustment mechanisms |
|
| G.14 | Token value protection schemes |
|
| G.15 | Token value protection schemes description |
|
| G.16 | Compensation schemes |
|
| G.17 | Compensation schemes description |
|
| G.18 | Applicable law |
|
| G.19 | Competent court |
|
| N | Field | Content |
|---|---|---|
| H.1 | Distributed ledger technology (DTL) | N/A as DTI is provided in F.13 |
| H.2 | Protocols and technical standards |
Networking layer $LION utilises the networking stack of Cronos EVM, which is built atop CometBFT. Nodes establish encrypted peer‑to‑peer connections using Secret Connection which employs Ed25519 identity keys and X25519 session keys. Streams are multiplexed over a single TCP connection via MConnection, and traffic is channelled by category. Peer discovery relies on static seed nodes, persistent peers and a peer exchange (PEX) address book. This setup underpins $LION’s settlement layer and avoids libp2p/gossipsub dependencies. Serialisation layer $LION transactions on Cronos EVM are serialised via Protocol Buffers (Protobuf) as defined in Cosmos SDK ADR‑020. Although $LION uses the CRC‑20 standard within the Ethermint EVM, the outer Cosmos SDK envelope remains Protobuf encoded, providing structured and upgrade‑compatible messaging. Cryptographic primitives $LION leverages secp256k1 for account‑level signatures and Ed25519 for validator consensus keys. Within the EVM environment, Keccak‑256 is used for contract and internal execution; for consensus and state hashes Cronos uses SHA‑256. Merkle inclusion proofs conform to ICS‑23. Ledger model The Cronos blockchain which supports $LION is account‑based. Each account may store balances, metadata and contract storage where applicable. State is maintained in a Merkleised key‑value structure, enabling verifiable proofs. Execution model $LION executes on the Cronos EVM chain via Ethermint. This means standard CRC‑20 token transfers and approvals take place in the EVM, while underlying state and modules may interact through the Cosmos SDK stack. The chain maintains deterministic execution semantics, and the fee‑market model is EIP‑1559‑inspired. Token standards $LION is issued as a CRC‑20 token on Cronos EVM. The CRC‑20 standard is functionally equivalent to Ethereum’s ERC‑20 token interface (Ethereum Request for Comment 20), supporting core functions such as transfer, approve, transferFrom, balanceOf, and allowance. This compatibility ensures that $LION can be used with standard Ethereum-based wallets, decentralised applications, and infrastructure tools while benefiting from Cronos’s integration with the Cosmos SDK ecosystem. Following its initial launch on Cronos, $LION has also been deployed to other blockchains: on Arbitrum as an ERC‑20 token and on Solana as an SPL token (Solana Program Library standard), which defines token behaviour within Solana’s runtime environment. Despite these multichain deployments, Cronos remains the canonical chain for $LION. APIs and interfaces Cronos EVM provides JSON-RPC endpoints for interacting with the $LION CRC-20 contract. Cronos also offers gRPC and REST APIs via the Cosmos SDK, and event subscriptions via CometBFT’s WebSocket interface. Public explorers such as explorer.cronos.org allow for inspection of $LION token transfers and contract activity. |
| H.3 | Technology used |
$LION runs on Cronos EVM, which is implemented in Go using the Cosmos SDK and Ethermint. The validator set on Cronos EVM comprises around 33 invited entities (for example major infrastructure providers). $LION’s architecture consists of a CRC‑20 token contract and associated staking vaults within the Ethermint EVM, sharing state with native Cosmos SDK modules. Runtime and build parameters Node software for Cronos EVM is built via reproducible pipelines, using CI processes and version control. Parameters such as gas limits, slashing thresholds and upgrade heights are set on‑chain. Upgrades are scheduled via the SDK upgrade module but require validators to manually install the updated binary and restart at the designated block height. Dependencies The Cronos EVM chain relies on CometBFT for consensus and P2P networking, Cosmos SDK for state and modules and Ethermint for EVM compatibility. $LION inherits this stack and operates atop it. Infrastructure components explorers, RPC gateways, analytics services are provided by Cronos Labs and ecosystem partners. |
| H.4 | Consensus Mechanism |
$LION is deployed on Cronos, which uses CometBFT engine, a Byzantine Fault Tolerant protocol derived from Tendermint. The validator set on this chain is permissioned, meaning that validators are not elected by public staking but instead selected through an internal admission process. Only entities that have been explicitly invited to join can participate in consensus. |
| H.5 | Incentive Mechanisms and Applicable Fees |
Transactions involving $LION on the Cronos EVM Chain are subject to standard network gas fees denominated in CRO. The chain uses an EIP-1559-style fee market where each transaction includes a base fee and an optional tip to validators. Unlike Ethereum, both the base fee and the tip are fully rewarded to validators. Users interacting with $LION, including transfers and staking vault actions, pay these fees upon inclusion in a block. There are no protocol-specific surcharges or taxes applied by the $LION project itself. Application-level staking incentives The $LION ecosystem includes on-chain staking vaults that offer fixed lock periods with corresponding reward multipliers. There are five lock options: 3, 6, 12, 36, and 60 months. Longer lock durations yield proportionally higher staking rewards. Users may deposit, upgrade, or withdraw from these vaults directly via the project interface. The vault guide on the project’s website outlines the full process, and there are no project-level protocol fees disclosed for these operations beyond standard network gas. |
| H.6 | Use of distributed ledger technology |
|
| H.7 | DLT functionality description |
|
| H.8 | Audit |
|
| H.9 | Audit outcome |
Kudelski Security’s Ethermint Audit 2022
|
| N | Field | Content |
|---|---|---|
| I.1 | Offer-related risks |
The market price of $LION may fluctuate sharply due to broader crypto-asset sentiment, exchange depth, and the discretionary release of tokens by affiliated entities. Liquidity conditions $LION may experience low trading volumes or wide bid-ask spreads, particularly during early distribution or campaign-driven activity. Large transactions and discretionary unlocks Pre-allocated $LION tranches may be released at the discretion of the project team; this discretionary supply and linear emissions can affect market pricing. Listing/access and venue dependency Market access for $LION depends on third-party platforms and may be affected by geo-blocking, policy changes, or delisting decisions. Off-chain programme dependency Some $LION benefits such as rebates, Earn campaigns, referrals are offered in partnership with Crypto.com, and such third parties may change, suspend, or exclude users at the platform’s discretion. |
| I.2 | Issuer-related risks |
|
| I.3 | Crypto-assets-related risks |
$LION transfers on Cronos EVM are final and cannot be reversed at the protocol level; key loss or misdirection is permanent. Utility-delivery risk Some $LION utilities are roadmap-based or conditional such as in-game use, debit-card linkage, governance. Delivery may be delayed or altered. Demand concentration and promotional exposure Demand for $LION may depend on off-chain campaigns or product tie-ins (e.g., Crypto.com Earn), which can start or end without notice. Custody and key management Token holders bear responsibility for safekeeping of private keys or custodial arrangements; loss may result in permanent asset loss. Bridging and supply fragmentation $LION is deployed across multiple chains (Cronos, Solana, Arbitrum); misconfigured bridges or peg mechanisms could create circulating-supply mismatch or cross-chain state divergence. Illiquidity from long-term locks Vault participation may involve lock-in periods up to 60 months, limiting user flexibility and resale options. |
| I.4 | Project implementation-related risks |
Roadmap items or smart-contract updates (e.g., new vaults, utility expansion) may be postponed or cancelled. Operational interruptions RPC access, vault UI performance, and data integrations depend on Cronos node infrastructure, which may experience latency or service degradation. Third-party dependency $LION’s visibility and usability rely on wallets, explorers, indexers, and programmatic endpoints maintained by Cronos Labs or partners. |
| I.5 | Technology-related risks |
$LION transactions execute on Cronos EVM, where flaws in Ethermint or Cosmos SDK including fee market logic, module behaviour may affect execution and settlement. Code quality and bugs Software bugs and defects in new Cronos EVM releases or updates could compromise system functionality, security, and user trust. Interoperability-related risk $LION exists on multiple chains; relay, mint/burn, or bridge module faults may result in peg instability or duplicated supply. |
| I.6 | Mitigation measures |
|
| N | Field | Content |
|---|---|---|
| S.1 | Name |
|
| S.2 | Relevant legal entity identifier |
|
| S.3 | Name of the crypto-asset |
|
| S.4 | Consensus Mechanism |
$LION is deployed on Cronos chain, which uses CometBFT engine, a Byzantine Fault Tolerant protocol derived from Tendermint. The validator set on this chain is permissioned, meaning that validators are not elected by public staking but instead selected through an internal admission process. Only entities that have been explicitly invited to join can participate in consensus. |
| S.5 | Incentive Mechanisms and Applicable Fees |
|
| S.6 | Beginning of period to which disclosed information relates |
|
| S.7 | End of period to which disclosed information relates |
|
| S.8 | Energy consumption |
|
| S.9 | Energy consumption sources and methodologies |
Full methodology available at : www.micacryptoalliance.com/methodology |
| S.10 | Renewable energy consumption |
|
| S.11 | Energy intensity |
|
| S.12 | Scope 1 DLT GHG emissions - controlled |
|
| S.13 | Scope 2 DLT GHG emissions - purchased |
|
| S.14 | GHG intensity |
|
| S.15 | Key energy sources and methodologies |
Full methodology available at: www.micacryptoalliance.com/methodologies |
| S.16 | Key GHG sources and methodologies |
Full methodology available at: www.micacryptoalliance.com/methodologies |
| S.17 | Energy mix | |
| S.18 | Energy use reduction | N/A |
| S.19 | Carbon intensity |
|
| S.20 | Scope 3 DLT GHG emissions – Value chain | N/A |
| S.21 | GHG emissions reduction targets or commitments | N/A |
| S.22 | Generation of waste electrical and electronic equipment (WEEE) |
|
| S.23 | Non-recycled WEEE ratio |
|
| S.24 | Generation of hazardous waste |
|
| S.25 | Generation of waste (all types) |
|
| S.26 | Non-recycled waste ratio (all types) |
|
| S.27 | Waste intensity (all types) |
|
| S.28 | Waste reduction targets or commitments (all types) | N/A |
| S.29 | Impact of the use of equipment on natural resources |
|
| S.30 | Natural resources use reduction targets or commitments | N/A |
| S.31 | Water use |
|
| S.32 | Non recycled water ratio |
|
| S.33 | Other energy sources and methodologies |
Full methodology available at: www.micacryptoalliance.com/methodologies |
| S.34 | Other GHG sources and methodologies |
Full methodology available at: www.micacryptoalliance.com/methodologies |
| S.35 | Waste sources and methodologies |
Full methodology available at: www.micacryptoalliance.com/methodologies |
| S.36 | Natural resources sources and methodologies |
|