MiCAR wind-down: What obligations does a project have when it stops operating?

Article 9(1) of MiCAR keeps a whitepaper online “for as long as the crypto-assets are held by the public”,¹ and nothing in Title II ends that duty when the project behind the token stops. Title II has no procedure for any of the three usual endings: insolvency, a voluntary wind-down or a community takeover (CTO). The practical answer is to tell the National Competent Authority (NCA) early, update the whitepaper and keep the NCA informed; a community that carries the token on by offering it or seeking its admission to trading in the Union will need a whitepaper of its own. A joint piece by MiCAR Whitepapers Europe and Hedman Law Firm.

The decision to stop a token project does not switch off its obligations under MiCAR such as the whitepaper. MiCAR does not explicitly state what should happen with the whitepaper after either of the events above occur.

The first important distinction is to be made for offers that ended before 30 December 2024, as these offers fall outside Articles 4 to 15. For tokens admitted to trading before that date, ESMA reads Article 143(2) as leaving offerors and persons seeking admission with the marketing rules only, while operators of trading platforms must ensure by 31 December 2027 that, where MiCAR requires one, a whitepaper is drawn up, notified, published and kept up to date.² We covered the trading platforms’ responsibilities in The Whitepaper Obligations MiCAR Places on CASPs.

Three ways a project ends

Insolvency (bankruptcy) is the forced route. The company can no longer pay its debts, an insolvency procedure is opened, usually by a court, and in most procedures a liquidator or administrator takes charge of the estate; the company is usually dissolved. Before that happens, the liquidator sells whatever still has value, such as the IP, codebase or brand, to repay creditors. In the case where the IP is bought up by another company, the token might get a second life with the same entity but different people at the helm.

A wind-down is chosen: the project, still solvent, closes the product, deals with the treasury, settles what it owes and winds up the company, on a timetable it controls. It is up to the project what they decide to do: remove the tokens from circulation or find a new owner for the project or settle all debts and leave the token in circulation. In that case, a community takeover (CTO) as described below can also occur.

A community takeover (CTO) happens when the original team leaves, sometimes by agreement, often by going quiet, and holders take over the token’s channels, liquidity, IP and roadmap. The company behind it may not survive, and the community has to organise a new company structure if they wish to stay compliant in the EU. The three overlap, too: a wind-down that runs out of money can turn into an insolvency, and a CTO can follow either.

How does MiCAR deal with it?

For a Title II token, MiCAR has no exit procedure. Title II, which governs offers to the public and admissions to trading of crypto-assets other than asset-referenced tokens (ARTs) and e-money tokens (EMTs), requires no redemption or wind-down plan, unlike the rules for ART and EMT issuers and for certain crypto-asset service providers (CASPs).³ What it does have are obligations tied to the token and its holders. There should at all times be a whitepaper online while the token is held by the public,¹ and each superseded version should stay online for at least ten years after its own publication, marked as no longer valid.⁴ ESMA’s register must hold all out-of-date versions in a separate archive, clearly marked as out of date, and nothing in MiCAR provides for their removal.⁵

Liability does not end with the company

Nothing in MiCAR expressly ends liability when a project stops. Under Article 15, the offeror or person seeking admission to trading and the members of its administrative, management or supervisory body may be liable to holders for losses caused by whitepaper information that does not meet the bar of clear, fair and not misleading.⁶ Article 15 sets no limitation period, and MiCAR does not specify what happens to a claim once the company has been dissolved; both questions fall to the applicable national law, including with respect to the members of those bodies. Such forms of liability can run for years and survive deletion of the company that issued or requested admission of the token to trading.

No transfer of offeror status

For a takeover of the company, MiCAR itself has no mechanism for transferring the status of offeror. Under Article 4(7), a subsequent offer to the public of the same token is a separate offer. The existing whitepaper can be reused only if it has been published in accordance with Articles 9 and 12 and the person responsible for drawing it up consents in writing; Article 5(4) has a similar route where the token is already admitted on another trading platform in the Union. Point (a) of Articles 4(1) and 5(1) requires the offeror or person seeking admission to be a legal person, which an informal group of holders will not usually be.¹¹

