ESMA MiCA White Paper Reporting Manual (XBRL taxonomy)

July 2025 ESMA65-55014868-14829

MiCA White Paper Reporting Manual Preparation of MiCA Crypto-Asset White Papers in iXBRL format

5 August 2022| ESMA32-60-254rev

Table of Contents I.

II. III.

IV. 1.1

1.2 1.3

1.4 1.5

2.2 2.3

2.4 2.5

Introduction Background 1. The Market in Crypto-Asset regulation ((EU) 2023/1114) lays down uniform requirements for the offer to the public and admission to trading on a trading platform of crypto-assets other than asset-referenced tokens and e-money tokens (OTHR), of asset-referenced tokens (ART) and of e-money tokens (EMT). Depending on the crypto-asset type (OTHR/ART/EMT), the regulation specifies requirements to comply by the following stakeholders: ▪

OTHR asset - Offeror, person seeking admission to trading, or operator of trading platforms for crypto-assets other than asset-referenced tokens and e-money tokens.

ART asset - Authorised issuers and Credit Institution.

EMT asset - Credit institution or electronic money institution.

One of those requirements for those stakeholders is to draw-up (create or modify) a crypto-asset white paper document.

2. Content and form of a white paper depend on the type of a crypto asset (OTHR/ART/EMT). The Implementing Technical Standard (EU) 2024/2984 (‘ITS’) defines forms, formats and expected templates for each type of crypto-asset white paper. This technical standard specifies that: -

Extract of article 1: “Persons drawing up a crypto-asset white paper referred to in Article 6(1), Article 19(1) or Article 51(1) of Regulation (EU) 2023/1114 shall provide the information required by this Regulation in a manner that is nondiscriminatory, fair, clear and not misleading, presented in a concise and comprehensible form and shall not omit material information.”

Extract of article 2: “Crypto-asset white papers shall be drawn up in XHTML format marking the fields set out in the Annex using Inline XBRL 1.1 specifications of the eXtensible Business Reporting Language (XBRL) and shall comply with the following requirements: a. the Inline XBRL instance document containing the crypto-asset white paper shall be submitted as a single XHTML file;…”

Extract of article 3: “ESMA may publish machine-readable and downloadable XBRL taxonomy files based on the taxonomy referred to in Article 2(2).”

3. Once completed, the white paper document that is created or modified (as per the meaning of “modification” under MICA regulation), is sent by the reporting entity to his competent authority associated; it means the competent authority of the home Member State, or the European Banking Authority.

Purpose 4. This document has been produced to assist reporting entities obliged under the MiCA ITS to prepare white papers, as well as software vendors assisting such entities in creating white papers that are compliant with the ITS on MiCA. It provides guidance 3

on technical common issues that may be encountered when creating white paper documents and explains how to resolve them. The purpose of this document is to promote a harmonized and consistent approach for the preparation of white papers in the format specified in the ITS on MiCA.

5. The content of this document is aimed at reporting entities who are required to

prepare white papers in iXBRL format in accordance with MiCA regulation, and at software firms developing software used for the preparation of white papers.The aim of the guidelines defined in this document is to facilitate the analysis and comparison of XBRL data contained in Inline XBRL documents;this document provides guidance on the expected syntax and structure of Inline XBRL documents.

This document contains parts that are of a highly technical nature, especially section IV.2.Several sections of this document are intended for a technical audience and assume that the reader has a working knowledge of the XBRL 2.1, XBRL Dimensions 1.0, Inline XBRL 1.1 and other XBRL specifications1 and has a basic understanding of XML, Namespaces and XML Schema.

6.This document is fully aligned with the technical rules and constraints defined in the referenced XBRL technical specifications.Some guidelines may however be more restrictive and precise to address the specifics of the iXBRL format.This Manual contains some additional validation rules that ESMA recommends applying.

Each white paper should be valid against validation rules included in the MiCA white paper taxonomy package, and ESMA recommends software vendors to implement them within their solutions to produce MiCA inline XBRL reports.In case no specific guidance is provided in this Manual, XBRL specifications must be followed.

Furthermore, if any aspect or mechanism covered by the XBRL specifications is not specifically mentioned in this Manual, it does not mean that such aspect or mechanism cannot be used in the MiCA inline XBRL report.

7. Each guidance item presented in this document is provided with an indication of

criticality. ESMA considers that all items marked as ‘MUST’ or ‘SHALL’ are critical to facilitate the consumption and comparability of a MiCA inline XBRL document. Items marked as ‘SHOULD’ do not generally impact the overall usability of a MiCA file, although this may need to be assessed on a case-by-case basis.

8. The content of this document is not exhaustive, and it does not constitute new policy. This document is intended to be updated as and when the need to do so arises.

