Two disclosure regimes now compete or rather, complement each other, in effect, for the same audience: an investor trying to work out what a token actually is before deciding whether it belongs in a portfolio. The first is the crypto-asset whitepaper regime under the EU's Markets in Crypto-Assets Regulation (MiCA), a binding legal instrument that has, since 2024, required issuers offering "other" crypto-assets into the EU, or seeking admission to trading on an EU platform, to produce a prescribed disclosure document before doing so.¹ The second is the Token Transparency Framework (TTF), an industry-built disclosure standard launched by Blockworks in June 2025 and since adopted, on a voluntary basis, by a coalition of exchanges, asset managers and protocols now organised under the Transparency Alliance.^{2 3}

Axis Group has drafted and submitted the majority of non-exchange MiCA whitepapers filed in Malta since the regime came into force, which gives us a fairly granular view of what the MiCA disclosure standard actually demands in practice, line by line, rather than as a summary of the regulation. That vantage point is the basis for this analysis. The purpose here is not to argue that one regime should replace the other; they serve different legal functions and, in several respects, different markets. The purpose is narrower and more practical: to assess, on a fair and even basis, which regime gives an end investor a more complete and more reliable basis for judging whether a given token's risk profile suits them, and to identify what a voluntary, industry-led framework such as the TTF could reasonably adopt from a mandatory, legally enforced one such as MiCA.

Two disclosure regimes, two origins

The starting point for any fair comparison is that MiCA and the TTF are not variations on the same idea. They come from different legal traditions and were built to solve different problems.

MiCA's whitepaper regime sits in Title II of the Regulation, which governs crypto-assets other than asset-referenced tokens (ARTs) and e-money tokens (EMTs); those two categories are subject to separate authorisation regimes under Titles III and IV, with materially heavier obligations. For the "other crypto-assets" category that Title II covers, which in practice includes most utility tokens and a large share of newly issued tokens, an offeror or a person seeking admission to trading must draw up a whitepaper in the form set out in Article 6 and Annex I, notify it to the competent authority of its home Member State at least twenty working days before publication, and only then make the offer or seek admission.^{4 5} Notification is not the same as approval; the competent authority does not sign off on the whitepaper's content before publication. But the authority retains the power to object, to require amendments, to demand supplementary risk warnings, and to intervene if the substance of the token suggests it has been mischaracterised, for example if it functions in reality as an ART or a financial instrument.⁵ The whitepaper obligation does not end at publication either. Article 12 requires the offeror to modify the whitepaper whenever a significant new factor, a material mistake or a material inaccuracy arises that is capable of affecting an investor's assessment, for as long as the offer continues or the asset remains admitted to trading, with a further seven working days' notice to the regulator before the update is published.⁶

The TTF has none of this legal architecture, by design. It began as an industry-led, "grassroots" disclosure standard, explicitly framed as a voluntary complement to proposals such as SEC Commissioner Hester Peirce's Safe Harbor concept rather than as a response to any binding statute.^{2 7} Its original structure, published in June 2025, organised disclosure into four categories, project and team, token supply and allocation, transactions and market structure, and financial disclosure, scored across eighteen weighted criteria to produce an aggregate transparency score.² That structure has since evolved into a filing-based model. A one-time B1 filing, described by Blockworks as "loosely" modelled on an S-1 registration statement, covers a token's launch: who is behind the project, how it is governed, how the token is allocated, what liquidity and listing arrangements exist, what was sold before launch, and the principal legal, technical and token-economic risks.^{7 3} A continuous B2 filing, aimed at mature, post-launch protocols, is intended to be kept current and now also captures DAO, Foundation and DevCo control structures, key-opinion-leader marketing arrangements, protocol-owned liquidity and buyback or loan activity, and disclosed exploits.³ The framework is now overseen by the Transparency Alliance, whose founding members include Coinbase, Kraken, Binance.US, Grayscale, Anchorage Digital, BitGo, VanEck, Bitwise and others representing a combined market capitalisation Blockworks puts at over $400 billion, with Moody's Ratings participating as an independent observer.³

