| 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 operator of the trading platform 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 |
The Mantle Network is built as an Ethereum Layer-2 solution and provides infrastructure for decentralised applications, smart contracts and on-chain financial activity. It serves as a core component for participating in and interacting with the network’s infrastructure and activities, including transaction fee payment, governance, and incentives. The Mantle ecosystem aims to be a “Liquidity Chain” that drives capital efficiency and innovation in on-chain finance, integrating decentralised application layers with data availability solutions. The total supply of MNT is 6,219,316,794.89 units, representing the maximum number of crypto-assets created for the Mantle ecosystem. Of this total supply, 3,172,988,154 MNT are reported as circulating, with the remaining supply held within the Mantle ecosystem treasury and subject to governance-based allocation decisions. |
| 09 | Further information about utility tokens |
|
| 10 | Key information about the offer to the public or admission to trading |
|
| N | Field | Content |
|---|---|---|
| A.1 | Name | N/A |
| A.2 | Legal form | N/A |
| A.3 | Registered address | N/A |
| A.4 | Head office | N/A |
| A.5 | Registration date | N/A |
| A.6 | Legal entity identifier | N/A |
| A.7 | Another identifier required pursuant to applicable national law | N/A |
| A.8 | Contact telephone number | N/A |
| A.9 | E-mail address | N/A |
| A.10 | Response time (Days) | N/A |
| A.11 | Parent company | N/A |
| A.12 | Members of the management body | N/A |
| A.13 | Business activity | N/A |
| A.14 | Parent company business activity | N/A |
| A.15 | Newly established | N/A |
| A.16 | Financial condition for the past three years | N/A |
| A.17 | Financial condition since registration | N/A |
| N | Field | Content |
|---|---|---|
| B.1 | Issuer different from offerror or person seeking admission to trading |
|
| B.2 | Name |
No public disclosure conclusively identifies which legal entity, if any, qualifies as the issuer of the MNT token within the meaning of Regulation (EU) 2023/1114 (MiCAR). This information could not be independently verified. The absence of a clearly identified and verifiable token issuer increases uncertainty regarding accountability, regulatory responsibility, and legal enforceability, and may negatively affect the overall risk profile of the crypto-asset.
As per available information: - Mantle was founded by Pascal Leblanc and launched in 2023. - MNT tokenholders own and govern the protocol. Based on publicly available information, which could not be independently and conclusively verified, Mantle appears to have been primarily funded through the BitDAO treasury. Additional strategic investors reportedly include Pantera Capital, Spartan, Folius Ventures, and others. |
| 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 |
|
||||||||||||||||||
| C.2 | Legal form |
|
||||||||||||||||||
| C.3 | Registered address | 40, Avenue Monterey, L-2163 Luxembourg Grand Duchy of Luxembourg, LU-LU | ||||||||||||||||||
| C.4 | Head office | N/A as LEI is provided in C.6. | ||||||||||||||||||
| C.5 | Registration date |
|
||||||||||||||||||
| C.6 | Legal entity identifier |
|
||||||||||||||||||
| C.7 | Another identifier required pursuant to applicable national law |
|
||||||||||||||||||
| C.8 | Parent company |
|
||||||||||||||||||
| C.9 | Reason for crypto-asset white paper Preparation |
|
||||||||||||||||||
| C.10 | Members of the management body |
|
||||||||||||||||||
| C.11 | Operator business activity |
|
||||||||||||||||||
| C.12 | Parent company business activity |
|
||||||||||||||||||
| C.13 | Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 |
|
||||||||||||||||||
| C.14 | Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 |
|
| N | Field | Content | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| D.1 | Crypto-asset project name |
|
||||||||||||||||||||||||
| D.2 | Crypto-asset name |
|
||||||||||||||||||||||||
| D.3 | Abbreviation |
|
||||||||||||||||||||||||
| D.4 | Crypto-asset project description |
|
||||||||||||||||||||||||
| 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 | Description of past milestones |
The Mantle testnet went live on 10 January 2023, after the project began development and testing. In May 2023, the BitDAO community voted to consolidate BitDAO and Mantle, rebranding under the Mantle name and preparing for migration of BIT to MNT at a 1:1 ratio. The mainnet Alpha of Mantle Network officially launched in mid-July 2023. The migration of BIT tokens to MNT occurred in mid-2023 around the mainnet launch period. Multiple ecosystem integrations and partnerships were established in late 2023, including integrations with NEAR, OKX Wallet and Ethena/USDe products. As of 2024, Mantle’s ecosystem continued to expand with ecosystem momentum in grants, rewards systems and liquidity programmes. MNT was listed on Bitunix with an active trading pair from 10 March 2025. During the first quarter of 2025, Mantle Network focused on rolling out previously designed features and technical improvements, alongside strengthening network security, optimising user experience and enhancing developer support. |
||||||||||||||||||||||||
| D.8 | Description of future milestones |
Planned network upgrade workstream including preparation/implementation activities related to EIP-3074 alongside continued ecosystem growth initiatives to expand usage and on-chain activity. |
||||||||||||||||||||||||
| D.9 | Resource allocation |
A total of 3,046,328,614 MNT, representing 49.0% of the total supply, is held within the Mantle Treasury. These assets are subject to allocation and use in accordance with Mantle governance proposals and are not considered to be in circulation until released following governance approval. The remaining 3,172,988,154 MNT, representing 51.0% of the total supply, is classified as circulating supply. |
||||||||||||||||||||||||
| 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 | Target expressed in currency | N/A |
| E.3 | Target expressed in units | N/A |
| E.3 | Target expressed in digital token identifier | 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 | Official currency or any other crypto-assets determining the issue price | N/A |
| E.10 | Fee expressed in currency | N/A |
| E.10 | Fee expressed in units | N/A |
| E.10 | Fee expressed in digital token identifier | N/A |
| E.11 | Offer price determination method | N/A |
| E.12 | Total number of offered/traded crypto-assets |
The number of MNT crypto-assets admitted to trading may vary over time due to changes in circulating supply resulting from governance-approved allocations from DAO-controlled Treasury Holdings. The upper bound of the asset quantity is defined by the fixed total supply of MNT, which is 6,219,316,794.89 crypto-assets. At the time of writing this white paper, the circulating supply is approximately 3,172,988,154 MNT, with the remaining supply held within the Mantle ecosystem treasury and subject to governance-based allocation. |
| 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 |
|
| E.25 | Value transfer methods for reimbursement | N/A |
| E.26 | Right of withdrawal | N/A |
| E.27 | Transfer of purchased crypto-assets |
|
| E.28 | Transfer time schedule | N/A |
| E.29 | Purchaser's technical requirements |
|
| E.30 | Crypto-asset service provider (CASP) name | N/A |
| E.31 | CASP identifier | N/A |
| E.32 | Placement form | N/A |
| 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 |
In accordance with the Code of Conduct all officers, directors, employees, agents, representatives, contractors and consultants (and other persons, regardless of job or position), are required to report any situation where there is the potential for conflict of interest between their interests and interests of Bitstamp. The Trading Policy that is in place within the Bitstamp Group prohibits all forms of market manipulation and has been designed to prevent insider trading. |
| E.39 | Applicable law |
|
| E.40 | Competent court |
|
| N | Field | Content |
|---|---|---|
| F.1 | Crypto-asset type |
|
| F.2 | Crypto-asset functionality |
MNT also confers governance functionality. Holders of MNT may participate in Mantle governance processes by delegating voting power and voting on proposals relating to protocol development, treasury usage, ecosystem initiatives and other governance matters. Governance participation is subject to the applicable governance rules and procedures in force at the relevant time. In addition, MNT is used within ecosystem programmes and incentive mechanisms, including participation in rewards and ecosystem initiatives made available through the Mantle ecosystem. The availability and conditions of such programmes are determined through governance decisions and may evolve over time. MNT is actively used across a diverse ecosystem spanning DeFi, CeFi, GameFi, AI, NFTs, governance, and network operations. Within DeFi, MNT can be locked in Rewards Station campaigns to earn token incentives, used to earn yield through money markets such as Lendle, INIT Capital, and Dolomite, deployed in liquidity staking with partner protocols including Merchant Moe and Agni, and utilised in Mantle Missions and other ecosystem events. In CeFi environments, MNT is supported in earn products, Launchpad and Launchpool campaigns on Bybit and other centralised exchanges, may be used as collateral for unified trading accounts and crypto loans, and can participate in products such as Double-Win Estimated Leverage, Dual Asset Investment, and liquidity mining programs. Within GameFi, MNT can be used for in-game purchases in titles such as Spot Zero, Party Icons, and L3E7. In the AI ecosystem, MNT supports interaction with advanced AI tools including ORA, Funny Money, and Heurist. In NFT markets, MNT can be used to purchase NFT collections launched on Mantle Network. |
| 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 |
MNT is designed to perform functional roles within the Mantle ecosystem, rather than to represent a claim on assets, profits or revenues. It does not constitute a security, asset-referenced token or e-money token. The crypto-asset does not provide holders with any contractual or statutory right to redemption against an issuer. The primary characteristics of MNT include its use as a network fee crypto-asset, enabling users to pay transaction fees in order to access and interact with the Mantle Network and its smart contracts. MNT also enables participation in governance, allowing holders to take part in decision-making processes relating to protocol development, treasury usage and ecosystem initiatives, subject to applicable governance rules. MNT further functions within ecosystem programmes and incentive mechanisms made available through the Mantle ecosystem. The availability and conditions of such programmes are determined through governance processes and may evolve over time. The total supply of MNT is fixed, with a portion of the supply in circulation and the remainder held within the Mantle ecosystem treasury. Treasury-held crypto-assets are allocated over time through governance decisions and may enter circulation subject to such approvals. |
| 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 |
|
| 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 available on the Mantle website (https://docs.mantle.xyz/governance/parameters/governance), at the time of this white paper, MNT holders are granted only limited functional rights within the Mantle ecosystem, which are further described as crypto-asset functionalities in F.2. |
| G.2 | Exercise of rights and obligations |
To use MNT for payment of transaction fees or interaction with decentralised applications on the Mantle Network, purchasers must hold MNT in a compatible blockchain wallet and comply with the technical requirements of the network, including transaction validation rules and applicable network fees. To exercise governance-related rights, purchasers must follow the procedures set out in the Mantle governance framework. This typically includes delegating voting power to an eligible address and participating in governance votes in accordance with the applicable voting rules, timelines and thresholds. Governance participation is voluntary and subject to the procedures in force at the relevant time. Participation in ecosystem programmes or initiatives that involve MNT may be subject to additional eligibility criteria, technical conditions or governance decisions, depending on the specific programme. The terms and availability of such programmes may change over time. Purchasers are responsible for complying with applicable laws and regulations and for safeguarding their private keys and access credentials. Failure to comply with technical requirements, governance procedures or applicable legal obligations may prevent purchasers from exercising certain functionalities associated with MNT. |
| G.3 | Conditions for modifications of rights and obligations |
The functional rights associated with MNT may be modified over time as a result of technical upgrades or governance decisions. There is no guarantee that existing functionalities will remain unchanged, and purchasers bear the risk of such changes when holding or using the crypto-asset. |
| 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 | N/A |
| G.8 | Utility tokens redemption |
|
| G.9 | Non-trading request |
|
| G.10 | Crypto-assets purchase or sale modalities | N/A |
| 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 | N/A as DTI is provided in F.13. |
| H.2 | Protocols and technical standards |
Mantle provides Ethereum-compatible JSON-RPC interfaces over HTTPS and WebSocket, enabling dApps to interact with the Layer 2 environment using standard Ethereum libraries without modification. Third-party operators may deploy verifier nodes that synchronise rollup data directly from the sequencer, enabling local transaction simulation and reduced reliance on public RPC endpoints. The network employs a private transaction pool where unconfirmed transactions are not broadcast publicly. The sequencer maintains exclusive ordering authority, preventing front-running whilst introducing temporary centralisation. Sequencer decentralisation is planned to improve liveness and censorship resistance. Protocol and execution layer Mantle operates as a modular Layer 2 architecture separating execution, data availability, settlement, and proof generation. The execution layer runs an EVM-compatible client derived from Optimism Bedrock, maintaining full Ethereum bytecode compatibility whilst processing transactions and evolving Layer 2 state. The sequencer orders transactions and produces Rollup blocks. The batcher submits transaction data through two parallel channels: it posts cryptographic batch commitments to Ethereum Layer 1 via EIP-4844 blob transactions, creating a permanent on-chain reference, whilst simultaneously distributing complete transaction data to EigenDA's decentralised storage network for cost-efficient retrieval.Simultaneously, rollup data is dispersed to EigenDA, a decentralised data availability network secured through Ethereum validator restaking. This dual-posting approach provides over 90% cost savings compared to Layer 1 calldata posting. The Mantle Succinct Proposer monitors Rollup block progression and generates zero-knowledge validity proofs using Succinct's SP1 system. These proofs cryptographically verify correct EVM state transitions and are submitted to the MantleSuccinctL2OutputOracle contract on Ethereum Layer 1. Upon successful verification, state roots achieve immediate finality without challenge periods, targeting approximately one-hour effective finality for Layer 2 to Layer 1 withdrawals. Due to reliance on EigenDA rather than Ethereum Layer 1 for primary data availability, the architecture is classified as a Validium under the Layer 2 categorisation framework established by L2Beat. State correctness is guaranteed by zero-knowledge validity proofs settled on Ethereum, whilst data availability depends on EigenDA's restaked validator network. Application layer Mantle supports comprehensive EVM smart contract deployment, enabling Ethereum-compatible dApps across DeFi, gaming, and general-purpose computation without modification. Canonical asset transfers between Ethereum Layer 1 and Mantle Layer 2 utilise bridge contracts. The L1StandardBridge locks deposits and emits cross-domain messages, whilst the L2StandardBridge mints equivalent Layer 2 representations. Withdrawals burn Layer 2 assets, prove against committed state roots, and release funds from the Layer 1 bridge after finalisation. Governance operates through MNT token-weighted delegated voting via Snapshot for off-chain vote aggregation and Gnosis Safe multisignature wallets for treasury custody. Token holders influence treasury distributions, protocol upgrades, and ecosystem parameters through Mantle Improvement Proposals. Ecosystem Application The mETH Protocol is a permissionless, non-custodial ETH liquid staking and restaking platform deployed on Ethereum L1 and governed by Mantle. Users stake ETH to receive mETH, a value-accruing receipt token redeemable for the underlying principal plus Ethereum PoS rewards (current APY ~2.41%, TVL ~$820M). It offers approximately 24-hour redemptions, deep liquidity, and composability across Mantle L2 DeFi for lending, trading, and yield farming. The protocol provides a liquidity buffer utilising Aave v3 and enables instant unstaking up to buffer capacity. The cmETH token represents mETH restaked across EigenLayer, Symbiotic, and Karak, accruing both staking and restaking rewards. |
| H.3 | Technology used |
The core runtime is a customised EVM client forked from go-ethereum and adapted for rollup semantics under Optimism Bedrock. Known as op-geth, it implements MNT as native gas token, meta-transaction sponsorship allowing third-party gas payment, and tokenRatio-based conversion logic. The client supports Ethereum's Osaka-era EVM semantics with compatibility preparations for the Fusaka upgrade expected in the first quarter of 2025. Batch submission and data availability The batcher constructs EIP-4844 blob-carrying transactions posting batch commitments to Ethereum Layer 1 whilst simultaneously dispersing data to EigenDA. EigenDA operators, who are restaked Ethereum validators, store data shards and provide cryptographic attestations of availability. Erasure coding ensures data reconstruction even if a minority of operators become unavailable. Proving system The Mantle Succinct Proposer generates zero-knowledge validity proofs via Succinct's SP1 framework. Proofs are submitted to the MantleSuccinctL2OutputOracle contract on Ethereum Layer 1, where successful verification immediately finalises state roots, enabling withdrawal processing without challenge periods. Smart contract infrastructure Key Layer 1 contracts include the L1StandardBridge for asset deposits and withdrawals, the OptimismPortal for cross-layer message passing and withdrawal finalisation, the SystemConfig for rollup configuration, the MantleSuccinctL2OutputOracle for state root verification, and the TimelockController for governing upgrade execution. Layer 2 predeploy contracts—deployed at deterministic addresses during network initialisation—include the L2StandardBridge, GasPriceOracle for dynamic fee calculation, and L2ToL1MessagePasser for withdrawal initiation. Bridge contracts employ upgradeable proxy architecture, separating contract logic from stored data to enable non-destructive upgrades that preserve existing state and balances. The TimelockController manages upgrade execution, currently configured at zero seconds for immediate deployment but adjustable through governance to introduce mandatory delay periods. mETH Protocol operational infrastructure Off-chain systems execute staking operations: an Oracle reports Ethereum Consensus Layer data via quorum-based mechanisms, an Initiator coordinates validator creation with node operators, an Allocator manages the unstake queue and optimises fund movements, and a Guardian monitors system health. These services operate statelessly, relying exclusively on Ethereum blockchain data rather than external APIs. Treasury management employs Gnosis Safe multisignature wallets on both Ethereum Layer 1 and Mantle Layer 2, holding segregated reserves for protocol development, ecosystem funding, and budget allocations. Dynamic gas pricing oracles propagate Ethereum Layer 1 conditions to Mantle Layer 2, adjusting fees to reflect Layer 1 cost fluctuations. |
| H.4 | Consensus Mechanism |
Data availability consensus is provided through EigenDA, where restaked Ethereum validators operate as node operators. These operators receive data dispersal requests from Mantle's batcher, store data shards, and provide signed attestations confirming availability. The protocol employs a quorum threshold mechanism whereby dispersal succeeds when a sufficient percentage of stake-weighted operators attest to data receipt. This structure prevents individual operator failures from disrupting data availability whilst maintaining high throughput. Operators face slashing risk if they attest to availability but fail to serve data upon retrieval request, creating a cryptoeconomic security model that aligns operator incentives with honest data provision. The restaked stake securing EigenDA is denominated in Ethereum, directly tying data availability security to Ethereum's validator set and economic weight. State validity consensus operates through zero-knowledge validity proofs rather than economic incentives or fraud-proof monitoring. The Mantle Succinct Proposer generates proofs using the SP1 framework, producing succinct cryptographic arguments that verify state transitions adhere to EVM execution rules. These proofs are deterministic: for any input state and transaction batch, only one valid output state exists, and the proof cryptographically certifies this transition. Proofs submitted to the MantleSuccinctL2OutputOracle contract on Ethereum Layer 1 undergo on-chain verification that checks the proof's mathematical validity. Upon successful verification, the state root is recorded as canonical, achieving immediate finality without challenge periods. This validity-proof approach contrasts with fraud-proof systems used in optimistic rollups, which assume state roots are correct unless challenged within a dispute window. Validity proofs eliminate this assumption by guaranteeing state correctness at submission time, enabling approximately one-hour end-to-end finality and removing reliance on active fraud monitoring. Settlement finality is anchored to Ethereum Layer 1, which serves as the ultimate arbiter of Mantle's state. State roots committed to Layer 1 inherit Ethereum's finality guarantees. Once a Layer 1 block containing a verified state root reaches finality under Ethereum's consensus, typically within fifteen minutes for economic finality under normal network conditions, the corresponding Layer 2 state becomes irreversible. The complete finality path combines proof generation time, Ethereum Layer 1 block inclusion, and Layer 1 finality, resulting in the target of approximately one hour from Layer 2 transaction execution to Layer 1 settlement finalisation. This represents a substantial improvement over optimistic rollups, which require seven-day challenge periods before withdrawals can finalise. The security model balances performance optimisation with Ethereum-aligned trust assumptions. Layer 2 execution throughput is maximised through centralised sequencing, trading decentralisation for speed. Data availability security relies on EigenDA's restaked validator set rather than Ethereum's base layer, classifying Mantle as a Validium under standard taxonomies. State validity receives absolute cryptographic guarantees through zero-knowledge proofs, eliminating reliance on economic incentives or watchers. The trusted sequencer represents the primary liveness risk: sequencer downtime prevents new transactions from being processed, though existing Layer 2 state remains verifiable and withdrawable via Layer 1 contracts. Data availability depends on EigenDA's honest-majority assumption amongst restaked operators. State validity and settlement finality inherit Ethereum Layer 1's security assumptions, requiring only that Ethereum's consensus functions correctly and that the zero-knowledge proving system is cryptographically sound. This hybrid consensus model delivers fast Layer 2 execution with target block times under two seconds whilst maintaining strong security properties through validity proofs and Ethereum settlement. |
| H.5 | Incentive Mechanisms and Applicable Fees |
MNT functions as the native gas token. All Layer 2 transactions require MNT payment following Ethereum's EIP-1559 specification with dynamic base fees and optional priority fees. Transaction costs comprise Layer 2 execution fees and Layer 1 data posting fees. The GasPriceOracle contract dynamically calculates fees by importing Ethereum Layer 1 gas prices. Meta-transaction sponsorship allows designated addresses to pay gas fees on behalf of users, enabling application developers to subsidise transaction costs. Protocol-level operational fees The batcher pays Ethereum Layer 1 gas fees for blob transactions and EigenDA dispersal fees to restaked operators. The Mantle Succinct Proposer incurs SP1 proving fees scaling with computational complexity. Fee revenues from Layer 2 transactions are collected by the sequencer operator. Revenue allocation mechanisms are not comprehensively documented. Bridge operation fees Deposits from Ethereum Layer 1 require Layer 1 gas payment. Withdrawals involve Layer 2 transaction fees for initiation and Layer 1 finalisation fees. The zero-knowledge proving system enables withdrawal finalisation approximately one hour after initiation, eliminating the seven-day delay characteristic of optimistic rollups. mETH Protocol fees The mETH Protocol charges a 10% protocol fee on staking rewards. The liquidity buffer mechanism integrates with Aave v3, providing combined staking and lending returns. Unstaking via buffer liquidity incurs a four basis point fee. cmETH restaking charges a twenty per cent protocol fee on restaking rewards. Protocol fees fund development, security audits, and ecosystem initiatives. Validator and operator incentives The sequencer operates as a centralised trusted entity without publicly specified revenue mechanisms. EigenDA operators receive fees from data dispersal requests and face slashing for unavailability. Verifier nodes operate without direct protocol incentives. mETH Protocol node operators receive compensation through consensus layer reward sharing. |
| H.6 | Use of distributed ledger technology |
|
| H.7 | DLT functionality description | N/A |
| H.8 | Audit |
|
| H.9 | Audit outcome |
Object: Comprehensive review of Mantle Network's Version 2 upgrade covering Solidity smart contracts and Golang software, including zero-knowledge rollup transition, MantleDA and EigenDA integration, MNT as native gas token, and bridge updates. Results: Twenty-one issues identified: four critical (infinite BVM ETH minting, datastore handling failures, token theft via cross-domain messages, bridged MNT theft), four high-severity (outdated Golang versions with denial-of-service vulnerabilities, insecure dependencies, unlimited retry logic, insufficient data validation), four medium-severity, five low-severity, and four informational. Actions: All critical vulnerabilities resolved through code modifications, balance checking, and input validation. High-severity issues addressed via dependency upgrades and validation enhancements. Medium and low-severity findings received fixes or acknowledgements. Secure3 | March 2024 – Node, Batcher, Proposer, and Tooling Incremental Audit Object: Incremental review of three pull requests affecting op-node, op-batcher, op-proposer, op-chain-ops, and op-service over seventeen days (12-28 February 2024), focusing on MantleDA integration and MNT native token support. Results: Twelve issues: one medium-severity (data with identifier one unretrievable from Mantle DA), nine low-severity (input validation gaps, connection handling, error propagation, test coverage), two informational notes. Actions: Medium-severity issue fully resolved via follow-up pull request. Low-severity findings acknowledged with partial fixes. Three of twelve issues resolved at report publication. Secure3 | March 2024 – Mantle V2 Solidity Contracts Audit Object: 30-day audit (31 January–1 March 2024) of Optimism Stack fork Solidity contracts, including Layer 1/Layer 2 bridges, cross-domain messengers, OptimismPortal, SystemConfig, GasPriceOracle, and MNT-native token functionality. Results: Twenty-nine issues: one critical (MNT/BVM_ETH theft via messenger approval and reentrancy), three medium-severity (cross-domain relay failures, gas estimation errors, unnecessary payable functions), seven low-severity, eighteen notes on style and optimisations. Actions: Critical and all medium-severity issues resolved through targeted fixes. Twelve of twenty-nine issues fully resolved, one partially resolved at report publication. Secure3 | March 2024 – Mantle OP-Geth Audit Object: 21-day audit (9-29 February 2024) of customised op-geth execution client, examining MNT as native token, meta-transaction support, tokenRatio gas accounting, Layer 1 cost integration, and deposit handling. Results: Eighteen issues: three critical (infinite BVM_ETH minting via missing balance checks, incorrect cost accounting excluding transaction value, insufficient sponsor validation enabling denial-of-service), five low-severity, ten informational notes. Actions: All critical vulnerabilities fully resolved through balance validation and cost accounting corrections. Seven of eighteen issues fully resolved, one partially addressed at report publication. |
| N | Field | Content |
|---|---|---|
| I.1 | Offer-related risks |
MNT transactions on Ethereum Layer 1 and Mantle Network Layer 2 achieve finality according to each chain's consensus rules. Erroneous transfers, phishing attacks, or malicious contract approvals result in permanent and irrecoverable loss. No protocol-level reversal mechanism exists. Market volatility and price risk MNT prices may experience rapid and material fluctuations driven by cryptocurrency market cycles, governance decisions, regulatory developments, liquidity constraints, or protocol announcements. Holders may incur significant mark-to-market losses, particularly during forced liquidation scenarios or when limited market depth prevents position exits at expected prices. Liquidity constraints MNT trading liquidity depends on exchange listing arrangements and market maker activities. Insufficient liquidity may prevent holders from executing large transactions without substantial price impact or delays. During periods of market stress, liquidity may deteriorate rapidly, exacerbating price volatility and exit difficulties. Custody and key management risk Loss or compromise of private keys controlling MNT holdings results in permanent forfeiture of assets. No password recovery, administrative override, or customer support intervention can restore access. Self-custody exposes holders to device failure, malware, phishing, social engineering, or physical theft. Hardware wallet malfunctions or loss of recovery phrases similarly result in irretrievable losses. Absence of statutory compensation No deposit insurance, government guarantee, or statutory compensation scheme protects MNT holdings. Holders bear the full downside risk of technical failures, operational incidents, smart contract exploits, or third-party service provider insolvencies. Lack of Intrinsic Value: The token does not possess inherent utility, functioning solely as a speculative asset. Its valuation is predominantly influenced by community engagement, speculative activities, and overall market sentiment, which presents considerable challenges to sustaining long-term value stability. Delisting Risks: Bitstamp Europe S.A. might remove the token from trading in line with Bitstamp Markets Trading Rules. |
| I.2 | Issuer-related risks |
|
| I.3 | Crypto-assets-related risks |
MNT exists in distinct forms: as an ERC-20 token on Ethereum Layer 1, as native MNT on Mantle Layer 2, and as wrapped wMNT on Layer 2. These distinct representations may create confusion for holders, complicate balance aggregation across platforms, introduce execution errors during bridging, or result in assets being sent to incompatible addresses. Bridging and cross-layer transfer risk Transfers between Ethereum Layer 1 and Mantle Layer 2 require use of canonical bridge contracts. Bridge operations incur Layer 1 gas fees for deposits and Layer 2 initiation fees plus Layer 1 finalisation fees for withdrawals. Withdrawals require approximately one hour for finality following zero-knowledge proof generation and Layer 1 verification. During periods of congestion on the Ethereum Layer 1 network, gas costs can increase significantly, potentially limiting the ability to move assets efficiently on one layer. Additionally, while bridge contracts usually undergo audits, there may still be vulnerabilities that could lead to fund loss or theft. Failed bridge transactions may require manual intervention or result in temporary asset inaccessibility. Supply dynamics and treasury distribution impact Initial total supply was 6,219,316,768 MNT as of 7 July 2023, with 49% allocated to Mantle Treasury as non-circulating holdings. Circulating supply is calculated as total supply minus treasury holdings. Governance-approved budget proposals authorise treasury distributions that increase circulating supply, potentially diluting existing holders or altering market dynamics. The scale and timing of treasury distributions remain subject to governance decisions and may occur unpredictably from a market perspective. Large distributions to ecosystem participants, liquidity programmes, or contributor budgets may create selling pressure. On-chain transparency and privacy exposure All transactions and balances on Ethereum Layer 1 and Mantle Layer 2 are publicly visible via blockchain explorers. Transaction history, wallet activity, bridging patterns, and holding amounts can be analysed and correlated. Sophisticated blockchain analysis may link addresses to real-world identities through exchange deposits, smart contract interactions, or cross-chain activity patterns. This exposure compromises financial privacy and may enable targeted attacks, social engineering, regulatory scrutiny, or unwanted commercial solicitation. Scams Due to the irreversible execution of blockchain transactions and the limited ability to identify counterparties in decentralised environments, crypto-asset markets are particularly exposed to fraudulent activity. Once assets are transferred, recovery is typically not possible. Investors should therefore exercise heightened caution when acquiring or transferring crypto-assets. Fraudulent schemes may include, among others, the issuance of counterfeit tokens bearing similar names, phishing attempts via email or social media, fake promotions or airdrops, and impersonation or identity theft. Market Abuse Crypto-asset markets may be particularly vulnerable to market abuse due to the characteristics of the underlying blockchain infrastructure and the fragmented nature of trading across platforms and jurisdictions. Practices such as front-running, spoofing, pump-and-dump schemes, wash trading, and other forms of manipulation may occur across different systems, trading venues, or geographic locations. These risks may be amplified for crypto-assets with low market capitalisation, limited liquidity, or a small number of trading venues. Such conditions can increase price volatility and susceptibility to manipulation, potentially resulting in significant losses, including the total loss of the invested funds. |
| I.4 | Project implementation-related risks |
The modular architecture separating execution, data availability, and settlement introduces complexity. Unforeseen bugs, integration failures, or performance degradation in any component may cause network instability, transaction processing delays, or temporary unavailability. The interaction between multiple independent systems creates potential for emergent failures not evident in isolated component testing. Third-party infrastructure dependencies The network relies on external services: EigenDA for data availability, restaked Ethereum validators operating as data availability nodes, third-party RPC providers for node access, and Succinct for proving infrastructure. Disruptions to any of these dependencies, including EigenDA validator set liveness issues, Succinct prover network congestion, or RPC provider outages, may impair network functionality. Users may lose the ability to submit transactions, query state, or access historical data. Data availability failures could prevent withdrawal processing. Community participation and governance engagement risk Effective governance requires active community participation through forum discussions and Snapshot voting. Low voter turnout, concentrated delegation, or apathy amongst tokenholders may result in governance capture by minority interests, delayed decision-making on critical issues, or proposal outcomes that fail to represent broad community preferences. Proposals may fail to achieve the 100,000,000 MNT quorum requirement despite substantive merit. Execution capacity and resource constraints Manual implementation of governance decisions depends on core contributor availability, technical expertise, and prioritisation. Resource constraints, competing obligations, key personnel turnover, or funding limitations may delay execution, leave approved proposals unimplemented indefinitely, or result in implementation errors. Complex technical changes may exceed team capabilities, requiring external contractor engagement and introducing additional coordination overhead. Regulatory uncertainty and compliance obligations Mantle operates within a rapidly evolving regulatory environment for Layer 2 networks, governance tokens, and decentralised finance protocols. Regulatory developments in major jurisdictions may impose new compliance obligations, reporting requirements, or operational restrictions. Conflicting regulatory frameworks across jurisdictions create legal complexity. Regulatory actions against similar projects may establish adverse precedents. Compliance costs may divert resources from technical development. Certain regulatory outcomes could require significant operational changes, restrict token transferability, or limit governance participation in specific jurisdictions. |
| I.5 | Technology-related risks |
Mantle Network derives security and finality from Ethereum Layer 1. Ethereum network degradation, including sustained congestion, consensus failures, client software bugs, or attacks on Ethereum validators, directly compromises Mantle's security guarantees. Extended Ethereum downtime prevents state root finalisation on Layer 1, delaying withdrawals and creating uncertainty about Layer 2 state validity. Ethereum protocol upgrades require corresponding Mantle Network updates to maintain compatibility. Data availability layer risks Data availability depends exclusively on EigenDA, a network of restaked Ethereum validators operating as data storage nodes. Insufficient operator participation, coordinated operator downtime, or economic attacks on restaked validators may prevent data dispersal success. If EigenDA becomes unavailable, new Layer 2 block production halts. Data withholding by malicious operators could prevent verification of Layer 2 state transitions. Whilst operators face slashing for attestation failures, the slashing mechanism's effectiveness depends on timely detection and economic deterrence remaining sufficient relative to attack incentives. Zero-knowledge proving system risks State validity relies on zero-knowledge proofs generated via Succinct's SP1 framework. Bugs in the proving system, cryptographic vulnerabilities in underlying mathematical constructions, or implementation errors in verification contracts could allow invalid state transitions to be accepted as valid. Prover network congestion or unavailability may delay proof generation, extending withdrawal finality times beyond the target one-hour window. Changes to SP1 architecture, pricing, or availability by Succinct directly impact Mantle's operational capacity. The cryptographic assumptions underlying zero-knowledge proof systems could be undermined by advances in quantum computing or cryptanalytic techniques. Sequencer centralisation A single centralised sequencer handles transaction ordering and Rollup block construction. This creates a critical single point of failure: sequencer downtime halts all Layer 2 transaction processing until restoration. The sequencer operator can censor specific transactions, reorder transactions to extract maximal extractable value, or engage in front-running based on visibility into pending transactions. Sequencer compromise through hacking, insider threat, or coercion could result in fund theft, network manipulation, or prolonged outages. Bridge contract vulnerabilities Cross-layer asset transfers depend on smart contracts including L1StandardBridge, L2StandardBridge, and OptimumPortal. Despite comprehensive audit coverage identifying and resolving critical vulnerabilities, residual risks remain. Undiscovered bugs, logic errors in edge cases, reentrancy vulnerabilities, or incorrect access controls could enable asset theft, permanent fund lock, or bridge manipulation. Upgrade mechanisms using TransparentUpgradeableProxy patterns and TimelockController introduce additional attack surfaces if governance processes are compromised or upgrade contracts contain flaws. Smart contract upgrade risks Protocol contracts employ upgradeable proxy patterns allowing logic changes through governance-authorised upgrades. The TimelockController is currently configured with zero-second delays. Malicious or erroneous upgrades could introduce vulnerabilities, alter economic parameters detrimentally, or enable unauthorised fund extraction. Insufficient community review during upgrade proposals, social engineering of governance participants, or compromise of multisignature key-holders could result in harmful upgrades being implemented. Front-running of announced upgrades may enable informed actors to exploit upcoming changes. Oracle manipulation risks (mETH Protocol) The mETH Protocol relies on off-chain oracle services to report Ethereum Consensus Layer data, including validator balances, rewards, and penalties. Compromised oracle reporters, coordinated false reporting, or bugs in quorum verification logic could result in incorrect exchange rate calculations, improper reward distributions, or manipulation of unstaking queues. Whilst oracles are designed to auto-pause upon detecting unexpected deviations, the pause mechanism itself depends on correct anomaly detection. Extended oracle failures prevent mETH exchange rate updates, creating staleness risk. Third-party protocol risks (mETH restaking) cmETH represents mETH restaked through EigenLayer, Symbiotic, and Karak. These third-party restaking protocols introduce additional risk layers: smart contract vulnerabilities in restaking protocol contracts, Actively Validated Service failures triggering slashing of restaked capital, operational failures by restaking protocol operators, or economic attacks on restaking protocol incentive mechanisms. Holders of cmETH face compounded risks from both base Ethereum staking and additional restaking protocol slashing conditions. Changes to third-party protocol fee structures, withdrawal mechanisms, or operational policies directly impact cmETH functionality and value. Software dependency and upgrade coordination Future security patches, performance improvements, or compatibility updates require coordinated adoption by node operators, service providers, and users. Version fragmentation, delayed upgrades, or incompatible implementations may create network splits, consensus failures, or security vulnerabilities. Critical security patches may require rapid deployment under time pressure, increasing implementation error risk. Dependency on upstream open-source projects, including go-ethereum, Optimism Bedrock, and SP1, creates exposure to bugs or vulnerabilities in upstream code. |
| I.6 | Mitigation measures |
Market volatility and price risk: Tokenomics parameters, including total supply of 6,219,316,768 MNT, circulating supply calculations, and treasury allocation schedules, are published and auditable on-chain. Circulating supply data is available via https://api.mantle.xyz/api/v1/token-data, enabling holders to conduct informed risk assessment and monitor supply-side dynamics. Multi-layer token representation complexity: Token contract addresses are explicitly documented: Ethereum Layer 1 (0x3c3a81e81dc49A522A592e7622A7E711c06bf354), Mantle Layer 2 native (0xdeaddeaddeaddeaddeaddeaddeaddeaddead0000), and wrapped wMNT (0x78c1b0C915c4FAA5FffA6CAbf0219DA63d7f4cb8), reducing confusion and misdirected transfers. Custody and key management risk: No protocol-level mitigation exists. User guidance clarifies that holders are responsible for securing private keys and employing appropriate custody solutions such as hardware wallets, multisignature arrangements, or professional custody services. Project implementation-related risks Third-party infrastructure dependencies: EigenDA employs slashing penalties for operator failures, providing economic security for data availability. Ethereum Layer 1 blob commitments via EIP-4844 transactions provide permanent on-chain references, creating an immutable audit trail independent of EigenDA operator liveness. Execution capacity and resource constraints: Governance establishes transparent decision-making with explicit proposal thresholds (200,000 MNT), voting periods (minimum 7 days), and quorum requirements (100,000,000 MNT). Budget allocation proposals undergo community scrutiny before implementation. Technology-related risks Data availability layer risks: Dual-posting to Ethereum Layer 1 and EigenDA ensures data availability redundancy. Blob commitments remain permanently available on Ethereum even if EigenDA operator availability deteriorates. Zero-knowledge proving system risks: Zero-knowledge validity proofs provide cryptographic certainty of state correctness, eliminating economic game-theory assumptions inherent in optimistic fraud-proof systems. Bridge contract vulnerabilities: Four security audits (January-April 2024) identified and resolved eighty issues including eight critical vulnerabilities. Bridge contracts employ upgradeable proxy patterns with governance oversight through TimelockController mechanisms. Smart contract upgrade risks: Protocol upgrades require governance approval and multisignature execution, preventing unilateral changes. The TimelockController delay is currently configured at zero seconds but is adjustable through governance to provide advance warning periods if desired. Oracle manipulation risks (mETH Protocol): Oracle quorum requirements and automatic pausing upon detecting unexpected deviations prevent manipulation. Off-chain components derive inputs exclusively from Ethereum blockchain data, eliminating external API dependencies. Sequencer centralisation: Verifier nodes can independently validate Layer 2 state without relying on sequencer honesty. Zero-knowledge validity proofs ensure invalid state transitions cannot be accepted. Users retain Layer 1 withdrawal capabilities, ensuring sequencer unavailability cannot permanently trap funds. Forced transaction inclusion mechanisms allow direct Layer 1 submission during sequencer downtime. Software dependency and upgrade coordination: Core network components are maintained in public repositories at https://github.com/mantlenetworkio, enabling transparent code review, issue tracking, and community contribution. |
| N | Field | Content |
|---|---|---|
| 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 |
|
| S.2 | Relevant legal entity identifier |
|
| S.3 | Name of the crypto-asset |
|
| S.4 | Consensus Mechanism |
Data availability consensus is provided through EigenDA, where restaked Ethereum validators operate as node operators. These operators receive data dispersal requests from Mantle's batcher, store data shards, and provide signed attestations confirming availability. The protocol employs a quorum threshold mechanism whereby dispersal succeeds when a sufficient percentage of stake-weighted operators attest to data receipt. This structure prevents individual operator failures from disrupting data availability whilst maintaining high throughput. Operators face slashing risk if they attest to availability but fail to serve data upon retrieval request, creating a cryptoeconomic security model that aligns operator incentives with honest data provision. The restaked stake securing EigenDA is denominated in Ethereum, directly tying data availability security to Ethereum's validator set and economic weight. State validity consensus operates through zero-knowledge validity proofs rather than economic incentives or fraud-proof monitoring. The Mantle Succinct Proposer generates proofs using the SP1 framework, producing succinct cryptographic arguments that verify state transitions adhere to EVM execution rules. These proofs are deterministic: for any input state and transaction batch, only one valid output state exists, and the proof cryptographically certifies this transition. Proofs submitted to the MantleSuccinctL2OutputOracle contract on Ethereum Layer 1 undergo on-chain verification that checks the proof's mathematical validity. Upon successful verification, the state root is recorded as canonical, achieving immediate finality without challenge periods. This validity-proof approach contrasts with fraud-proof systems used in optimistic rollups, which assume state roots are correct unless challenged within a dispute window. Validity proofs eliminate this assumption by guaranteeing state correctness at submission time, enabling approximately one-hour end-to-end finality and removing reliance on active fraud monitoring. Settlement finality is anchored to Ethereum Layer 1, which serves as the ultimate arbiter of Mantle's state. State roots committed to Layer 1 inherit Ethereum's finality guarantees. Once a Layer 1 block containing a verified state root reaches finality under Ethereum's consensus—typically within fifteen minutes for economic finality under normal network conditions—the corresponding Layer 2 state becomes irreversible. The complete finality path combines proof generation time, Ethereum Layer 1 block inclusion, and Layer 1 finality, resulting in the target of approximately one hour from Layer 2 transaction execution to Layer 1 settlement finalisation. This represents a substantial improvement over optimistic rollups, which require seven-day challenge periods before withdrawals can finalise. The security model balances performance optimisation with Ethereum-aligned trust assumptions. Layer 2 execution throughput is maximised through centralised sequencing, trading decentralisation for speed. Data availability security relies on EigenDA's restaked validator set rather than Ethereum's base layer, classifying Mantle as a Validium under standard taxonomies. State validity receives absolute cryptographic guarantees through zero-knowledge proofs, eliminating reliance on economic incentives or watchers. The trusted sequencer represents the primary liveness risk: sequencer downtime prevents new transactions from being processed, though existing Layer 2 state remains verifiable and withdrawable via Layer 1 contracts. Data availability depends on EigenDA's honest-majority assumption amongst restaked operators. State validity and settlement finality inherit Ethereum Layer 1's security assumptions, requiring only that Ethereum's consensus functions correctly and that the zero-knowledge proving system is cryptographically sound. This hybrid consensus model delivers fast Layer 2 execution with target block times under two seconds whilst maintaining strong security properties through validity proofs and Ethereum settlement. |
| S.5 | Incentive Mechanisms and Applicable Fees |
|
| S.6 | Beginning of the period to which the disclosed information relates |
|
| S.7 | End of period to which disclosed information relates |
|
| Mandatory key indicator | ||
| S.8 | Energy consumption |
|
| Sources and methodologies | ||
| S.9 | Energy consumption sources and methodologies |
Full methodology available at : www.micacryptoalliance.com/methodologies |
| Supplementary information on principal adverse impacts on climate and other environment-related adverse impacts of the consensus mechanism | ||
| Supplementary key indicators | ||
| 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 |
|
| Sources and methodologies | ||
| 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 |
| Optional information on principal adverse impacts on the climate and on other environment-related adverse impacts of the consensus mechanism | ||
| Optional indicators | ||
| S.17 | Energy mix | |
| S.18 | Energy use reduction | 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 |
|
| Sources and and methodologies | ||
| S.33 | Other energy sources and methodologies |
|
| S.34 | Other GHG sources and methodologies |
|
| S.35 | Waste sources and methodologies |
|
| S.36 | Natural resources sources and methodologies |
|