9.In the XBRL taxonomy framework for MiCA regulation, three primary entry points are defined for: a.Asset-Referenced Token (ART) white paper, b.E-Money Token (EMT) white paper, c.and white paper of crypto-asset other than asset-referenced token and emoney token.Each entry point corresponds to a specific type of crypto-asset, as specified in the templates for the crypto-asset white papers defined in the annex of Implementing Technical Standard (EU) 2024/2984.

These entry points are intended for use by reporting entities.For software venders’ technical purposes, a fourth entry point has been created, dedicated to the full content of the taxonomy.

https://specifications.xbrl.org/

II. Summary table of updates Reporting manual version 1.0

Document updates (incl. guidance number…) Creation of the document

Release date July 2025

III. Glossary The following definitions of XBRL-related terms are provided to support and facilitate understanding of this document. Official definitions can be found in the XII Glossary published by XBRL International 2.

abstract

An attribute of an element to indicate that the element is only used in a hierarchy to group related elements together. An abstract element cannot be used to tag data in an instance document.

abstract concept

A taxonomy element that has an abstract attribute set to “true” and that is not used to defined hypercubes, dimensions and members. It can also be referred to as header.

arcrole

Technical construct used in XBRL linkbases to identify the type of relationship between elements.

attribute

A property of an element such as its name, balance, data type, period type and whether the element is abstract.

block tag

A single fact that contains the content of an entire or a part of a section of a report. A block tag may include text, numeric values, tables and other data. A block tag is applicable to facts with datatype of dtrtypes:textBlockItemType.

concept

A taxonomy element that provides the meaning for a fact. Concept in this context excludes abstract concepts, and elements that are used to define hypercubes, dimensions and members.

context

Entity and fact-specific information (reporting period, segment/scenario information, and so forth) required by XBRL that allows tagged data to be understood in relation to other information.

crypto-asset White Paper

Regulated information is defined in Articles 6, 19 and 51 of the Regulation (EU) 2023/1114.

dimension

XBRL technical term for axis.

documentati on label

Documentation of a concept, providing an explanation of its meaning and its appropriate usage and any other documentation deemed necessary.

2 https://www.xbrl.org/guidance/xbrl-glossary/

domain

An element that represents a set of members sharing a specified semantic nature;the domain and its members are used to classify facts along the axis of a table.For example, "Lithuania" is a domain member in the domain "Member States," and would be used to classify elements such as revenues and assets in Lithuania as distinct from other Member States.

When a fact does not have any domain member specified, that means it applies to the entire domain or to a default member of a domain set in the taxonomy.

domain member

An element representing one of the possibilities within a domain.

element

XBRL components (items, domain members, dimensions, and so forth). The representation of a reporting concept, including line items in the face of the statements, important narrative white paper elements, and rows and columns in tables.

ELR

Extended Link Role, a set of relations representing a particular piece of a report indicated by a role. Extended link roles are used in taxonomies to separate linkbases into smaller logical chunks

MiCA taxonomy

The taxonomy to create a white paper document in line with MiCA regulation.

fact

The occurrence in an instance document of a value or other information tagged by a taxonomy element.

hypercube

XBRL technical term for a table.

Inline XBRL

Technology that provides a mechanism for embedding XBRL tags in HTML documents. This allows the XBRL benefits of tagged data to be combined with a human-readable presentation of a report.

Inline XBRL document

A single document that combines structured, computer-readable data with the reporting entity’s human-readable presentation of a business report using the Inline XBRL standard.

Inline XBRL document set

A group of one or more Inline XBRL documents which when comprising sufficient metadata results in one or more target XBRL document when transformed according to the mapping rules prescribed in the technical specification.

ITS

Implementing Technical Standard (EU) 2024/2984

label

Human-readable description for an element. Each element has a standard label that normally corresponds to the element name, and is unique across the taxonomy. Elements may have also other labels (commentary, documentation, standard, terse) in particular documentation labels containing more elaborate descriptions of the element’s definition, meaning, scope and application.

line item

Line items normally represent the concepts being reported. They are used to markup numeric information as well as qualitative (nonnumeric) information. Line items can be used either individually or in a table (in combination with axis and axis members).

linkbase

XBRL technical term for a relationships file.

namespace

A namespace is the “surname” of an element represented as a Universal Resource Identifier (URI) identifying the organization that maintains the element definition and its version. For example, https://www.esma.europa.eu/taxonomy/2025-03-31/mica/ is a namespace of the 2025 version of the MiCA white paper taxonomy defined by the ESMA.

parent-child relationship