Comparing the substance of disclosure

Judged purely on the categories of information requested, the two regimes overlap more than a first glance suggests. Both ask who controls the project and how; both ask how the token supply is structured and allocated; both ask what risks attach to the asset; and both, in their more recent iterations, ask about liquidity and listing arrangements. The difference lies less in what is asked and more in how far each regime goes in specifying it, and in what each treats as optional versus mandatory.

Mapped category by category, the two disclosure sets line up more closely than a first glance suggests, though the precision of the mapping varies considerably by topic. On issuer and offeror identity, Annex I is mandatory and specific: Parts A to C require legal form, registered address, management body identity and experience, business activity and financial condition, whereas the TTF folds the equivalent information into its "project and team" category and leaves the scope and granularity of what is actually disclosed largely to the filer. On project description, Annex I's Part D requires objectives, development stage, funding sources and dependencies, and the TTF's B1 filing covers broadly similar ground under the same heading. On offer or trading-admission terms, Annex I's Part E is explicit about pricing, subscription terms, and the applicable law and jurisdiction governing the offer, while the TTF's launch disclosures cover pricing and terms but are considerably less prescriptive about which jurisdiction's law actually governs a purchase. On token characteristics and rights, both regimes require disclosure of supply mechanics, holder rights, transfer restrictions and redemption terms, MiCA under Annex I Parts F and G and the TTF under its token supply and allocation category, though again with MiCA's version being the more itemised of the two.

The two regimes diverge more sharply once the comparison moves into technology, risk and environmental disclosure. Annex I's Part H requires a description of the underlying consensus mechanism, smart contract functionality and audit outcomes as a dedicated, mandatory section; the TTF addresses technology only indirectly, folded into its treatment of technical risk rather than given a structural category of its own. Risk disclosure is mandatory under both, but Annex I's Part I sits alongside the statutory risk warnings required separately by Article 6(5), giving MiCA's risk section a fixed regulatory floor that does not depend on the drafter's own judgment, whereas the TTF's risk disclosure, while present, is not organised into any fixed taxonomy of risk types and is left considerably more to the filer's own framing. Environmental and sustainability impact is the clearest structural gap between the two: Annex I's Part J requires disclosure of energy consumption and greenhouse gas emissions under a dedicated ESMA/EBA technical standard, and the TTF addresses no equivalent category at all.

A whitepaper prepared under Annex I typically runs to well over a hundred individually numbered disclosure items once each of the ten Parts is broken down into its sub-items.¹ The TTF's original scoring model, by contrast, was built around eighteen weighted criteria, and even its more detailed B1/B2 filing structure is organised around a handful of broad categories rather than a granular checklist.^{2 3} That is not a criticism in itself; a framework aimed at rapid, voluntary adoption across a large number of already-trading tokens has good reason to keep its filing burden lower than a statutory regime built around regulatory notification deadlines. But for an investor assessing completeness, the difference in specificity is material. Annex I's structure leaves little to the drafter's discretion as to what counts as adequate disclosure of, say, management body experience or smart contract audit outcomes, and its ten-part structure is largely uniform from one issuer to the next, which is what makes cross-issuer comparison possible. A B1 filing, by contrast, can satisfy the TTF's "complete" status while saying comparatively little about the technical architecture of the underlying protocol, since technology and audit disclosure has no dedicated, mandatory field of its own in the way Annex I Part H requires.