In that case the whitepaper will need to be updated to reflect the changes in command and inform the public of any changes in the trajectory of the project or members of the board.

What still applies, and until when

The remaining duties depend on timing. Article 12(1) requires a modified whitepaper whenever a significant new factor, material mistake or material inaccuracy is capable of affecting the assessment of the crypto-assets, but only “for the duration of the offer to the public or for as long as the crypto-asset is admitted to trading”.⁴ A decision to stop will on almost any reading be such a factor. The modified whitepaper goes to the NCA at least seven working days before publication, in machine-readable format even where the original predates 23 December 2025.⁷ If a running offer is cancelled, Article 14(3) adds a hard deadline: funds collected from holders or prospective holders must be returned no later than 25 calendar days after the date of cancellation.⁸

MiCAR stops there. It does not specify who keeps the website running once the offeror has ceased to exist.

In practice: write to the regulator, then keep it informed

Title II offers no channel for this beyond the Article 12 notification, so the practical step in our opinion is an informal one. Write to the home competent authority as soon as the decision is taken and, where possible, before anything is filed or dissolved. None of this replaces or delays a disclosure of such information as soon as possible due under Article 88.⁹ Send a short, factual email with the plan attached:

After a CTO: a new whitepaper from the people carrying the token

The offeror’s status stays with the original company. The community can act as the offeror in section A of the whitepaper with its own entity. If the community wants to carry the token forward in the Union, by seeking admission to an EU trading platform or by anything else that amounts to an offer to the public, it will usually need its own whitepaper.

Who can take over the token

For most open-source projects, taking over is as simple or difficult as acquiring the majority of the tokens. But for proprietary projects, one cannot acquire the rights to intellectual property by buying up the tokens, so the IP owner’s consent is likely necessary. At the same time, the old team is often unreachable, and an offeror that has ceased to exist cannot consent at all. For an admission, the platform can also carry the whitepaper requirements by written agreement (Article 5(3)), though the community still needs a legal person to seek admission; the own-initiative route in Article 5(2) applies only where a required whitepaper has not been published under Article 9.¹¹

Setting up the new offeror

The community sets up a legal person, such as a foundation, a company or an association with legal personality, to act as offeror or person seeking admission. That entity draws up a whitepaper on the template in the Inline XBRL (iXBRL) format.¹³ It notifies the whitepaper to its home competent authority at least 20 working days before publication, with an explanation of why the token should not be considered a crypto-asset excluded under Article 2(4), an e-money token or an asset-referenced token.

The entity does not have to be established in the Union: one in a third country without an EU branch takes as its home Member State the one where the token is intended to be offered to the public for the first time or, at its choice, the one where the first application for admission to trading is made. The authority does not approve the whitepaper in advance.¹⁴

The whitepaper must cover the issuer where that differs from the offeror and may not contain material omissions,¹⁴ which after a takeover will, in our view, usually mean the history: who launched the token, what became of the original team and its holdings, who still controls the smart contract and any admin keys, and what the community can and cannot change. The entity and the members of its administrative, management or supervisory body take on Article 15 liability for it.⁶

If the old team is still reachable, the handover is cleaner with its help: a final modified whitepaper recording the handover while the offer runs or the token is admitted to trading, and an email to the original offeror’s authority pointing to the community’s new whitepaper. If it is not, the community can send that email itself.

The decentralisation argument

A community without an entity may be tempted to argue that the token now has no identifiable issuer, and is therefore fully decentralised and exempted from the obligation. The Commission has stated, relying on recital 22, that crypto-assets without an identifiable issuer fall outside Title II,¹⁵ but it did not address a token that had an issuer and a notified whitepaper and then lost the team behind them. Given the uncertainty surrounding the definition of decentralisation and the ongoing debate on this issue, relying on this argument does not appear to be the most appropriate strategy for an entity seeking to maintain the token’s long-term market presence and success. A more prudent approach would be to assume responsibility for the token and issue a MiCAR whitepaper. This whitepaper could clearly distinguish the new entity from the token’s previous owners and explain that their actions should not be attributed to the new entity. Appropriate disclaimers could also be included to mitigate the risk of the new entity being held responsible for past conduct.

