MiCA Whitepaper Inline XBRL

N	Field	Content
00	Table of contents	General Information 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	2026-03-19
02	Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114	This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. 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	This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.
04	Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114	The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.
05	Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114	FALSE
06	Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114	The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.
07	Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114	Warning 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	Mantle token (MNT) is a native crypto-asset that powers the Mantle ecosystem, a decentralised blockchain network designed to support modular and scalable applications. 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	This field does not apply, as 05 is False.
10	Key information about the offer to the public or admission to trading	Bitstamp Europe S.A is now seeking its admission to trading of Mantle tokens within the EU enabling compliant secondary market liquidity. This admission would allow existing holders to trade MNT on a regulated EU venue 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	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	TRUE
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
E.1	Public offering or admission to trading	ATTR
E.2	Reasons for public offer or admission to trading	By admitting the asset to trading, holders of the token will gain transparent price discovery and improved liquidity. This enables the project’s community and ecosystem participants to more easily enter and exit positions, supporting a dynamic and efficient market.
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	3172988154 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	ALL
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	The token will be available for trading on Bitstamp Europe S.A. trading platform. The token can be purchased there by using deposited funds or any other valid form of payment available on the trading platform.
E.25	Value transfer methods for reimbursement	N/A
E.26	Right of withdrawal	N/A
E.27	Transfer of purchased crypto-assets	When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account. If a client wants to hold the token in their own wallet, they will need to (i) provide an external blockchain wallet address, where the crypto-assets will be sent if a withdrawal is initiated and (ii) satisfy all other requirements applicable to a withdrawal in line with the Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 on information accompanying transfers of funds and certain crypto-assets.
E.28	Transfer time schedule	N/A
E.29	Purchaser's technical requirements	When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account and a client does not need to fulfill any other technical requirement to hold the crypto-assets on their Bitstamp account, apart from have either a computer or phone with an internet connection and appropriate software in order to interact with the Bitstamp services.
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	Bitstamp Europe S.A.
E.34	Trading platforms Market identifier code (MIC)	BESA
E.35	Trading platforms access	Admission to trading of the MNT crypto-asset is sought on Bitstamp. Access to trading, once admission is granted, will be provided through Bitstamp’s trading platform, including its website and mobile applications, in accordance with Bitstamp’s terms of use and applicable regulatory requirements.
E.36	Involved costs	There are no costs to create an account on the trading platform; however, trading fees and other costs apply in accordance with the fee schedule available at https://www.bitstamp.net/fee-schedule.
E.37	Offer expenses	This field does not apply, as there is no offer to the public.
E.38	Conflicts of interest	There are no conflicts of interest of the persons involved in the admission to trading. Bitstamp Group has a strict Code of Conduct and Trading Policy in place. They both mitigate the possibility of 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	Luxembourg
E.40	Competent court	Luxembourg

N	Field	Content
F.1	Crypto-asset type	Crypto-assets other than asset-referenced tokens or e-money tokens
F.2	Crypto-asset functionality	MNT is used as the network fee asset, enabling users to pay transaction fees in order to submit transactions and interact with smart contracts deployed on the Mantle Network. This functionality allows access to network services and supports the operation of decentralised applications within the ecosystem. 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	The core functionalities of the MNT crypto-asset, including its use for network fee payment, governance participation and access to Mantle Network services, are implemented and operational. Additional enhancements and functionalities may be introduced progressively over time through governance driven development.
F.4	Type of crypto-asset white paper	OTHR
F.5	The type of submission	NEWT
F.6	Crypto-asset characteristics	MNT is the native crypto-asset of the Mantle Network, a decentralised Ethereum Layer-2 blockchain. MNT was introduced pursuant to a governance-approved 1:1 migration from BIT. An ERC-20 representation of MNT exists on Ethereum (Layer 1), and tokens may be transferred between Ethereum and Mantle Network via the Mantle canonical bridge, which facilitates cross-chain movement between L1 and L2 environments. 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	This field does not apply as MNT is not issued by an identifiable legal entity.
F.9	Starting date of offer to the public or admission to trading	2026-04-21
F.10	Publication date	2026-04-20
F.11	Any other services provided by the issuer	This field does not apply as MNT is not issued by an identifiable legal entity.
F.12	Language or languages of the crypto-asset white paper	English
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	K1KRW1TFQ, C0D7M4H0R
F.14	Functionally fungible group digital token identifier, where available	QH1GF1J5H
F.15	Voluntary data flag	FALSE
F.16	Personal data flag	TRUE
F.17	LEI eligibility	FALSE
F.18	Home Member State	Luxembourg
F.19	Host Member States	Austria, Belgium, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Liechtenstein, Lithuania, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden

