
Author: JoĂŁo Lages
A MiCA-compliant token launch is not a single filing. It is a controlled sequence in which the legal classification, accountable entities, product terms, technical controls, white paper, marketing and distribution model all describe the same instrument. If one layer says something different, the project does not have a documentation problem. It has a product-governance problem.
This is especially important in 2026. MiCA is fully applicable, the final EU transitional period for existing crypto-asset service providers expired on 1 July 2026, and white papers now follow standardised, machine-readable requirements. A launch plan based on an old national registration, a PDF assembled just before sale, or an assumed “utility” label is no longer credible.
Before drafting disclosure, create a rights inventory. It should state exactly what the holder receives, who owes each obligation, whether the token is transferable, how value is determined, what happens on redemption or termination, and which party controls supply. Classification follows those rights and the token's economic function, not its name.
The route usually begins with four questions:
The ESMA guidelines on classifying crypto-assets as financial instruments are a practical starting point for the first question. A classification memorandum should also record rejected alternatives. That reasoning becomes important because a Title II notification must include an explanation of why the asset is not excluded from MiCA and is neither an e-money token nor an asset-referenced token.
A frequent launch error is to treat “the project” as if it were one regulated person. MiCA instead assigns duties to identifiable roles: the issuer, offeror, person seeking admission to trading, trading-platform operator and crypto-asset service provider. One company may perform several roles, or different companies may divide them, but the responsibility map must be explicit.
For a Title II token, identify the legal person making the public offer and the home Member State for notification. If another entity seeks admission to trading, document its responsibilities separately. If a CASP provides custody, exchange, placement or transfer services, record the exact authorised entity, licence scope, outsourcing chain and client contract.
As of 1 July 2026, the EU-wide transitional period for legacy providers has ended. ESMA states that entities providing crypto-asset services to EU clients without a MiCA licence must cease those services. The April 2026 ESMA statement on the end of transitional periods also stresses that authorisation belongs to a specific EU legal entity, not merely to a group brand. Due diligence should therefore verify the entity in ESMA's register and match it to the contract and service being delivered.
A white paper cannot be accurate if the underlying decisions are still moving. Before writing it, assemble an evidence room that supports every material statement. It should contain the final rights matrix, corporate approvals, technical architecture, token-supply controls, smart-contract specifications, service-provider agreements, conflicts assessment, risk register, complaints route, marketing plan and launch-country list.
For each statement about reserves, redemption, utility, governance or security, assign an evidence owner. For example, if marketing says holders can redeem at any time, the evidence room should show the contractual right, operational procedure, liquidity source, smart-contract path and responsible entity. If those five elements do not align, remove or correct the claim before the white paper is frozen.
This approach turns disclosure into an output of the operating model. It also makes later updates manageable because the team can identify which evidence changed and whether the change is capable of affecting a holder's assessment.
Crypto-assets other than asset-referenced tokens and e-money tokens generally follow the Title II route when no exemption applies. The offeror or person seeking admission to trading prepares the white paper, gives the home authority the required classification explanation and identifies the host Member States and planned start date.
Under MiCA Article 8, the white paper and classification explanation must be notified at least 20 working days before publication. The competent authority does not give prior approval to a Title II white paper or the related marketing communications. A launch team must not turn a notification receipt into language such as “approved by the regulator.”
The sequence matters:
Exemptions should be treated as legal conclusions, not commercial shortcuts. The facts supporting an exemption, including the offer size, audience, consideration, service status or token distribution mechanism, should be documented and monitored throughout the offer.
MiCA white papers are no longer only documents designed for human reading. Commission Implementing Regulation (EU) 2024/2984 establishes standard forms, formats and templates, and ESMA provides taxonomy and reporting resources for machine-readable white papers. The production workflow must therefore control structured data as carefully as narrative copy.
Create one controlled source of truth for legal names, identifiers, token characteristics, offer dates, rights, supply figures, sustainability indicators and risk descriptions. Generate the human-readable presentation and machine-readable filing from that source where possible. Manual re-entry across legal, technical and marketing teams invites discrepancies that can survive review.
The white paper should explain who the token is for, what rights it creates, how the technology works, the terms of the offer, principal risks and the applicable environmental disclosures. It should not contain assertions about future value, guaranteed liquidity or regulatory endorsement. The summary must remain proportionate to the underlying risks rather than reading like a sales page.
Marketing communications must be clearly identifiable, fair, clear and not misleading, and consistent with the white paper. The practical control is a release gate: no landing page, deck, influencer brief, exchange announcement or campaign goes live unless its material claims have been checked against the controlled disclosure set.
Test common claims individually. “Fully backed” requires evidence of the backing assets, ownership, custody and holder claim. “Redeemable” requires an enforceable right and executable process. “EU compliant” should identify the actual legal route and responsible entity. “Available across Europe” depends on the offer and service footprint, not simply on a website being accessible.
The same gate should cover community channels. A founder's social post or moderator's answer can contradict carefully drafted disclosure just as easily as a formal advertisement.
Map the journey from the first advertisement to token delivery and subsequent transfer. For every step, identify the entity, regulated service, customer information, screening decision, asset flow and record retained. This exposes gaps that a generic instruction to “implement KYC” will miss.
Where a CASP intermediates crypto-asset transfers, Regulation (EU) 2023/1113 imposes information requirements commonly described as the crypto travel rule. It has applied since 30 December 2024. The precise data and verification process depend on the transfer and counterparties, including whether a self-hosted address is involved. The issuer should confirm how its CASP handles the required information, sanctions controls, failed transfers and data retention.
Do not assume that CASP passporting solves the public-offer analysis or that an issuer notification authorises custody and exchange. Issuance, offering, admission to trading and crypto-asset services are separate questions even when the same launch touches all of them.
Technical assurance starts with a legal-to-code matrix. Each relevant promise should map to a contract function, off-chain procedure or explicit limitation. Supply caps map to minting permissions. Redemption maps to burn and settlement processes. Transfer limits map to allowlists or other controls. Emergency rights map to pause, upgrade and recovery governance.
Audit reports are useful but incomplete. The project also needs evidence for administrator-key custody, segregation of duties, upgrade approval, incident escalation, oracle failure, chain disruption and reconciliation between on-chain supply and off-chain records. If an administrator can alter a right that the white paper describes as fixed, the disclosure must explain that power and its controls.
Run operational rehearsals before launch. Simulate an incorrect mint, compromised key, rejected customer, unavailable CASP, failed redemption and urgent disclosure update. A control that exists only in policy but cannot be executed under time pressure is not launch-ready.
A token launch does not end when distribution opens. If the crypto-asset is admitted to trading, or admission is requested, MiCA's market-abuse framework becomes relevant. The issuer, offeror or person seeking admission may need processes for identifying and disclosing inside information, controlling access, managing conflicts and escalating suspicious behaviour.
Published white papers and marketing communications must also be modified when a significant new factor, material mistake or material inaccuracy could affect the assessment of the crypto-asset. Under MiCA Article 12, the modified material and intended publication date are notified at least seven working days before publication. Maintain a change log that links every product release, treasury decision and contractual amendment to a disclosure-impact assessment.
A project should select providers after classification, not before it. An ordinary utility token may require MiCA-aware issuance support and authorised crypto-asset services. A token that represents equity, debt, profit participation or another financial instrument needs securities-law structuring, investment-services permissions, investor documentation and an appropriate custody and transfer model.
Lympid's white-label investment platform is relevant to the second track: tokenized investment products distributed within a MiFID framework. It should not be described as the default solution for an ordinary MiCA utility-token offer. Teams still evaluating whether they need a token can use the practical product-first utility-token test; teams comparing the broader regimes can consult the guide to tokenization strategy in the European Union.
A token is ready to launch when its legal classification is documented, each regulated role belongs to a named entity, disclosure is generated from verified evidence, marketing matches the white paper, distribution partners are authorised for their exact services, code implements the disclosed rights, and post-launch reporting can operate from day one.
Delay the launch if classification depends on branding, the responsible offeror is unclear, an old national CASP registration remains in the service chain, white-paper data is being assembled manually from conflicting sources, or the product cannot execute a redemption, incident or disclosure-update procedure in rehearsal. MiCA compliance is not a badge added to a token. It is the operating system around the offer.
This article provides general information and does not constitute legal, tax, investment or financial advice. The applicable requirements depend on the token, rights, entities, services, distribution method and jurisdictions involved.