Cross-chain bridges sit at one of the most legally unsettled intersections in digital-asset practice. A protocol that moves tokens between two blockchain networks can, depending on its design, constitute a payment service, a custody arrangement, an exchange facility, a securities intermediary, or some combination of all four – each triggering a different regulatory obligation under Lithuanian law and, where European Union frameworks apply, across the entire single market. The MiCA regulation (the EU's Markets in Crypto-Assets Regulation) and the Payment Services Act transposed from the revised Payment Services Directive together form the primary legal perimeter in Lithuania. For any business building or operating a cross-chain bridge with Lithuanian-registered entities or Lithuanian-resident users, the classification question is not academic. It determines whether the entity needs a CASP authorisation (Crypto-Asset Service Provider licence) from the Bank of Lithuania, whether the Travel Rule – the obligation to pass originator and beneficiary data with a transfer – applies to bridge transactions, and whether the smart contracts powering the bridge constitute regulated financial infrastructure. This guide maps those risks step by step.
What activities does a cross-chain bridge trigger under Lithuanian law?
A cross-chain bridge is regulated at the point where it performs an activity that falls within the MiCA CASP perimeter or the payment-services regime – not at the point where it uses smart contracts to do so. The Bank of Lithuania, as Lithuania's national competent authority under MiCA, applies a substance-over-label test: what the bridge actually does determines the licence category, not what the whitepaper says it does. That principle cuts both ways. A bridge that merely relays a message between two chains and releases locked tokens may look like a custody operation. A bridge that temporarily holds assets in escrow and issues a wrapped token in exchange looks like both a custody service and, arguably, an exchange. One that charges a fee denominated in a reference asset moves closer to an asset-referenced instrument under the MiCA ART (asset-referenced token) regime. The MiCA CASP framework covers, among other activities, the custody of crypto-assets on behalf of clients, the operation of a trading platform for crypto-assets, and the transfer of crypto-assets on behalf of clients. A bridge that does any of those things – whether through human operators or autonomous contracts – sits inside the perimeter.
In our cross-border practice, we consistently find that bridge operators underestimate the custody angle. The lock-and-mint model – where native tokens are locked on Chain A and a wrapped version is minted on Chain B – involves a period during which the bridge contract holds the original tokens. That temporal custody, even if contractually framed as a technical escrow, maps onto what MiCA defines as the safeguarding of crypto-assets and the private keys relating to them on behalf of clients. When the operator controls the bridge contract's admin keys, the supervisory exposure is direct.
The Travel Rule, grounded in the FATF Recommendation 15 and implemented through Lithuania's AML/CFT legislation, applies to virtual-asset transfers meeting the applicable threshold – and a cross-chain bridge transfer is, in regulatory substance, a transfer. The question of whether the bridge operator qualifies as the originating or beneficiary VASP (virtual asset service provider) determines whose compliance obligation it is to collect and transmit originator and beneficiary data. Where the bridge is permissionless and has no identifiable operator, that obligation migrates to any centralised on-ramp or off-ramp that interacts with it.
How does a business obtain CASP authorisation from the Bank of Lithuania for a bridge-related activity?
Obtaining CASP authorisation from the Bank of Lithuania requires a complete application demonstrating governance, capital adequacy, AML/CFT controls, and technological resilience – the application process is sequential and document-intensive, typically spanning several months from submission to decision. The Bank of Lithuania already had direct experience supervising cryptocurrency-related entities under the pre-MiCA VASP regime, which means its supervisory expectations are informed and its review process is substantive rather than administrative. Applicants should not treat the process as a registration formality.
The core steps are as follows:
- Activity scoping: map the bridge's functions – transfer, custody, exchange, advisory – against the MiCA CASP activity categories and determine which authorisation class or classes apply. A bridge combining custody and transfer services will need an authorisation covering both activities.
- Entity establishment: the applicant must be a legal entity incorporated in Lithuania or another EU member state seeking to passport from Lithuania. For a new entrant, that means incorporating a UAB (private limited company) or an equivalent EU-registered vehicle.
- Policy and control documentation: the Bank of Lithuania requires AML/CFT policies, internal controls, conflicts-of-interest procedures, outsourcing arrangements (critical where bridge logic is deployed on a third-party protocol), and a technology risk framework addressing smart-contract audit status, key management, and incident response.
- Capital demonstration: MiCA sets minimum own-funds requirements that vary by CASP activity category. The exact figures are set by the regulation and depend on which services are authorised; they should be confirmed against the current consolidated MiCA text and the Bank of Lithuania's published guidance.
- Fit-and-proper assessment: the Bank of Lithuania will assess the management body and shareholders holding qualifying interests. For a bridge operated by a DAO-adjacent structure or a multi-sig committee, identifying the natural persons responsible for management is a recurring structural challenge.
- Whitepaper (where applicable): if the bridge issues a crypto-asset – including a wrapped token that falls under MiCA's "other crypto-assets" category – a compliant whitepaper must be notified to the Bank of Lithuania before publication. Where the wrapped token has characteristics of an ART or EMT, a separate authorisation track applies.
- Passporting notification: once authorised in Lithuania, a CASP may passport its services across the EU and EEA by notifying the Bank of Lithuania, which then coordinates with the relevant host-state authority. For a bridge serving users across multiple member states, this is the primary commercial advantage of the Lithuanian route.
The timeline from submission of a complete application to authorisation decision is qualitatively described in the MiCA text as a matter of months; the Bank of Lithuania's own practice under the prior VASP regime moved faster than many EU counterparts, but applicants should plan for the process to run longer than the statutory minimum if the application requires supplementary information rounds. In our practice, we advise clients to treat the preparation phase – prior to formal submission – as the longest and most consequential stage. A structurally weak application does not fail quickly; it consumes time in correspondence while the clock runs.
To assess whether your bridge structure requires a CASP authorisation and which activity categories apply, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the bridge architecture, the token economics, the user geography – change the analysis materially.
How does MiCA classify the tokens a cross-chain bridge produces or moves?
Token classification under MiCA turns entirely on the rights and functions the token actually confers, not on the label assigned in the documentation – and for bridge operators, that principle creates a structural trap. The most common bridge-generated token is a wrapped asset: a synthetic representation of a native token, redeemable for the underlying on return. Under MiCA, the classification of that wrapped token depends on whether it references the value of one or more assets, whether it functions as a means of payment, and whether it confers rights against an issuer.
A wrapped token that maintains a one-to-one peg to a single native crypto-asset is most naturally an "other crypto-asset" under MiCA – subject to whitepaper obligations but not to the more demanding ART or EMT authorisation tracks. However, a bridge that wraps a fiat-pegged stablecoin – moving a USDC or USDT equivalent from one chain to another – is handling what may be classified as an EMT (e-money token) on both sides of the bridge. The issuer of the underlying EMT holds the authorisation; the bridge operator handling it takes on CASP transfer or custody obligations. Mis-classifying a token can convert a product launch into an unregistered securities offering or an unauthorised payment service. That is not a theoretical risk. The Bank of Lithuania has demonstrated willingness to act on unauthorised activity since its supervision of the earlier VASP register.
A further classification question arises when a bridge charges a fee payable in a governance token. If that governance token carries rights to revenue distributions or voting rights over a protocol generating income, the token may acquire characteristics of a transferable security under the EU's Markets in Financial Instruments Directive, which MiCA explicitly carves out of its own scope. In that case, the bridge operator faces a separate MiFID II analysis, not just a MiCA one. In our practice, we have seen governance token designs that were clearly intended as pure utility mechanisms nonetheless acquire security-like characteristics as the protocol matured and fee flows became material.
Who bears legal liability when a cross-chain bridge smart contract fails?
When a bridge smart contract fails – through an exploit, a logic error, or an oracle manipulation – the question of who is liable turns on the legal relationship between the bridge operator, the smart-contract deployer, and the user whose assets were lost. There is no single answer, but the analysis in Lithuanian and EU law converges on several liability vectors. First, where the bridge operator holds a CASP authorisation for custody or transfer services, the safeguarding obligations under MiCA create a direct duty to clients. A smart-contract failure that results in loss of client assets will be measured against whether the operator met its technical resilience and security obligations under the MiCA CASP regime. Second, where the bridge is operated without authorisation but falls within the CASP perimeter, the operator faces both regulatory enforcement and civil claims from affected users. Third, even a genuinely decentralised bridge – one without an identifiable operator – may attract liability at the periphery: the team that deployed the contract, the DAO token holders who voted to approve a parameter change, or the front-end provider who presented the bridge to end users.
In Lithuania, the general civil liability provisions of the Civil Code apply in the absence of sector-specific rules. A court assessing liability for a smart-contract failure will examine the nature of the obligation – was it a best-efforts service or a result obligation? – and whether the failure was foreseeable and preventable. Smart contracts that have not been audited by an independent technical auditor are in a materially weaker position; the absence of an audit is circumstantial evidence of negligence in the operation of a financial service. MiCA's operational resilience requirements, which apply to authorised CASPs, effectively import a duty-of-care standard that courts can reference even in non-CASP disputes.
The DAO liability question deserves particular attention. Where a bridge is governed by a DAO structure – a DAO (decentralised autonomous organisation) in which token holders vote on protocol parameters – Lithuanian law does not recognise the DAO as a legal entity. That means the DAO's governance actions may be attributed to its participants, particularly those who voted affirmatively on a change that caused the failure. Wrapping a DAO in a recognised legal structure – a Lithuanian UAB with a governance framework that mirrors DAO voting, a Cayman Foundation company, a Wyoming LLC, or a BVI entity – before the bridge goes live is the standard mitigation. Choosing the right wrapper depends on the protocol's economics, the user base, and the operator's appetite for ongoing regulatory engagement.
What are the cross-border tax and banking implications for a Lithuanian bridge operator?
A Lithuanian CASP operating a cross-chain bridge faces a three-layer cross-border problem: the entity is taxed in Lithuania, its services are consumed across the EU under passport, and its banking relationships must support both fiat and crypto flows in multiple jurisdictions. Each layer interacts with the others in ways that can neutralise the advantages of the Lithuanian licence if they are not addressed together.
On the tax side, the Lithuanian corporate income tax regime applies to the entity's Lithuanian-source and worldwide income if it is resident in Lithuania. Token issuance events, bridge fees, and treasury management all have Lithuanian tax consequences that need to be mapped against the specific token and revenue model. Where a Lithuanian entity issues wrapped tokens on behalf of users, the question of whether the issuance constitutes a taxable supply under Lithuanian VAT law requires specific analysis; the EU's VAT treatment of crypto-asset services is not uniform and Lithuania's position should be confirmed with current guidance from the State Tax Inspectorate. In our practice, we consistently find that operators who plan the licence first and the tax structure afterwards encounter avoidable mismatches between the corporate structure and the revenue model.
On the banking side, Lithuanian payment institutions and banks have become more cautious about crypto-related corporate customers in the period since MiCA's adoption. An authorised CASP with a clean AML/CFT framework and a business model the compliance team can describe clearly is in a stronger position than an unlicensed entity. However, banking is not automatic even for regulated entities; the operator needs a corporate account capable of handling fiat settlements, a custody arrangement for the bridge's treasury assets, and – where the bridge interacts with EMTs – a banking relationship with an issuer or processor that handles redemption flows.
The cross-border angle intensifies for bridges that serve users outside the EU. Where Lithuanian-domiciled bridge infrastructure processes transactions for users in the UAE, Singapore, Hong Kong, or the United States, the operator picks up compliance obligations in those jurisdictions in addition to the MiCA/Lithuanian regime. VARA in Dubai, the MAS Payment Services Act regime in Singapore, and the SFC's VASP licensing framework in Hong Kong each have their own triggers. A bridge with Lithuanian CASP authorisation does not automatically satisfy any of those non-EU regimes. The operator's cross-border user footprint must be mapped against each relevant regime, and in some cases allied counsel in the relevant jurisdiction will need to be engaged to confirm local obligations.
If your bridge structure involves users or banking relationships outside the EU, write to OBOLUS at info@oboluslaw.com to map the full compliance stack. If a prior application stalled or a banking relationship was declined, a second structural review can surface the underlying cause and the route forward.
A cross-chain bridge matter in practice
In a recent cross-border structuring matter, a development team building a multi-chain bridge approached us after a national regulator in an EU member state flagged their wrapped-token model as potentially requiring an EMT authorisation rather than a standard CASP transfer-service licence. The wrapped token in question was designed to represent a Euro-pegged stablecoin across two EVM-compatible chains. We reviewed the token's rights structure, the bridge contract's custody mechanics, and the fee model. Our analysis confirmed that the wrapped token did not itself qualify as an EMT under MiCA because the redemption right ran against the underlying stablecoin issuer rather than against the bridge operator; the bridge's obligation was a transfer and custody service, not an issuance. We restructured the contractual documentation to make that distinction explicit, updated the whitepaper disclosure language to reflect the correct classification, and assisted the team in preparing the Bank of Lithuania CASP application covering transfer and custody activities. The application was submitted on schedule and the regulatory correspondence resolved the classification question without requiring a separate EMT authorisation track. The bridge went live the following quarter.
Which regulatory profile applies to your bridge build?
Bridge operators are not a uniform category. The regulatory exposure and the corresponding authorisation strategy vary materially by architecture and business model. The following profiles capture the most common configurations we advise on.
Profile A – Centralised bridge with identified operator: A business entity controls the bridge contracts, holds admin keys, and charges fees to users. This profile sits squarely inside the MiCA CASP perimeter for custody and transfer services. The operator needs a CASP authorisation from the Bank of Lithuania (or another EU NCA), an AML/CFT programme meeting FATF Travel Rule expectations, and a technology risk framework. The timeline to authorisation is a matter of months from a complete submission. The key risk is operating during the application period without interim status clarity.
Profile B – Protocol-controlled bridge with governance token: The bridge operates via smart contracts governed by a DAO with a governance token. No single entity holds admin keys. This profile faces the question of whether the governance token is a security (MiFID II analysis) and whether the DAO's governance participants are collectively operating an unlicensed CASP. The recommended mitigation is to establish a legal wrapper – a Lithuanian UAB, a Cayman Foundation, or a BVI entity – to hold the deployment infrastructure and enter into contracts, and to apply for CASP authorisation in the operator entity's name. The timeline is the same as Profile A, but the preparatory work to define the governance entity takes longer.
Profile C – Non-custodial bridge (atomic-swap or message-passing): The bridge never takes custody of assets; it facilitates atomic swaps or passes verified messages that trigger releases on each chain. This is the profile most likely to fall outside the MiCA custody perimeter. However, if the bridge charges a fee, facilitates exchange between different crypto-assets, or interacts with EMTs, residual CASP exposure may remain. A regulatory opinion confirming the non-custodial position should be obtained before launch, particularly if the bridge is accessible to EU-resident users.
Profile D – Bridge operated as a feature of a broader licensed platform: The bridge is embedded in an exchange, wallet, or custodian that already holds or is seeking CASP authorisation. In this case, the bridge activity is subsumed within the existing authorisation if the CASP scope covers the relevant activity categories. The operator needs to confirm that its existing authorisation (or application) explicitly includes bridge-related transfer and custody activities. An amendment to an existing authorisation is materially faster than a fresh application.
Is a "utility" label on a whitepaper sufficient to avoid regulatory classification?
A common assumption in the bridge and DeFi space is that labelling a token as a utility token in the whitepaper resolves its legal classification. It does not. The Bank of Lithuania, ESMA, and every major EU national competent authority that has addressed token classification publicly applies a substance-over-form test. The label is evidence of the issuer's intent; it is not determinative of the token's legal character. What matters is the rights the token actually confers: is there a right to revenues, to interest, to redemption at a fixed value, or to vote on economic parameters that affect token value? If yes, the token may be a security, an ART, or an EMT regardless of what the whitepaper calls it.
In our practice, we assess classification against the full rights structure, the economic incentives built into the token model, and the actual behaviour of the token in secondary markets. That analysis frequently produces a different result from a plain reading of the whitepaper. For a bridge operator, the cost of mis-classification is not a fine at launch; it is an enforcement action that requires unwinding a live product while users hold affected tokens. The earlier the classification question is addressed in the design phase, the more options are available to structure around a problematic classification.
Related to this myth is the belief that because a bridge is technically "non-custodial" it is automatically unregulated. As noted above, that is not necessarily true. The technical architecture is a factor in the analysis, but it is not the only factor. A non-custodial bridge that facilitates exchange between crypto-assets for a fee, that operates a front-end accessible to EU users, and that issues governance tokens with economic rights may, in aggregate, engage multiple MiCA CASP activity categories.
Related at OBOLUS
- DeFi, Tokenization and Smart-Contract Law – our core practice covering DeFi protocol structuring, token issuance and smart-contract legal frameworks across jurisdictions.
- NFT Project Legal Structuring in Jersey – how to structure an NFT project in a common-law offshore hub with favourable regulatory positioning.
- Enforcement of Foreign Judgment Under Heightened Scrutiny – cross-border enforcement strategy when a recovery order must survive challenge in a second forum.
FAQ
Can a DeFi protocol be regulated?
Yes. The legal test is whether the protocol performs an activity that falls within a regulated perimeter – under MiCA, a payment-services directive, or a securities regime – regardless of whether a human intermediary is involved. A DeFi protocol that operates an exchange function, provides custody of client assets, or issues tokens referencing fiat or other assets may require CASP authorisation from the Bank of Lithuania or another EU national competent authority. Decentralisation of the technical layer does not, by itself, remove regulatory exposure from the entity or individuals that deploy, govern, or profit from the protocol.
What legal wrapper suits a DAO?
The appropriate legal wrapper for a DAO depends on the protocol's governance model, its user base, and the jurisdiction in which it seeks regulatory engagement. Common options include a Lithuanian UAB for EU-facing activity requiring CASP authorisation, a Cayman Foundation company for protocols wishing to limit participant liability without a share structure, and a BVI entity for broader international flexibility. Wyoming and Marshall Islands LLC structures are used in some US-adjacent contexts. Each wrapper has different tax, liability, and governance implications. There is no universal answer; the choice should follow a full analysis of the DAO's economic model and regulatory exposure.
Who is liable when a smart contract fails?
Liability for a smart-contract failure in Lithuania is assessed under general civil liability principles and, where the contract was operated as part of a regulated service, under the MiCA CASP regime's operational resilience standards. An authorised CASP bears primary responsibility to clients for safeguarding failures. Where a DAO governs the protocol, governance participants who voted to approve a change that caused the failure may face attribution of liability. The deploying team, the front-end provider, and any entity marketing the service to users are all potential defendants. Independent security audits and clear contractual terms mitigating liability for inherent smart-contract risk are the standard baseline mitigations.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers, DeFi protocols 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. We assess classification against the substance of rights, not the marketing label – and we work alongside forensic partners to convert on-chain evidence into court-ready disclosure applications where recovery is required. To discuss your bridge structure, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Roman Levitt, Technology and DeFi Counsel – advising on DeFi protocol structuring, cross-chain legal risk, smart-contract governance, and token classification across EU and non-EU digital-asset regimes.
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.