Conclusion: the whitepaper outlives the company

MiCAR treats a whitepaper as a standing statement to the people who hold the token, and they do not disappear when a project does. Until the legislator or the authorities say more, the approach we would take is the boring one: tell the authority early, keep it informed, keep the documents online and, if the token carries on under new hands, give it a new whitepaper with new names on it.

Frequently asked questions

References

1. Regulation (EU) 2023/1114 of the European Parliament and of the Council of 31 May 2023 on markets in crypto-assets (MiCAR), OJ L 150, 9.6.2023, Article 9 (publication of the crypto-asset white paper and of the marketing communications), paragraph 1. Full text (EUR-Lex); Article 9 (ESMA Interactive Single Rulebook).
2. MiCAR, Article 143 (transitional measures), paragraphs 1 and 2; ESMA, Q&A ESMA_QA_2654, ‘Offerors and CASPs’ responsibilities with regards to white papers for Title II tokens admitted to trading prior to 30 December 2024′, ESMA answer, 14 October 2025. Article 143; ESMA Q&A 2654.
3. MiCAR, Article 47 (redemption plan), Article 55 (recovery and redemption plans) and Article 74 (orderly wind-down of crypto-asset service providers). Article 47; Article 55; Article 74.
4. MiCAR, Article 12 (modification of published crypto-asset white papers and of published marketing communications), paragraphs 1, 7 and 9. ESMA Interactive Single Rulebook.
5. MiCAR, Article 109 (register of crypto-asset white papers, of issuers of asset-referenced tokens and e-money tokens, and of crypto-asset service providers), paragraph 2. ESMA Interactive Single Rulebook.
6. MiCAR, Article 15 (liability for the information given in a crypto-asset white paper), paragraph 1. ESMA Interactive Single Rulebook.
7. MiCAR, Article 12(2); ESMA, Q&A ESMA_QA_2845, ‘Machine-readable (XBRL) format requirement for modified white papers’, ESMA answer, 12 May 2026. ESMA Q&A 2845.
8. MiCAR, Article 14 (obligations of offerors and persons seeking admission to trading of crypto-assets other than asset-referenced tokens or e-money tokens), paragraph 3. ESMA Interactive Single Rulebook.
9. MiCAR, Title VI: Article 86 (scope of the rules on market abuse), paragraph 1; Article 87 (inside information), paragraphs 1 to 3; Article 88 (public disclosure of inside information), paragraphs 1 and 2; Article 89 (prohibition of insider dealing), paragraphs 1 and 2. Article 86; Article 87; Article 88; Article 89.
10. MiCAR, Article 2 (scope), paragraph 2, point (b), and Article 55. ESMA Interactive Single Rulebook.
11. MiCAR, Article 4 (offers to the public of crypto-assets other than asset-referenced tokens or e-money tokens), paragraphs 1 and 7, and Article 5 (admission to trading of crypto-assets other than asset-referenced tokens or e-money tokens), paragraphs 1 to 4. Article 4; Article 5.
12. ESMA, Q&A ESMA_QA_2671, ‘Exemption from white paper requirements when offering a crypto-asset other than an ART or EMT’, answer provided by the European Commission, 21 May 2026. ESMA Q&A 2671.
13. Commission Implementing Regulation (EU) 2024/2984 of 29 November 2024 laying down implementing technical standards for the application of Regulation (EU) 2023/1114 of the European Parliament and of the Council with regard to forms, formats and templates for the crypto-asset white papers, Articles 1, 2 and 4 and Annex, Table 2. EUR-Lex.
14. MiCAR, Article 3 (definitions), paragraph 1, point (33) (home Member State); Article 6 (content and form of the crypto-asset white paper), paragraph 1, point (b), and paragraph 2; Article 8 (notification of the crypto-asset white paper and of the marketing communications), paragraphs 1, 3, 4 and 5. Article 3; Article 6; Article 8.
15. ESMA, Q&A ESMA_QA_2552, ‘Application of Title II requirements to CASPs operating a trading platform for crypto-assets’, answer provided by the European Commission, 18 February 2026; MiCAR, recital 22. ESMA Q&A 2552.