The relationship between elements that indicates subordination of one to the other as represented in a print listing or a statement presentation. Relationships files use parent-child hierarchies to model several different relationships, including presentation, particular cases of summation of a set of facts, and membership of concepts within a domain used as the axis of a table.

period type

An attribute of an element that reflects whether it represents a stock (‘instant’ in XBRL terminology) that is reported at a particular date or a flow (‘duration’) reported in a time period.

Reporting entity

MiCA white paper reporting entity.

segment/ scenario

Components of contexts containing additional information to be associated with facts in an instance document; this information encompasses in particular the dimensional classifications or breakdowns defined by axes and domain members in taxonomies.

standard label

The default label for an element defined in a taxonomy.

terse label

Short label for a concept, often omitting text that should be inferable when the concept is reported in the context of other related concepts.

table (XBRL context)

An element that organizes a set of axes and a set of line items to indicate that each fact of one of the line items could be further characterized along one or more of its axes.

For example, if a line item is ‘Revenues’ and an axis is ’Segments’ and this axis has the following two domain members ‘Reportable segments’ and ‘All other segments’, the XBRL instance document and Inline XBRL document could include facts representing revenues with breakdowns for ‘Reportable segments’ and ‘All other segments’.

tag or mark up (verb)

To use taxonomy elements to identify information reported in a report.

target XBRL document

The XBRL-valid XBRL instance document represented by metadata in the Inline XBRL document set.

taxonomy, taxonomies

Electronic dictionary of business reporting elements used to report business data.A taxonomy is composed of a schema file or files (with extension .xsd) and relationships linkbase files (with extension .xml) directly referenced by that schema.The taxonomy schema files, together with the relationships files, define the concepts (elements) and relationships that form the basis of the taxonomy.The set of related schemas and relationships files altogether constitute a taxonomy.

Set of instructions which when applied to a string used in the reporting entity’s report outputs a value in an XBRL-valid format and in a predefined data type.

transformati on rule type or data type

Data types (monetary, string, share, decimal, and so forth) define the kind of data to be tagged with the element name.

typeddimensions

A taxonomy-defined dimension is a dimension specified within a taxonomy rather than being a built-in dimension.It serves to provide additional qualifications necessary to fully identify a fact.For instance, it may specify that a fact pertains to a particular geographic region.Such dimensions can be "typed," meaning the taxonomy defines the format of their values (e.g., the structure of a postal code).

Uniform Resource Identifier is a string of characters used to identify a resource.

URI

validation

The process of checking that instance documents and taxonomies correctly meets the rules of the XBRL specification.

IV. Guidance 1 Guidance for reporting entities 1.0 Presentation of White Papers in iXBRL Guidance 1.0.1 Presentation of White Papers in the iXBRL format Each White Paper shall be prepared in an Inline XBRL file format, as specified in MiCA Regulation.

1.1 Use of languages Guidance 1.1.1 Language of labels The crypto-asset White Paper shall be drawn up in an official language of the home Member State of the reporting entity, or in a language customary in the sphere of international finance.

Where the crypto-asset is also offered in a Member State other than the home Member State, the crypto-asset White Paper shall also be drawn up in an official language of the host Member State or in a language customary in the sphere of international finance.

Guidance 1.1.2 White Papers presented in more than one language When a reporting entity needs to present a white paper in two (or more) languages, a dedicated document for each language shall be prepared within a file format compliant with Guidance 1.0.1.From a technical standpoint, a different language version of the white paper will be considered as a separate white paper iXBRL file.Those two or more iXBRL files shall be submitted to his competent authority associated.

Such iXBRL files shall be tagged in the exact same way, regardless of the language in which they were prepared.Specifically, all language versions of a white paper shall be consistent in terms of the iXBRL file's contents, and such contents shall be tagged with the use of the same taxonomy elements (which should be shared across the iXBRL file presented in different languages).

1.2 Selection of appropriate elements to mark up disclosures Guidance 1.2.1 Use of labels to select appropriate elements Element labels provide human-readable descriptions of the meaning of a taxonomy element.Element names and standard labels may not exactly align with ITS field names;however, each reportable element includes a concise label that follows the ordering from the ITS (EU) 2024/2984.This facilitates easier identification of corresponding elements for tagging.10

1.3 Use of dimensions and enumerations Guidance 1.3.1 Use of dimensions XBRL taxonomies are designed to represent the reporting templates used in the reporting process.These templates are constructed of technical structures (ELRs) and are intended to encompass all requirements that align with the reporting entity's obligations to provide information within a specific reporting framework.The construction of a structure typically reflects a specific area of information.

While each defined area of information is represented by a single structure, certain parts of it may be intended for further disaggregation.The XBRL standard allows for such structures using additional components, specifically dimensions, which are dedicated to line items undergoing further disaggregation for different item types, categories, classes or maturities.

