• Pricings

  • Research

    MiCA CASP Authorization: What to Prove Before July 1, 2026

    July 16, 2026

    8 mins read

    MiCA's grandfathering window for crypto-asset service providers closes July 1, 2026. After that date, no granted CASP authorization means no legal access to EU clients. The authorization file asks providers to demonstrate client-asset segregation, custody integrity, and internal controls as evidence a supervisor can check, not as a claim. That is a verification problem before it is a paperwork problem.

    TL;DR: MiCA CASP authorization becomes mandatory on July 1, 2026, when the transitional grandfathering regime ends. A crypto-asset service provider that has not been granted authorization by its national competent authority loses the right to serve EU clients. The file a provider submits has to demonstrate client-asset segregation, custody integrity, and control enforcement as verifiable evidence, not as a written assertion.
    For any crypto-asset firm serving EU clients, July 1, 2026 is the date the grandfathering safety net disappears and MiCA CASP authorization becomes the only thing standing between the business and its market. The license file has to evidence that client assets are segregated and controls are enforced continuously, not just assert it. Orochi Network's zkDatabase lets a provider prove those conditions without exposing the full client ledger.
    Key Takeaways:
    • MiCA CASP authorization is mandatory from July 1, 2026; without a granted license, serving EU clients becomes unlawful.
    • Eleven member states closed their grandfathering windows early, some by December 2025, so the practical deadline has already passed in much of the EU.
    • The authorization file asks a provider to demonstrate safekeeping and segregation of client crypto-assets, governance, and operational resilience.
    • Periodic reports prove a condition on the reporting date, not in the moment a supervisor asks.
    • Cryptographic verification lets a provider show segregation and control evidence on demand while keeping the underlying client data private.

    What does MiCA CASP authorization require before the July 1, 2026 deadline?

    MiCA CASP authorization requires a crypto-asset service provider to be assessed and licensed by a national competent authority before July 1, 2026, covering custody, trading, exchange, order handling, advice, and transfer services. Under the transitional regime, providers that operated under national law before 30 December 2024 could continue until July 1, 2026, or until their authorization was granted or refused, whichever came first. ESMA has been clear that the grandfathering clock does not pause for a pending application.
    The scope is wider than exchanges. Custody and administration of client crypto-assets, operation of a trading platform, exchange between crypto-assets and funds, execution and placing of orders, reception and transmission, advice, portfolio management, and transfer services each fall inside the CASP definition. A provider offering any of these to EU clients needs the license.

    The grandfathering window has already closed in much of the EU

    The July 1, 2026 date is the outer limit, not a uniform start. Eleven member states chose shorter transitional windows, with Germany and Ireland closing theirs by December 2025. A provider that read July 1 as a single EU-wide deadline may already be operating outside the law in several jurisdictions.
    This fragmentation matters for any provider passporting across borders. National competent authorities ran their own application timelines, and several required complete files months before the federal backstop. For most jurisdictions the practical cutoff to submit a complete CASP application was June 30, 2026. The supervisory question on July 2 is simple and binary: does this provider hold a granted authorization in the member states where it serves clients, or not.

    Authorization turns operational claims into evidence a supervisor can check

    A CASP authorization file is not a statement of intent. It asks the provider to demonstrate that client crypto-assets are segregated from its own, that holdings reconcile to liabilities, and that internal controls are actually enforced. MiCA places safekeeping and segregation of clients' crypto-assets at the center of the custody obligation, alongside governance, conflict-of-interest handling, complaints procedures, and operational and ICT resilience.
    The gap most providers underestimate sits between the license grant and ongoing supervision. Authorization is a point-in-time assessment. Supervision is continuous, and a national competent authority can ask for evidence at any moment that segregation held, that a control fired, or that client holdings matched the ledger on a given day. The table below maps each obligation to the evidence a supervisor expects.
    mica-casp-obligation-evidence-map.svg Each MiCA CASP obligation translates into an evidence demand a supervisor can make at any time, not only at the authorization date.
    A provider that can produce that evidence quickly and credibly carries less supervisory risk than one that has to reconstruct it from internal systems after the request lands.

    Periodic attestation leaves a gap between the report and the question

    A monthly or quarterly report proves a condition was true on the reporting date. It says nothing about the days in between, which is exactly where a supervisor's question tends to fall. Between reports, client balances move, custody arrangements change, and a control can fail without any external signal.
    For a custodian, the live question is whether segregated client holdings have continuously matched recorded liabilities. A report dated three weeks ago cannot answer that for today. The provider either trusts its own internal systems and asks the supervisor to do the same, or it finds a way to make the condition checkable on demand. The first option is the model MiCA is moving the market away from. This is the same continuous-evidence problem that MiCA stablecoin compliance created for reserve reporting, now applied to the service-provider layer.

    Where does verifiable data fit in MiCA CASP compliance?

    Verifiable data lets a crypto-asset service provider prove a compliance condition, such as client-asset segregation or holdings-to-liabilities reconciliation, without publishing the client ledger behind it. The provider generates a cryptographic proof at the data source, and a national competent authority or counterparty checks the proof rather than trusting an internal report.
    zkDatabase, the Verifiable Database built by Orochi Network, applies here in a specific way. A custodian can prove that segregated holdings reconcile to liabilities at every state change, that a control was enforced, or that a balance condition held on a given date, while the underlying account-level data stays private. This is selective disclosure: prove the relevant condition, keep the data confidential. The mechanism is the same one covered in privacy-preserving compliance, and it builds directly on continuous digital asset custody reserve verification.
    One boundary worth stating plainly. zkDatabase does not grant authorization and does not replace the national competent authority's assessment. It gives a provider a way to produce control and segregation evidence that a supervisor can verify independently, which is a narrower and more honest claim than continuous compliance. The same selective-disclosure pattern is what pushed euro stablecoin bank consortiums toward verifiable infrastructure rather than raw public transparency.

    Conclusion

    MiCA CASP authorization is now the line between operating legally in the EU and operating outside the law. The deadline mechanics are settled, and for much of the bloc they have already passed. What separates a clean supervisory relationship from a fragile one is whether a provider can show that client assets stayed segregated and that its controls actually fired on the day in question, as evidence rather than assertion. Verifiable Data Infrastructure does not change what MiCA requires. It changes how cheaply and credibly a provider can prove it, on the day the supervisor asks.
    Book an Advisory Call Talk through where verifiable proof fits into your CASP authorization and ongoing supervision workflow.

    FAQ

    What is MiCA CASP authorization and when is it required?

    MiCA CASP authorization is the license a crypto-asset service provider must hold to serve EU clients, required from July 1, 2026. It covers custody, trading platform operation, exchange, order handling, advice, portfolio management, and transfer services. After the transitional grandfathering regime ends, operating without a granted authorization in the relevant member states is unlawful.

    Did every EU member state use the July 1, 2026 grandfathering deadline?

    No. July 1, 2026 is the outer limit set by MiCA, but member states could choose shorter transitional windows. Eleven states closed their grandfathering periods early, with Germany and Ireland ending theirs by December 2025. A provider passporting across borders has to check each jurisdiction's actual cutoff rather than assuming a single EU-wide date.

    What does a CASP have to prove during authorization and supervision?

    A CASP has to demonstrate that client crypto-assets are segregated from its own, that holdings reconcile to recorded liabilities, and that governance, conflict-of-interest, and operational resilience controls are enforced. Authorization assesses this at a point in time, but supervision is continuous, so a national competent authority can request evidence that a condition held on any given day.

    How can a provider prove segregation without exposing client data?

    A provider can generate a cryptographic proof that a condition, such as segregated holdings matching liabilities, is true at the data source, then share the proof rather than the data. zkDatabase produces this kind of verifiable evidence so a supervisor or counterparty checks the math instead of trusting an internal report, while account-level client data stays private.