Cross-chain bridges – the protocols that lock assets on one blockchain and mint equivalent representations on another – sit at an intersection of operational complexity and regulatory ambiguity that established operators underestimate at significant cost. A business that deploys or integrates a bridge without first mapping the legal exposure can find itself operating an unlicensed money-transmission facility, issuing an unregistered security, or holding unhedged civil liability for losses caused by a smart-contract exploit. In our practice advising exchanges, custodians and token issuers, we have seen this risk surface well after a build is live – when regulatory scrutiny or a security incident forces the legal question that should have been answered at the design stage. This page sets out the regulated basis for cross-chain bridge activity, the specific legal risks established operators face, the cross-border structuring issues that arise when a bridge connects users across multiple regulatory regimes, and the process we follow to reduce that exposure.
What is cross-chain bridge legal risk, and why does it matter now?
Cross-chain bridge legal risk is the aggregate of regulatory, civil liability and contractual exposure that arises when a protocol moves or represents digital assets across separate blockchain networks. It is not a single legal category. It spans money-transmission law, securities regulation, custody rules, AML/CFT obligations and, in some regimes, the treatment of tokenized representations as new issuances requiring fresh authorization.
The risk has intensified as regulators in the leading hubs – including ESMA and national competent authorities under MiCA, the SEC and CFTC in the United States, and the FCA in the United Kingdom – have begun examining whether bridge operators are conducting regulated activities. The question they ask is not how the protocol is labeled. It is what the protocol does: does it transfer value? Does it hold assets in custody? Does it issue a new instrument? The answers determine the regulatory gate.
For an established operator – a licensed exchange, a custodian, or a token issuer with an existing product set – adding a bridge is not a neutral technical decision. It is an activity expansion. It may require a licence variation, a new AML program, or a disclosure obligation to existing regulators. Operators we advise routinely discover that their current authorization does not extend to the bridge function they have built.
How do regulators classify bridge activity?
Regulatory classification of a cross-chain bridge turns on the legal substance of what the bridge does, not the label its developers apply. Across the regimes we track, three classification outcomes recur with the greatest frequency.
First, where a bridge holds assets in a smart contract on the origin chain while minting a wrapped token on the destination chain, the lock-and-mint mechanic can constitute custody – a regulated activity under MiCA's CASP framework, the FSRA regime in ADGM, and the VARA rulebooks in Dubai. If no authorized entity controls the custody function, the operator may be providing custody without authorization.
Second, the minted wrapped token may itself constitute a new instrument. Under MiCA, a wrapped token that tracks the value of another asset could be analyzed as an asset-referenced token (ART) – requiring issuer authorization rather than the lighter CASP registration. Under US securities law, the SEC has taken positions suggesting that certain wrapped tokens carrying economic rights may be investment contracts. The analysis is fact-specific, but the risk is real.
Third, where a bridge processes transfers involving fiat-denominated stablecoins or tokens with a fixed value peg, the activity may constitute money transmission or payment services. In the United States, state money-transmitter licensing requirements apply on a state-by-state basis. In Singapore, the Payment Services Act administered by MAS requires a licence for Digital Payment Token services. In the UK, FCA registration under the Money Laundering Regulations is the baseline, with additional financial-promotion obligations for any bridge that handles stablecoins marketed to UK users.
The cross-border dimension compounds this. A bridge connecting Ethereum and a Layer 2 may be accessed by users in the EU, the UAE, Singapore and the United States simultaneously. Each user base can trigger the regulatory requirements of its home jurisdiction. An operator licensed in one hub is not automatically covered for users in another.
A common assumption we encounter is that a utility label on a whitepaper settles the legal classification of a bridge token. It does not. We assess classification against the substance of rights the token carries – economic exposure, governance weight, redemption mechanics – not the marketing description. Regulators apply the same lens, and the gap between label and substance is where enforcement actions originate.
For a scoped regulatory classification review of your bridge architecture, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity, the user base, the token mechanics – change the analysis.
Who bears liability when a bridge smart contract fails?
When a bridge exploit occurs, the legal question of who bears liability is resolved by examining the contractual relationship between the operator and users, the representations made in the bridge documentation, and the applicable law determined by conflict-of-laws rules.
In our cross-border practice, we have observed three common liability structures in bridge documentation, each carrying different risk profiles.
Under the first model, the bridge is presented as a pure peer-to-peer protocol. The documentation disclaims all operator liability and characterizes the smart contract as the sole mechanism of performance. Courts in common-law jurisdictions – including England and Wales and Singapore – have begun scrutinizing whether such disclaimers are enforceable where the operator retains upgrade authority, pause authority, or fee-extraction rights. If the operator can intervene in the protocol, the disclaimer is harder to sustain.
Under the second model, a legal entity stands behind the bridge and accepts some form of operational responsibility. This is the structure most regulators prefer. It creates a clear enforcement target, but it also concentrates the civil liability that arises from an exploit. The challenge for established operators is that the entity behind the bridge may already hold a licence that imposes capital adequacy, insurance or indemnification obligations – obligations that were sized for the original business, not for bridge-scale custody exposure.
Under the third model, a DAO structure governs the bridge, with token holders voting on upgrades and parameter changes. DAO legal risk is a distinct area of practice. Without a legal wrapper – a Cayman foundation, a BVI company, a Marshall Islands LLC, or equivalent – DAO participants may bear joint and several liability as an unincorporated association. Operators integrating a DAO-governed bridge inherit that governance risk if they cannot demonstrate clear separation between the bridge protocol and their licensed entity.
The practical point for an established operator is this: the liability posture of a bridge cannot be defined solely by its smart-contract code. It is defined by the documentation, the governance architecture, the degree of operator control, and the jurisdiction that will adjudicate a dispute. All four factors require legal input before deployment.
What AML and Travel Rule obligations apply to bridge operators?
AML/CFT obligations under the FATF Recommendations – including Recommendation 15 on virtual assets and the Travel Rule requiring originator and beneficiary data to travel with a transfer – apply where the bridge operator is a virtual asset service provider (VASP) under the applicable national implementation.
Whether a bridge operator is a VASP turns on the same activity analysis described above. Where the bridge custodies assets, processes transfers on behalf of users, or facilitates exchange, the VASP characterization is likely. The Travel Rule then requires that transaction-identifying information be transmitted to the next obliged entity in the transfer chain. For a bridge, the "next obliged entity" question is genuinely difficult: the destination chain may have no VASP in the conventional sense, and the counterparty may be a non-custodial wallet. Regulators in the major hubs have not yet provided uniform answers.
In practice, established operators we advise take one of two approaches. The first is to apply their existing VASP compliance program to bridge-mediated transfers, treating bridge transactions as within scope from day one. The second is to obtain a legal opinion confirming that the bridge activity falls outside the VASP perimeter before launch – with the opinion based on current regulatory guidance in each relevant jurisdiction, updated as guidance evolves. Neither approach is costless, but the first is generally more defensible in an examination context.
Sanctions exposure is a parallel concern. Where a bridge processes transactions for users in sanctioned jurisdictions, or where bridge liquidity pools receive funds from sanctioned addresses, the licensed operator entity faces OFAC or equivalent exposure. The smart-contract neutrality of the bridge is not a defense available to a licensed entity with a US nexus.
How should an established operator structure a bridge for cross-border compliance?
The cross-border structuring question for a bridge operator is, at its core, a question of entity design: which legal entity operates which function of the bridge, in which jurisdiction, and under which regulatory authorization.
In our practice, we work through four structuring axes when advising an established operator on a bridge build.
The custody nexus. The entity that holds locked assets on the origin chain should be the entity that holds the relevant custody authorization. If that entity is in the EU, MiCA CASP authorization covers the custody function. If it is in Dubai, VARA authorization is needed. If it is in Singapore, the MAS Payment Services Act framework applies. Operating the custody function from an entity without authorization in the jurisdiction of the user base creates a coverage gap.
The issuance nexus. The entity that mints wrapped tokens on the destination chain may be a different entity from the one that operates the custody. Where the wrapped token is classified as an ART or an EMT under MiCA, the minting entity needs issuer authorization – not merely CASP authorization. This is a structuring point that has caught operators by surprise, because the distinction between a CASP and an issuer is not always intuitive at the product level.
The governance nexus. If the bridge is governed by a DAO or a multi-sig controlled by contributors across multiple jurisdictions, the governance structure needs a legal wrapper that identifies the responsible entity, limits the liability of token holders, and provides a clear counterparty for regulatory correspondence. We regularly advise on Cayman foundation structures and BVI vehicles as governance wrappers for bridge protocols.
The user nexus. The applicable regulatory regime is determined in part by where users are. A bridge that geo-blocks US users still needs to consider the Travel Rule obligations of the EU regime for EU users, the VARA rulebook for UAE users, and the MAS framework for Singapore users. A global bridge operated from a single-entity structure is almost always non-compliant in at least one material jurisdiction.
To map the licence, banking and compliance stack for your bridge build, write to info@oboluslaw.com. If a prior application stalled or an existing authorization does not cover the bridge activity you are planning, a structural review can identify the route forward.
What are the most common legal mistakes bridge operators make?
The most common legal mistake in a bridge deployment is treating the bridge as a technical extension of an existing product rather than as a new regulated activity requiring its own authorization analysis.
We have seen this pattern play out in several ways. A licensed exchange adds a bridge to support multi-chain withdrawals and does not check whether its exchange license covers custody on the origin chain or issuance on the destination chain. A token issuer deploys a bridge to expand its token's reach across networks and does not consider whether the bridge mint constitutes a new issuance that requires a whitepaper or disclosure under MiCA. A custodian integrates a third-party bridge into its product stack and does not analyze whether the bridge provider is a regulated entity – exposing the custodian to counterparty risk it has not disclosed to its own regulator.
A second recurring mistake is inadequate documentation of the legal relationship between the bridge operator and its users. Bridge documentation that is copied from open-source repositories typically contains governing-law and dispute-resolution clauses that were written for a different entity in a different jurisdiction. They may specify a jurisdiction that the operator does not operate in, a governing law that imposes strict liability standards the operator has not priced, or a dispute mechanism that is unenforceable in the user's home country.
A third mistake is governance opacity. Where a bridge's upgrade keys or pause authority are held by individuals rather than a legal entity, and where those individuals are in multiple jurisdictions, the governance structure creates regulatory and liability uncertainty that no disclaimer can cure. Regulators in the major hubs increasingly expect to identify a legal person responsible for a bridge's operation. An anonymous multi-sig does not satisfy that expectation.
In a recent matter, a mid-sized payments company had deployed a bridge that processed stablecoin transfers across three networks. When the operator sought to expand into a regulated market, the licensing authority identified that the bridge custody function was unattributed to any authorized entity and that the wrapped token it minted had not been subject to any classification analysis. We restructured the entity architecture, obtained a classification opinion, and prepared the disclosure for the licensing application. The operator was able to proceed with the expansion on a timeline measured in months rather than years.
Which bridge structure suits your operator profile?
Different operator profiles call for different legal structures. The right answer depends on the operator's existing authorization, its user base, the assets the bridge handles, and its risk tolerance. The matrix below describes four common profiles.
Profile A – Licensed exchange adding a bridge for multi-chain withdrawals. The existing exchange license typically covers the transfer function but may not cover the custody of locked assets on the origin chain as a standalone activity. The practical instrument is a license variation or a separate custody authorization for the entity operating the lock function. Timeline depends on the regulator and the scope of the existing authorization; it is typically a matter of weeks for a variation in a well-functioning regime. Key risk: if the locked-asset custody is material in scale, the regulator may impose additional capital or insurance requirements.
Profile B – Token issuer bridging its token to additional networks. The mint on the destination chain is the critical legal point. If the wrapped token is economically identical to the original, the classification analysis is relatively straightforward. If the wrapped version carries additional governance or economic rights, a fresh classification analysis is needed. The applicable instrument depends on the classification outcome: CASP authorization, ART/EMT issuer authorization under MiCA, or a no-action analysis in a jurisdiction that permits informal regulatory engagement. Key risk: a wrapped token that is classified differently from the original creates a two-regime compliance burden.
Profile C – Custodian integrating a third-party bridge. The custodian's primary obligation is due diligence on the bridge provider. Is the provider regulated? Does the provider carry insurance or a bond? Does the bridge documentation create a sub-custody relationship that the custodian must disclose to its regulator? The instrument is a third-party provider assessment and a contract that clearly allocates liability. Key risk: a bridge exploit that causes client asset loss where the custodian has not disclosed the sub-custody arrangement to its regulator or its clients.
Profile D – DAO-governed bridge seeking a legal wrapper. The typical instrument is a Cayman foundation company or a BVI company, with the governance token-holder community as the beneficiary of the foundation. The foundation provides a legal person for regulatory correspondence, limits contributor liability, and permits the bridge to enter contracts. The applicable timeline for entity formation in the Cayman Islands or BVI is measured in weeks for a standard structure. Key risk: if the foundation's governance documents do not reflect the actual decision-making power of the token holders, the wrapper will not protect contributors from liability in a dispute context.
A common assumption: DeFi protocols are self-regulating and outside the regulatory perimeter
A common assumption among bridge operators is that a sufficiently decentralized protocol operates outside the regulatory perimeter – that DeFi is, by definition, not regulated. This assumption is incorrect as a matter of current regulatory direction.
MiCA explicitly reserves the question of fully decentralized protocols for future legislative attention, but the ESMA-supervised CASP regime already captures protocols that are not fully decentralized. The test is whether a person or entity provides services to third parties. Where a bridge has an identifiable operator – a company, a foundation, a multi-sig held by identified persons – the service-provision test is likely met. The degree of decentralization affects the analysis but does not automatically exclude the protocol from regulation.
In the United States, the CFTC and SEC have each brought enforcement actions against DeFi protocol operators, asserting that the presence of an identifiable development team or governance token-holding entity is sufficient to establish jurisdiction. The FCA in the United Kingdom has similarly indicated that the economic substance of an activity, rather than its technical architecture, determines whether financial promotion and registration requirements apply.
The practical implication for an established operator is that adding a DeFi bridge component to a regulated business does not reduce the regulatory exposure of the business as a whole. It may increase it, by bringing the bridge activity within the scope of the operator's existing license obligations – obligations that were not designed with bridge-scale activity in mind.
Related at OBOLUS:
- DeFi, Tokenization & Smart-Contract Law – the full OBOLUS practice area covering token issuance, smart-contract liability, and DeFi structuring for businesses
- DAO Legal Wrapper for Established Operators – how to select and implement a legal entity structure for DAO-governed protocols
- Token Sale Agreement Drafting in Cayman Islands – Cayman-law documentation for token issuances, including bridge token offerings
FAQ
Can a DeFi protocol be regulated?
Yes. Whether a DeFi protocol is subject to regulation depends on whether an identifiable person or entity provides services to third parties through it. Under MiCA, the VARA rulebooks, the MAS Payment Services Act, and the FCA's regime, the regulatory perimeter extends to protocols with an identifiable operator regardless of their technical architecture. Full decentralization may take a protocol outside the perimeter, but most operational bridges retain an upgrade authority, a fee-extraction mechanism, or a governance structure that satisfies the service-provision test. Legal analysis of the specific protocol is required before drawing any conclusion.
What legal wrapper suits a DAO?
The most common wrappers for DAO-governed bridge protocols are the Cayman foundation company, the BVI business company, and the Marshall Islands decentralized autonomous organization LLC. Each provides a legal person for regulatory correspondence and contract counterparty purposes, and each limits the liability of token-holding contributors. The right choice depends on the DAO's user base, the regulatory regimes it touches, and whether the governance token is likely to be classified as a security in any material jurisdiction. A Cayman foundation is widely used where the protocol has EU, UAE or Singapore users.
Who is liable when a smart contract fails?
Liability for a smart-contract failure is determined by examining the operator's documentation, the representations made to users, the degree of control the operator retained over the contract, and the governing law. Where an operator retains upgrade authority or pause authority, disclaimers of liability are harder to sustain in common-law courts. Where a legal entity stands behind the protocol, that entity bears the primary civil exposure. Where a DAO without a legal wrapper governs the contract, participants may bear joint and several liability as an unincorporated association. In each case, the analysis is jurisdiction-specific and fact-specific.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers 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 token classification against the substance of rights conferred – not the marketing label – and our disputes team coordinates freezing relief and on-chain tracing across leading common-law forums. To discuss your bridge structure or cross-chain compliance position, contact info@oboluslaw.com.
By Roman Levitt, Technology & DeFi Counsel – specializing in smart-contract liability analysis, DeFi protocol structuring, and cross-border token classification for established digital-asset operators.
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.