| N | Field | Content |
|---|---|---|
| I.00 | Table of contents |
II. Summary Part A- Information about the issuer of the e-money token Part B - Information about the e-money token Part C - Information about the offer to the public of the e-money token or its admission to trading Part D - Information on the rights and obligations attached to e-money tokens Part E - Information on the underlying technology Part F - Information on the risks Part G – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts |
| I.01 | Date of notification |
|
| I.02 | Statement in accordance with Article 51(3) of Regulation (EU) 2023/1114 |
|
| I.03 | Compliance statement in accordance with Article 51(5) of Regulation (EU) 2023/1114 |
|
| I.04 | Warning in accordance with Article 51(4), points (a) and (b), of Regulation (EU) 2023/1114 |
|
| I.05 | Warning in accordance with Article 51(6), 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 e-money token 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 that any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law. |
| I.06 | Characteristics of the crypto-asset |
Each e-money token is issued at par value upon receipt of funds. It is backed 1:1 by the equivalent amount denominated in the same currency, either as a deposit in segregated accounts with credit institutions or invested in qualifying high-quality liquid assets with minimal market risk, credit risk, duration risk, and concentration risk. |
| I.07 | Right of redemption |
Redemptions are conditioned on the holder establishing a customer relationship with Monerium. Funds received in exchange for EURe are transferred via the Single Euro Payment Area (“SEPA“) payment system and denominated in euros. At request, Monerium will redeem the monetary value of the e-money at any time and at par value. Redemption may be requested in whole or in part.. Right to redeem e-money is conditional upon (i) holding the corresponding amount of e-money at your address, (ii) compliance with Monerium’s Terms of Service and internal policies, and (iii) the absence of any restriction imposed by a regulator, law enforcement authority, or a court of competent jurisdiction. |
| I.08 | Key information about the offer and/ or admission to trading |
Currently, EURe is not listed on platforms operated by external crypto asset service providers. However, Monerium may seek its admission to trading on future MiCA-compliant trading platforms. |
| N | Field | Content | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| A.1 | Statutory name |
|
|||||||||||||||
| A.2 | Trading name |
|
|||||||||||||||
| A.3 | Legal form |
|
|||||||||||||||
| A.4 | Registered address | Not applicable as LEI is in A.7 | |||||||||||||||
| A.5 | Head office | Not applicable as LEI is in A.7 | |||||||||||||||
| A.6 | Registration date |
|
|||||||||||||||
| A.7 | Legal entity identifier |
|
|||||||||||||||
| A.8 | Another identifier required pursuant to applicable law |
|
|||||||||||||||
| A.9 | Contact telephone number |
|
|||||||||||||||
| A.10 | E-mail address |
|
|||||||||||||||
| A.11 | Response time (days) |
|
|||||||||||||||
| A.12 | Parent company |
|
|||||||||||||||
| A.13 | Members of the management body |
|
|||||||||||||||
| A.14 | Business activity |
Monerium is also registered as a Virtual Asset Service Provider with the Central Bank of Iceland. Monerium intends to provide exchange services for EMTs and crypto assets. |
|||||||||||||||
| A.15 | Parent company business activity |
|
|||||||||||||||
| A.16 | Conflicts of interest disclosure |
|
|||||||||||||||
| A.17 | Issuance of other crypto-assets |
|
|||||||||||||||
| A.18 | Activities related to other crypto-assets |
|
|||||||||||||||
| A.19 | Connection between the issuer and the entity running the DLT |
|
|||||||||||||||
| A.20 | Description of the connection between the issuer and the entity running the DLT |
Monerium has no or limited connections with the entities, persons, or foundations associated with Ethereum, Arbitrum, Scroll, and Polygon. Monerium has close working connections with persons associated with Gnosis, Nobel, and Linea. In some cases, Monerium has received grants related to the deployment of EMTs from the blockchain foundation in question. Companies related to the entities running blockchains on which Monerium issues are also minority shareholders of Monerium. |
|||||||||||||||
| A.21 | Newly established |
|
|||||||||||||||
| A.22 | Financial condition for the past three years |
Business development and performance, three-year comparison Monerium’s activity scaled materially across the period, with e-money usage indicators strengthening year on year. EURe issuance increased from about EUR 1.0 million in 2022 to EUR 11.5 million in 2023, reaching a peak of EUR 17.0 million, and then to a peak of about EUR 25.0 million in 2024. Cumulative on-chain EURe turnover rose to EUR 620 million in 2023 and EUR 2.6 billion in 2024. Monerium experienced exceptional growth in its customer base, recording an increase of over 600% from 2022 to 2023, and a further expansion of approximately 190% in 2024, alongside a growing share of corporate clients. GBPe issuance started in 2024 and was about GBP 0.4 million by year end. Financial performance, three-year comparison Loss for the year was ISK 84.3 million in 2022, ISK 93.8 million in 2023, and ISK 184.0 million in 2024. The higher loss in 2024 is mainly explained by the start of amortisation of previously capitalised development costs once revenue generation began, with an amortisation expense of ISK 86.0 million in 2024, alongside higher operating costs as activities expanded. 2024 also shows operating revenue of ISK 63.7 million, mainly interest income on safeguarded funds of ISK 55.0 million plus fee income of ISK 8.7 million. Financial position and capital resources, three-year comparison Equity increased from ISK 651.2 million in 2022 to ISK 685.4 million in 2023 and ISK 1115.1 million in 2024. The reported equity ratio for 2024 is materially lower mainly because the balance sheet expands with safeguarded funds and matching liabilities rather than because equity fell in absolute terms. Capitalised development costs increased from ISK 415.5 million in 2022 to ISK 605.6 million in 2023 and ISK 773.6 million in 2024, reflecting continued investment in the platform. Liquidity and cash flow narrative Cash and cash equivalents were ISK 175.4 million at end 2022, ISK 18.7 million at end 2023, and ISK 437.7 million at end 2024. The reduction by end 2023 is consistent with the build-and-scale phase and continuing operating losses. The 2024 cash position should be interpreted alongside the safeguarding structure: safeguarded funds of e-money holders were ISK 3.872 billion and are matched by liabilities to e-money holders of the same amount. The provided annual financial statements do not include a cash flow statement, so this narrative is based on year-end cash levels and the disclosed balance sheet structure rather than a formal operating, investing and financing cash flow reconciliation. |
|||||||||||||||
| A.23 | Financial condition since registration |
|
|||||||||||||||
| A.24 | Exemption from authorisation |
|
|||||||||||||||
| A.25 | E-money token authorisation |
|
|||||||||||||||
| A.26 | Authorisation authority | ||||||||||||||||
| A.27 | Persons other than the issuer offering to the public or seeking admission to trading of the e-money token in accordance with Article 51(1), second subparagraph, of Regulation (EU) 2023/1114 | This field does not apply. | |||||||||||||||
| A.28 | Persons other than the issuer offering to the public or seeking admission to trading of the e-money token in accordance with Article 51(1), second subparagraph, of Regulation (EU) 2023/1114 |
|
|||||||||||||||
| A.29 | Reason for offering to the public or seeking admission to trading of the e-money token by persons referred to in Article 51(1), second subparagraph, of Regulation (EU) 2023/1114 |
|
| N | Field | Content | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| B.1 | Name |
|
||||||||||||||||
| B.2 | Abbreviation |
|
||||||||||||||||
| B.3 | Details of all natural or legal persons involved in design and development |
|
||||||||||||||||
| B.4 | Type of white paper | |||||||||||||||||
| B.5 | The type of submission | |||||||||||||||||
| B.6 | Crypto-asset characteristics |
Monerium e-money tokens are live on Ethereum, Gnosis, Arbitrum, Scroll, Linea, and Polygon. Each token supports functions compliant with the ERC20 and ERC2612. |
||||||||||||||||
| B.7 | Website of the issuer |
|
||||||||||||||||
| B.8 | Starting date of offer to the public or admission to trading |
|
||||||||||||||||
| B.9 | Publication date |
|
||||||||||||||||
| B.10 | Any other services provided by the issuer |
|
||||||||||||||||
| B.11 | Language or languages of the white paper |
|
||||||||||||||||
| B.12 | 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 |
Polygon: JVM0S87GB Gnosis: 3P9X6K6P2 Arbitrum One: S45L7172C Scroll: ZHKQJ78VZ Linea: 6KL7TK20G Noble: 5LN265K07 |
||||||||||||||||
| B.13 | Functionally fungible group digital token identifier, where available |
|
||||||||||||||||
| B.14 | Personal data flag |
|
||||||||||||||||
| B.15 | LEI eligibility |
|
||||||||||||||||
| B.16 | Home Member State | |||||||||||||||||
| B.17 | Host Member States |
| N | Field | Content |
|---|---|---|
| C.1 | Public offering or trading | |
| C.2 | Number of units |
|
| C.3 | Trading platforms name |
|
| C.4 | Trading platforms market identifier code (MIC) |
|
| C.5 | Applicable law |
|
| C.6 | Competent court |
|
| N | Field | Content |
|---|---|---|
| D.1 | Holder’s rights and obligations |
To enjoy redemption rights, a holder must become a Monerium customer, conditioned upon accepting our Terms of Service and successfully completing our customer due diligence (“CDD“) process. Customers can make a redemption request by submitting a redemption order via our customer interface. Applicable information must accompany the redemption request, including the beneficiary's name and account number. The customer confirms the transaction by signing a message sent to the linked blockchain address with his/her private key. Subsequently, the same amount of EURe is burnt from the holder's address, and funds (EUR) are sent via SEPA to the identified beneficiary. As Monerium is required to comply with KYC/AML and sanction rules, in some cases, redemption requests may be halted and subjected to further checks or declined. Such cases can arise where Monerium deems that the holder has violated requirements in our Terms of Services, or suspicion of money laundering, terrorist financing, or sanction violation arises. According to Art. 50 of MiCAR Monerium is prohibited from granting holders of EURe interest or any other benefit related to the length of time a holder of an EURe holds it. Therefore, holders of EURe have no claim nor are entitled to any interests or other returns earned on the funds Monerium safeguards. In case of Monerium insolvency, EURe holders enjoy a special priority statutory claim according to the Icelandic Bankruptcy Act No. 21/1991, which states that “assets and interest in the possession of the bankruptcy estate shall be delivered to a third party if the third party proves his/her entitlement.“ Thus, the funds received in exchange for EURe shall be paid from the asset pool in priority to all other creditors. Blockchain transactions are generally irreversible. When EURe is transferred to a third-party address, which is not under the holder’s control, the holder automatically transfers and assigns the right to redeem e-money in exchange for funds to that third party. That third party's right to redeem e-money received from the holder is contingent on Monerium accepting such a person as a customer. Blockchain transactions are entered into at the holder's sole responsibility; therefore, losses due to fraudulent or accidental transactions can not be recovered. Monerium may be obligated to freeze EURe that is sent or received to/from blacklisted addresses. In such cases, a holder forfeits any rights associated with EURe, including the ability to redeem EURe. |
| D.2 | Conditions of modifications of rights and obligations |
Monerium reserves the right to amend our Terms of Service that are not in our customers’ favor by providing customers with at least two (2) weeks' notice. Monerium will provide such notice to customers on our websites, via email or other electronic means. Such amendments will become effective on the date specified in the notice unless the customer notifies us otherwise prior to the date specified in the notice. If a customer does not accept our revised terms, the customer has the right, at his/her sole discretion, without any liability, to terminate our Terms of Service forthwith. As stipulated in Art. 51(12) of MiCAR, a new version of this white paper shall be drawn up, notified to competent authorities, and published on the Monerium website if any significant new factor, material mistake, or material inaccuracy capable of affecting the assessment of EURe is identified. |
| D.3 | Description of the rights of the holders |
|
| D.4 | Rights in implementation of recovery plan |
According to Art. 55 of MiCAR, which refers to Title III, Chapter 6, Monerium must draw up and maintain a recovery plan that provides measures to be taken by Monerium to restore compliance with the requirements applicable to the reserve of assets in cases where Monerium fails to comply with those requirements. In cases where events pose a significant risk of disrupting Monerium operations, the recovery plan may be implemented, which might impose certain restrictions on holders' rights, such as the following:
|
| D.5 | Rights in implementation of redemption plan |
This operational plan is intended to support the orderly redemption of EURe and ensure the equitable treatment of all EURe holders. The Central Bank of Iceland activates the redemption plan in cases where it is deemed that Monerium is unable or likely to be unable to fulfill its obligations, including insolvency, resolution, or withdrawal of Monerium's electronic money institution authorization. The redemption plan shall demonstrate Monerium's ability to redeem all outstanding EURe issued without causing undue economic harm to its holders or to the stability of the markets of the reserve assets. Activating the redemption plan may temporarily or permanently suspend the EURe holder's right of redemption to ensure fair and equitable treatment of all holders. An information notice about activating the redemption plan and its process will be published on the Monerium website and social media channels. The redemption plan will provide further information regarding claim submission, timelines, redemption process, and claim filing criteria. Redemption requests filed under the redemption plan are contingent upon the holder's successful completion of the customer due diligence process, as further explained in the Monerium Redemption Plan. |
| D.6 | Complaint submission contact |
All complaints must be objectively based and submitted in writing to complaint@monerium.com. According to Monerium, a complaint must be objectively based to be considered. |
| D.7 | Complaints handling procedures |
|
| D.8 | Dispute resolution mechanism |
The Complaint Committee is located at Guðrúnartún 1, 105 Reykjavik, with the email address fjarmal@nefndir.is and can be reached via the phone number +354 578-6500. Further information can be found on the Complaint Committee website nefndir.is. It shall be stressed that Committee rulings do not prevent subsequent case handling by a court of law. |
| D.9 | Token value protection schemes |
|
| D.10 | Token value protection schemes description |
|
| D.11 | Compensation schemes |
|
| D.12 | Compensation schemes Description |
|
| D.13 | Applicable law |
|
| D.14 | Competent court |
|
| N | Field | Content |
|---|---|---|
| E.1 | Distributed ledger technology |
|
| E.2 | Protocols and technical standards |
EURe is implemented using the native token and smart-contract standards of the blockchains on which it is deployed. On Ethereum, Arbitrum, Gnosis, Polygon and Linea, EURe is deployed as an ERC-20-compatible contract compiled for the EVM. Token balances, allowances and transfer events are stored in the contract’s on-chain state and are updated deterministically as part of EVM transaction execution. On Noble, which is built on the Cosmos SDK, EURe is issued through native modules rather than an EVM contract; issuance and redemption logic is handled by the x/florin module and balances are recorded in the Cosmos x/bank subsystem. On EVM-based networks, the EURe contracts follow the ERC-20 fungible token standard and adopt additional issuer-specific controls. The v2 contracts integrate ERC-2612 “permit” functionality, allowing off-chain signatures to authorise approvals and enabling gasless approval flows in compatible applications. The contract design also incorporates blacklist features implemented via dedicated components in the Monerium smart-contracts codebase.Token upgrades are implemented using an upgradeable proxy pattern: version 1 (V1) token addresses remain stable while delegating state management to version 2 (V2) contracts behind the scenes, so on-chain balances remain associated with a fixed address even when the underlying implementation is updated. The execution environment for EURe on Ethereum, Arbitrum, Gnosis, Polygon and Linea is an EVM-compatible virtual machine. Contracts are written in high-level languages and compiled to EVM bytecode, which is executed deterministically on all participating nodes. Transactions and blocks in the execution layer are serialised using Recursive Length Prefix (RLP) encoding, and smart-contract calls follow the Ethereum Application Binary Interface (ABI) specification. Transaction authentication relies on secp256k1-based ECDSA signatures, and addresses are represented as 20-byte values commonly displayed using EIP-55 checksum casing. Keccak-256 hashing is used to derive transaction identifiers, compute storage keys and produce internal state commitments. Client access on EVM-based networks uses Ethereum-standard JSON-RPC 2.0 interfaces exposed over HTTP(s) or WebSocket by execution clients and infrastructure providers. These interfaces allow applications and wallets to query EURe balances, inspect transfer logs at specific block heights and submit signed transactions for inclusion in the network without running a validator or full node. On Ethereum, Gnosis and Polygon, these JSON-RPC endpoints sit on top of standard Ethereum-style node stacks. On Arbitrum and Linea, JSON-RPC compatibility is maintained at the API level, but node roles differ: both networks introduce a rollup-specific sequencer component that orders transactions and batches them for settlement on Ethereum, and Linea additionally operates a prover pipeline that generates zkSNARK proofs for batched state transitions. Arbitrum exposes both general-purpose public RPC endpoints and sequencer-focused endpoints intended primarily for transaction submission. The sequencer endpoints are restricted to a narrow set of methods (for example, eth_sendRawTransaction and related calls) and are optimised for forwarding transactions into the sequencer’s ordering pipeline, whereas standard RPC URLs provide a broader read/write interface for querying chain data. This separation allows infrastructure providers to scale transaction ingress independently from state-query traffic while preserving Ethereum-style JSON-RPC semantics for most application integrations. On Noble, EURe leverages the Cosmos SDK’s native module architecture. Noble is an application-specific chain focused on asset issuance; modules such as x/florin enable native issuance of EURe, and x/bank maintains an account-based ledger of balances. Transactions are ordered and finalised via the CometBFT consensus engine, and clients interact with the chain using Cosmos RPC, gRPC and REST endpoints rather than Ethereum JSON-RPC. Token balances, transfers and module events related to EURe can be queried through these APIs or via block explorers that index Noble’s on-chain data. Across all supported blockchains networks, the EURe implementation follows consistent design principles: an account-based ledger model, deterministic on-chain execution and reliance on widely adopted, open standards for transaction encoding, cryptography and client interfaces. |
| E.3 | Technology used |
The off-chain platform reconciles fiat movements and coordinates corresponding on-chain actions. Monerium’s technical documentation describes EURe as being minted when a payment is received and burned when tokens are used to send euros via SEPA transfer, linking regulated e-money operations to on-chain balances on supported networks. Developers integrate primarily through Monerium’s REST APIs and published SDKs, which support distinct sandbox and production environments and provide mechanisms to monitor issuance/redemption workflows (e.g., via order/event subscriptions). Cross-network movement of EURe is exposed as a Monerium-operated service: users initiate the transfer in Monerium’s interface, sign the request, and Monerium coordinates the required steps across the relevant networks as part of the overall issuance/redemption and bookkeeping process. Operationally, EURe’s on-chain supply, transfers, and contract/module events remain publicly verifiable on each supported network via standard explorers and node interfaces. This enables independent verification of on-chain activity even if Monerium’s web services are unavailable, while the off-chain platform operates under the controls and requirements applicable to a licensed electronic money institution. |
| E.4 | Purchaser’s technical requirements |
A purchaser must bring his/her blockchain wallet address and link it to the Monerium interface. The purchaser will then be asked to sign a message with his/her private key to verify that he/she owns and controls the blockchain address in question. Once the customer's due diligence has been completed, a purchaser will receive an IBAN (International Bank Account Number) associated with the purchaser's blockchain address. To receive EURe, the customer must receive a euro payment via SEPA to the IBAN Monerium provided to the purchaser. Once Monerium has received the order via SEPA, the equivalent amount of euros will be minted as EURe tokens to the purchaser's blockchain wallet address. Therefore, to execute an EURe blockchain transaction, purchasers must have the technical capabilities to operate their own blockchain wallets and hold the relevant native crypto-asset to pay blockchain transaction fees. As EURe is issued on public blockchain networks, access to EURe can be achieved through various decentralized finance applications (“DeFi“). Purchasers should be aware that a direct customer relationship is required to redeem EURe directly through Monerium. EURe acquired via DeFi may become subject to further scrutiny and, in some cases, denial of service where we suspect fraudulent activity. |
| E.5 | Consensus mechanism |
On Ethereum, transaction ordering and finality are provided by Ethereum’s Proof-of-Stake consensus mechanism. Validators participate as block proposers and attesters, following Ethereum’s fork-choice rules and finality gadget to agree on the canonical chain and provide economic finality for blocks containing EURe transactions. On Gnosis Chain, EURe relies on Gnosis’ Proof-of-Stake consensus. Gnosis transitioned to this model through “The Merge” on Gnosis, adopting a separation between an execution layer and a PoS consensus layer. Validators in this model are responsible for proposing and validating blocks, and for finalising the chain that records EURe transfers. On Polygon PoS, EURe is recorded on a Proof-of-Stake network operated by a validator set that handles block production, validation and chain security. Polygon’s PoS architecture defines validator roles and the settlement design that together determine the ordering and confirmation of EURe transactions on this network. On Arbitrum, EURe operates on an optimistic rollup built on top of Ethereum. Arbitrum uses a sequencer-based ordering layer to provide fast inclusion of transactions: the sequencer orders and batches user transactions, including those involving EURe. Ultimate settlement and finality are anchored to Ethereum Layer 1, with withdrawals and finality dependent on the rollup’s dispute and challenge process on Ethereum. On Linea, EURe is supported on a zero-knowledge rollup that also relies on Ethereum for final settlement. Linea orders transactions via a sequencer and achieves economic finality through validity proofs that are verified on Ethereum. Blocks are treated as final once their associated proofs have been accepted on Layer 1, with Linea’s architecture also documenting internal coordination and attestation components that support this flow. On Noble, EURe relies on Noble’s use of CometBFT for consensus and its Proof-of-Authority model. Noble operates with a permissioned validator set, as described in Noble’s PoA documentation. These validators run CometBFT consensus to order transactions, commit blocks and provide finality for EURe state transitions on Noble. Across all these environments, EURe does not modify or extend the base-layer consensus rules. Instead, it is a token whose correctness and finality are determined by the consensus mechanisms of Ethereum, Gnosis Chain, Polygon PoS, Arbitrum, Linea and Noble respectively. |
| E.6 | Incentive Mechanisms and Applicable Fees |
On Ethereum, validators are incentivised through staking rewards and fee revenue derived from transactions included in their blocks. User transactions, including those involving EURe, pay gas fees. Under Ethereum’s EIP-1559 mechanism, these fees consist of a base fee that is burned and an optional priority fee (tip) that is paid to the block proposer or validator for transaction inclusion. On Gnosis Chain, users pay transaction fees in the chain’s gas token. Gnosis has adopted an EIP-1559-style mechanism in which a BASEFEE component of the transaction fee is burned, while a PRIORITYFEE component acts as a tip to validators, incentivising them to include transactions such as EURe transfers in their blocks. On Polygon PoS, validators are economically incentivised through the network’s Proof-of-Stake validator economics, including staking and associated rewards as defined in the Polygon PoS design. Users pay transaction fees in Polygon PoS’s native gas token. Polygon supports type-2 / EIP-1559-style transactions, and its documentation describes the fee mechanics that govern how base fees and tips are handled within the network. On Arbitrum, users pay a single transaction fee that reflects both the cost of L2 execution and the cost of posting the necessary calldata and data to Ethereum Layer 1. The sequencer plays a central role in transaction ordering and fee collection for inclusion in the rollup’s L2 chain, while the underlying economic model accounts for the costs of securing data and settlement on Ethereum. On Linea, fees are designed to cover both the cost of L2 execution and the cost of publishing data to Ethereum. Linea uses an EIP-1559-style fee model with a base fee and a priority fee, and its documentation describes in more detail the behaviour of these parameters, including the treatment of the base-fee floor under varying network conditions. On Noble, which operates under a PoA model, economic security is linked to fees captured in USDC. The globalfee module defines the transaction-fee parameters and the set of accepted fee tokens and amounts at the chain level. EURe transactions on Noble are therefore subject to Noble’s fee configuration, including the requirement to pay transaction fees in accepted fee tokens as specified by the globalfee module. From the perspective of an EURe holder, the primary direct costs of using EURe are the transaction fees imposed by the underlying network, payable in the relevant gas or fee token and any fees set out in Monerium’s own pricing for issuance, redemption and cross-chain services. |
| E.7 | Use of distributed ledger technology |
|
| E.8 | DLT functionality description |
|
| E.9 | Audit |
|
| E.10 | Audit outcome |
Ackee Blockchain’s Monerium smart contracts 22 Aug 2023
|
| N | Field | Content |
|---|---|---|
| F.1 | Issuer-related risks |
Insolvency risks: The risk of Monerium going bankrupt can severely impact the price stability of EURe and holders' capability to redeem EURe at par value. Insolvency risk can also impact Monerium's ability to perform redemptions upon request. Regulatory risks: Monerium services are conditional on complying with regulatory requirements, including maintaining a license or other governmental authorizations in the jurisdictions in which Monerium operates. Circumstances may change when more stringent requirements are imposed on companies such as Monerium. Such constraints may limit our ability to provide our services as is. Monerium may also lose its license or be subject to further restrictions when Monerium fails to meet regulatory requirements. In any such circumstances, Monerium's ability to provide EURe holders with the same level of services may be limited. Operational risks: Operational risk can stem from the inadequate implementation, execution, or overall functioning of our internal systems, processes, or procedures. Failure to manage operational risks can lead to service delays or more severe deficiencies that can materially affect EURe issuance and redemption processes. Third-party risks: Monerium relies on multiple third parties to provide the services. A third party's failure in service delivery may lead to unexpected outcomes, such as delays in performing issuing and redemption functions. Compliance risks: Failure to comply with all applicable legal requirements governing Monerium operations can lead to legal penalties and reputational loss. Customers may temporarily or permanently lose access to issuing and redemption functions in cases where suspicion of money laundering, terrorist financing, sanction evasion, or other illegitimate activities arises. Market risks: Funds that Monerium safeguards on behalf of EURe holders can decrease in value and/or become illiquid due to market forces. In such scenarios, Monerium may not execute redemption requests within the expected execution times as stated in Monerium's Terms of Service. Environmental, Social, and Governance risks: With an increased focus on ESG factors, businesses' potential negative impact on the environment and societies must be assessed and controlled. ESG risks may prevent Monerium from issuing EURe on certain blockchain networks that utilize the Proof of Work consensus mechanism due to the alleged excessive energy consumption. |
| F.2 | Token-related risks |
Price stability risks: As EURe may be acquired on secondary markets, its market value might not be stable compared to EUR. Safeguarding risks: Mismanagement of the funds Monerium receives in exchange for EURe or the insolvency of our banking partners can lead to circumstances where the safeguarded assets decrease in value, subsequently becoming lower than the outstanding issued EURe. This risk could affect Monerium's ability to redeem EURe at par and promptly. Liquidity risks: Market conditions may be such that the financial instruments Monerium invests in the safeguarded assets can become illiquid, thus deterring Monerium's ability to perform redemption upon request. This risk can materialize during market stress, bank insolvencies, or Monerium financial difficulties. Market risks: Changes in the interest rate environment can affect the value of the financial instruments Monerium invests in the safeguarded assets. Under such circumstances, Monerium may be unable to redeem EURe at par value. Fraud risks: Risk of EURe holder loss resulting from fraud, scam, or other malicious actions. Fraud can include phishing attacks, identity theft, and general scams. Taxation risks: Due to the novelty of blockchain technology, EURe's tax treatment may differ between jurisdictions. Holders should also note that because MiCA defines EURe, it may qualify as a crypto-asset and electronic money. Thus, the tax treatment of EURe may vary among EEA member states. EURe holders are solely responsible for reporting and paying all, if any, taxes associated with their EURe usage. Regulatory risks: Changes in legislation or enforcement actions carried out against Monerium can affect the legality and price stability of EURe. |
| F.3 | Technology-related risks |
Blockchain risks: Blockchain networks can become subject to technical vulnerabilities, including attacks that can lead to network disruption, such as transaction downtime, which would prevent EURe holders from executing transactions during such disruptions. Other risks derived from the use of blockchain technology are identified below:
|
| F.4 | Mitigation measures |
|
| 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 |
On Ethereum, transaction ordering and finality are provided by Ethereum’s Proof-of-Stake consensus mechanism. Validators participate as block proposers and attesters, following Ethereum’s fork-choice rules and finality gadget to agree on the canonical chain and provide economic finality for blocks containing EURe transactions. On Gnosis Chain, EURe relies on Gnosis’ Proof-of-Stake consensus. Gnosis transitioned to this model through “The Merge” on Gnosis, adopting a separation between an execution layer and a PoS consensus layer. Validators in this model are responsible for proposing and validating blocks, and for finalising the chain that records EURe transfers. On Polygon PoS, EURe is recorded on a Proof-of-Stake network operated by a validator set that handles block production, validation and chain security. Polygon’s PoS architecture defines validator roles and the settlement design that together determine the ordering and confirmation of EURe transactions on this network. On Arbitrum, EURe operates on an optimistic rollup built on top of Ethereum. Arbitrum uses a sequencer-based ordering layer to provide fast inclusion of transactions: the sequencer orders and batches user transactions, including those involving EURe. Ultimate settlement and finality are anchored to Ethereum Layer 1, with withdrawals and finality dependent on the rollup’s dispute and challenge process on Ethereum. On Linea, EURe is supported on a zero-knowledge rollup that also relies on Ethereum for final settlement. Linea orders transactions via a sequencer and achieves economic finality through validity proofs that are verified on Ethereum. Blocks are treated as final once their associated proofs have been accepted on Layer 1, with Linea’s architecture also documenting internal coordination and attestation components that support this flow. On Noble, EURe relies on Noble’s use of CometBFT for consensus and its Proof-of-Authority model. Noble operates with a permissioned validator set, as described in Noble’s PoA documentation. These validators run CometBFT consensus to order transactions, commit blocks and provide finality for EURe state transitions on Noble. Across all these environments, EURe does not modify or extend the base-layer consensus rules. Instead, it is a token whose correctness and finality are determined by the consensus mechanisms of Ethereum, Gnosis Chain, Polygon PoS, Arbitrum, Linea and Noble respectively. |
| S.5 | Incentive Mechanisms and Applicable Fees |
|
| S.6 | Beginning of the period to which the disclosed information relates |
|
| S.7 | End of the period to which the 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/methodology |
| 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) |
|
| S.29 | Impact of the use of equipment on natural resources |
|
| S.30 | Natural resources use reduction targets or commitments |
|
| S.31 | Water use |
|
| S.32 | Non recycled water ratio |
|
| Sources and and methodologies | ||
| S.33 | Other energy sources and methodologies |
Full methodology available at: www.micacryptoalliance.com/methodologies |
| S.34 | Other GHG sources and methodologies |
Full methodology available at: www.micacryptoalliance.com/methodologies |
| S.35 | Waste sources and methodologies |
Full methodology available at: www.micacryptoalliance.com/methodologies |
| S.36 | Natural resources sources and methodologies |
|