MiCAR Wind-Down: What Obligations Does a Project Have When It Stops Operating?

Regulation · Joint publication with Hedman Law Firm · October 2026

Article 9(1) of MiCAR keeps a whitepaper online "for as long as the crypto-assets are held by the public"^[1], 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^[2]. 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, 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)^[3]. 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^[1], and each superseded version should stay online for at least ten years after its own publication, marked as no longer valid^[4]. 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^[5].

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^[6]. 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.

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^[11].

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.

In our view, it could be argued that a formal wind-down, coupled with the offeror publishing an updated whitepaper that expressly states it is ceasing all operations and withdrawing from any further involvement with the token, may serve to bring the offeror's ongoing obligations in respect of the token to an end and, accordingly, limit its potential liability going forward. This argument is in our opinion even stronger in the case of a CTO or a transfer to a new project owner, where a new whitepaper will be issued and a new entity will assume responsibility for its content. In such circumstances, the original offeror would no longer be the person responsible for the whitepaper, and liability for subsequent disclosures should, in principle, rest with the new offeror. The original offeror would, however, likely remain liable for the information contained in the whitepaper(s) it published before the transfer and for ensuring availability of the previous versions, even if that function is also transferred to the new team.

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"^[4]. 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^[7]. 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^[8].

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^[9]. Send a short, factual email with the plan attached:

• what is happening (insolvency, wind-down or handover) and the timeline;
• whether an offer is running (and, if it is cancelled, how funds will be returned within the 25 days) and where the token is admitted to trading;
• the final modified whitepaper, if one is required, and when it will be notified;
• the open question: what the authority expects for the whitepaper once the offeror is dissolved.

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.

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^[11].

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^[13]. 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^[14].

The whitepaper must cover the issuer where that differs from the offeror and may not contain material omissions^[14], 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^[6].

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.

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^[15], 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.

Yamal Kalaf, LL.M., Co-Founder, MiCAR Whitepapers Europe B.V.
Vladislav Linko, MA, Senior Associate, Hedman Law Firm