Cross-chain bridges – the protocols that lock assets on one distributed ledger and mint corresponding representations on another – have reshaped how digital-asset businesses move value across ecosystems. They have also introduced a layer of legal exposure that most operators discover only after something goes wrong. A token issuer that routes user funds through a bridge serving multiple blockchain networks may simultaneously engage the securities regimes of several jurisdictions, the Travel Rule (the obligation to pass originator and beneficiary data with a transfer) requirements of others, and the liability rules of whichever legal system a court decides to apply when the bridge contract fails or is drained.
The legal question is not merely whether a bridge needs a licence. It is which jurisdiction's rules attach to which component of the bridge stack, who bears liability when an exploit occurs, and how those answers change when the entity operating the bridge, its users, and its treasury sit in three different countries. As regimes converge on MiCA and activity-based licensing models multiply from VARA in Dubai to the MAS Payment Services Act in Singapore, the cross-border character of bridge operations is moving from a structural nuance to a front-line regulatory problem.
This page maps the regulated perimeter for cross-chain bridges, works through the common-mistake patterns we see in practice, and sets out a decision matrix by operator profile. The cross-border angle runs through every section – because bridge risk is inherently multi-jurisdictional.
What Is a Cross-Chain Bridge, Legally?
A cross-chain bridge is, at its legal core, a custodial or quasi-custodial arrangement: the bridge protocol holds or controls the original asset while issuing a synthetic claim on a second chain. That description matters because custody is a regulated activity in most flagship licensing regimes, including under MiCA's CASP authorisation framework, the VARA rulebooks, and the MAS Payment Services Act. Operators who characterise a bridge purely as infrastructure – as a technical relay with no legal character – are working from a premise that regulators in the leading hubs are increasingly unwilling to accept.
The classification question turns on the substance of what the bridge does, not on the label applied in the documentation. Where a bridge holds or controls user assets at any point in the transfer cycle, it engages custody analysis. Where it mints a synthetic token redeemable for the underlying asset, it may engage e-money or asset-referenced token analysis under regimes such as MiCA. Where access to the bridge is marketed or intermediated, broker-dealer analysis enters the picture. In our practice, the first task with any bridge operator is disaggregating the stack into its legal components and mapping each against the applicable regulatory perimeter.
Which Jurisdiction's Rules Apply to a Bridge?
The applicable legal regime for a cross-chain bridge depends on where the relevant nexus points sit – and bridges typically spread those points across multiple countries by design. The operating entity may be incorporated in one jurisdiction, the validator set may be geographically distributed, the smart contracts may be deployed on a chain with no fixed seat, and the users may span dozens of national markets. Each of those facts is independently capable of attracting a regulator's attention.
In our cross-border practice, we regularly advise clients that a bridge business faces potential regulatory scrutiny from at least three directions. First, the jurisdiction of incorporation or operation: if the operator entity is licensed or required to be licensed – as a CASP under MiCA, as a VASP under the BVI VASP Act 2022, or as a digital-asset service under the AIFC/AFSA framework in Kazakhstan – that regime's rules apply to the operator's conduct regardless of where users are located. Second, the jurisdiction of the user: regulators including the FCA, MAS, and the SFC take the position that offering services to their residents engages local rules even without a local entity. Third, the jurisdiction of the assets: where the underlying locked asset is a security or a regulated instrument, the regime governing that instrument follows it into the bridge.
The practical consequence is that a bridge operator cannot design its way to a single-jurisdiction answer. It can, however, structure deliberately to reduce unintended nexus points – choosing the incorporation seat, the governance forum, and the user access design with cross-border legal exposure in mind from the outset.
To map the jurisdiction matrix for your bridge structure, contact OBOLUS at Map your options. The entity, the asset type, and the user geography each alter the analysis. A scoped assessment covers all three vectors before your next deployment decision.
Token Classification and the Wrapped-Asset Problem
Mis-classifying a wrapped token can convert a product launch into an unregistered securities offering. That risk is especially acute for bridges because the wrapped asset – a synthetic representation of the original – may carry different legal characteristics than the underlying token it tracks. A wrapped version of a governance token that confers economic rights on the new chain may look considerably more like a security than the original token did on its native chain.
The governing principle, applied consistently by the SEC, MiCA's ESMA guidance, and the FCA's cryptoasset classification work, is that classification follows the substance of the rights conferred, not the marketing label. A token called "wrapped" or "synthetic" does not thereby avoid security analysis. The relevant questions are: what rights does the holder acquire, against whom, and on what terms? A utility label on a whitepaper does not settle the legal classification. That is the most persistent myth in the token-launch space, and bridges amplify it because the wrapping process can inadvertently graft new rights onto a previously non-security asset.
We assess classification against the substance of rights at each layer of the bridge stack: the lock-up mechanism, the mint function, the redemption path, and any governance or yield features attached to the wrapped token. Where classification is genuinely uncertain, the analysis needs to be documented before deployment, not reconstructed after a regulator inquires.
Smart Contract Liability: Who Is Liable When a Bridge Fails?
When a bridge exploit drains locked assets, the liability question reaches further than most operators anticipate. The immediate question is whether the smart contract code constituted a legal representation to users – a question that turns on how the bridge was presented, what documentation governed the relationship, and whether any party made warranties about the security or performance of the protocol. Beyond that immediate question sits a chain of potential claims: against the deploying entity, against the multi-signature key holders who controlled the bridge treasury, against auditors who certified the code, and in some cases against the DAO or governance participants who approved the upgrade that introduced the vulnerability.
In a recent recovery matter involving a bridge exploit, a payments company identified the transaction path through two chains and three exchanges within hours of the breach. We engaged allied counsel in a common-law forum to secure an on-chain disclosure order against one of the exchanges, and a worldwide freezing order was in place before the attacker could move the assets to a non-custodial wallet. The outcome depended entirely on the speed of the legal response and the ability to characterise the wrapped asset as property subject to proprietary relief in that forum. That characterisation is now settled in England & Wales following AA v Persons Unknown and in Hong Kong following the court's recognition of crypto as property in Re Gatecoin, but it requires careful pleading in each case.
Liability upstream – the question of which entity the claimant sues – is where bridge operators face the most dangerous legal gap. A bridge structured as a DAO with no clear legal wrapper may leave governance token holders exposed to claims that they are general partners or co-tortfeasors, particularly in U.S. jurisdictions that have considered unincorporated DAO liability. A bridge with a Cayman Islands foundation or a BVI operating entity presents a cleaner defendant profile, though even those structures require careful maintenance to preserve the separation.
AML and the Travel Rule: Does It Apply to Bridge Transfers?
The Travel Rule – the obligation under FATF Recommendation 15 to transmit originator and beneficiary information alongside a virtual-asset transfer – applies to transfers conducted by virtual asset service providers (VASPs). Whether a bridge is a VASP, and therefore subject to Travel Rule obligations, is an active question in multiple jurisdictions. The answer depends on the same substance-over-label analysis that governs token classification: if the bridge operator controls or intermediates the transfer, it is likely to be treated as a VASP for AML purposes, regardless of how the protocol describes its architecture.
The compliance burden is compounded by the cross-chain character of bridge transfers. A transfer from chain A to chain B that passes through a bridge may be treated as a single transaction or as two separate transactions depending on the applicable AML rules. If the bridge is a VASP, it must screen both the sending and the receiving address, gather the required originator and beneficiary data, and transmit that data to any VASP at the other end of the chain. In practice, the absence of a counterpart VASP at the destination – a common feature of DeFi-native receiving addresses – creates a structural Travel Rule gap that regulators in Singapore, the EU, and the UAE are actively addressing.
If your bridge interacts with regulated VASP counterparties, the Travel Rule analysis cannot wait until after launch. Contact OBOLUS at Map your options to work through the AML architecture before the first transaction goes live.
Decision Matrix by Bridge Operator Profile
The right legal structure for a cross-chain bridge depends on the operator's profile, the asset types in scope, and the user geography. The following matrix sets out the primary decision branches in prose form.
Profile A – Institutional bridge operator, regulated asset pairs, users in licensed jurisdictions. This operator needs full CASP authorisation under MiCA if EU users are in scope, plus activity-based licensing in any additional hub (VARA for Dubai-based operations, MAS DPT licensing for Singapore). The bridge treasury should sit with a licensed custodian or within a regulated entity that can hold the locked assets as a segregated book. The wrapped token needs a classification opinion before issuance. Timeline to full licensing is typically measured in months per jurisdiction, reflecting the sequential nature of CASP and VASP applications. The principal legal risk is operating in advance of authorisation while applications are pending – a gap that regulators treat as an enforcement matter.
Profile B – Protocol-native bridge, permissionless design, no formal operator entity. This profile carries the highest regulatory exposure. Without a legal entity, every participant in governance or key management is a potential regulatory target. U.S. CFTC and SEC enforcement posture, the FCA's approach to DeFi, and ESMA's guidance under MiCA all indicate that regulators will look through protocol architecture to identify the responsible persons. The appropriate response is not to avoid incorporation but to choose the right wrapper: a Cayman Islands foundation, a BVI entity, or in some cases a Swiss association, each with a documented governance structure that separates the legal entity's obligations from the protocol's decentralised operations.
Profile C – Enterprise bridge for a tokenization platform, asset-specific, B2B users only. This operator benefits from the narrower user perimeter. B2B-only bridges may qualify for lighter regulatory treatment in some jurisdictions, particularly where the bridge is ancillary to a regulated tokenization or securities settlement service. The key risk here is that the tokenized asset itself may be a security, in which case the bridge carrying it inherits the securities-law obligations of the underlying instrument. The legal architecture needs to align the bridge's regulatory status with the classification of the assets it carries.
What Are the Common Mistakes Bridge Operators Make?
In our cross-border practice, we see a consistent pattern of structural errors in bridge deployments. The first and most common is treating the bridge as infrastructure rather than as a service. Infrastructure framing may be commercially accurate at the protocol level, but it does not map to the regulatory perimeter: regulators assess economic function, not technical architecture. A bridge that holds user assets – even transiently – is a custodial service in most regimes.
The second common error is deploying with a single-jurisdiction legal analysis. Bridge operators frequently engage counsel in their incorporation jurisdiction and treat that analysis as comprehensive. It is not. The user-facing component of the bridge engages the laws of every jurisdiction where users access the service, and the asset-specific components engage the laws of the jurisdictions whose instruments the bridge carries. A legal analysis that does not map all three vectors – entity, user, asset – is structurally incomplete.
The third error is deferring the liability structure until after an exploit. The contractual framework between the bridge operator and its users, the multi-sig key governance documentation, and the insurance or reserve architecture for hack events need to be in place before the bridge goes live. After an exploit, the question is no longer how to structure the liability – it is how to manage it. Those are very different legal engagements with very different costs.
A common assumption we encounter is that the bridge's decentralised design removes the operator from the regulatory picture. In practice, regulators have demonstrated – through enforcement in the U.S., guidance in the EU, and supervisory activity in Singapore – that they will identify the persons who deployed the contracts, hold the admin keys, or benefit from the protocol's revenues, and they will treat those persons as responsible for the applicable regulatory obligations. Decentralisation is a spectrum, not a binary, and the legal analysis follows the actual control structure.
Self-Assessment: Is Your Bridge Legally Structured?
Before a bridge goes live – or before the next version is deployed – the following questions identify where the legal exposure is likely to concentrate.
- Has the bridge operator entity been identified, incorporated, and advised of its regulatory obligations in each material jurisdiction?
- Has the wrapped token been classified against the securities and crypto-asset regimes of the jurisdictions where users will access the bridge?
- Is the bridge subject to VASP or CASP licensing requirements in any jurisdiction where it operates, and if so, has the appropriate authorisation been obtained or applied for?
- Does the AML architecture address the Travel Rule for transfers where a regulated VASP is at one end of the chain?
- Is the multi-sig governance structure documented in a legal instrument that clearly allocates liability among key holders?
- Are the terms of service governing the bridge user relationship drafted to reflect the actual technical risk profile – including smart contract failure, oracle manipulation, and liquidity events?
- If the bridge is operated by a DAO, does the DAO have a legal wrapper, and does that wrapper limit the liability of governance token holders?
- Is there a documented incident response plan – legal as well as technical – that includes pre-authorised counsel engagement, an issuer freeze request process, and a litigation-ready transaction record?
If any of these questions produces a "no" or an "unclear," the gap needs to be closed before the bridge handles material user flows. We structure licensing, banking, and tax as one mandate rather than three disconnected workstreams, and the same integrated approach applies to bridge legal architecture.
Related at OBOLUS
- DeFi, Tokenization and Smart-Contract Law – our core practice area covering the full regulated perimeter for protocol operators and token issuers
- Smart Contract Legal Review: the Compliance Burden in Practice – a detailed analysis of what a pre-deployment contract review covers and where liability concentrates
- On-Chain Asset Tracing for Early-Stage Founders – how to initiate a recovery action when bridge exploit proceeds are still traceable
FAQ
Can a DeFi protocol be regulated?
Yes – and in practice it frequently is, irrespective of its decentralised architecture. Regulators including ESMA under MiCA, the FCA, and the MAS have each indicated that they assess economic function and control over a protocol, not its technical design. Where identifiable persons deploy contracts, hold admin keys, or collect fees, those persons may be treated as the regulated operator. A protocol's decentralised label does not remove it from the regulatory perimeter; it shifts the analysis to who within the protocol sits inside that perimeter.
What legal wrapper suits a DAO?
The appropriate wrapper depends on the DAO's purpose, the jurisdictions it touches, and the liability risk its token holders carry. A Cayman Islands foundation is widely used for protocol DAOs because it provides legal personality without shareholders, aligning with the token-holder governance model. A BVI company or a Swiss association may suit narrower use cases. The choice of wrapper also affects how the DAO interacts with exchanges, banking counterparties, and regulators – all of whom require a legal entity to contract with. There is no universal answer; the structure follows the facts.
Who is liable when a smart contract fails?
Liability when a smart contract fails turns on the contractual relationship between the deploying entity and users, the representations made about the contract's security or fitness for purpose, and the applicable tort or delict regime. Where the operator is an identifiable legal entity, it is the primary defendant. Where the protocol is a DAO without a legal wrapper, governance token holders who voted on relevant upgrades or who hold admin keys may face direct claims. Auditors who certified the contract may face professional liability claims. The answer varies by jurisdiction and by the specific failure mode.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers, protocol 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. We assess token and protocol classification against the substance of rights and economic function – not the marketing label. We structure licensing, banking, and tax as one mandate rather than three disconnected workstreams. To discuss your bridge legal architecture or to commission a pre-deployment classification review, contact info@oboluslaw.com or message us via t.me/oboluslaw.
By Roman Levitt, Technology & DeFi Counsel – specialising in smart-contract liability, protocol legal architecture, and cross-border regulatory analysis for bridge and DeFi 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.