There are, however, categories where the TTF is demonstrably more specific than MiCA, and it would not be a fair comparison to gloss over them. Insider allocations, vesting schedules and pre-launch sales are covered by Annex I only indirectly, through general offer terms and token characteristics, whereas the TTF's B1 filing treats them as an explicit, itemised requirement. The same asymmetry holds for market maker and exchange listing agreements, which have no direct analogue in Annex I at all, and for ongoing governance and control structures, DAO, Foundation or DevCo arrangements, which Annex I discloses only as they stood at the time of publication, updated solely if a later change is significant enough to trigger the Article 12 modification duty, while the TTF's B2 filing treats them as a continuously updated field by design. Buybacks, protocol-owned liquidity and treasury loan activity, key-opinion-leader marketing arrangements, and exploit history are handled the same way: none map cleanly onto any Annex I part, yet all are explicit, itemised fields in a B2 filing. These are real gaps in a token market that MiCA's whitepaper structure, drafted primarily with issuance-stage disclosure in mind, was not built to capture. An investor evaluating a token two years after its listing, trying to work out whether a foundation has been quietly buying back supply on the open market or whether an "independent" commentator promoting the token was in fact paid to do so, will generally find more directly useful, purpose-built fields in a B2 filing than in a MiCA whitepaper drafted at the time of the original offer.

Assurance: the standard each regime holds disclosure to

The more consequential difference between the two regimes, in our assessment, is not what is disclosed but what standard that disclosure is held to, and what happens if it turns out to be wrong.

MiCA sets a substantive quality bar, not merely a completeness bar. Article 6(2) requires that whitepaper information be "fair, clear and not misleading," presented "in a concise and comprehensible form," and free of material omissions.⁴ That standard is enforced through two separate mechanisms. First, the whitepaper must include a management body attestation: the issuer's management confirms compliance with Title II and attests, to the best of its knowledge, that the information presented is fair, clear and not misleading and omits nothing material.⁴ That is a named, accountable certification, not an anonymous submission. Second, Article 15 creates a statutory civil liability regime: offerors, persons seeking admission to trading, operators of trading platforms who prepare a whitepaper themselves, and members of their management bodies, are liable to crypto-asset holders for losses caused by whitepaper information that is incomplete, unfair, unclear or misleading relative to the Article 6 and Annex I requirements, and any contractual attempt to exclude that liability is void.⁸ A holder still has to show the infringement occurred and that they relied on it, which is a real evidentiary burden, but the liability itself cannot be waived away in the terms of sale.

The TTF, at present, makes no equivalent claim about the substance of what is filed. Blockworks describes its Disclosure Score explicitly as a measure of "completeness of disclosure, not quality."³ That is a candid and, we think, an important admission: the framework tracks whether a field has been filled in, not whether what was written in it is accurate. There is, from what is publicly documented, no independent verification step, no third-party audit of submitted figures, and no attestation requirement analogous to MiCA's management body certification. A "Complete" filing status signals that a project answered the questions the framework asks; it does not signal that the answers were checked against anything. Nor is there, currently, any liability regime attached to a false or materially incomplete B1 or B2 filing; participation itself is voluntary, and a project that files inaccurately faces reputational consequences within the Transparency Alliance's membership at most, rather than the kind of civil exposure Article 15 creates.

This is the single largest gap between the two regimes from an investor-protection standpoint. Completeness and accuracy are different properties of a disclosure document, and a framework that measures only the former can be satisfied by a document that answers every question with information that happens to be wrong, self-serving, or strategically vague, so long as every field is nominally filled. MiCA's approach, requiring both a named attestation and a route to civil liability if that attestation later proves false, gives an investor a reason to treat the document's content as more than a marketing exercise dressed up as disclosure. The TTF does not yet give investors an equivalent reason, beyond the reputational stake exchanges and asset managers now hold as Alliance members in the framework's credibility.

Enforcement and consequences for non-disclosure

A related asymmetry concerns what happens when disclosure falls short. Under MiCA, the consequences are not merely reputational. A competent authority can prohibit or suspend an offer, require corrective publication, or, in the most serious cases, refer the matter for enforcement action; failure to comply with the whitepaper regime is grounds for a trading platform to withdraw or refuse admission to trading of the asset.¹ Regulatory oversight, in other words, is backed by market access itself: an issuer that will not produce a compliant whitepaper cannot lawfully be offered or listed within the EU.

