Audits & MiCAR: where code security meets regulatory disclosure

Regulation · Joint publication with Hashlock · July 2026

A smart contract audit is not, in most cases, a legal precondition for offering a token in the EU. The MiCAR whitepaper RTS asks the audit question anyway: field H.8 asks whether the technology used has been audited, and field H.9 asks for the outcome of the audit^[2]. Either way, the answer becomes part of a regulatory filing. In this joint piece, Hashlock and MiCAR Whitepapers Europe explain how audits and MiCAR disclosure fit together, and why running them as one workstream produces a stronger launch than running them apart.

Every token project makes two promises. To its users, that the code is safe. To the market and its regulators, that what it says about itself is true. Break the first and the damage is immediate: an exploited contract, a drained treasury. Break the second and the damage arrives slowly, as rejected filings, delisted tokens and markets that quietly close to you. Most teams take one of these promises seriously from day one and leave the other until it becomes urgent.

Serious projects now make good on both promises before launch. A smart contract audit tells the market the code does what it claims; a MiCAR whitepaper tells the regulator, the exchange and the investor what that claim actually is. The two are usually treated as separate workstreams, run by different people on different timelines. They should not be. That is the reason Hashlock, a Web3 security firm specializing in smart contract auditing, and MiCAR Whitepapers Europe have written this piece together: the audit that secures your code and the whitepaper that discloses it are, in practice, two halves of the same exercise.

Why are audits important?

A smart contract audit is an independent review of a project's code before it goes live. Its purpose is blunt: find the vulnerabilities while they are still cheap to fix. Once value is locked in a contract, an access control mistake stops being a code review comment and becomes an incident.

The recurring findings are familiar to anyone who reads audit reports. Access control issues, where a function that should be restricted is not. Logic flaws that only surface under unusual market conditions. Oracle dependencies and upgrade paths that concentrate risk in a single key. And economic exploits, where every contract behaves exactly as written and the combination still loses user funds. None of these are exotic. Most of them are found, and fixed, in ordinary audits every week.

There is a commercial layer on top of the security one. Exchanges and launchpads increasingly ask for an audit report as part of listing due diligence, and investors read audit status as a rough proxy for how seriously a team takes its own product. For credible projects, an audit has become an industry standard rather than a differentiator. Its absence is what gets noticed.

Why are audits important under MiCAR?

MiCAR requires a whitepaper for public offers and admissions to trading of crypto-assets other than ARTs and EMTs, the Title II category into which most tokens fall^[1]. That whitepaper is not a free-form marketing document. It follows the mandatory template in Annex I of Commission Implementing Regulation (EU) 2024/2984, field by field, in a machine-readable format^[2].

Part H of the template covers the underlying technology. Field H.8 asks whether the technology used has been audited. Field H.9 asks for the outcome of that audit^[2]. There is no way around the question. A project that has been audited discloses the result in a regulatory filing; a project that has not been audited states that, in the same filing, to the same audience of supervisors, trading platforms and investors.

Part I of the template then requires disclosure of the risks associated with the crypto-asset and the technology, together with any mitigation measures^[2]. This is where an audit quietly earns its fee a second time. A completed audit report is the natural evidence base for those disclosures: it identifies the actual technology risks, records what was remediated, and lets the drafter describe mitigation in specific terms rather than generic ones. Vague risk language in a regulatory filing helps nobody, least of all the issuer.

The framing matters, so we will be precise about it. An audit is not a general legal precondition for a Title II whitepaper, and this article does not claim that audits are mandatory under MiCAR. This means that H.8, which asks whether an audit has been performed, can also be answered false. The accurate statement is narrower and, for issuers, more useful: the template asks the audit question directly, and while authorities currently do not assess a whitepaper based on whether the underlying technology has been audited, an audit may strengthen the project's position towards investors and exchanges by providing additional transparency and assurance regarding the technology. The same audit report can therefore serve as a valuable source of information for multiple stakeholders. Regulatory expectations may also continue to evolve, and technology audits could become more relevant within the wider compliance landscape in the future. A whitepaper does not guarantee compliance and an audit does not guarantee security. Together, they can reduce, though not eliminate, both kinds of exposure.

How does an audit work?

An audit starts before any line of code is read. The project team and the auditors agree on the scope: which contracts, at which commit, with what documentation of intended behaviour. This unglamorous step quietly decides what the audit will be worth. A precise review of the contracts that actually holds user funds is evidence; a vague pass over "the codebase" is marketing.

Then comes the part that cannot be automated. Hashlock's senior researchers read the code manually, line by line, and interrogate its assumptions. What happens when a function receives inputs the designers never expected? What breaks when a dependency behaves differently on a fork, or during a chain reorg? Where has risk been quietly delegated to a component nobody has reviewed? Software-assisted offensive testing runs alongside, simulating known attack patterns, but tools find the known. The findings that matter most, the economic exploits where every contract behaves exactly as written and the system still loses user funds, are found by people who have watched that class of protocol break before.

What the project receives first is not a verdict but a working document: findings classified by severity, each with context and a recommended fix. The process is a conversation throughout, with findings discussed as they surface rather than saved for a reveal. The team remediates, the auditors verify the fixes, and only then is the final report issued with a rating. On Hashlock's scale, code is assessed on quality, vulnerability, future risk and complexity. Anything below "Secure" should not be deployed, and the "Hashlocked" designation is reserved for projects that keep investing in security after the audit, through continuous monitoring and bug bounty programs. The rating is designed to say something about a team's posture, not only its code.

Across more than 200 audits and over $1.3 billion in onchain value secured, one lesson repeats: systems rarely break where everyone is watching. They break where an assumption seemed reasonable and attention had moved on. An audit is a point-in-time review of a defined scope. It cannot promise that nothing will ever go wrong, which is precisely why field H.9 asks for an outcome rather than a stamp. The final report is written to be read by outsiders: developers first, then exchanges, investors and, under MiCAR, the supervisor reading the whitepaper it feeds.

Preparing for compliance and building trust

The practical question for a team planning an EU launch is sequencing. The order that works is the boring one: finish the technical review before the disclosure documents are finalised, and start the MiCAR classification and whitepaper work early, not in the week before the token generation event. An audit that concludes after the whitepaper is notified is an audit the whitepaper cannot use.

Run in the right order, the two workstreams feed each other. The scope documents and architecture descriptions prepared for the auditors are the raw material for the whitepaper's technology section, and the final audit report flows directly into fields H.8 and H.9 and the Part I risk disclosures^[2]. One workstream's output is the other's input, and the result is a filing that tells one consistent story about the code.

Two habits keep that story accurate over time. First, address findings before filing: an audit with open critical findings is a worse look in a disclosure document than no audit mention at all, so remediate first and then disclose the resolved status precisely. Second, keep the documentation current. MiCAR requires a modified whitepaper for significant changes^[1], and a re-audit after a major code change is what keeps the answer in field H.9 true. Trust, in both disciplines, is a maintenance job.

One project, two disclosures, one story

Audits and MiCAR compliance are usually described as separate workstreams. They are better understood as the same exercise seen from two sides: both exist so that outsiders can verify what insiders claim. A project that treats them together, on one timeline, with one set of documentation, reads differently to an exchange, a supervisor and an investor than one that bolts either on at the end.

Launching in Europe? Talk to both teams about a combined security and compliance approach.