A token issuer building a cross-chain bridge discovers, weeks before mainnet, that routing assets between two Layer-1 networks may constitute a money transmission activity, a securities intermediation function, or both – depending on which regulator looks first. For early-stage founders, that classification question is not academic. It determines whether the protocol requires a licence, whether the token is a regulated instrument, and whether the team carries personal liability for every transfer processed before the legal structure was confirmed.
Cross-chain bridge legal risk sits at the intersection of DeFi legal analysis, smart contract liability, and cross-border regulatory reach. A bridge does not merely move value; it transforms the legal character of that value as it crosses network and, in many cases, jurisdictional boundaries. This page maps the core risk categories, the structuring choices available to early-stage teams, and the process by which counsel works through the analysis before a single line of production code is deployed.
Why Cross-Chain Bridges Attract Regulatory Attention Faster Than Other DeFi Products
Regulators treat a cross-chain bridge as a regulated entity when it performs the functional equivalent of a licensed activity, regardless of whether the team intended that outcome. Under MiCA, the transfer of crypto-assets on behalf of third parties is a regulated service requiring CASP authorisation; a bridge that executes that transfer automatically does not escape the perimeter simply because the intermediation is coded rather than manual. The same logic applies under the applicable VASP provisions enforced by VARA in Dubai, the Payment Services Act administered by MAS in Singapore, and the money-transmitter licensing regimes maintained by US state regulators and FinCEN at the federal level.
The functional test is what matters. Regulators ask: does the protocol lock assets on one chain and issue a representative token on another? Does it hold user funds, even briefly, in a smart contract controlled by a multisig or a governance module? Does it charge a fee for the service? Affirmative answers push the analysis toward a regulated activity, and the jurisdiction of the user – not of the founding team – often determines which regulator asserts authority first.
In our cross-border practice, we have seen early-stage teams proceed to mainnet on the assumption that decentralisation removes the licensing obligation. Regulators across the major hubs have consistently rejected that assumption. The FCA in the UK, ESMA's guidance supporting national competent authorities under MiCA, and the SEC in the United States have each signalled that the degree of decentralisation is a fact-intensive question, not a switch that turns off regulatory perimeter analysis.
The cross-border dimension compounds the risk. A bridge deployed by a Cayman-incorporated foundation with EU users and a multisig controlled by US-resident key-holders simultaneously engages at least three regulatory regimes. Each regime may assert jurisdiction over a different aspect of the same operation.
To map your bridge's regulatory perimeter before launch, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity, the user base, the custody model – change the analysis materially.
Token Classification: How the Wrapped Asset Changes Everything
Every cross-chain bridge issues some form of representative token, and the legal character of that token is a separate question from the character of the bridging service itself. Mis-classifying that token is the single fastest route from a product launch to an unregistered securities offering.
The classification analysis turns on substance, not label. A whitepaper that describes a bridged token as a "utility token" does not settle the legal question. Under MiCA, tokens must be assessed against the ART (asset-referenced token) and EMT (e-money token) categories before defaulting to the general "other crypto-assets" regime; each category carries distinct issuer authorisation and whitepaper obligations. Under US securities law, the applicable analysis examines whether holders receive an investment contract – a test that evaluates economic reality, not marketing terminology.
A wrapped Bitcoin or wrapped Ether product issued by a bridge protocol presents a different profile from a bridge-native governance token. The wrapped product may attract ART analysis under MiCA if it references an external asset. The governance token may attract securities analysis if it confers profit-participation rights or signals an expectation of return from the efforts of the development team. Both instruments can exist in the same protocol, and each requires its own classification memo before the product goes live.
We assess classification against the substance of rights conferred – voting power, redemption rights, revenue participation, transferability – not against the marketing label applied at issuance. That discipline matters because a regulator reviewing the protocol post-launch will apply the same substance-over-form approach, and the classification memo produced before launch is the primary evidentiary tool available to the founders.
Smart Contract Liability: Who Holds the Keys When the Bridge Fails?
When a cross-chain bridge suffers an exploit, a failed oracle update, or a governance attack, the liability question turns on who controlled the relevant decision points at the time of the loss. Smart contract code does not create a liability-free environment; it reassigns the question of control to a different set of facts.
The relevant control points in a typical bridge architecture include the multisig that can upgrade the contract, the oracle or relayer network that validates cross-chain state, the governance module that approves parameter changes, and the emergency pause function that could have halted operations before a loss propagated. Each control point is potentially a point of legal responsibility. A founder who holds two of five multisig keys may carry liability in a jurisdiction that applies a functional control test. A development company that wrote the upgradeability logic may carry liability under a negligence theory in a common-law forum if the upgrade mechanism was foreseeable as a vector for loss.
In a recent recovery matter, a payments-adjacent protocol suffered a bridge exploit that moved a seven-figure balance across three networks before the pause function was activated. We worked with on-chain forensics specialists to trace the assets through wrapped-token unwrapping transactions and identified the destination addresses within hours of the loss event. The analysis was used to support a disclosure application in a leading common-law forum, and a freezing order was obtained against the identified wallets before the assets could be further dispersed. The founding team's prior engagement with counsel on the protocol's governance architecture significantly shortened the time needed to establish the control-point analysis for the court.
The lesson is structural: decisions made at the architecture stage – about who holds keys, how upgrades are approved, and where the pause authority sits – are simultaneously engineering decisions and legal decisions. Treating them as only the former creates the gap that a post-exploit litigation must then bridge.
AML, the Travel Rule, and Bridge Protocols: A Compliance Gap That Regulators Are Closing
The Travel Rule (the obligation, derived from FATF Recommendation 15, to pass originator and beneficiary data with a virtual asset transfer) was designed for centralised intermediaries. Cross-chain bridges were not designed with the Travel Rule in mind. That gap is now the subject of active regulatory attention across every major hub.
A bridge that functions as a VASP under the applicable regime is expected to collect, hold and transmit originator and beneficiary information for each transfer above the applicable threshold. The threshold varies by jurisdiction and the de-minimis level is a [VERIFY] item in each specific regulatory context – but the obligation exists at some threshold in every regime that has implemented FATF Recommendation 15, including the MiCA framework in the EU, the VASP provisions enforced by VARA in Dubai, the Payment Services Act administered by MAS, and the AML/CFT rules maintained by CIMA in the Cayman Islands.
The practical difficulty is architectural. A bridge that operates through a smart contract and a decentralised relayer network has no natural point at which to insert a Travel Rule data collection step. That architectural constraint does not create a regulatory exemption; it creates a compliance design problem that must be resolved before the protocol serves users in Travel Rule jurisdictions. Solutions range from integrating a Travel Rule protocol at the front-end interface level to restricting access to users who have completed KYC through a compliant on-ramp. Each solution has different implications for the protocol's decentralisation posture and its user experience.
We regularly advise founding teams on the compliance design question before the architecture is finalised, because retrofitting Travel Rule compliance into a live bridge is significantly more expensive than building the data-passing capacity into the original design.
DAO Structure and the Decision Matrix: Choosing the Right Legal Wrapper for a Bridge Protocol
The choice of legal wrapper for a cross-chain bridge protocol shapes every downstream legal question: who holds the IP, who employs the contributors, who enters the banking relationship, and who is the counterparty when a regulator issues a notice. A DAO structure (a decentralised autonomous organisation) without a legal wrapper leaves each of those questions answered by operation of general law – typically by imposing joint and several personal liability on the most identifiable participants.
The decision matrix for early-stage bridge founders generally presents three primary profiles:
Profile A – Foundation wrapper (Cayman or BVI). A non-profit foundation holds the protocol IP and enters third-party contracts. The governance token is issued by the foundation. Timeline to structure: typically a matter of weeks for the entity formation, with the token documentation and VASP analysis running in parallel. Key risk: the foundation model is under increasing regulatory scrutiny in jurisdictions that characterise the foundation as the controlling entity for regulatory perimeter purposes.
Profile B – Dual-entity structure. A foundation holds the protocol, and a separate operating company (often in a licensing-friendly jurisdiction such as the AIFC in Kazakhstan or under the ADGM regime in Abu Dhabi) holds the licence and the banking relationship. The operating company is the regulatory interface; the foundation is the governance layer. Timeline: longer, as the VASP or CASP application runs on top of the entity formation work. Key risk: transfer-pricing and substance requirements mean the operating company must have genuine economic substance in its jurisdiction.
Profile C – Wrapped DAO with LLC or DUNA equivalent. Some US-incorporated protocols now use a Wyoming DAO LLC or a newer statutory form to give the DAO legal personality. This addresses the joint-and-several liability problem for US-resident participants but does not resolve the non-US regulatory question and may attract US securities law scrutiny if governance tokens are publicly traded. Key risk: the legal wrapper may anchor the protocol to US jurisdiction in ways the team did not anticipate.
No single wrapper is correct for every profile. The right answer depends on where the key-holders are resident, where the users are located, what licence (if any) the protocol's activity requires, and what the token's legal character is on classification analysis.
If a prior structuring attempt stalled or a banking relationship closed, a second read can surface the structural reason and the route forward. Contact OBOLUS at info@oboluslaw.com to map the entity, licence, and compliance stack for your build.
Cross-Border Regulatory Risk: The User Base Determines the Exposure, Not the Founding Team's Address
The most common misconception among early-stage bridge founders is that incorporating outside the United States, the European Union, or the United Kingdom removes exposure to those regulators. It does not. Each of those regimes asserts jurisdictional reach based on where users are located, not where the development team is incorporated.
MiCA's CASP authorisation requirement applies to entities that provide crypto-asset services to persons in the EU, regardless of where the entity is established. The FCA's financial-promotion regime applies to communications that are capable of being received by UK persons. The SEC has consistently asserted extraterritorial reach over offerings and trading activity that affects US persons, even when the issuer has no US presence.
A cross-chain bridge with open access – no geofencing, no KYC at the interface level – is effectively serving users in every jurisdiction simultaneously. That means the team must either obtain the relevant licences, implement credible access restrictions, or accept a risk posture that includes multi-jurisdictional regulatory exposure.
In our cross-border practice, we have worked with bridge teams operating out of the AIFC in Kazakhstan, under the ADGM regime in Abu Dhabi, and through BVI-incorporated foundations to construct access policies and jurisdiction-specific disclosures that form part of a documented, good-faith compliance posture. That posture is not a guarantee of regulatory safety, but it is the evidence base that distinguishes a team that tried to comply from one that did not consider the question.
Allied counsel in the relevant jurisdiction are engaged where the local-law analysis requires a qualified opinion on the ground. That network covers the major licensing hubs and the primary dispute forums.
Common Mistakes Early-Stage Bridge Teams Make Before Launch
The most consequential mistakes in bridge development occur not at the code level but at the legal-architecture level, and they almost uniformly happen before the first regulatory interaction rather than during it.
The first and most frequent is proceeding to a public token issuance without a classification memo. A team that issues a governance or bridged token without a written legal analysis of its classification in the primary jurisdictions of its user base has no evidentiary foundation for its own good-faith defence if a regulator subsequently characterises the token as a security or an ART. The memo does not need to be long; it needs to be written, dated, and grounded in a substantive analysis of the rights conferred.
The second common mistake is treating the legal structure as a post-launch problem. Entity formation, VASP analysis, and compliance design are pre-deployment tasks. A bridge that goes live before the entity structure is confirmed is one that may be operating as an unincorporated association or a general partnership under the law of the founders' home jurisdiction – with the liability consequences that follow.
The third is underestimating the banking dependency. A bridge protocol generates fee revenue. That revenue needs a banking or payment-processing relationship. Banks and payment processors apply their own due-diligence standards to crypto-related clients, and those standards frequently require a licence, a compliance programme, and a legal opinion on the nature of the activity. Founders who defer the legal work until they need the bank account find that the bank account is the forcing function – and by then the legal work is on an emergency timeline with the associated cost.
A self-assessment question worth asking before launch: can the team produce a written answer to each of the following? What is the legal character of each token the protocol issues? What activity does the protocol perform, and in which jurisdictions does that activity require a licence? Who controls the upgrade and pause functions, and what liability does that control create? If any of those questions draws a blank, the legal architecture is not ready.
Related at OBOLUS
- DeFi, Tokenization and Smart Contract Law – our core practice for protocol founders, token issuers and DAO structures across jurisdictions.
- Staking Service Legal Framework in Bermuda – the regulated basis for staking operations and yield-generating DeFi products in a leading offshore hub.
- Sanctions Screening for Crypto in South Korea – compliance obligations for protocols and exchanges serving Korean users or operating through Korean infrastructure.
FAQ
Can a DeFi protocol be regulated?
Yes. A DeFi protocol falls within the regulatory perimeter when it performs a function that requires a licence under the applicable regime – such as transferring crypto-assets on behalf of third parties, providing custody, or operating an exchange function. Regulators apply a functional test based on what the protocol actually does, not on whether it is described as decentralised. The degree of decentralisation is a fact-intensive question, and no regime currently treats full decentralisation as an automatic exemption from licensing obligations.
What legal wrapper suits a DAO?
The appropriate wrapper depends on where key-holders reside, where users are located, and what activity the DAO's protocol performs. Common structures include a Cayman or BVI foundation holding the protocol IP, a dual-entity model pairing a foundation with a licensed operating company in a VASP-friendly jurisdiction, and a Wyoming DAO LLC for teams with significant US-resident participation. No single structure suits every profile. A classification and activity analysis should precede the entity decision, because the wrapper follows the regulatory characterisation, not the other way around.
Who is liable when a smart contract fails?
Liability turns on who held meaningful control at the relevant decision points – the multisig signers who could upgrade the contract, the governance participants who approved a parameter change, the development company that introduced the vulnerability. Common-law forums, including courts in England and Wales and Singapore, have demonstrated willingness to pierce the smart-contract layer and identify controlling parties for the purpose of freezing orders and damages claims. Legal structuring decisions made at the architecture stage directly affect the liability analysis after a failure.
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, 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 token classification, contact info@oboluslaw.com.
By Roman Levitt, Technology and DeFi Counsel – specialising in smart contract liability, protocol governance structures, and token classification for early-stage DeFi and cross-chain infrastructure teams.
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.