The TTF has no equivalent enforcement lever of its own. Filing is voluntary, non-filing carries no formal sanction, and an "Outdated" or "Partial" status is, at present, informational rather than a bar to listing anywhere. That said, this is also where the framework's institutional backing matters most for its future trajectory rather than its current state. Because the Transparency Alliance's founding members include several of the exchanges investors actually transact on, there is a plausible path by which filing status becomes a de facto listing or promotion criterion even without any regulator involved, in much the same way exchange listing standards already function as private enforcement of disclosure norms in traditional markets. As of the most recent figures we reviewed, 80 total disclosures existed across the framework, with 63 current and 17 outdated, which suggests adoption is still concentrated among a subset of listed projects rather than being close to universal.³ Whether that becomes a meaningful enforcement mechanism will depend on whether members choose to condition listing or marketing support on filing status, which the framework does not currently require of them.

Which regime serves the investor better

Taken as a whole, and judged specifically against the goal of giving an investor what they need to assess whether a token's risk profile fits their appetite, MiCA's Title II whitepaper regime is the more rigorous instrument. Its disclosure content is more granular and less discretionary, its quality standard is explicit and substantive rather than confined to completeness, it carries a named attestation and a statutory liability backstop, its update obligation persists for the life of the offer or trading admission rather than only at launch, and its enforcement is tied directly to market access within the EU. None of that is a surprise, given that MiCA is binding law built with the machinery of a financial services regulator behind it, while the TTF is a voluntary, industry-built standard barely a year old, and it would be an unfair comparison to expect parity between the two on legal weight. But on the narrower question of which document, if an investor could read only one, gives them the more reliable basis for a risk decision, the MiCA whitepaper is the stronger instrument, precisely because its content has consequences attached to it being wrong.

That said, the TTF has genuine, distinct value that MiCA does not replicate, and a fair assessment has to credit it. MiCA's whitepaper regime applies only to offers into the EU or admissions to trading on EU platforms; the very large share of tokens that never seek EU admission have no equivalent disclosure obligation at all, and for those tokens the TTF is, in practice, the only structured disclosure standard available to investors. Its continuous B2 filing also captures categories of ongoing, secondary-market-relevant activity, buybacks, protocol-owned liquidity, KOL marketing, exploits, governance changes, that MiCA's issuance-oriented whitepaper structure was not designed to track as granularly, even accounting for the Article 12 update obligation. An investor holding a token two years post-listing is arguably better served, on those specific questions, by a current B2 filing than by an unmodified whitepaper from the original offer.

What Blockworks could reasonably adopt from MiCA

Given that gap in assurance rather than in coverage, the most useful improvements available to the TTF are less about adding new disclosure fields and more about strengthening what stands behind the fields that already exist. Several elements of the MiCA regime seem directly transferable to a voluntary, industry-run framework without requiring anything resembling statutory authority.

A quality standard distinct from a completeness standard would be the most consequential single addition. Scoring whether a field was answered is a reasonable first filter, but a parallel indicator of whether the answer meets a baseline of fairness, clarity and non-omission, even if self-assessed initially, would move the Disclosure Score closer to something an investor can actually rely on rather than a proxy for effort.

A named attestation requirement would address the accountability gap directly. MiCA does not require third-party audit of whitepaper content; it requires that an identified member of the issuer's management body personally certifies the disclosure's fairness and completeness. The TTF could adopt an equivalent step at comparatively little cost: requiring a named officer, rather than an anonymous corporate submission, to attest to each B1 or B2 filing would create a personal accountability link that currently does not exist in the framework.