Therefore, XBRL taxonomies contain line items and dimension components, which are both elements used to markup data.Line items normally represent the concepts being reported.They are used to markup numeric information as well as qualitative (non-numeric) content.Line items are stand-alone but can be used either individually or on a table (in combination with axis and potentially axis members).Dimension components may or may not be predefined in the taxonomy explicitly.

The MiCA white paper taxonomy restricts the use of dimensions with an explicit list of domain members with a fixed number of domain members and instead embraces typed dimensions, as of current, no explicit dimensions are applied in the context of MiCA white paper taxonomy.With the typed dimensions reporting entities can comply with requirements without being constrained by a closed reporting structure.

Type dimensions allow reporting entities to report as many items as necessary based on the actual state of the reporting entity, providing greater flexibility in the disclosure process.The reporting entities must bear that such constructions do not provide domain members in the tagging process but instead shift the responsibility of defining characteristics for metadata used for tagging on the reporting entities.

Typed dimension used in context of MiCA white paper is technically restricted to line identifiers rather than meaningful typed value.Line identifier

Identity

Business address

Function

Identity_1

Address_1

Function_1

Identity_2

Address_2

Function_2

Identity_3

Address_3

Function_3

Example for Members of management body typed dimension

Guidance 1.3.2 Restrictions on allowable content for information disclosure with the usage of enumerated lists XBRL taxonomies facilitate the imposition of constraints on permissible disclosure content. The MiCA white paper taxonomy utilizes that possibility and associates an 11

element with a predefined set of acceptable values, if such applies. For that reason, the taxonomy includes the Extensible Enumeration 2.0 specification3. Although there is not yet a transformation rule able to properly display the implementation of Extensible Enumeration 2.0 items in a human-readable way in the iXBRL white paper and for that reason it is recommended to follow the hidden section guidance and apply relevant styles.

1.4 Units of measure Guidance 1.4.1 Use of standard units of measure As per the XBRL 2.14 and Inline XBRL 1.15 specifications, each numeric tag must be associated with a unit of measure.To achieve consistency in the use of units of measure (e.g.EUR for Euro, GW for Gigawatt, km for Kilometre, etc.) in Inline XBRL documents, reporting entities should check the XBRL specifications and unit registry6 whether a required unit exists before defining a custom unit.

Preparers are discouraged from defining and using units that imply a scale factor on a given measure (e.g.millions of EUR) because the Inline XBRL specifications already provide a scale attribute which indicates the required scaling value.Under the MiCA white paper framework, the recommended use of units for reporting purposes is as follows: 1.Monetary → iso4217:{currency_code} 2.Energy → utr:kWh for Kilowatt-Hours 3.

Emissions CO2 → utr:tCO2 for Metric tons of CO2 equivalent 4.Mass → utr:t for Tones 5.Volume → utr:m3 for Cubic Meter 6.Decimal → xbrli:pure

1.5 Block tagging Guidance 1.5.1 Considerations for block tagging In instances where multiple pieces of text corresponding to a single block tag are disclosed in different sections of the white paper, reporting entity should tag such information using one block tag with the Inline XBRL constructs, which allow for the concatenation (or exclusion) of text content within the document.

3 https://specifications.xbrl.org/work-product-index-extensible-enumerations-extensible-enumerations-2.0.html 4 http://www.xbrl.org/Specification/XBRL-2.1/REC-2003-12-31/XBRL-2.1-REC-2003-12-31+corrected-errata-2013-02- 20.html#_4.6.2 5 http://www.xbrl.org/specification/inlinexbrl-part1/rec-2013-11-18/inlinexbrl-part1-rec-2013-11-18.html#sec-nonFractions 6 https://www.xbrl.org/utr/utr.xml

2 Guidance for software firms to ensure technical validity The following section provides software firms with recommendations on the technical aspects and rules that their tools should support to facilitate harmonized reporting by reporting entities.Furthermore, it offers guidance on which messages could be used to alert users when a recommended rule has been violated.

To enhance the clarity of this document, recommended rules and messages are highlighted in grey boxes and red font.

2.1 Contexts Guidance 2.1.1 Reporting entity identification According to MiCA regulation, reporting entities shall identify themselves in the Inline XBRL document by using either an ISO 17442 Legal Entity Identifier (LEI) or another identifier required pursuant to applicable national law.Where an LEI is used, it shall be implemented in such a manner that the identifier elements have a valid Legal Entity Identifier (LEI) as their content.

