An ever increasingly multi-chain world has led to the proliferation of cross-chain bridges, a key technological innovation providing a solution for a fundamental challenge: allowing different blockchain networks to communicate and share assets.
As new blockchains continue to emerge, each with its unique features and assets, the need for these cross-chain bridges has become evident. As of January 2024, the total value locked (TVL) in major cross-chain bridges on Ethereum is approximately $23.5 billion. Arbitrum One has the highest TVL at $10.52 billion, followed by Optimism Bridge at $6.13 billion, while Polygon PoS bridge ranks third at $2.27 billion.[1] In this article, we will delve deep into the architecture, benefits, and challenges of the different types of cross-chain bridges, and then proceed to assess the potential regulatory implications under the EU’s Markets in Crypto-Assets Regulation (MiCA) given the multiple components underlying most bridging implementations.
Cross-Chain Bridges – Overview and Architecture Types
Cross-chain bridges enable the transfer of assets and information between separate blockchain networks, enabling smart contract execution such as token swaps, but also data transfers for various other interactions.
Transferring digital assets between different blockchains can be beneficial for multiple reasons. For instance, someone might want to transfer their Bitcoin to the Ethereum blockchain to use it in Decentralised Finance (DeFi) platforms, where they can potentially earn interest on their Bitcoin. In other instances, the cost of executing a transaction on a blockchain like Ethereum may be prohibitively large, and users may want move their assets to less costly chains to incur in cheaper transaction fees for their activities. Regardless of the user's needs, transferring assets from one blockchain to another requires a bridging protocol to ensure that the bridged asset can be used on only one blockchain at a time, preventing double spending.[2]
The need of cross-chain bridges stems from the inherent design of blockchains as self-contained systems. This is due to smart contracts being “passive”, (i.e., they cannot actively read data without an external trigger), and unaware of any data outside the blockchain ledger they live on. This inability to read external data also extends to data that exists on other blockchains, and thus a communicator is needed to read events on one blockchain and sends a corresponding signal on the destination blockchain. Moreover, since blockchains operate independently from each in self-contained systems, it is not feasible to directly transfer a digital asset from one blockchain to another. Instead, a version of the asset from the original blockchain needs to be replicated on the destination blockchain. This process requires communication between different blockchains, and the communication system or protocol enabling this interaction is known as a bridge.
Bridge Architecture
The typical architecture of a cross-chain bridge includes three main components: the source chain, the destination chain, and the cross-chain component. The source chain corresponds to the blockchain where the asset originates, as seen in the figure 1 below. On the other hand, on right side of figure 1 is the target blockchain, the destination blockchain of the transfer. The cross-chain component is the core part of the bridge architecture. It usually involves an oracle system for cross-chain communication, and a verification mechanism to verify the authenticity of cross-chain messages.
Figure 1 - Cross-chain Bridge Overview. Source: Author
Cross-chain Bridge Standard Implementation
The first element of a bridge is a custodian on the source blockchain, a role that is typically taken up by a smart contract. The custodian role is simple: locking up the assets that are deposited into it. The second element of a bridge is an issuer on the destination chain. The issuer role is to create, on the destination chain, a representation of the assets which have been locked up on the source chain. The architecture involving a custodian and an issuer is structured to prevent the duplication of digital assets transferred via a bridge. For this reason, it is crucial for bridges to only create the destination chain version of assets only after confirming receipt of the actual asset on the originating blockchain. This method ensures that only one version of the token can be actively traded at any given moment, thereby averting the risk of double spending. In the context of the bridge cross-chain communication protocol, we can conceptualise the custodian-issuer elements as foundational anchors, each firmly positioned within its own distinct blockchain. Bridging the gap between these two anchors is a dynamic third component, a conduit of sorts, which facilitates the flow of information and transactions across the different chains. This cross-chain component transmits messages from the source chain to the target chain and it might take different forms. The most common form is that of an oracle, an agent that is able to fetch (and write) external information into a blockchain ecosystem. Other forms include the use of relay nodes, which may involve creating a network similar to the ones of the blockchains that they are trying to bridge assets between.
Focusing on the most common form of cross-chain communication, an oracle is a specialised agent with both data transmission and data verification responsibilities. In cross-chain bridges designs, the oracle is the communicator that listens to a signal from one blockchain and writes it to another. The signal in this process is usually a transaction being executed , and the communication can be in either direction, i.e., from the source blockchain to the destination blockchain, or vice-versa. Thus, bridges, typically combine these three elements: asset custodians, representation issuers, and oracles.
In a standard bridge implementation, the bridging process is as follows: as a first step the user transfers an asset to a custodian, which locks it immediately. Upon receipt of the digital asset, the custodian signals that the asset were received and that the corresponding issuer on the destination blockchain can create or unlock a representation of the asset. The cross-chain communicator listens to this signal and transmits it to the destination chain. On the destination chain, the issuer can now issue a representation of the asset for use on the new blockchain. Should the user want to bridge the asset back on the original chain, the process is reversed. A user first destroys (burns) the token on the destination chain. The cross-chain communicator listening to the destination chain will notice the event corresponding to a burn, and will signal the transaction to the custodian on the original source chain. Upon receipt of the signal, the custodian will then release the asset on the source blockchain to return to the initial state of the bridging process.
Figure 2 - Standard Bridge Architecture. Source: Author
The one described above is an overview of cross-chain bridges standard implementation workflow and components. Diving deeper into bridges implementation and their architecture, bridges can be classified into four types, based on the verification method used: the Notary model, also known as externally verified model; the Hash-Time Lock model, also known as locally verified model; the Relay Model, also known as the natively verified model; and lastly the Optimistic Verification Model.
Types of Cross-Chain Bridging Architecture
The Notary Model
The Notary model establishes a trusted third party to manage cross-chain operations. There are two variants:
- Single-Signature Notary: A centralised approach where a single entity verifies and initiates cross-chain transactions. While fast, it is vulnerable to single points of failure.
- Multi-Signature Notary: This model requires a majority of notaries to verify a cross-chain request. Transactions proceed only if more than a specific threshold of notaries (e.g., two/thirds) achieve consensus.
Figure 3 - Notary Cross-Chain Bridge Model. Source: Author
In this model, when users send assets to a designated address on the source chain, these assets are temporarily locked. External validators, which could be Proof of Authority (PoA)-based Multi-Party Computation (MPC) networks, Proof of Stake (PoS) based MPC networks, Oracles, or Trusted Execution Environment (TEE) networks, verify the transaction and enable the target chain to generate corresponding assets.
For example, the Multichain Bridge (formerly Anyswap) uses an MBI (Multiple Blockchain Interaction) architecture, incorporating Secure Multi-Party Computing (SMPC) and a Threshold Signature Scheme (TSS) distributed key generation algorithm for decentralized cross-chain message passing. This system involves a group of nodes, each independently managed by various organisations, institutions, and individuals. These nodes collaboratively generate portions of a private key used for signing transactions. Nodes collectively sign transactions and no single node can sign a transaction individually, so that the full private key is never fully assembled. This approach ensures that the complete key remains secure and cannot be intercepted.
Externally verified bridges offer efficiency and high scalability, but their security heavily relies on the external validation set, which often forms the weakest link in the security chain. This architecture has been susceptible to severe hacking incidents, underscoring the inherent risk of relying on external validators.
Hash-Time Lock Model
This model leverages smart contracts for decentralised asset management. Locally Verified Bridges use a peer-to-peer liquidity network model, directly trading and verifying original assets between the source and target chains. This model typically employs atomic swaps based on hash time lock contracts. Hash-time lock contracts make use of a piece of data known only to a specific user, the so-called Secret, which is usually a random number. The secret ensures security and trustlessness in transactions. The sender cannot reclaim the tokens until the time expires, and the recipient can only claim the tokens by proving they know the secret.
Examples include the cBridge by Celer, which enables high-speed, low-cost cross-chain payments between Ethereum Layer 2 systems and other Layer 1 or Layer 2 networks.
A Hashed Timelock Contract bridge operates through the following process:
Figure 4 - Hash-Time Lock Contract Bridge. Source: Author
Initially, two parties have to lock their assets in HTLC smart contracts, one on the source chain, and one on the destination chain.
Creation of the Hashlock. The secret, secretA, is first generated by user A. User A then creates a hash of this secret, resulting in a hash(secretA). This hashed value is known as the hashlock. The hashlock is used in setting up the HTLC; it locks the contract, ensuring that the tokens can only be unlocked by someone who knows the original secret.
The HTLC contains several key pieces of information, including the sender, recipient, amount of a token, expiration time, and the hashlock. The contract states that the tokens can be unlocked either by providing a preimage (the original secret) that, when hashed, matches the hashlock, or if the time expires, allowing the sender to reclaim the tokens.
Unlocking the Tokens. To unlock the tokens, the recipient must provide the preimage (the original secret secretA) to the contract. The contract then hashes this preimage and checks if it matches the hashlock. If it does, it confirms that the recipient has the correct secret, and the tokens are released to them. If the recipient cannot provide the correct preimage before the expiration, the sender can reclaim the tokens.
While locally verified bridges are trustless and easily adaptable to multiple chains, they are limited in their universality. They primarily support transfer of value use cases, such as Swap bridges, but not generic information and data transmission, such as for Arbitrary Message Bridges (AMB) bridges. HTLCs operate on a principle of locking funds until a certain condition is met, typically the revelation of a preimage of a hash within a certain timeframe. This mechanism is well-suited to financial transactions, where the primary concern is the secure and atomic transfer of assets between parties or across chains. However, for AMBs, the goal is to convey a wide range of data types and instructions across blockchains, which may not necessarily be financial in nature and do not fit within the lock-and-release pattern of HTLCs. AMBs require a protocol that can handle, verify, and correctly apply arbitrary data payloads to state changes, smart contract interactions, and other complex operations on the target chain, which goes beyond the capacity of HTLCs.
The Relay Model
The relay model abstracts data verification in cross-chain operations into a consensus challenge at the Relay layer, enhancing scalability. Instead of each blockchain having to directly verify the data from another chain (which can be resource-intensive and slow), a Relay layer is implemented, with the goal of establishing trust between blockchains that otherwise have no knowledge of each other's state or data. The relay layer takes on the responsibility of verification, and it ensures that the data being transferred is accurate and trustworthy before it is accepted by the destination blockchain. To maintain integrity and security, the relay layer often employs a consensus mechanism. This allows multiple independent validators or nodes to agree on the validity of the cross-chain transaction or message. If a discrepancy or invalid transaction is detected, the consensus challenge mechanism allows it to be flagged and rejected. This model involves:
- Relay Nodes: These nodes monitor and synchronise transaction data to the relay chain.
- Consensus Nodes: These nodes on the relay chain verify the validity of cross-chain transactions.
The relay model's performance and security depend on the consensus mechanism employed, with Byzantine fault-tolerant algorithms such as PBFT being common choices. Native Verified Bridges operate on the principle of deploying lightweight nodes of both source and target chains on each other’s networks. These nodes employ Simple Payment Verification (SPV) to validate transactions by comparing hash values. SPV, a method for verifying payments without a full node, involves deploying a lightweight node from the source chain (Blockchain A) on the target chain (Blockchain B) to verify messages. These lightweight nodes store only block headers, containing encrypted data digests, to efficiently validate transactions without downloading the entire blockchain history.
An example of a protocol utilising a Relay chain with its own consensus protocol is the Poly Network. Poly Network's bridge infrastructure includes three key components: the Relay Chain, Relayers, and Interoperation Smart Contracts. The Relay Chain, called Poly Chain, serves as the decentralised and trustless anchor for interoperation across participating blockchains. The relay chain acts as a coordinator within the multi-chain architecture, managing the registration, modification, and cancellation of participant chains. It synchronizes all participant chain block headers, allowing these chains to stay updated with the relay chain's header. The consensus algorithm of Poly Chain is BFT-like consensus, and consensus nodes of the Relay Chain have to run full nodes in every blockchain supported by the protocol, so as to perform full verification on every block.
Figure 5 - Poly Network Relay chain. Source: Poly Network Whitepaper
On the other hand, some bridge protocols perform native verification solely through light clients relayers, without their own consensus-based Relay chain. For instance, the Waterloo Bridge by Kyber Network and the Rainbow Bridge by Near Protocol are examples of this type of native verification model. Waterloo Bridge facilitates bidirectional transfers between Ethereum and EOS, utilizing SPV light nodes. In contrast, the Rainbow Bridge between Near and Ethereum ecosystems incorporates an additional layer of security through an optimistic verification solution alongside native verification.
Taking the Rainbow Bridge as an example, the bridge uses two light clients:
- An Ethereum light client implemented on NEAR,
- A NEAR light client implemented in Solidity as an Ethereum contract.
Figure 6 - Rainbow Bridge Relay Model Implementation. Source: Near.org
The bridge includes relay services like Eth2NearRelay and Near2EthRelay, which send headers to the respective light clients, facilitating the bridging process. EthOnNearClient is a NEAR contract implementing the Ethereum light client, storing a limited number of Ethereum block hashes. NearOnEthClient, an Ethereum contract, implements the NEAR light client, capable of verifying NEAR contract execution results and headers. Moreover, the bridge makes use of Provers, separate contracts (EthOnNearProver and NearOnEthProver) that are used to verify specific events or results on the respective blockchains.
Despite their generally high security, native verified bridges are costly due to the need for running lightweight clients and performing SPV verification, which results in significant gas consumption. The scalability challenge is also notable, as each new blockchain integration requires developing a pair of lightweight clients.
Optimistic Verification Bridges
Optimistic Verification Bridges are a novel architecture that seeks to balance the trade-offs inherent in other bridge types. The term "optimistic" comes from the assumption that most transactions and operations are honest by default. The bridge optimistically accepts the posted information as true without immediate verification, which greatly increases efficiency and reduces the time for cross-chain communication.
Optimistic Verification Bridges employ various off-chain agents, with the first one being Updater proxies, specialised nodes within the bridge's architecture. Their job is to monitor one blockchain (source), and when they detect a transaction or event that needs to be communicated to another blockchain (destination), they create and sign a cryptographic commitment. This commitment typically includes the merkle root of the data, which is a hash that represents the set of transactions or information to be bridged. Updater proxies must pledge or lock up assets as collateral as a form of security. This provides a financial incentive for the updaters to act honestly. If they were to sign a false Merkle root or commit fraudulent information, they would risk losing their pledged assets. Once the merkle root is signed, a Relayer system (which can be external to the bridge operator, e.g, Gelato Network, Biconomy) read this root and transmit it to the destination chain(s).
The Relayer posting the data to the destination chain starts a fraud proof window period. To safeguard against the optimistic assumption being wrong, the system allows for challengers. These entities, named Watchers, monitor the information being bridged and the commitments made by updater proxies. If challengers detect an incorrect or fraudulent merkle root, they can submit a challenge within this specified timeframe to prevent malicious activity from being finalised. If the challenge period passes without any proof of fraud being submitted, the data is considered valid and be consumed by the application layer. The processor is often an automated service or bot that watches for the finalisation of data on the destination chain, and takes the last step of submitting the merkle proof to the bridge smart contract on the destination chain.
A prime example of an Optimistic Verification bridge is the Nomad Bridge, which uses an optimistic-rollup mechanism for secure message and asset bridging. The Nomad protocol is built around two elements: on-chain smart contracts and off-chain agents. The on-chain smart contracts are responsible for deploying Nomad's messaging API directly on the blockchain, so that developers can send messages to - and access the replicated state of - the various supported blockchains. This is achieved through an outbox-like smart contract called Home on the source chain, and an inbox-like smart contract called Replica on the destination chain. On the other hand, the off-chain agents (Updaters, Relayers, Processors, and Watchers), play a crucial role in ensuring the security and transmission of states between different chains, establishing the core framework of the messaging layer. The Updater role is similar to a notary, having the task of signing the messages from the source chain and confirm their authenticity. In Nomad's architecture, any fraudulent activity by an Updater is traceable to the Home contract on the originating chain. Updaters are required to place a bonded stake on the sending chain as a security measure. If fraud is confirmed, the trail leads back to the Home chain, and the bond posted by the Updater is slashed as a penalty for their malicious behaviour. 
Figure 7 - Nomad Optimistic Bridge. Source: Author
Nomad optimistic verification does not use light clients to natively verify cross-chain messages. Messages sent from the originating blockchain are optimistically signed and then go through a period of scrutiny on the destination blockchain. During this enforced timeout, the messages are available for examination, and any discrepancies can be identified and challenged. A critical aspect of this protocol is the role of Watchers, which are entities tasked with monitoring the network's integrity by actively observing transactions and identifying fraudulent activities. The system's security is contingent upon the presence of at least one honest Watcher who is vigilant in detecting and reporting any fraudulent behaviour within the network. Despite its innovative approach to solving the cross-chain trilemma of extensibility, trustlessness, and generalisability, the Nomad Bridge has faced significant challenges, including a hacking incident due to contract configuration errors.
In conclusion, each type of cross-chain bridge presents a unique blend of advantages and limitations. Native verification offers high security at the expense of cost and scalability; external verification provides efficiency and scalability but with added trust assumptions; local verification excels in trustlessness and easy adaptation but is limited in applicability; and optimistic verification bridges strive for a balanced approach, often combining elements of other verification methods to optimise security and efficiency.
Bridging under MiCA – the regulatory implications for the different bridging models
Bridging protocols and solutions can generally be seen as an amalgamation of various services which may result in the provision of crypto-asset services as defined under MiCA, depending on the bridge model involved. However, it is worth first examining the prima facie considerations that arise in standard, sui generis cross-chain bridge implementations regardless of the specific models, which will then be covered in turn further on in this article.
Prima facie considerations for standard cross-chain bridges
Custody
On a standard bridge implementation, the custody of crypto-assets on the source blockchain, even if undertaken through a smart contract, may give rise to the possibility of the provision of custody as a service. This service is defined in MiCA as follows:
Safekeeping or controlling, on behalf of third parties, crypto-assets or the means of access to such crypto-assets, where applicable in the form of private cryptographic keys.
Given that the provision of a crypto-asset service may take place even through the use of smart contracts, it is easy to meet the threshold in this case, especially since the crypto-assets may, in most implementations, be held in custody in the locker smart contract until the crypto-assets on the destination chain are ‘burned’ and the process is, in essence reversed.
What would be more important to assess is whether the custody function is being undertaken in such a manner as to result in the provision of a crypto-asset service by a crypto-asset service provider (‘CASP’) as defined under MiCA, a topic which has been discussed at length in one of our previous articles.
Issuance of crypto-assets
On the opposite end of a bridging transaction, there typically tends to be the issuance of a crypto-asset on the destination chain if the minting function is called, which crypto-asset can loosely be seen as a representation of the crypto-asset that was, or is, present on the source chain. The nature of the issued crypto-asset is important; while broadly speaking, the issuance of a crypto-asset on its own right typically does not carry any notable regulatory obligations as long as there is not public offering or admission to trading is being sought, there are certain reporting obligations imposed on issuers depending on the crypto-asset type involved. This would, for example, be the case for issuers of asset-referenced tokens (ARTs) and e-money tokens (EMTs).
One notable exception to the above arises whenever there is the issuance of an EMT that references an official currency of a Member State, which shall upon issuance be deemed to be offered to the public in the Union as per Article 48(2) of MiCA. It will certainly be interesting to see how this particular article will play out in practice within the broader DeFi realm, and how enforceability will be exercised, if possible.
The modality of issuance is also important. If the issuance is done by a non-identifiable person, then Titles II, III or IV of MiCA will not apply. What constitutes an issuance by a non-identifiable issuer is not defined under MiCA and therefore subject to interpretation, but an automated issuance through a smart contract without any meaningful interference or control by an identifiable person is likely to constitute an issuance by a non-identifiable person.
Transfer of crypto-assets
The third crypto-asset service that may potentially be in play is the provision of transfer services in relation to crypto-assets, which is defined as follows:
Providing services of transfer, on behalf of a natural or legal person, of crypto-assets from one distributed ledger address or account to another
This is likely to be one of the most material considerations for cross-chain bridges that facilitate transfers between blockchains that utilise inherently different infrastructures, such as Ethereum and Solana. It would be easier to argue, for instance, that cross-chain bridging between EVM-compatible chains does not constitute a transfer of crypto-assets, as long as the source and final destination addresses are one and the same and there isn’t the faculty for the user to specify a different destination address – although, strictly & technically speaking, the crypto-asset is being transferred from one DLT address to another throughout the whole bridging process, so it would always be best to analyse this service in light of the particulars of the case at hand.
Reception and transmission of orders
This service is likely to be relevant in those cases where the crypto-asset on the destination chain is different than the one on the source chain, and at the end of the transaction flow, there is a swap/exchange taking place to the extent that it can constitute a sale or purchase order for crypto-assets. Another requirement would be the presence of a third party on the receiving end of the transmission of such an order, since this service is defined as follows:
The reception from a person of an order to purchase or sell one or more crypto-assets or to subscribe for one or more crypto-assets and the transmission of that order to a third party for execution
If the order is executed by the same person receiving such an order, a different service may come into play.
Execution of orders on behalf of clients
Otherwise colloquially known as ‘brokerage’, this is crypto-asset service may subsist if the purchase or sale order is executed by the CASP on behalf of the client. It may be applicable to cross-chain bridge providers that exercise significant manual intervention in an end-to-end manner, and can be thought of as an amalgamation of ‘reception of orders’ and ‘exchanges of crypto-assets for other crypto-assets’.
Exchange of crypto-assets for other crypto-assets
Once again, this service may apply if one is talking about a different crypto-asset that results after a bridging transaction is executed. What is important here, once again, is that there is the actual conclusion of purchase or sale contracts, as per the definition:
The conclusion of purchase or sale contracts concerning crypto-assets with clients for other crypto-assets by using proprietary capital
Another important element of this service is that the conclusion of the purchase or sale contract must have resulted by the use of proprietary capital of the CASP.
Assessing the various cross-chain bridging models
Before delving into the specific bridging models in turn, apart from the BCAS article linked further above, it is also worth reading another previous article of ours where we examined the extension of Permissionless DLT Networks, as defined under ESMA’s Second Consultation Package on MiCA, to DeFi protocols. In that article, it was theoretically established that as long as no person is controlling a DeFi protocol/platform and its use, and no person is playing a fundamental and essential role for the functioning of a DeFi protocol/platform without which such DeFi protocol/platform cannot be used, then that same DeFi protocol/platform can be deemed to be exempted from MiCA’s scope.
In other words, and from an opposite angle, in order for a DeFi protocol or platform to fall within scope of MiCA, there must exist a service provider – client relationship, as propounded in our previous article. Without a service provider – client relationship, users accessing a DeFi technology are not doing so as clients of CASPs providing crypto-asset services; it can well be argued that users are accessing a “common good resource”, as referenced under point 63 of ESMA’s Second Consultation Package. Any elements that could lead to the establishment of a service provider – client relationship, such as the charging of fees (excluding transaction fees payable to validators/miners), could lend to the establishment of a CASP for all intents and purposes. It is worth noting, at this stage, that most cross-chain bridges do charge fees, increasing the likelihood of the establishment of a CASP-client relationship.
The four specific bridging models to be examined all have varying levels of decentralisation and/or manual intervention, which will result in different implications for each and every model. Three general assumptions shall be made:
- Any smart contract components to be covered are not renounced, i.e. the deployer still has ownership or control over the contract;
- One person (natural/legal) or one common group has created and maintains the bridging protocol or architecture in question; and
- Fees are being charged to users who make use of the bridging protocol.
The Notary/Externally Verified Model under MiCA
The Notary Model is arguably the least decentralised model out of the four, naturally subject to its factual implementation. At the heart of it, there is a trusted third party which manages cross-chain operations. While notaries can either be single-signature or multi-signature, the two variants are not material to the consideration of whether a CASP exists or not, and therefore the following analysis takes into consideration both variants which ultimately perform the function of an external validator set.
The initial transaction is initiated by the user, who deposits the crypto-asset in question to the locker smart contract. The person controlling the locker smart contract may be seen as performing custody as a service, even if the custody is being performed for a brief period, since there is the subsistence of safekeeping or control on behalf of third parties of crypto-assets. In any case, the safekeeping or control subsists throughout until the crypto-asset issued on the destination chain is ‘burned’ and the crypto-assets in the locker smart contract are unlocked.
Upon the notary vote being passed, another transaction is executed, being the issuance of crypto-assets on the destination blockchain. The person controlling the issuer smart contract may be seen as performing the issuance of a crypto-asset, with issuances typically not carrying much weight in terms of regulatory applications as long as no offer to the public is being performed, but subject to the exceptions propounded previously.
The crypto-asset issued on the destination blockchain is then transferred to a wallet address indicated by the user, at which point transfer of a crypto-asset as a service may subsist, especially if the DLT address of the user on the destination blockchain is different to the DLT address on the source blockchain. However, even if the DLT addresses are the same, the fact that there is a transfer initiated from the issuer smart contract to a DLT address owned or controlled by the user may be enough for transfer as a service to subsist owing to the way in which the transfer of crypto-assets service is defined under MiCA, although as mentioned above may prove to be easier to build an argument as to why this would not be the case, if the initial and end DLT addresses are the same.
The Hash-Time Lock/Locally Verified Model under MiCA
This model has less ‘moving parts’ than the Notary Model, which is likely to result in a higher level of decentralisation generally speaking since the only interventions, if one can use that term, are by the user itself. The main components are locker and issuer smart contracts, a peer-to-peer liquidity network, and atomic swaps being effected through the exchange and verification of the ‘secret’.
Once again, there may be the possibility of custody as a service coming into play, depending on the level of ownership or control over the smart contracts on the respective chains. However, this is arguably the only potential service that subsists here, since there is no issuance of a crypto-asset taking place; the crypto-asset on the destination chain emanates from the peer-to-peer liquidity pool in most such implementations unless the minting function is integrated as it is technically possible. Given that the crypto-assets are being transferred through an exchange of a hashed secret, it is also difficult to argue that a transfer of a crypto-asset as a service is present.
The fact that this model limits the transfer capabilities to ‘value’ only to the exclusion of generic information and data transmission makes this model a strong contender for a MiCA-excluded bridge, a prime example of simplicity greatly reducing the possibility of regulatory implications.
The Relay/Natively Verified Model under MiCA
This third model represents a technically more complex solution than the previous two, but not necessarily resulting in any novel or different regulatory implications.
Instead of reliance on ‘notaries’ or a ‘secret’, there is reliance on a network of nodes and relayers to bridge a crypto-asset from one blockchain network to another. The words “validators, nodes or miners” are only used once in MiCA’s text, precisely under Recital 93, which states:
A provider of transfer services for crypto-assets should be an entity that provides for the transfer, on behalf of a client, of crypto-assets from one distributed ledger address or account to another. Such transfer service should not include the validators, nodes or miners that might be part of confirming a transaction and updating the state of the underlying distributed ledger. Many crypto-asset service providers also offer some kind of transfer service for crypto-assets as part of, for example, the service of providing custody and administration of crypto-assets on behalf of clients, exchange of crypto-assets for funds or other crypto-assets, or execution of orders for crypto- assets on behalf of clients. Depending on the precise features of the services associated to the transfer of e-money tokens, such services could fall under the definition of payment services in Directive (EU) 2015/2366. In such cases, those transfers should be provided by an entity authorised to provide such payment services in accordance with that Directive. [emphasis added by author]
It is important to note that the Recital focuses on one specific crypto-asset service, namely that of the provision of transfer services, and exempts validators, nodes or miners from qualifying as CASPs offering such a service. However, they are only exempted to the extent that they “might be part of confirming a transaction and updating the state of the underlying distributed ledger”, meaning that the exemption only applies insofar as they are limitedly undertaking such functions.
If the relay function is being undertaken separately than the validation function in that it is ‘performed’ through a component separately run by a third party (as is likely to be in most cases due to the different software required), it is still likely not to result in the provision of a crypto-asset transfer as a service, since the relayer is not transferring a crypto-asset but rather simply syncing block headers across the relevant networks on the relay layer/network itself – in other words, relaying headers.
However, there are certain implementations, such as LayerZero, where Relayers can also send native gas (crypto-asset) on the destination chain along a message, so as to facilitate transactions on the destination chain. In such cases, one could argue that the native gas does not constitute part of the original transaction initiated by the user, and that the crypto-assets constituting the native gas are separate from the crypto-assets making up the user’s original transaction. This would mean that the transfer of native gas does not constitute a crypto-asset service.
Even so, the argument above might not hold water if the bridge implementation in question allows the user to request and specify a custom amount of gas to receive on the destination chain, and pays for that amount itself. Depending on how this is technically handled at the back-end, it may constitute an exchange of crypto-assets.
Generally and on the basis of the general assumption that the architecture overall is being maintained by one person or one group of persons, there could still be the subsistence of the custody service as well as the transfer service, due to the manner in which such crypto-asset services have been broadly defined. The crypto-asset issuance factor also remains relevant.
The Optimistic Verification Model under MiCA
The main differences of this model compared to the Relay Model is the use of more off-chain agents, namely the Updaters, Processors and Watchers, as well as the removal of the intermediate relay network. However, the presence of these off-chain agents does not have much in terms of material implications from a MiCA perspective, and the Relayer role has been covered in the previous section. In fact, the presence of such off-chain agents may arguably make this model more decentralised due to the fragmentation of the function provision, and it may well be said that if the off-chain agents are run by different persons, then it would be difficult to argue that any one of them classifies as a CASP.
The crypto-assets that are pledged/locked by the Updater proxies are different than the crypto-assets constituting the transaction initiated by users, and therefore the custody element is immaterial specifically and solely in relation to the crypto-assets pledged by the Updater proxies.
Ultimately, the same conclusion can be drawn as in the previous sections. The only two potentially relevant services are the custody and transfer ones, and once again, there may be implications regarding the issuance of a crypto-asset – but these considerations are mostly relevant if two or more of the agent roles are undertaken by one and the same person.
Newer bridges that allow for swapping
Recently, there has been the emergence of cross-chain bridges that allow users to deposit one crypto-asset on the source chain, and receive a different crypto-asset altogether on the destination chain. An example of such an implementation is Rhino.fi.
These implementations which allow for ‘native swapping’ run a higher risk of being seen as offering the exchange of crypto-assets as a service, and if the swap does not happen natively, there may still be the subsistence of ‘reception and transmission of orders’ or ‘execution of orders’ as crypto-asset services. A lot would depend on the source and management of the liquidity being used for the swap to be effected; if, for instance, the liquidity is within the control of a person or a group of persons who also exercise control over the bridging architecture, it may well constitute the exchange of crypto-assets as a service – as long as there is some form of a sale or purchase being concluded.
Conclusion
It is worth noting that, with the exclusion of the Hash Time Lock Model, the three common considerations for cross-chain bridges are the following:
- Is there the subsistence of custody as a service?
- Is there the subsistence of transfer as a service?
- Is there a crypto-asset issuance taking place, and if so, what is the crypto-asset type being issued?
The Hash Time Lock Model seems to be the model that is least susceptible to falling within MiCA’s purview, and depending on the operation of the off-chain agents in the Optimistic Verification model, this is also likely to be a good candidate for exclusion from MiCA. While in the respective analyses it was noted that the Notary Model might be the least decentralised model of the four, ultimately it all boils down to the implementation and maintenance of the architecture in question on a case-by-case basis.
At this current juncture, it may be difficult to find a bridging architecture that meets the definition of a ‘Permissionless DLT Network’ as proposed by ESMA in their MiCA Second Consultation Package, and by extension it would be difficult to term any bridging solution as ‘fully decentralised’. Given the complexity of cross-chain bridge architectures and an appreciable degree of centralisation involved, it is well recommended that operators of such bridges conduct a thorough analysis to determine the extent to which, if any, certain parts of the architecture may fall within the scope of MiCA.
[1] https://l2beat.com/bridges/summary
[2] the possibility for the asset holder to spend the same token twice. In a token bridging context, a double spend means using the same token on its original blockchain and the blockchain it was transferred to.