A structured, mandatory risk taxonomy would improve comparability across filings. Annex I's Part I approach, requiring risk disclosure organised by category (offeror risk, asset risk, technology risk, implementation risk) rather than left to free-form narrative, makes risk sections easier to compare across issuers. The TTF's current risk disclosure is present but not organised this way, and imposing a fixed taxonomy would reduce the extent to which risk sections vary in usefulness purely as a function of drafting quality.

A defined update trigger, rather than reliance on voluntary B2 adoption, would close the gap Article 12 addresses. MiCA requires modification of the whitepaper whenever a significant new factor or material inaccuracy arises, with a defined notice period; the TTF's B2 filing is intended to be "continuously updated" but, from what is publicly documented, has no defined trigger or cadence forcing an update when something material happens. Attaching a concrete disclosure obligation to specific triggering events, an exploit, a governance change, a material treasury transaction, would give the continuous filing model teeth it does not yet have.

A machine-readable, standardised schema, akin to the XHTML and Inline XBRL format MiCA mandates under its implementing technical standards, would make filings computationally comparable across projects rather than dependent on how each project chooses to present its own disclosure.⁹ This would also make third-party analysis and aggregation, including by the Alliance's own institutional members, considerably easier to build.

Finally, an environmental or operational sustainability disclosure item, addressing energy consumption and consensus mechanism impact for protocols where that is material, would close a category the TTF does not currently address at all, and one that a growing share of institutional allocators now factor into their own risk and mandate screening independently of any regulatory requirement.

Conclusion

Neither regime is a finished product, and neither should be read as a template the other ought to copy wholesale; they were built to do different jobs, for different populations of tokens, under different legal constraints. But measured against the specific standard this analysis set out to apply, giving an end investor the information needed to judge whether a token's risk profile suits their appetite, MiCA's Title II whitepaper regime remains the more rigorous benchmark, largely because of what stands behind its disclosure requirements rather than the requirements themselves: a substantive quality standard, a named attestation, a statutory liability backstop, and enforcement tied to market access. The Token Transparency Framework fills a real gap for the very large population of tokens MiCA's territorial and product scope does not reach, and its continuous filing model captures secondary-market developments that a point-in-time whitepaper, even with an update obligation attached, was never structurally built to track as granularly. Closing the remaining distance between the two, for a framework built voluntarily by industry rather than imposed by statute, looks less like adding new disclosure categories and more like importing the accountability mechanisms, attestation, a defined quality bar, and a structured, comparable format, that give MiCA's regime its practical weight as a genuine industry standard.

---

References

Footnotes

1. Regulation (EU) 2023/1114 of the European Parliament and of the Council of 31 May 2023 on markets in crypto-assets (MiCA). EUR-Lex, full text. ↩ ↩² ↩³

2. Blockworks, "Blockworks Unveils New Token Transparency Framework" (June 2025). Business Wire. ↩ ↩² ↩³ ↩⁴

3. Blockworks, "Token Transparency Framework." blockworks.com/token-transparency; Blockworks, "Blockworks Launches the Transparency Alliance" (May 2026). Business Wire. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

4. MiCA, Article 6, "Content and form of the crypto-asset white paper," and Annex I. Regulation (EU) 2023/1114, EUR-Lex. ↩ ↩² ↩³

5. MiCA, Article 8, notification of the crypto-asset white paper to the competent authority. Regulation (EU) 2023/1114, EUR-Lex. ↩ ↩²

6. MiCA, Article 12, "Modification of published crypto-asset white papers." Regulation (EU) 2023/1114, EUR-Lex. ↩

7. Blockworks, "A new framework for token market transparency." blockworks.com/news/token-transparency-framework. ↩ ↩²

8. MiCA, Article 15, "Liability attached to a crypto-asset white paper." Regulation (EU) 2023/1114, EUR-Lex. ↩

9. ESMA, implementing and regulatory technical standards on the format and content of crypto-asset white papers under MiCA, including the MiCA XBRL/iXBRL reporting taxonomy. ESMA, MiCA taxonomy reporting manual. ↩