Cross-chain bridges – protocols that lock assets on one blockchain and mint corresponding representations on another – sit at one of the most legally contested points in digital-asset infrastructure. A business deploying or integrating a bridge in the Czech Republic must answer a question that regulators across the EU are actively working through: does this protocol constitute a regulated service, and if so, under which regime?
Under MiCA (the Markets in Crypto-Assets Regulation), the European Union's binding digital-asset regime administered by ESMA and national competent authorities, the legal classification of a cross-chain bridge turns on the substance of what it does – not on what its documentation calls it. A bridge that issues wrapped tokens may be operating an ART (asset-referenced token) regime; one that charges fees for transfer may be providing a crypto-asset transfer service. The Czech Republic, as an EU member state, implements MiCA in full, which means a bridge operator with Czech nexus – an entity, employees, or a user base located here – faces live regulatory exposure.
This guide walks through the classification question, the applicable Czech and EU legal environment, the practical steps for managing bridge legal risk, and the cross-border tax and banking interactions that compound it.
What Is a Cross-Chain Bridge and Why Does It Create Legal Risk?
A cross-chain bridge is a protocol that enables the transfer of value or data between two distinct blockchain networks by locking the original asset and minting a synthetic or wrapped equivalent on the destination chain. The legal risk is immediate: the moment a protocol mints a new token, it may be issuing a crypto-asset within the meaning of MiCA – triggering whitepaper, disclosure, and authorisation obligations that apply regardless of whether the issuer considers itself a "DeFi" project.
Czech Republic-based operators also contend with the transposition of EU Anti-Money Laundering directives into domestic law. Where a bridge accepts transfers from identified wallets and passes them to another chain, the question of whether it constitutes a VASP (virtual asset service provider) – with full AML/KYC obligations including the Travel Rule (the obligation to pass originator and beneficiary data with a transfer) – is a live compliance issue, not a future hypothetical. The Czech National Bank (ČNB) is the designated national competent authority for MiCA oversight and receives AML supervisory data on virtual-asset-related activity.
In our practice, the businesses most exposed are those that built bridge infrastructure before MiCA entered its full applicability phase and are now retrofitting compliance onto architecture that was not designed with a regulated-service model in mind.
How Does MiCA Classify Cross-Chain Bridge Activity?
MiCA does not contain a dedicated provision for bridges, which is precisely why classification analysis is essential. The regime defines several categories of crypto-asset service (CAS) and several token types, and a bridge can fall into more than one simultaneously.
The first classification axis is token type. If a bridge mints a wrapped token backed by a basket of assets or tied to the value of a reference asset, it may constitute an ART. If the wrapped token tracks the value of an e-money instrument, it may constitute an EMT (e-money token). Both carry issuer-authorisation requirements and reserve obligations under MiCA. An issuer without authorisation cannot lawfully offer these instruments to EU users – including Czech users.
The second axis is service type. A bridge that executes transfers between users on behalf of a business may be providing a transfer service; one that aggregates liquidity and routes the optimal path may resemble an exchange service. Each of these is a licensed activity under MiCA's CASP (Crypto-Asset Service Provider) authorisation, which in the Czech Republic is issued by the ČNB as the relevant NCA.
The CASP authorisation carries a passporting mechanism: once granted in one EU member state, it permits the holder to operate across the EU/EEA without additional national licensing. That makes a Czech authorisation structurally attractive for bridge operators whose users are distributed across Europe – but it also means the authorisation threshold is the EU standard, not a lighter national one.
MiCA's token classification regime distinguishes ARTs, EMTs, and other crypto-assets by the nature of the rights they confer – substance governs, not the label in the whitepaper. A bridge operator relying solely on a "utility" designation does so at material regulatory risk.The process above describes the standard classification path. Your facts – the token mechanics, the fee model, the entity structure, the user geography – change the analysis materially. To map your bridge's regulatory exposure under MiCA, contact OBOLUS at Map your options.
Step 1: Establish Which Entity Has Czech Nexus
The starting point for any bridge operator is a nexus analysis: which legal person, if any, has a connection to the Czech Republic sufficient to bring the MiCA and AML regimes into play. Czech nexus can arise through incorporation, a registered branch, employees or contractors based in the country, or – most frequently overlooked – a material Czech user base accessing the bridge.
An operator incorporated in a third country but actively marketing to Czech users is not insulated from MiCA. The regime applies on the basis of where services are provided, not only where the provider is registered. The ČNB and ESMA have both signalled that substance-over-form analysis applies to the question of EU market access.
In practical terms, nexus analysis produces one of three outcomes. First: no EU nexus – the operator has no entity, no employees, and no marketing directed at EU users. Regulatory exposure under MiCA is low, though not zero. Second: incidental EU nexus – Czech or other EU users access the bridge without active solicitation. The operator should document this, geo-restrict proactively, and take legal advice on whether the reverse solicitation exemption is properly available. Third: active EU nexus – the operator is incorporated in the Czech Republic or is actively marketing to EU users. MiCA authorisation is required.
We regularly advise bridge operators at the second stage who have misread the scope of the reverse solicitation carve-out. That exemption is narrow and is not a durable compliance posture for a business scaling its EU user base.
Step 2: Conduct Token and Service Classification
Token classification is not a marketing exercise. It is a legal analysis of the rights that the token confers on the holder and the obligations it places on the issuer – judged against the MiCA taxonomy and, where applicable, the Czech transposition of the EU Prospectus and MiFID II regimes (relevant if the token has characteristics of a transferable security or a financial instrument).
For a cross-chain bridge, the classification matrix typically runs as follows. The wrapped token is assessed against ART and EMT definitions. If it falls outside both – because it confers no reference-asset claim and does not track e-money – it may qualify as an "other crypto-asset" under MiCA, which triggers lighter-touch whitepaper obligations but not full ART/EMT authorisation. The bridge service itself is assessed against the CASP activity list. Transfer service is the most commonly applicable category, but exchange, custody and portfolio management are each relevant depending on the bridge's architecture.
A common mistake at this step is conducting the analysis once, at launch, and not revisiting it as the bridge's functionality evolves. Adding a fee-earning liquidity layer, a governance token, or a lending module each potentially opens a new classification question under MiCA – and may require an amendment to or a new CASP authorisation.
The AUDIENCE_MYTH is persistent here: a utility label on a whitepaper does not settle legal classification. ESMA and national competent authorities assess the substance of the rights conferred. We assess classification against the substance of rights, not the marketing label – and the Czech NCA will do the same.
Step 3: Map AML and Travel Rule Obligations
AML compliance for a cross-chain bridge in the Czech Republic runs on two tracks. First, the Czech AML Act transposes the EU AML directives and applies to virtual-asset service providers operating in or from the Czech Republic. A bridge operator that qualifies as a VASP must register with, and report to, the Financial Analytical Unit (FAÚ), the Czech AML authority. Second, the Travel Rule – derived from FATF Recommendation 15 – requires that originator and beneficiary data accompany a virtual-asset transfer above the applicable de-minimis threshold. The precise threshold is set by Czech and EU implementing rules; operators should consult current legislation for the figure in force.
The Travel Rule presents a technical challenge for bridges specifically, because the protocol architecture often does not preserve the sender-receiver relationship across chains. A lock-and-mint model breaks the chain of custody in a way that a same-chain transfer does not. Technically compliant Travel Rule implementation for a bridge requires either a compliant off-chain messaging layer or a protocol-level solution that links the originating address to the minted token's recipient.
In our cross-border practice, Travel Rule non-compliance is consistently the issue that triggers supervisory attention first. Bridge operators that have resolved the token classification question but have not built Travel Rule infrastructure into their architecture are exposed to enforcement action from the FAÚ and, potentially, to CASP authorisation conditions that require the deficiency to be remedied before the licence is granted.
Step 4: Address Smart Contract Liability and Governance Structure
A cross-chain bridge is typically governed – at least in part – by a smart contract (self-executing code on a blockchain that carries out pre-defined instructions automatically). When a bridge smart contract is exploited, paused, or produces an unintended outcome, the liability question is: who is legally responsible?
Czech law does not yet contain a dedicated liability regime for smart contracts. The analysis defaults to the Czech Civil Code, which applies principles of product liability, service liability, and, where relevant, tort. The practical result is that the entity that deployed the contract – or that holds out the protocol as its service – bears primary exposure. Anonymous or pseudonymous deployment does not extinguish liability; it creates an identification risk that regulators and courts will attempt to resolve through disclosure orders and forensic analysis.
For bridge operators governed by a DAO (decentralised autonomous organisation), the legal wrapper question is acute. An unincorporated DAO operating a bridge in the Czech Republic has no separate legal personality, which means each token-holding participant may be jointly and severally liable for the DAO's obligations. The standard mitigation is to establish a legal wrapper – a Czech entity, a foundation in a neutral jurisdiction, or a structure such as a Panama DAO wrapper – that accepts liability, holds the relevant regulatory authorisations, and contracts with users on defined terms.
In a recent matter, a token-issuance project had deployed bridge infrastructure governed by a DAO with no legal wrapper. When a third-party auditor identified a critical vulnerability, the team had no legal entity capable of signing a remediation contract, engaging external security counsel, or responding to a regulator's inquiry. We assisted in establishing an appropriate structure and repairing the contractual relationships on an accelerated timeline. The situation illustrated how governance gaps create operational risk that legal counsel must address alongside technical remediation.
Step 5: Work Through the Cross-Border Tax and Banking Interaction
For a Czech Republic-connected bridge operator, the tax and banking questions are inseparable from the regulatory ones. Czech tax law treats virtual assets as property for income-tax purposes, though the specifics of how bridge fees, wrapped-token issuance, and liquidity-provision rewards are characterised depend on the entity's structure, the contractual terms, and the flow of funds. A bridge operator earning fees in cryptocurrency faces the question of whether those fees constitute business income, and in what period they crystallise. These are fact-specific determinations; operators should not rely on generic crypto-tax guidance.
Banking access for bridge operators in the Czech Republic is constrained. Czech banks are cautious about business accounts for virtual-asset businesses, and bridge operators – particularly those whose activity is novel and whose regulatory status is transitional – face heightened due diligence demands. The practical solution most operators we advise use involves a combination: a Czech or EU-regulated payment institution for fiat operations, and a specialist crypto-friendly account for operational cryptocurrency flows, maintained in a jurisdiction with strong VASP banking infrastructure.
The cross-border dimension is critical. A bridge operator with a Czech entity, EU users, a Cayman or BVI holding company, and banking in a third jurisdiction faces a multi-layer reporting and substance requirement. Transfer pricing between the operating and holding entities, permanent establishment risk in jurisdictions where developers are based, and VAT treatment of service fees are each live issues. We structure licensing, banking and tax as one mandate rather than three disconnected workstreams – because a structure that solves the licensing question but creates a tax exposure is not a complete solution.
If a prior banking relationship collapsed or a licence application stalled, a structural review can surface the reason and the path forward. Write to OBOLUS at Map your options.
Decision Point: Which Operator Profile Are You?
Bridge operators in or connecting to the Czech Republic typically fall into one of three profiles, each with a distinct legal path.
Profile A – The incorporated Czech operator: An entity registered in the Czech Republic deploying or operating a bridge as a commercial service. This operator requires CASP authorisation from the ČNB under MiCA, a Travel Rule solution, and AML registration with the FAÚ. The timeline for CASP authorisation is not yet fixed by settled Czech NCA practice; early applicants should budget for a process measured in months rather than weeks, with the ČNB conducting substantive review of governance, AML systems, capital, and the token classification rationale. The key risk is applying before the classification analysis is complete, which can result in a request for additional information that extends the timeline materially.
Profile B – The EU-nexus operator incorporated elsewhere: A bridge operator incorporated outside the Czech Republic but with Czech or EU users or employees. This operator must decide whether to establish a Czech or other EU entity for CASP authorisation purposes (and benefit from passporting), or to restructure its user-access model to remove EU nexus. Neither path is costless. CASP authorisation requires a genuine EU presence; passive geo-blocking is not reliable without a documented reverse-solicitation analysis. The key risk is delay – operating without authorisation while the application is pending exposes the operator to supervisory intervention.
Profile C – The DAO-governed bridge: A protocol without a clear operating entity, governed by token holders via on-chain voting. This operator faces the most urgent legal task: establishing a wrapper that can hold the CASP authorisation, enter contracts with users, and absorb liability. The wrapper jurisdiction – Czech Republic, Malta, Cayman, Panama, or another suitable forum – is a decision that turns on tax efficiency, banking access, and governance flexibility. Key risk: delay in establishing the wrapper while the protocol continues to operate exposes the underlying token holders to personal liability.
Related at OBOLUS
- DeFi, Tokenization and Smart Contract Law – legal structuring for protocols, token issuers and on-chain businesses
- DAO Legal Wrapper in Panama – governance structures and legal personality for decentralised protocols
- VASP Licensing in the United Kingdom – FCA registration and MLR compliance for virtual-asset businesses
FAQ
Can a DeFi protocol be regulated?
Yes. Under MiCA, regulatory exposure turns on the substance of what a protocol does and who controls it – not on whether it labels itself "decentralised." A DeFi protocol that issues tokens referencing external assets, charges transfer fees, or is controlled by an identifiable person or entity can fall within the CASP or token-issuer authorisation requirements. Czech Republic operators face this analysis under MiCA as implemented by the ČNB. Complete decentralisation – meaning no identifiable operator – remains a theoretical position rather than a reliable compliance posture for most commercial protocols.
What legal wrapper suits a DAO?
The right wrapper depends on governance needs, tax posture, and where the DAO's regulatory authorisation will sit. Common options include a Czech or other EU entity for CASP authorisation and passporting across the EU, a Cayman Foundation Company offering flexible governance with no share capital, or a Panama DAO structure providing legal personality with member-liability protection. The wrapper must be capable of holding authorisations, contracting with users, and absorbing liability. OBOLUS advises on the full structure – regulatory, tax and governance – as a single mandate.
Who is liable when a smart contract fails?
Under Czech law, liability for a smart-contract failure defaults to general civil-law principles: the entity that deployed the contract or held out the protocol as its service bears primary exposure. Anonymous deployment does not extinguish liability – it creates an identification risk that regulators and courts work to resolve through disclosure. For DAO-governed protocols without a legal wrapper, token holders may face joint and several liability. Establishing a legal entity before deployment, and including limitation-of-liability terms in user agreements, are the standard mitigants.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers, bridge operators and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the tax, banking and compliance that sit around them. Digital assets are the whole of our practice. In our cross-border mandates, we structure licensing, banking and tax as one workstream – because a gap in any one of them undermines the others. To discuss your bridge structure, token classification, or Czech Republic regulatory exposure, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Roman Levitt, Technology & DeFi Counsel – advising on smart contract liability, protocol governance and DeFi regulatory classification across EU and multi-jurisdiction deployments.
This publication is general information about the law and does not constitute legal advice. It is not a substitute for advice tailored to your circumstances. OBOLUS accepts no liability for action taken or not taken on the basis of this material. For advice on your situation, contact info@oboluslaw.com.