The scheme attribute of the identifier elements shall have "http://standards.iso.org/iso/17442" as its content.Example (from http://codes.eurofiling.info/): <xbrli:entity> <xbrli:identifier scheme=”http://standards.iso.org/iso/17442″> KGCEPHLVVKVRZYO1T647 </xbrli:identifier> <xbrli:entity> It is recommended that software firms include appropriate validations in their tools.

The following messages are recommended to be used: Messages: “invalidIdentifierFormat” and “invalidIdentifier”

Guidance 2.1.2 Formatting of the period element in the context of the Inline XBRL document It is recommended to present the period element in the yyyy-mm-dd format, i.e.without the time component (an example, a period element including a time component would appear as: 2025-01-01T00:00:00:00).A time component is not expected to be necessary when tagging MiCA white papers.

It is recommended that software firms include appropriate validations in their tools, to ensure that: The xbrli:instant elements MUST identify periods using whole days (i.e.specified without a time content and time zone).In case of violation, the following messages are recommended to be used: Violation: “periodWithTimeContent”, “periodWithTimeZone”

Guidance 2.1.3 Use of segment and scenario containers in the context elements of Inline XBRL documents The XBRL 2.1 specification defines two open containers in context elements of XBRL instance documents.These are xbrli:segment and xbrli:scenario.According to the XBRL Dimensions 1.0 specification, a taxonomy prescribes which of the two shall be applied in XBRL instance documents to contain dimension members.

For MiCA white paper purpose, it is recommended to use xbrli:scenario.Therefore, it is recommended that software firms include appropriate validations in their tools, to ensure that: xbrli:segment container MUST NOT be used in contexts.In case of violation, the following message is recommended to be used: Violation: “segmentUsed When using the xbrli:scenario in contexts, it shall not contain any content other than the one defined in XBRL Dimensions specification.

Consequently, custom XML shall not be used in xbrli:scenario.It is recommended that software firms include appropriate validations in their tools, to ensure that: xbrli:scenario in contexts MUST NOT contain any other content than defined in XBRL Dimensions specification.The following messages are recommended to be used: Messages: “scenarioContainsNonDimensionalContent”

Guidance 2.1.4 The Inline XBRL document shall only contain data of the reporting entity It shall be ensured that the Inline XBRL document contains data only of a single reporting entity. It is recommended that software firms include appropriate validations in their tools, to ensure that: All entity identifiers and schemes in contexts MUST have identical content In case of violation, the following message is recommended to be used: Violation: “multipleIdentifiers”

2.2 Facts Guidance 2.2.1 Attributes defining accuracy of numeric facts A single attribute describing the precision of facts shall be used consistently, as indicated in the Working Group Note published by XBRL International7. Therefore, it is recommended that software firms include appropriate validations in their tools, to 7 http://www.xbrl.org/WGN/precision-decimals-units/WGN-2017-01-11/precision-decimals-units-WGN-2017-01- 11.html#inconsistent-

levels-of-accuracy

ensure that: The accuracy of numeric facts MUST be defined with the ‘decimals’ attribute rather than the ‘precision’ attribute.The following messages are recommended to be used: Messages: “precisionAttributeUsed” As indicated in guidance from XBRL International8, it should be noted that the scale factor used in iXBRL is separate from the XBRL "accuracy" mechanism (expressed using "decimals" or "precision").

Examples of the application of the ‘scale’ and ‘decimals’ attributes can be found at https://www.xbrl.org/guidance/ixbrl- taggingfeatures/#3-scaling-numeric-values.

Guidance 2.2.2 Representation of rates, percentages and ratios Reporting entities should ensure a consistent XBRL representation of percentages in decimal notation.For that purpose, it is recommended that white paper reports follow the provisions of XBRL 2.1 specification published by XBRL International9.

As an example, following the above-mentioned specifications, if a reporting entity wants to tag a percentage value of 81%, this shall be tagged with ix:nonFraction element with a unit of pure10 and a scale attribute set to -2, resulting in XBRL representation of the value correct notation, i.e.as 0.81.

Guidance 2.2.3 Transformation of facts Whenever a string or numeric value used in a White Paper report does not conform to the format defined by the predefined data type of the taxonomy element used to tag it, a transformation rule shall be applied.

For that purpose, it is recommended to apply the Transformation Rules Registry 5 as published by XBRL International on the dedicated website11 or any more recent versions of the Transformation Rules Registry provided with a ‘Recommendation’ status at XBRL International.

Guidance 2.2.4 Facts duplication According to the Working Group Note on handling duplicate facts12 published by XBRL International, there are four classes of duplicates for numeric and non-numeric facts: ▪ ▪ ▪ ▪

Complete duplicates, Consistent duplicates (numeric only), Multi-language duplicates (string only), Inconsistent duplicates

8 https://www.xbrl.org/guidance/ixbrl-tagging-features/#3-scaling-numeric-values 9 http://www.xbrl.org/Specification/XBRL-2.1/REC-2003-12-31/XBRL-2.1-REC-2003-12-31+corrected-errata-2013-02- 20.html#_4.8.2 10 http://www.xbrl.org/Specification/XBRL-2.1/REC-2003-12-31/XBRL-2.1-REC-2003-12-31+corrected-errata-2013-02- 20.html#_5.1.1.3.1 11 https://specifications.xbrl.org/work-product-index-inline-xbrl-transformation-registry-4.html

12 https://www.xbrl.org/WGN/xbrl-duplicates/WGN-2015-12-09/xbrl-duplicates-WGN-2015-12-09.html

Reporting entities shall not use numeric taxonomy elements to markup different values for a given context unless the difference is a result of rounding related to presentation of the same information with a different scale in more than one place in the same report.Based on the above definitions of duplicates, it is required that reporting entities shall not report inconsistent duplicates within the content of an inline XBRL document.

Therefore, it is recommended that software firms include appropriate validations in their tools, to ensure that: Inconsistent duplicate numeric facts MUST NOT appear in the content of an inline XBRL document.In case of violation, the following message is recommended to be used: Violation: inconsistentDuplicateNumericFactInInlineXbrlDocument Inconsistent duplicate non-numeric facts SHOULD NOT appear in the content of an inline XBRL document.

In case of violation, the following message is recommended to be used: Violation: inconsistentDuplicateNonnumericFactInInlineXbrlDocument

Guidance 2.2.5 Readability of the information extracted from a block tag Due to the mechanics of producing XHTML documents, some narrative blocks extracted into an XBRL instance may not remain formatting identical to the original document when viewed in isolation (e.g., lost table structures, styles, or line breaks).As a result, the extracted information may lack legibility and clarity.

Block tagging for MiCA white paper should be able to designate meaningful fragments of a well-formed XHTML document that are extracted into XBRL for processing, notably that the underlying XHTML code contains the appropriate style attributes that allow for a proper display of tagged data13.That means that the extracted information, when displayed outside the context of the original document, retains the original’s legibility and clarity, though not necessarily its style.

In any case, reporting entities should ensure that the information extracted/rendered in the tag: -

presents the words and numbers in the same order and is as legible and clear as the human-readable report where there is space between words and numbers in the source text, there is at least some space retained in the text block (i.e. “e-money tokens 3m EUR” should not become “emoneytokens3mEUR” after extraction) information that is contained in tables in the human-readable report is meaningfully transcribed in the extracted tagged information.

Guidance 2.2.6 Technical construction of a block tag Limitations of transformation mechanics in the production of XHTML documents are known and understood within the XBRL community. 13 For example, in the case of information presented in a tabular format in the full document, the code underlying the XHTML document

could contain relevant HTML table tags such as <table>, <th>, <tr>, etc which would ensure that the extracted tagged data includes a presentation of the fact value in a tabular format.

Until transformation mechanics are further improved, it is recommended that, for white papers purpose, reporting entities follow the guidance below to ensure a better consistency of the extracted tagged information from the human-readable report.

In line with the XBRL International Working Group Note published on 19 April 202314, for facts with a datatype of dtr-types:textBlockItemType, reporting entities shall always set the iXBRL @escape attribute to “true” to ensure that the resulting fact value is XHTML valid.Meanwhile, the facts with other data types, such as xbrli:stringItemType shall instead set the @escape attribute to "false" as their values are not expected to contain XHTML.

Value of the @escape attribute MUST match the data type of the corresponding fact.Therefore, all facts with datatype of dtr-types:textBlockItemType MUST use the @escape attribute set to “true”.Moreover, facts with other datatypes, such as xbrli:stringItemType MUST use the @escape attribute set to “false”.In case of violation, the following message is recommended to be used.Violation: improperApplicationOfEscapeAttribute

Guidance 2.2.7 Use of the ID attribute on facts Including unique ID attributes for each tagged fact enhances data analysis and improves processing efficiency for end-users. Therefore, for white paper purposes, reporting entities should include an ID attribute with a unique value for each tagged fact in their reports.

2.3 Restrictions on Inline XBRL and other constructs Guidance 2.3.1 Inline XBRL constructs that shall be avoided For MiCA white paper reporting scenario, only facts that are not eligible for transformation can be included in the ix:hidden section (i.e.where content is not intended for display).Therefore, a fact can be included in the ix:hidden section only if no applicable transformation rule exists in the latest recommended Transformation Rules Registry (e.g.

, for enumerationSetItemType).The Inline XBRL specification does not permit XHTML markup (e.g.<xhtml:span>) to be included within numeric facts.For the purposes of MiCA white papers, XHTML content within numeric values is unnecessary and should be removed to facilitate tagging.The ix:hidden should not be used as a workaround to tag such values.

In such case, the visible text in the report corresponding to the hidden fact shall have applied a custom style property “-ix-hidden”15 which value follows the id attribute of that fact.Unlike other style properties, the value of ‘-ix-hidden’ is not inherited.For example, for the element “E.1 Public offering or admission to trading”:

14 https://www.xbrl.org/WGN/html-for-ixbrl-wgn/WGN-2023-04-19/html-for-ixbrl-wgn-2023-04-19.html 15 https://www.xbrl.org/WGN/html-for-ixbrl-wgn/WGN-2024-11-05/html-for-ixbrl-wgn-2024-11-05.html#sec-hidden-fact-css-link

The real tag for this element is: <ix:nonNumeric name="mica:PublicOfferingOrAdmissionToTrading" contextRef = "_ctx1" id="mica_PublicOfferingOrAdmissionToTrading_ctx1" escape="false"> https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#AdmissionToTrading </ix:nonNumeric> But the report file includes a human-readable layer with the hidden tag:

<div style="-ix-hidden:mica_PublicOfferingOrAdmissionToTrading_ctx1;">Admission to trading</div></td> where mica_PublicOfferingOrAdmissionToTrading_ctx1mica_PublicOfferingOrAdmissionTo Trading_ctx1 is the value of the id attribute on the fact in the hidden section and “Admission to trading” corresponds to its value in the report (that would have been transformed to the fact value should a transformation rule be available).

It is recommended that software firms include appropriate validations in their tools, to ensure that: The ix:hidden section of Inline XBRL document MUST not include elements eligible for transformation.In case of violation, the following messages are recommended to be used: Violation: “transformableElementIncludedInHiddenSection” Violation: “factInHiddenSectionNotInReport”

Guidance 2.3.2 Other constructs that shall be avoided Application of the HTML <base> element or ‘xml:base’ attribute makes the processing of the Inline XBRL document more complex and may impact references to other files, images or CSS styles. Therefore, these items shall not be used. It is recommended that software firms include appropriate validations in their tools, to ensure that:

The HTML <base> elements and xml:base attributes MUST NOT be used in the Inline XBRL document. In case of violation, the following messages are recommended to be used: Violation: “htmlOrXmlBaseUsed”

2.4 Other content of Inline XBRL documents Guidance 2.4.1 Inclusion of content other than XHTML and XBRL in the Inline XBRL document The inclusion of an executable code in an Inline XBRL document is a potential threat and may cause security issues.Software firms shall therefore inspect resources embedded or referenced by the XHTML document and its inline XBRL to ensure that no malicious content or executable code is included in the “machine-readable layer” of the document, i.

e.in images, headers of images, style properties, or other resources which make up the content of a document and which would be retrieved as part of its rendering.Since the Inline XBRL document is a format requirement and is not expected to impact the “human readable layer” of a report, this guidance should not be seen as limiting the inclusion of links to external websites, to other documents or to other sections of the report.

In case of inclusion references to e-mail addresses, these should be provided in the form of a non-linked text, i.e.stripped of the ‘mailto’ link.It is recommended that software firms include appropriate validations in their tools, to ensure that: Resources embedded or referenced by the XHTML document MUST NOT contain executable code (e.g.java applets, javascript, VB script, Shockwave, Flash, etc).

In case of violation, the following message is recommended to be used: Violation: “executableCodePresent” This also applies to embedding script-based inline XBRL viewers as part of Inline XBRL documents.For MiCA white papers, images should be included in the XHTML document.Preparers are encouraged to ensure that their file size does not exceed the support of browsers.

Images embedded in the XHTML document as a base64 encoded string shall specify media type as defined by MIME RFC 2045 (hereinafter referred to as MIME type) whose content corresponds to the MIME specified.In case of images that are not embedded in the XHTML (and only referenced by the XHTML) where the MIME type is not specified, such files shall match their file extension.

Therefore, it is recommended that software firms include appropriate validations in their tools, to ensure that: 19

Images embedded in the XHTML document as a base64 encoded string MUST have the correct MIME type specified.In case of violation, the following message is recommended to be used: Violation: “incorrectMIMETypeSpecified” Violation: “MIMETypeNotSpecified” Images not embedded in the XHTML document where MIME type is not specified MUST match their file extensions.

In case of violation, the following message is recommended to be used: Violation: “imageDoesNotMatchItsFileExtension” To avoid any potential threats that may be brought by specific formats used for saving images included in the XHTML document, reporting entities shall only use PNG, GIF, SVG (please note that direct embedding of <svg> elements is not allowed and the SVG images shall be included in <img> element) or JPEG graphic files.

Therefore, it is recommended that software firms include appropriate validations in their tools, to ensure that: Images included in the XHTML document MUST be saved in PNG, GIF, SVG or JPEG formats.In case of violation, the following message is recommended to be used: Violation: “imageFormatNotSupported” Preparers shall not embed images carrying information in the white papers.

Images can only be used for content such as branding information, graphical layout, photographs, etc.

Guidance 2.4.2 Indication of the language used in textual mark ups It is recommended to apply the ‘xml:lang’ attribute - indicating the report’s language on the root HTML element of the XHTML file.Additionally, the attribute should also be applied to the ‘ix:references’ tag, from which it shall be transformed to the root xbrli:xbrl element in the resulting XBRL instance document.

Each tagged text fact16 should have an ‘xml:lang’ attribute that is assigned to the fact or inherited e.g.from the root element.Its value must correspond to the language of text in the content of a tag.To enable automatic checks on whether all tags in the report are provided in at least the language of the report, it is recommended that software firms include appropriate validations in their tools to ensure that:

16 As defined in http://www.xbrl.org/Specification/oim/CR-2020-05-06/oim-CR-2020-05-06.html#term-text-fact.

Each tagged text fact MUST have the ‘xml:lang’ attribute assigned or inherited, and all tagged text facts MUST be provided in at least the language of the report. In case of violation, i.e. missing ‘xml:lang’ attribute, the following message is recommended to be used: Violation: “undefinedLanguageForTextFact” Violation: “taggedTextFactOnlyInLanguagesOtherThanLanguageOfAReport”.

Guidance 2.4.3 Use of more than one target XBRL document for an Inline XBRL Document Set (IXDS) Only one MiCA white paper XBRL instance document is expected in a filing.Therefore, MiCA white paper content must be in a default target document (i.e.without the target attribute), and other target documents must not be used.It is recommended that software firms include validation rules in their tools to ensure that: Target attribute SHOULD not be used.

In case of violation, the following message is recommended to be used: Violation: “targetAttributeUsedForMiCAContents”

Guidance 2.4.4 Use of the Cascading Style Sheet (CSS) language to style the Inline XBRL document CSS may be used to format the reports.However, the transformations need to be used appropriately.For example, they must not be used to hide information by making it not visible e.g.by applying display:none style on any tagged facts.Moreover, it is recommended to apply styles globally rather than define them separately for each part of the report.

For MiCA white papers, it is recommended that software firms include validation rules in their tools to ensure that: The CSS SHOULD be embedded within the document.In case of violation, the following message is recommended to be used: Violation: “externalCssFile”

Guidance 2.4.5 Application of ix:continuation and ix:exclude elements For MiCA white papers, it is recommended that application of ix:continuation or ix:exclude element should be applied for marking-up multiple pieces of text to a single text block tag. In this regard, preparers’ attention is drawn to the existing provisions concerning application of the ix:continuation element (Section 4 of the Inline XBRL 1.1 21

specification) and of the ix:exclude element (Section 5 of the Inline XBRL 1.1 specification)17 .

2.5 Technical validity of reports Guidance 2.5.1 Ensuring report validity against XBRL specifications Reporting entities must ensure that the Inline XBRL document is valid with respect to a set of listed XBRL18 specifications.To ensure data quality, it is recommended that reporting entities validate each white paper report against the assertions (validation rules) defined in the MiCA white paper taxonomy, prepared according to the Formula 1.

0 specification and its modular extensions19.For MiCA white papers, it is recommended that software firms include validation rules in their tools to ensure that: Target XBRL document MUST be valid against the assertions specified in MiCA white paper taxonomy with severity set to http://www.xbrl.org/2022/severities.xml#ERROR appearing as target of generic arc with http://xbrl.org/arcrole/2022/assertion-unsatisfied-severity arcrole.

Target XBRL document SHOULD be valid against the assertions specified in MiCA white paper taxonomy with severity set to http://www.xbrl.org/2022/severities.xml#WARNING appearing as target of generic arc with http://xbrl.org/arcrole/20/assertion-unsatisfied-severity arcrole In case of violation, the following messages are recommended to be used: Violation: “targetXBRLDocumentWithFormulaErrors” Violation: “targetXBRLDocumentWithFormulaWarnings”

17 http://www.xbrl.org/specification/inlinexbrl-part1/rec-2013-11-18/inlinexbrl-part1-rec-2013-11-18.html#d1e1605 18 “MiCA XBRL Taxonomy 2025 Documentation” section 3, subsection 3.2 19 https://specifications.xbrl.org/work-product-index-formula-formula-1.0.html