Cross-chain bridges sit at the intersection of multiple legal regimes simultaneously. A bridge that locks assets on Ethereum, mints wrapped tokens on an alternative layer-one chain, and routes liquidity through an automated smart contract does all of this without a centralized operator visible to any one regulator. In Bermuda, that architecture raises immediate questions under the Digital Asset Business Act (DABA) regime — the island's principal statutory framework for digital asset activity. The analysis that follows maps the legal exposure, identifies the regulatory classification question, and sets out the practical steps an operator should take before going live.
Why Bermuda matters for bridge operators
Bermuda was among the first common-law jurisdictions to enact a purpose-built digital asset business statute, and it remains one of the most structurally coherent environments for technology-forward crypto projects. The Bermuda Monetary Authority (BMA) administers the DABA regime, which requires any person carrying on digital asset business (as defined) in or from Bermuda to hold a licence. A cross-chain bridge entity incorporated or operated from Bermuda falls squarely within that inquiry.
The BMA's activity-based approach means the classification question starts not with the technology but with the economic function. Does the bridge hold, transfer, or exchange digital assets on behalf of others? Does it issue a wrapped token that functions as a claim against a locked reserve? Each positive answer pulls the operation closer to a licensed activity under the applicable DABA provisions. In our practice, we see bridge developers assume that operating through a smart contract severs the jurisdictional link. It does not. The BMA looks to where the founding entity, the operational team, and the management decisions sit — not only to where the code runs.
The BMA's DABA regime applies to entities incorporated in Bermuda and to those conducting digital asset business from the island. For an inbound bridge operator, that reach is deliberately broad.
What legal risk does a cross-chain bridge actually create?
Cross-chain bridge legal risk in Bermuda is not a single question — it is a stack of overlapping exposures that compound if left unaddressed before launch.
The first layer is regulatory classification. A bridge that custodies locked assets even temporarily may be providing a custody service under the DABA regime. A bridge that mints wrapped tokens pegged to an underlying asset may be issuing a digital asset that resembles an asset-referenced token — a category that draws heightened scrutiny under both the Bermuda regime and, where EU users are involved, under MiCA (the Markets in Crypto-Assets Regulation administered by ESMA and national competent authorities). Mis-classification at this layer can convert what the developer intends as a utility product into an unlicensed securities or money-service operation.
The second layer is smart-contract liability. When a bridge exploit or oracle manipulation causes users to receive fewer assets than they deposited, the question of who bears legal responsibility turns on the contractual and tortious relationship between the deployer, the governance community, and the user. Bermuda common law treats this as a standard negligence and contract analysis, but the facts of a decentralized system make attribution genuinely difficult.
The third layer is AML/CFT compliance. Bridges are a documented vector for value obfuscation. The FATF's guidance on virtual assets — including Recommendation 15 on virtual asset service providers — expressly contemplates cross-chain transfer mechanisms. The BMA aligns its supervisory expectations with FATF standards. A bridge that processes transfers without adequate transaction monitoring and a meaningful Travel Rule posture will face enforcement exposure even if it holds a valid licence.
The fourth layer is cross-border reach. If the bridge serves users located in EU member states, the UK, or the United States, the Bermuda licence does not exhaust the compliance map. MiCA's ART/EMT provisions, the FCA's financial promotion rules, and US federal frameworks administered by the SEC, CFTC, and FinCEN each carry independent application depending on the token's economic characteristics and the users' geography.
A common assumption in the builder community is that a utility label on a whitepaper settles the legal classification. It does not. Classification follows the substance of the rights conferred — the economic exposure, the governance rights, and the redemption mechanics — not the marketing term chosen. We assess classification against that substance in every engagement.
How does the BMA licensing process work for bridge operators?
An operator seeking to run a cross-chain bridge from Bermuda should approach the BMA licensing process as a multi-stage structured dialogue, not a one-shot filing. The BMA operates a tiered system under DABA, and the applicable tier depends on the breadth of activities the bridge conducts.
The process typically proceeds in the following sequence.
Step 1: Pre-application scoping
Before any formal submission, the operator should conduct a detailed activity mapping exercise. This means listing every function the bridge performs — locking, minting, relaying, fee collection, governance token distribution — and assessing each against the DABA defined activities. The output is a scoping memo that identifies which activities require a licence and which (if any) fall outside the regulatory perimeter. This memo also anchors the pre-application conversation with the BMA.
Operators we advise regularly discover at this stage that their architecture touches more licensed activities than the founding team anticipated. A relayer that collects fees for routing transfers may itself be providing a transfer service. A governance token with fee-sharing mechanics may carry the hallmarks of a security under the applicable regime.
Step 2: AML/CFT programme design
The BMA requires licence applicants to demonstrate a functioning AML/CFT programme at the point of application, not as a post-licence deliverable. For a bridge, this requires a written risk assessment of the specific cross-chain transfer vectors the protocol supports, a transaction monitoring policy that addresses the technical realities of wrapped-token mechanics, and a Travel Rule compliance solution that can attach originator and beneficiary data to transfers at or above the applicable threshold under the relevant FATF-aligned provisions.
The Travel Rule — the obligation to pass originator and beneficiary identification data alongside a transfer — is particularly testing for bridge architectures because the minting event on the destination chain is structurally distinct from the lock event on the source chain. Counsel and the compliance team need to agree a coherent position on how that data travels across the bridge before filing.
Step 3: Entity and governance structuring
Most serious bridge projects reaching the BMA licensing stage have already incorporated a Bermuda entity, typically an exempted company. The licensing application, however, also scrutinises the governance layer. If the bridge is governed by a DAO (decentralized autonomous organization) — a token-holder collective that votes on protocol upgrades and fee parameters — the BMA will want to understand the relationship between the DAO and the licensed Bermuda entity. That relationship needs to be documented in the constitutional documents and the governance framework before the application is filed.
A pure on-chain DAO without a legal wrapper creates significant liability risk for token-holder participants who may be treated as general partners under Bermuda or applicable foreign law. The practical solution is a formal legal wrapper — a Bermuda exempted company, a foundation, or an LLC depending on the governance architecture required. Each structure has different tax, liability, and governance implications that need to be mapped before a choice is made.
Step 4: Formal application and BMA review
The formal DABA application includes the corporate documents, the AML/CFT programme, the business plan, the technical architecture overview, the governance framework, and the fitness-and-propriety materials for each beneficial owner and senior manager. The BMA's review timeline varies by complexity, though bridge applications with a sophisticated governance structure and a novel technical architecture typically require a more extended review period than standard exchange or custody applications. The BMA may request additional information during review, and responsiveness at that stage materially affects the overall timeline.
Step 5: Ongoing compliance post-licensing
A DABA licence is a continuing obligation. The BMA expects licensees to report material changes to the business model, the governance structure, and the technology. For a bridge, a protocol upgrade that changes the asset types supported, the wrapped-token mechanics, or the oracle design may constitute a material change requiring pre-notification. Building a regulatory change-management process into the protocol's upgrade governance is not optional — it is a condition of maintaining the licence.
Contextual bridge: The process above describes the standard path. Your facts — the entity structure, the user base's geography, the token mechanics, and the banking relationships — change the analysis at every step.
To map the licence, AML, and governance stack for your bridge build, write to OBOLUS at info@oboluslaw.com. For a scoped assessment, you can also map your options here.
How does token classification drive legal exposure?
Token classification is the single highest-stakes legal determination a bridge project makes, and it must be resolved before any public-facing activity begins. The classification question applies to both the wrapped token the bridge mints and, where relevant, the governance token used to administer the protocol.
Under the DABA regime, a digital asset that confers rights resembling a debt instrument or equity interest in an enterprise may trigger additional regulatory obligations beyond the base DABA licence. Where the wrapped token is pegged to a basket of assets or to a fiat currency, the ART/EMT analysis under MiCA becomes relevant for any EU-connected distribution, regardless of the issuer's Bermuda domicile.
The practical classification analysis asks three questions for each token type. First, what rights does holding the token confer on the holder — purely technical access, a governance vote, a share of revenue, or a redemption right against a specific reserve? Second, is the token marketed, distributed, or used in a way that creates a reasonable expectation of profit from the efforts of others? Third, is the token redeemable at a predictable value, and if so, against what reserve and under what conditions?
A bridge governance token that distributes protocol fees proportionally to stakers will receive significantly more regulatory scrutiny than a purely voting token with no economic return. In our cross-border practice, we regularly see the fee-distribution mechanic introduced late in the tokenomics design process — often after the classification analysis has been completed — which requires the entire exercise to be reopened.
The cross-border dimension matters acutely here. A token that passes the Bermuda classification analysis may still be characterised as a security by the SEC or CFTC under US federal law, or as a financial instrument by an EU national competent authority applying MiCA. The Bermuda analysis is a necessary starting point, not a complete answer.
What liability framework applies when a bridge is exploited?
Bridge exploits — whether through oracle manipulation, smart-contract vulnerabilities, or validator key compromise — have resulted in some of the largest losses in the digital asset sector. The legal question of who is liable under Bermuda law turns on the structure of the relationship between the deployer and the user.
Where the bridge is operated by an identified licensed entity, the starting point is contract. The terms of service — or, in the absence of formal terms, the implied terms arising from the architecture of the product — define what the operator promised. A bridge that represents itself as custodying assets in a specific smart contract architecture, and then changes that architecture through an upgrade that is subsequently exploited, faces exposure for breach of those representations under ordinary Bermuda contract law.
Where the bridge is governed by a DAO and no licensed entity is identified, the liability analysis becomes more difficult — but not more favorable to participants. Bermuda courts, applying common-law principles inherited through the island's constitution and judicial practice, would likely look for the individuals or entities that exercised material control over the protocol at the time of the loss. Developers who hold administrative keys, multisig signatories who approved the exploited upgrade, and foundation board members who supervised the protocol may all face personal exposure if the DAO wrapper provides no meaningful insulation.
In a recent recovery-adjacent matter, a DeFi protocol deployer approached us in the weeks following an oracle manipulation event. The protocol had been governed by an unincorporated token-holder collective with no formal legal documentation. We assisted in assessing the liability position of the founding team members, identifying the contractual and tortious exposure under the applicable common-law analysis, and advising on the options available to users who had suffered loss. The matter underscored that governance informality does not reduce liability — it redistributes it to identifiable individuals.
How does the cross-border tax and banking dimension interact?
A Bermuda-licensed bridge operator benefits from a tax environment that, as a general matter, does not impose corporate income tax or capital gains tax on the entity's digital asset activities — a structural advantage that draws technology-forward businesses to the island. That advantage does not extend automatically to the operator's principals, investors, or users in higher-tax jurisdictions.
The tax analysis for a cross-chain bridge involves at least three distinct questions. The first is where the bridging income — fees, spread, and protocol revenue — is generated and booked. The second is how the wrapped-token issuance and redemption mechanics interact with the tax treatment of the underlying locked assets, which will differ materially depending on whether the tax authority treats the lock event as a disposal. The third is whether the operator has created a taxable presence or permanent establishment in any jurisdiction through the activities of team members, servers, or validators operating outside Bermuda.
Banking is a parallel constraint. Bermuda-incorporated digital asset businesses need banking relationships to operate. Bermuda has a small domestic banking sector, and the willingness of those institutions to serve DABA-licensed bridge operators depends heavily on the quality of the AML/CFT programme and the clarity of the business model. Cross-border banking — maintaining accounts in the US, the UK, or Singapore to service international payment flows — requires those jurisdictions' banks to be comfortable with the Bermuda regulatory status and the AML posture. We regularly advise on the documentation package that makes that conversation productive rather than protracted.
If a prior application stalled or a banking relationship did not progress, a second read of the structural facts can surface the reason and the route forward. Write to us at info@oboluslaw.com or map your options here.
Decision matrix: which operator profile should structure how?
Not every bridge project has the same legal profile, and the appropriate structure varies accordingly. The following framework reflects patterns we observe in practice.
Profile A — an institutional-grade bridge handling significant volumes between well-established layer-one networks, with identified developers and a Bermuda exempted company already in place. This profile should pursue a full DABA licence, invest in a formal AML/CFT programme with a FATF-aligned Travel Rule solution, and negotiate a governance agreement between the licensed entity and any associated DAO. Timeline to launch readiness is driven by the BMA review period, which varies by complexity, but the operator should plan for a period measured in months rather than weeks. Key risk: the AML programme for cross-chain transfers requires specialist technical input that many compliance consultants without DeFi experience cannot provide.
Profile B — an early-stage bridge project with a small founding team, no significant locked value, and a primarily technical user base. This profile may sit below certain thresholds under the DABA regime during a development phase, but that assessment must be confirmed by qualified Bermuda counsel before any public launch. Assuming a permissive position without legal confirmation is the single most common structural mistake in this category. Key risk: the growth trajectory of successful bridge projects means that a project that starts below regulatory thresholds may cross them rapidly, and retroactive compliance is harder and more expensive than pre-launch compliance.
Profile C — a bridge operated by a DAO with no identified legal entity, seeking to use Bermuda as a governance and structuring base. This profile requires resolution of the DAO legal wrapper question before any BMA engagement is possible. The options — Bermuda foundation, exempted company, or a hybrid structure with a foundation holding shares in an operating company — each have different governance, liability, and tax implications. The legal wrapper decision is the critical first step, and it cannot be delegated to the tokenomics or governance community alone.
Self-assessment checklist before you launch
Before engaging with the BMA or accepting user deposits, a bridge operator based in or structured through Bermuda should be able to answer yes to each of the following questions. An honest no — or a not sure — is a signal to engage counsel before proceeding.
- Has the activity mapping exercise been completed, and has each bridge function been assessed against the DABA defined activities by qualified counsel?
- Has the token classification analysis been conducted for both the wrapped token and any governance token, covering both Bermuda law and the applicable foreign law for each material user geography?
- Does the legal entity structure reflect the governance architecture of the protocol, including the relationship between any DAO and the licensed entity?
- Is an AML/CFT programme in place that addresses the specific technical characteristics of cross-chain transfers, including a written Travel Rule compliance position?
- Has the terms-of-service documentation been reviewed for the liability exposure created by the smart contract architecture, including the upgrade and governance mechanics?
- Are banking relationships in place that can withstand the due diligence of the relevant financial institutions in each jurisdiction where the operator maintains accounts?
- Is there a regulatory change-management process that will identify and notify material changes to the protocol's architecture or governance before those changes go live?
Related practices at OBOLUS:
- DeFi, Tokenization & Smart-Contract Law – end-to-end legal counsel for protocol operators, token issuers and DeFi builders
- DAO Legal Structures – A Practical Guide – legal wrapper options for decentralized autonomous organizations and governance communities
- Transfer Pricing for Crypto Groups under MiCA – cross-border tax structuring for digital asset groups operating within the EU MiCA regime
FAQ
Can a DeFi protocol be regulated?
Yes. Regulatory status follows function, not form. A DeFi protocol that custodies assets, facilitates transfers, or issues tokens conferring economic rights may fall within the licensing perimeter of the BMA's DABA regime or other applicable regimes regardless of its decentralized architecture. The relevant question is whether an identifiable entity or individual exercises material control over the protocol's operation — and in most cases, at least during the development phase, one does.
What legal wrapper suits a DAO?
The appropriate legal wrapper depends on the DAO's governance architecture, its commercial relationships, and the liability profile the founding team is willing to accept. Bermuda offers several structural options, including exempted companies and foundations, each with different governance, liability, and tax characteristics. The wrapper choice must be made before BMA engagement and should reflect the relationship between on-chain governance rights and the responsibilities of the licensed entity. There is no universal answer — the choice is fact-specific.
Who is liable when a smart contract fails?
Liability turns on the relationship between the deployer and the user at the time of the failure. Where an identified entity operated the protocol, the analysis begins in contract and tort under the applicable law. Where governance was exercised by a DAO, courts applying common-law principles will look to individuals who held and exercised material control — including multisig keyholders and upgrade approvers. A well-drafted terms-of-service document and a sound legal wrapper reduce, but do not eliminate, that exposure.
About OBOLUS
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 structures 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 applied — and we work alongside forensic partners to convert on-chain evidence into court-ready disclosure applications where disputes arise. To discuss your bridge or DeFi project, contact info@oboluslaw.com or message us via t.me/oboluslaw.
By Roman Levitt, Technology & DeFi Counsel — specialist in smart-contract legal architecture, cross-chain protocol structuring, and DAO governance frameworks across multiple jurisdictions.
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.