N	Field	Content
G.1	Purchaser rights and obligations	There is no legal or smart contract that confers to purchasers of the MNT crypto-asset any contractual, ownership, profit participation, repayment, redemption rights or any obligations against the Mantle Network, the Mantle ecosystem, or any associated contributors. 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	MNT does not confer any contractual rights, ownership rights, financial claims, or enforceable obligations against the Mantle Network, the Mantle ecosystem, or any associated contributors. The requirements set out below constitute technical preconditions and user responsibilities necessary to access and maintain the functional rights described in G.1. 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 token confers no ownership or financial claims as of the date of this white paper. 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	This field does not apply, as there is no offer to the public.
G.5	Issuer retained crypto-assets	0
G.6	Utility Token Classification	FALSE
G.7	Key features of goods/services of utility tokens	N/A
G.8	Utility tokens redemption	FALSE
G.9	Non-trading request	TRUE
G.10	Crypto-assets purchase or sale modalities	N/A
G.11	Crypto-assets transfer restrictions	According to Mantle tokenomics documentation (https://docs.mantle.xyz/governance/parameters/tokenomics) as of 24-02-2026, MNT tokens must not be reoffered, resold, or transferred in the United States, to U.S. persons, or for the account or benefit of U.S. persons, unless an exemption from, or exception to, U.S. securities registration requirements applies.
G.12	Supply adjustment protocols	FALSE
G.13	Supply adjustment mechanisms	This field does not apply, as G.12 is false.
G.14	Token value protection schemes	FALSE
G.15	Token value protection schemes description	This field does not apply, as G.14 is false.
G.16	Compensation schemes	FALSE
G.17	Compensation schemes description	This field does not apply, as G.16 is false.
G.18	Applicable law	There is no written legal agreement between the issuer and the crypto asset holder that sets out the laws that govern the legal relationship between those two parties. In the absence of such an agreement, the laws that govern that relationship will depend on the location of the issuer (to the extent that can be identified) and the given crypto asset holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset holder.
G.19	Competent court	There is no written legal agreement between the issuer and the crypto asset holder that sets out which jurisdiction's courts will have authority to deal with a dispute between the crypto asset holder and the issuer. In the absence of such an agreement, the laws that competent court will depend on the location of the issuer and the given token-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset holder.

N	Field	Content
H.1	Distributed ledger technology	N/A as DTI is provided in F.13.
H.2	Protocols and technical standards	Networking layer 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	Execution client 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	Mantle does not implement an independent Layer 1 consensus algorithm. Instead, the network derives security and finality from Ethereum Layer 1 whilst employing a rollup-specific mechanism for Layer 2 transaction ordering and state validation. A centralised sequencer currently handles transaction ordering and Rollup block construction, receiving transactions from users via RPC endpoints, ordering them according to priority fee and receipt time, executing them against the current Layer 2 state, and producing sequential Rollup blocks. This sequencer model provides high throughput and low latency but introduces temporary centralisation: the sequencer operator can censor transactions, reorder them for extractable value, or cause liveness failures through downtime. Sequencer decentralisation remains under governance discussion without finalised implementation timelines or specific technical approaches. 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	Network-level transaction 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	FALSE
H.7	DLT functionality description	N/A
H.8	Audit	TRUE
H.9	Audit outcome	Sigma Prime \| April 2024 – Mantle L2 Rollup V2 Security Assessment 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.

Part I - Information on risks

N	Field	Content
I.1	Offer-related risks	Irreversibility of transactions 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	This field does not apply, as MNT operates under decentralised governance via token-weighted voting. No centralised entity possesses token issuance authority.
I.3	Crypto-assets-related risks	Multi-layer token representation complexity 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	Protocol complexity and integration risk 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	Ethereum Layer 1 dependency 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	Offer-related risks 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.

General information	Page 3
Part A - Information about the offeror or the person seeking admission to trading	Page 4
Part B - Information about the issuer, if different from the offeror or person seeking admission to trading	Page 5
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	Page 6
Part D - Information about the crypto-asset project	Page 7
Part E - Information about the offer to the public of crypto-assets or their admission to trading	Page 8
Part F - Information about the crypto-assets	Page 9
Part G - Information on the rights and obligations attached to the crypto-assets	Page 10
Part H – Information on underlying technology	Page 11
Part I - Information on risks	Page 12
Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts	Page 13

Index

General information

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 underlying technology

Part I - Information on risks

Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts