SoK: Security and Privacy of Blockchain Interoperability

Recent years have witnessed significant advancements in cross-chain technology. However, the field faces two pressing challenges. On the one hand, hacks on cross-chain bridges have led to monetary losses of around 3.1 billion USD, highlighting flaws in security models governing interoperability mechanisms and the ineffectiveness of incident response frameworks. On the other hand, users and bridge operators experience restricted privacy, which broadens the potential attack surface.In this paper, we present the most comprehensive study to date on the security and privacy of blockchain interoperability. We employ a systematic literature review, yielding a corpus of 212 relevant documents, including 58 academic papers and 154 gray literature documents, out of a pool of 531 results. We systematically categorize 57 interoperability solutions based on a novel security and privacy taxonomy. Our dataset, comprising academic research, disclosures from bug bounty programs, and audit reports, exposes 45 cross-chain vulnerabilities, 4 privacy leaks, and 92 mitigation strategies. Leveraging this data, we analyze 18 notable bridge hacks accounting for over 2.9 billion USD in losses, mapping them to the identified vulnerabilities.Our findings reveal that a substantial portion (65.8%) of stolen funds originates from projects secured by intermediary permissioned networks with unsecured cryptographic key operations. Privacy-wise, we demonstrate that achieving unlinkability in cross-chain transactions is contingent on the underlying ledgers providing some form of confidentiality. Our study offers 17 critical insights into the security and privacy of cross-chain systems. We pinpoint promising future research directions, underscoring the urgency of enhancing security and privacy efforts in cross-chain technology. The identified improvements have the potential to mitigate the financial risks associated with bridge hacks, fostering user trust in the blockchain ecosystem and, consequently, wider adoption.


I. INTRODUCTION
Blockchain interoperability is a key component for realizing the full potential of blockchain technology.As the landscape evolves, interoperability is gaining momentum in use cases including bridging liquidity fragmentation, optimizing decentralized exchanges (DEX) trades, enhancing scalability through mechanisms like sharding [1], extending through sidechains [2], and enabling asset exchanges and transfers across platforms [3].Taking a step back to 1996, Wegner postulated [4]: "interoperability is the ability of two or more software components to cooperate despite differences in language, interface, and execution platforms".However, achieving interoperability across blockchains -distributed systems where mutual trust is often absent -adds a dimension of complexity.Here, the challenge is not merely syncing  software components but rather integrating  distributed systems, each with its unique challenges encompassing safety, liveness, accountability, and centralization [5], [6].Such orchestration is realized using interoperability mechanisms (IMs).The differing transactional models, consensus mechanisms, and cryptographic primitives across networks only escalate this challenge.Despite these hurdles, the domain has seen prolific contributions from scholars, providing solutions, novel architectures, and varied use cases [7]- [15].A recurring theme from these studies underscores the pressing need for rigorous research on security and privacy in IMs.Hacks Analysis Recommendations Fig. 2. Section II presents the background knowledge necessary for understanding this paper.Section III shows the methodology followed to systematically analyse existing work.We present our security and privacy models in Sections IV and V, respectively.These include relevant properties, security-and privacy-enabler solutions, and the analysis of vulnerabilities, attacks, and leaks on cross-chain systems.The classification of the selected corpus of studies is presented in Section VI along with a discussion of the results.

A. Motivation
The importance of studying security in interoperability cannot be understated.Since May 2021, the mounting losses due to bridge hacks have exceeded USD 3B, as illustrated in Figure 1.According to Immunefi [16], white-hat hackers have been compensated over USD 20M through bug bounty programs, preventing potential losses of a staggering USD 1B.Moreover, cross-chain bridge hacks have catapulted to the top of the DeFi incidents leaderboard [17]- [19], emerging as the preferred target of cybercriminals.The present scenario, as of mid-2023, paints a grim picture with rampanthacks [20]- [23].Consequently, the total value locked (TVL) in crosschain bridges has nose-dived from its zenith at USD 58B in early 2022, to a mere USD 4.5B by October 2023, a downfall also attributed to diminishing asset prices in the bearish market [24], [25].We hypothesize that the intertwined crosschain systems, in conjunction with the already well-studied vulnerability-prone smart contracts, be it at the bytecode or higher-level language dimensions [26], have amplified the risk exposure of these protocols.The fact that those protocols are attractive honeypots makes them keenly pursued targets, across the three interoperability modes we examine: asset exchanges, asset transfers, and data transfers [7], [27].If this issue isn't comprehensively tackled, the trajectory suggests a future with no bridge left uncompromised.Furthermore, malevolent entities use cross-chain on and off ramps to launder stolen assets-sometimes from other bridges [28], attempting to circumvent deny lists and complicating forensic investigations, given several forensic tools available widespread [29], [30].
Even though most of the funds stolen in interoperability solutions come from cross-chain bridges, other interoperability schemes also originate numerous vulnerabilities [31]- [33].In this paper, we capture the security and privacy approaches of all solutions and establish a comprehensive understanding of cross-chain security and privacy-a subject currently scattered throughout various sources in the literature.Strikingly, similar vulnerabilities can often denote distinct notions of security and privacy.As such, our approach leans heavily on a methodological survey, where we gather, evaluate, and study academic papers and grey literature, spanning blog posts, whitepapers, and audit reports.To our understanding, our effort represents the most extensive survey of blockchain interoperability to date.We distil insights from the academic discourse, extant crosschain attacks-from a theoretical and practical perspective, and their subsequent implications.Additionally, we propose a set of mitigation strategies and best practices tailored to the corpus of vulnerabilities we have studied.

B. Research Questions
This paper answers several research questions:

RQ1 -How do security-and privacy-centric designs differ in blockchain interoperability solutions, and what impact do these variances have on the overall security and privacy of protocols?.
Securely interoperating different blockchains is a challenging task.It involves establishing a new security boundary that depends on the security of at least two existing networks and involves multiple design trade-offs [11], [27], [33], [34].Similarly, considering a set of blockchains with different privacy guarantees, it is unclear what privacy is in the context of multiple systems.Also supported by a recent work [35], we reckon that there is too much privacy for criminals and too little privacy for general users -i.e., a non-accountable ecosystem cannot penalize malicious actors and thus renders the system unfair.
Security-wise, we propose a set of properties from the distributed system literature to classify interoperability solutions based on the specific security approaches employed and how they guarantee safety and liveness in each protocol.The most straightforward safety violation is the absence of atomicity in cross-chain transactions, which can lead to "double-spending".Some cross-chain deal [36] and atomic swap protocols [37]- [41], instead of relying on the all-or-nothing property, state that everything is fine if honest nodes do not end up worse off than how they started the protocol.
In terms of privacy, for example, Hash-Time Lock Contracts (HTLCs) [38] suffer from transaction linkability problems.Transactions in different chains can disclose cross-chain interactions between parties through a value published on both chains [42].In asset transfer bridges, the amount locked in one chain can be linked to the amount minted on the destination chain, leading to the same problem.Additionally, the lack of privacy for bridge operators increases the attack surface to those entities [43].
In this paper, we aim to explore the relevant properties and approaches to guarantee the different levels of security and privacy in blockchain interoperability.

RQ2 -What are the known cross-chain vulnerabilities, attack vectors, privacy breaches, and corresponding mitigations, and how can they be mapped to past incidents?.
Our second research inquiry compels us to investigate crosschain attacks, focusing on the vulnerabilities that give rise to them.We categorize these identified vulnerabilities into four distinct security layers explained in Section IV-B.In addition to the theoretical research, we examine real-world cross-chain hacks, which collectively account for over 3 billion USD, and compare them with academic studies.We pinpoint the disparities between existing research findings and their practical application and map each vulnerability to possible mitigations.

RQ3 -Based on the existing gaps, what are potential best practices and avenues for future research to enhance the security and privacy of cross-chain protocols?.
When it comes to practical considerations, when combining an extreme privacy-or security-focused blockchain with a lesser one, the resultant degree of security or privacy is likely to be minimal.Additionally, in a world where achieving a balance between transparency and privacy is imperative, and total privacy may hinder the ability to trace transactions, potentially affecting investigations into security breaches, the ideal level of privacy for cross-chain scenarios remains unclear.In a time when the industry is actively seeking stability, we observe that the design of cross-chain solutions remains largely ad hoc, with each solution custom-crafted for specific blockchains or applications.Through a comprehensive analysis of existing studies, we put forth a collection of best practices and future research avenues.In this paper, we will delve into these intricate questions and furnish initial insights that protocol designers, developers, and analysts can use as a foundation for further research and development.

C. Contributions
This paper provides the following contributions: • Systematization of knowledge.Systematizes properties and approaches of secure and privacy-enhancing crosschain protocols by curating relevant academic literature and real-world data, including cross-chain hacks and other audit reports, and provides an in-depth analysis.• Academia-industry synergy.Bridge the divides between academic research and industry application, correlating theoretical vulnerabilities with past real-world incidents.• Strategic insights.Identifies lessons learned, highlights emerging research directions, and proposes a set of mitigations and best practices, enabling practitioners to build secure and private cross-chain bridges.
This manuscript systematically consolidates and builds upon existing literature, illuminating novel insights and advancements within the research domain.The organizational framework of this document is depicted in Figure 2. Section II provides a primer on blockchain interoperability.Section III introduces a rigorous methodology, systematically adopted to constructively assess and incorporate prior research.Section IV and Section V detail our advanced security and privacy

Source Chain
Target Chain Fig. 3. Blockchain interoperability studies the flow of data and assets between two networks powered by an Interoperability Mechanism (IM).The actor(s) that take the role of IM depend on the Security Approach of the solution (cf.Section IV).Legend: 1   ○ Fetch data and 2  ○ Issue Transactions.models, respectively.These sections not only spotlight pivotal properties but also innovative mechanisms for enhancing security and privacy, along with proactive strategies to optimize potential challenges in cross-chain systems.Section VI offers a structured categorization and an insightful analysis of the curated body of interoperability research.Section VII briefly discusses the contribution to related literature.Concluding this discourse, Section VIII presents our forward-looking remarks and insights.

Data and Code Availability:
The data and code for ensuring replicability are available on GitHub, accessible at the following URL: https://github.com/RafaelAPB/SoKSPBlockchainInterop.

II. A PRIMER ON BLOCKCHAIN INTEROPERABILITY
This section presents a succinct introduction to blockchain interoperability, which is necessary for understanding the rest of this paper.Blockchain interoperability allows data and value to be sent across a set of different domains.Besides distributed ledgers, these domains can have the form of centralized databases, mainstream systems, or any other distributed system.This paper focuses mainly on cross-chain systems where domains are distributed ledgers { 1 ,  2 , ...,   } ∈ .

A. The Source of Truth -Underlying Blockchains
In this paper, while the primary emphasis is not on the security of the underlying networks of cross-chain protocols, it is imperative to recognize their pivotal role as critical dependencies for these protocols.Consequently, we provide a succinct and scientific overview elucidating the relevance of the network and consensus layers in the context of interoperability studies.
The finality of the source chain in an interoperability solution is critical: chains with Nakamoto-based consensus (i.e., a probabilistic finality algorithm called proof of work -PoW) are subject to forks.Proof of Stake-based (PoS) chains are sensitive to long-range attacks [44].As a common vulnerability, forks can be created in these protocols, as more valid blocks are mined in parallel suffixing a determined block in the chain.If these block headers are relayed to the target chain before being considered final, actions based on them should not be successful in guaranteeing the absence of safety violations -e.g., double spending or other violations of crosschain logic [32].This main chain identification increases the complexity of the bridge contract in the destination chain.On the other hand, chains with instant or near-instant finality such as PBFT-based [45], do not suffer from the same problem.Blocks are only added to the blockchain when they are already considered final.However, the verification cost and complexity differ as one needs to know the validation committee at each point to validate the corresponding attestations -this does not work for dynamic committees that most blockchains use.
A possible attack is a cross-chain 51% attack, where the attacker creates valid block headers faster than the rest of the network, and exploits the difference in state between before and after the attack.For example, the attacker sends funds to a bridge (spends the funds on the source blockchain), and sends a Merkle proof and block header to the relay contract.After that, he conducts a 51% attack and gets the funds back on the source chain.However, the bridge does not revert, yielding a cross-chain double spend.To the best of our knowledge, this specific attack has not been verified in practice.

B. Interoperability Modes
The literature [1], [46]- [49] agrees on the three existing interoperability modes: asset exchanges (AE), data transfers (DT), and asset transfers (AT).Different interoperation modes require different protocol architectures, and consequently different security and privacy guarantees.
Consider accounts  1 and  2 in domains  1 and  2 (typically domains are ledgers, but note that for arbitrary crosschain interoperability, domains may be centralized systems).Asset exchange protocols allow untrusted parties to atomically exchange assets.For example, asset  owned by  1 on ledger  1 , can be exchanged for asset  owned by  2 on ledger  2 .This is achieved by issuing local transactions in both blockchains with the assistance of hash-locks (the proof ) [10].An asset exchange can be mediated by a trusted party, or run directly between both parties through an off-chain communication channel.
Asset transfer protocols encompass locking or burning an asset in the source chain and creating (minting) a representation of that asset in the target chain -we call it the lock-mint or burn-mint pattern, respectively.In practice, the process of locking is transferring the asset to an escrow controlled by a smart contract, a centralized entity, or a set of parties through a multi-signature.Once the asset is locked in the source chain, the verification occurs in the target chain.The verification can be done by replicating the source chain's consensus mechanism in the target chain [50], [51] or using a proof-based mechanism such as zero-knowledge proofs [44], [52], [53].An alternative mechanism is leveraging liquidity pools on both chains [7], [54], where no asset is minted, but rather several native assets are unlocked and sent to the user.However, these escrows create honeypots that incentivize attackers to break through them.
Data Transfers generalize interoperability.Information written in one domain can be transferred or copied to another (typically accompanied by a proof, for example, the payload of a blockchain view [55]).Usually, distributed ledger technology (DLT) Gateways are used to facilitate this process, running a gateway-to-gateway protocol [56].Different interoperability modes are different classes of cross-chain rules.

C. Cross-Chain Events, Transactions and Rules
We present the concepts of cross-chain events, transactions, and models based on previous work [7], [32].Transactions issued in one domain trigger internal state changes and emit events (i.e., trigger transactions) based on the operations performed.We enrich these local transactions with additional metadata, and we call those cross-chain events.Metadata can be a cross-chain transaction identifier, a time using a global clock, the price of a token in USD, or other offchain information.A cross-chain event () is composed of native and non-native domain attributes.The former are attributes retrieved from the underlying domains -e.g., parameters of local transactions -whereas the former are additional parameters proper to enable interoperability, such as a ledger identifier, off-chain context, or a cross-chain transaction identifier.Therefore, we can define a cross-chain transaction () as a composition of , representing state changes across multiple domains.

Definition 1 (Valid Cross-Chain Transaction). A cross-chain transaction 𝑐𝑐𝑡𝑥 is valid if and only if every cross-chain event
∈  is valid.Cross-chain events are valid if every local transaction  ∈  is valid and finalized, and its metadata is true * .Moreover, to evaluate the validity of  these must be orchestrated by cross-chain rules that define what transactions are valid according to the difference between the expected and the actual behavior.For example, a cross-chain rule for an asset transfer protocol might define that there must not be an event minting an asset on  2 before an event locking the corresponding asset in  1 .Given any business logic, one can create arbitrarily complex cross-chain rules.We refer the reader for a formal treatment [32] with a specific example of cross-chain rules on [57], and to the Appendix A.

III. RESEARCH METHODOLOGY
This section presents the methodology followed to answer the research questions enumerated in Section I. Firstly, we perform a literature review that focuses on the search for papers about security and/or privacy, including attacks, incidents, or vulnerabilities in blockchain interoperability solutions.Finally, we actively search for resources in grey literature to retrieve data about recent cross-chain hacks, and incident or audit reports.The methodology is depicted in Figure 8, in Appendix B.

A. Data Sources
We used Google Scholar as our primary source of data given that it indexes most major digital libraries and proceedings (e.g., ACM Digital Library, IEEE Xplore, Springer Nature Lecture Notes in Computer Science), grey literature libraries (e.g., arXiv, Cryptology ePrint Archive), and other resources (e.g., books, thesis, or other online repositories).

B. Search Procedure
We conducted a systematic literature review by crawling papers using Google Scholar's keyword search.The search was limited to papers since 2015 due to the limited amount of research available before that period [10].The following search query was used to search for papers within our research scope: ("blockchain interoperability" OR "cross-chain") AND ("attack" OR "incident" OR "hack" OR "leaks") AND ( ("security" AND ("vulnerability" OR "mitigation")) OR "privacy") This search yielded 2010 results.We stopped searching on the 300th reference, finding no relevant papers beyond the 250th.In this first analysis, we filtered the results according to being written in English and to their title and abstract.Our final selection criteria included papers addressing blockchain interoperability security, privacy, attacks, vulnerabilities, leaks, or corresponding mitigations.We ended up with 58 studies.In addition to the retrieved results, we utilized the snowballing and forward reference techniques.We also set up Google alerts to stay informed about new papers related to "blockchain interoperability" and "cross-chain".These were retrieved manually according to the same criteria.Through this approach, we identified an additional 49 studies, which we believe cover the majority of relevant research for our study.Due to the unstructured practices in the area, we included multiple gray literature resources focusing on past cross-chain hacks, audit reports, vulnerabilities, and disclosures through bug bounty programs.Therefore, we analyzed an additional 154 relevant documents.

C. Practical screening criteria
In our practical screening criteria, we place paramount importance on cross-chain privacy and security, delving into the nuances of cross-chain hacks and vulnerabilities.Additionally, we give comprehensive attention to L2 solutions, particularly rollups, based on native cross-chain bridges.Conversely, our screening criteria exclude applications based on cross-chain solutions, security and privacy of individual blockchains, L2 solutions such as payment channels that lack cross-chain relevance, and security issues exclusive to smart contracts without broader cross-chain implications.

D. Limitations
Naturally, our methodology comes with certain limitations.In our quest for grey literature resources primarily centered on cross-chain hacks, to mitigate the potential for unsoundness or bias, we meticulously compile data from a variety of sources.In these cases, each resource undergoes thorough examination and assessment by at least two of the paper's authors to guarantee the integrity of the information.Additionally, we acknowledge that our analysis of industry solutions and associated vulnerabilities may not encompass the entirety of the landscape, primarily due to limitations in the available  documentation.Nevertheless, we make diligent efforts to compile all accessible information concerning projects that collectively represent over 75% of the Total Value Locked (TVL) in cross-chain solutions [25].Nevertheless, despite these limitations, this paper is the most extensive and comprehensive research paper conducted so far on the security and privacy of blockchain interoperability.

IV. SECURITY MODEL FOR CROSS-CHAIN SYSTEMS
In this section, we present the properties that define a secure interoperability system while considering the requirements of the various stakeholders.Additionally, we showcase and discuss the literature according to the existing security approaches.Finally, we present the most extensive list, so far presented, of theoretical cross-chain vulnerabilities, attacks, and mitigations and map them to real-world hacks that account for more than 3 billion USD.We gather all relevant insights and propose guidelines for building secure and robust crosschain systems.

A. Motivation
A common assumption for interoperability systems is that the underlying chains are trusted.The reasons are clear: if there is a transaction issued on the target chain based on a rewritten transaction on the source chain -e.g., an asset locked in  1 and a representation minted in  2 , the asset in  2 may become unbacked -and therefore worthless.Figure 4 illustrates this scenario. 1○ A dishonest miner, which also operates a relayer, is a selfish miner [58]; 2 ○ the selfish miner forges a valid syntactic block with transactions that did not occur (e.g., locking random assets); 3 ○ the selfish miner sends those block headers via the relayer to the source chain light client in the target chain.Consensus-wise, block i+1b is valid despite not being included in the canonical chain, signifying the creation of a fork.The target chain should have a fork resolution mechanism to decide which block to accept [44], [50], and therefore, which transaction inclusion requests to accept.
This theoretical attack is one of the arguments for a multichain ecosystem (i.e., blockchain engines [10]) instead of cross-chain bridges.In those systems, the execution and settlement layers are one, which results in the cross-chain state (e.g., source chain's block header) being validated by a shared stratum between instances of a blockchain engine.However, bridges between blockchain engines and between blockchain engines and external blockchains still have to be developed (e.g., Toposware [59] and Cosmos [60], or Polkadot [61] and Ethereum [62]).Multichain ecosystems will probably need cross-chain interoperability, and the security of such interactions does not seem fundamentally different from crosschain interoperability between L1s [7].

B. Security Layers
The security of a cross-chain system can be decomposed into the security of several layers, as depicted in Figure 5. Existing literature supports similar breakdowns [63].The Network Layer forms the bedrock.It concerns about the systems or networks that underlie a cross-chain solution.These can be distributed ledgers or even centralized databases.For instance, the chosen consensus mechanism and smart contract engines drive the security of this layer.Above that, the Protocol Layer addresses the different architectural decisions to build a cross-chain protocol.It includes defining the actors, their roles and responsibilities, and how the relevant security and performance properties are guaranteed.Further up the stack, we encounter the Implementation Layer.It encompasses the entire implementation lifecycle, including off-chain (e.g., relayers, oracles, incident response systems) and on-chain code (e.g., smart contracts, protocols) to serve as mechanisms to facilitate interoperability and on-chain contracts that execute the respective business logic.Finally, at the top, once cross-chain solutions are designed and implemented, one must ensure that it is operational and upgradeable.As in every software, offchain and on-chain programs may have vulnerabilities that compromise their functionality.At the Operational Layer, specifies the procedures for deploying, maintaining, and upgrading on-chain and off-chain components.It concerns with who manages the protocol, how to monitor the infrastructure, how to update the code, and how the system reacts to external or internal unexpected events.This paper explores vulnerabilities, attacks, and mitigations at the last three layers -i.e., as said in Section X, we assume the underlying networks are safe and live and are concerned about security at the protocol, implementation, and operational levels.

C. Security Properties
Based on our comprehensive literature review, we strive to propose a set of fundamental properties that characterize a secure cross-chain system, based on well-known work in the dependable computing area [64], based on fundamental crosschain concepts [32].The core idea behind security properties is that they depend on the underlying cross-chain logic (a set of cross-chain rules).We define three security properties for IMs.The integrity of a cross-chain system is evaluated as a function of how reliable the integrity of the data or assets is managed:  Integrity depends on the use case and therefore the interoperability mode.A rule of thumb for integrity in asset transfers and asset exchanges is that double spend should not occur.Conversely, for data transfers, integrity is normally assured by enforcing every transferred data point  to have equivalent representations using a standardized blockchain view [55].IMs must be held accountable for their actions, namely if they provide integrity.This property encompasses two facets: identification and punishment of actors, for example through slashing mechanisms [44].Furthermore, a cross-chain protocol should ensure non-repudiation of actions regarding its participants.

Definition 3 (Accountability).
An IM is accountable if several conditions hold: 1) the metadata of any  ∈  is public or at least retrievable; 2) for every integrity violation in  , there is a mechanism to prove that violation; and 3) there is a thirdparty that can enforce punishments for proved violations (e.g., third-party, blockchain smart contract).
Finally, we require the availability property for IMs to be considered secure and guarantee the availability of resources and services for users and operators.Protocols must be resilient to failures and handle unexpected behavior quickly.

Definition 4 (Availability). An IM provides availability if it is ready to process (validate, issue, or relay) valid 𝑐𝑐𝑡𝑥𝑠.
The availability of IMs therefore depends again on the specification of cross-chain rules and, furthermore, the liveness of the underlying infrastructure.

D. Security Approaches
We discuss the proposed cross-chain security taxonomy based on the approaches to guarantee the properties above.
a) Centralization: Centralized trusted parties can hold users' funds and issue transactions in  [107], or function solely as relay services [48], [56] that do not hold funds but are legally accountable for the information relayed.In rollups, centralized operators are responsible for ordering and batching transactions in the L2 and submitting them to the L1.To avoid liveness compromises, they usually allow  [38], [40], [42], [95]- [106] 15 (29%) Note: The table categorizes various security approaches (SAs) prevalent in blockchain interoperability research into two tiers.The first tier provides an overarching classification, while the second tier offers a finer granularity.The "IM Role" column denotes the role of the Interoperability Mechanism (IM), and the "Implementations" column references specific studies or implementations that employ the particular approach.The final column quantifies the number and percentage of papers adopting each method, with the percentage visually represented using cell shading.This classification aids in discerning the emphasis of the research community on different security strategies.Notably, the distinctions between decentralized and distributed systems are crucial.While decentralization pertains to the control being distributed among multiple, potentially untrustworthy entities, distribution refers to computational tasks being carried out by multiple entities.
submitting proofs directly to the L1 contract [108].Project maintainers operate these nodes, which raises concerns about centralization, censorship and MEV.Centralization offers increased performance since no agreement between parties is needed and effectively eliminates threats from decentralized architectures [65].Additionally, it enforces accountability as entities must comply with KYC [69].However,  can be censored due to bribery, coercion collusion [74].Note that multiple centralized exchanges have been the target of cyber-attacks resulting in users experiencing fund theft (e.g., FTX [109], BXH [110], or more recently CoinEx [111]).These are due, for example, to wallet security breaches [112], DDoS attacks [113], or due to rug pulls [21].
b) Trusted Computation: TEEs (trusted execution environments) [114] ensure the integrity and authenticity of computation conducted within a secure enclave at the hardware level.Computation validity can be verified through local or remote attestation by external parties.TEE-based cross-chain solutions focus on protecting private keys [43], operations on key shares between operators [115] or generate proofs [43], [116], [117].In centralized TEE-based systems, the power is solely given to the administrators [79], which can promote unfairness by censoring or colluding to maximize financial gains.A possible solution is having multiple TEE-based hosts controlled by different entities (and from different hardware providers [104]) to remove the possibility of collusion [77].LayerZero-based applications [118], that rely on a single oracle and relayer, can also be subject to collusion attacks as shown in [119].TEEs have, nonetheless, inherited limitations.The enclave attestation keys are provided by the manufacturer who can embed malicious code into the hardware or spoof data [79].TEEs are also subject to other attacks discussed in previous work [120].
2) Distributed Trust: Centralized solutions are simple to implement, faster, and cheaper but incur higher security risks.A solution for this over-trusted mechanism is to rely on distributing power among multiple entities to validate  -i.e., through an intermediary distributed network.Intermediary networks verify and maintain proof of actions of other chains [36], [80], [121], [122].More decentralized solutions leverage consensus mechanisms such as proof of work or proof of stake, in which anyone can be a part of the voting.On the other hand, less decentralized solutions use consensus mechanisms, such as proof of authority or PBFT, where involved parties are whitelisted.In the case of small networks, Threshold Signature Schemes (TSS) and Multi-Signatures (MS) are possible solutions.There are crosschain applications based on intermediary networks for all interoperation modes (asset exchanges [36], [37], [80], data transfers [72], [75], [85], [86], [123], and asset transfers [43], [76], [82]- [84], [88]).a) Permissionless Networks: When applied to crosschain bridges, they produce new state roots containing  of all chains, which are sent to the destination chain, which validates requests against them [82].Cross-chain protocols based on this architecture have to deal with increased latency and cost of execution.This is due to requiring an agreement between untrusted parties, and the issuance of transactions that pay (usually high) gas fees.
Relying on external networks to validate the state of  makes the cross-chain protocol reliant on its security since the miners of this network act as the validators for the cross-chain protocol.In particular, when dealing with public networks, its security depends on an appropriate incentive mechanism for users who follow the protocol and slashing for malicious actors [37].Actors should not profit more from deviating than from following the protocol.Furthermore, in case of misbehaviour, they should be held accountable.Interoperability solutions based on proof of stake networks should guarantee that the overall value protected by the protocol does not surpass the stake held by the majority of validators otherwise its cryptoeconomic security might not be enough [44], [124].Axelar [121] adds another security layer using quadratic voting (when validating ) to avoid vulnerabilities associated with the increasing voting power of high-stake validators [125].Note that interoperability based on intermediary networks using custom tokens with low value is not advisable due to token price fluctuations (cf.Section VI-B).
Finally, to tackle the ad-hoc bridge design problem, Blockchain Engines were proposed [10].This model relies on a relay chain that connects to several other smaller chains, and provides shared security and composability in that interconnected environment.Each project has a custom messaging mechanism (e.g., IBC or XCMP) that allows arbitrary communication between networks within the same ecosystem.Even though this standardizes cross-chain communication within each ecosystem, it is still required to address interecosystem interoperability [59]- [61], [115].An advantage of the Blockchain Engine approach is that it is easy to plug in new chains, eventually requiring the development of compatibility modules that allow communication.The main difference to the other ad-hoc approaches is this layer of shared security on top of the coordinating chain.Additionally, the relay chain can be tailor-built to specific use cases in which business logic validations occur at that level [126].
b) Permissioned Networks: Instead of relying on a network in which anyone can join, one can opt for a more controlled environment.In PoA [123] and TSS-based [43], [88], [127] networks, validators are whitelisted and usually controlled by reputable or trusted entities.The only requirement is the existence of an identification service where parties register beforehand [96].However, we still highlight the necessity of securing permissioned networks using economic incentives.Firstly, the due diligence to select parties is seldom known.Secondly, reputable entities can engage in transaction censorship.Finally, they have been subject to hacks or bankruptcy (e.g., FTX, Terra, Binance).The Uniswap Assessment report [124] also raises questions regarding Wormhole's PoA network, mainly on how they guarantee expected validators' performance, protocol involvement, and SLA (service level agreements) compliance.
Nonetheless, this controlled environment simplifies paramount challenges that are still unaddressed.Relying on fewer entities decreases the latency required for any state change, be it a normal , an upgrade, or an emergency pause transaction.This contrasts with the approach of permissionless networks, where these actions would require a long voting period enforced by the underlying governance protocol.There is a tension between the level of decentralization of a protocol and the efficiency of incident response protocols.Permissionless networks of validators can authorize transactions based on a threshold of valid signatures collected on-or off-chain and submitted in batch to trigger blockchain state changes [127].
Asset exchange protocols can leverage these schemes to build trust directly between users and operators [73], [74], [105].The main advantage of this scheme is that no user can move funds without the agreement of the trusted validator, nor the other way around.Nevertheless, funds can be locked for a long time if the validator becomes unavailable or, in the worst-case scenario, gets compromised.A possible solution is the involvement of multiple entities to guarantee liveness even in the event of crashes.The core assumption in these protocols is that the validator is trusted -i.e., it is unclear how one could recover if each validator misbehaves.A possible solution to guarantee liveness is employing some rollback mechanism triggered either when a period elapses or by presenting proof to a trusted component through cryptographic mechanisms.These can be implemented as a timelock or a centralized disputer, respectively.
The usage of MPC to build trust in environments with mutually untrusted entities has also been proposed by [43], [103], [104], [127].However, once trust is set, protocols require other mechanisms to validate , such as TSS or MS.There are also Blockchain Engines approaches based on permissioned networks.The main idea is to incorporate additional security measures at the relay chain, such as access control or data verifications in  [75], [84].Lastly, [83] considers a different architecture for a permissioned blockchain system, which is organized hierarchically with multiple tiers of networks that publish state in the main relay chain.The authors argue that it improves the scalability via parallel transaction execution, similar to sharding.We raise concerns about the number of hops a  would require between these tiers.On the other hand, HyperService [85] proposes a system that offers interoperability and programmability across blockchains through a blockchain of blockchains designed to provide a unified view of dApps' execution status -i.e., it is possible to write smart contracts that execute logic in multiple subnetworks atomically but with limited business logic.
3) Native State Validation: Previous approaches rely on external validation techniques, either performed by one or multiple parties, in more centralized or decentralized settings.We now dive further into security approaches that rely on proof validation within the interoperating networks.
a) Inclusion Proofs: We now delve into security approaches that rely on on-chain proof validation.Such schemes use proofs to provide verifiable evidence of emitted events in one chain.Relayers send block headers from the source chain to the target one.These headers serve to validate proofs provided by users and can also be verified -for instance, using zero-knowledge proofs -a prominent solution is Harmonia [44].Users can submit requests once block headers are accepted and marked as final in the light client implementation.Inclusion proofs can take the form of Merkle paths [50] or note commitments [92] and are evaluated against the crosschain logic and predefined rules.If these are valid the user can trigger the corresponding transactions on the target chain.The security of this scheme is grounded on the light client implementation in the target chain, which is dependent on the source chain's consensus mechanism.Solutions have been applied to consortium chains [86], to PoW-based chains [50], [128], and to building PoS light clients for the Ethereum 2.0 sync committees ( [129]) [44], [51], [91].Currently, in Ethereum sync committees, a majority of nodes are assumed to be honest, and no slashing mechanism is in place -i.e., accountability for the bridge is not guaranteed † .The potential for relayers to go offline or get compromised poses a risk to the protocol's liveness and safety.When the light client is unsynchronized with the latest state of the source chain, user requests may fail.Additionally, ensuring robust economic security requires the implementation of effective incentivization and slashing mechanisms for relayers.A notable advantage compared to externally verified systems is that even if an entire network of relayers were to collude, they could only disrupt the system if they possess greater mining/voting power than the rest of the source chain, which is equivalent to mounting a 51% attack on that network -this underscores the paramount importance of having secure and resilient source chains.
b) Validity Proofs: Validity-proof-based bridges rely on proving systems to validate the state of the source chain's consensus mechanism within the target chain [52], [53], [82], [93], [94].However, contrarily to inclusion proof-based systems, there is no need to understand the exact consensus logic of other ledgers as it only requires verifying a succinct zeroknowledge proof -constant time in zkSNARK-based bridges.The soundness of the specific implementation drives the security of these cross-chain bridges.We identify intrinsic drawbacks and limitations associated with the technology.Most ZK proof systems require a trusted ceremony between the prover and the verifier, where a Common Reference String (CRS) is generated as a public parameter and used by those parties for proving and verifying proofs [44].Other protocols do not require a trusted setup but have proven to have efficiency problems, hindering their adoption in practice.In particular, the creation of proofs is the bottleneck.Therefore, techniques such as recursive verification or the parallelization of subcircuits [52] and fine-tune optimizations [44] were proposed.To reduce on-chain operational costs solutions leverage verifiable off-chain computation -i.e., proofs are created by centralized off-chain mechanisms [52], [130].An optimization technique is to batch multiple blocks and generate single proofs [52], [53].Moreover, circuits are tailor-made to each specific program, highlighting the lack of flexibility of the technology.ZK schemes are currently unsuitable for widespread adoption in resource-constrained devices [53].Nevertheless, with further research, ZKP will hold substantial promise and relevance in this domain.There is a pressing need for continued research to enhance proof generation efficiency, reduce memory demands, and lessen reliance on trusted setups.Notably, in March 2023, two zkEVM projects were launched (Polygon [122] and zkSync [131]), and more have followed (e.g., Scroll [132] and Taiko [133]), foreseen to increase Ethereum's scalability while lowering transaction costs.c) Fraud Proofs: Fraud proofs allow for securing a crosschain protocol using a reactive approach [82].Block headers or other relevant proofs are assumed to be correct until proven † https://github.com/ethereum/consensus-specs/issues/3321otherwise -i.e., are optimistically accepted [134].External watchers submit fraud proofs to challenge invalid relayed block headers or transaction batches (in optimistic rollups [135]).Before these periods elapse, transactions based on this information are not considered final -i.e., user requests are denied.Watchers are rewarded by presenting fraud proofs, and at the same time, relayers/operators see their stake slashed in case of forwarding invalid block headers or invalid transaction batches [136] -relayer accountability is guaranteed.Safetywise, there must be a correct watcher online at all times, which is usually assured by the project maintainers [108].Additionally, choosing an appropriate time window is critical.A usual practice to avoid relying on synchronous communication between parties is to set extended time windows -seven-day periods for settlement in Ethereum [108].Consequently, a  takes longer to settle but incurs lower maintenance costs due to most of the blocks not being challenged by watchers.
4) Secret-based and time-based locks: Hash Time-Locked Contracts (HTLC) [10], [38] is a decentralized asset exchange protocol.It assembles a commit-reveal scheme based on hashlocks and timelocks.Parties agree on parameters off-chain and have predefined periods in which they must act to complete the protocol -i.e., rely on synchronous communication between parties through trusted off-chain communication channels.Both parties are assumed to have read/write access to both ledgers.Therefore, no trust in intermediaries to relay information exists.HTLCs do not guarantee atomicity under longstanding crashes due to the synchronous nature of the protocol.The majority of the solutions alter the synchronous communication assumptions by inserting intermediary networks [80], [87], or focus on the usage of premiums [40], [95], [137].A premium is a value staked as collateral before the execution of the actual protocol.It must be a value acceptable by the victim as a possible compensation for locking up assets for the duration of the protocol.Simultaneously, it needs to be small enough so that parties engage in the swap -i.e., accept the risk of losing this value.There are multiple game-theoretical analyses of HTLCs or simple variations such as [38], [40], [99], [138].In particular, [138] proves that the protocol is more likely to be completed under collateralized models (i.e., using premiums).However, the actual exchange of premiums (before the protocol) is still vulnerable to attacks [103] (even though these are usually much smaller amounts than the values to swap).
Relying on explicit time intervals is challenging when each permissionless blockchain has different time management mechanisms, usually implemented at a very coarse grain level -in the order of hours or days.Therefore, primitives such as Verifiable Timed Commitments (VTC) [139] or Verifiable Timed Signatures (VTS) [140] were proposed.In the former, if one party decides not to reveal the value behind the hash commitment, it can be brute-forced by the victim in a configurable number of computation steps.Manevich et al. [106] extends the solution with ZK cryptography to prove arbitrary attributes for the timed commitment.In the latter, parties share signatures from jointly signed refund transactions, which allows one to abort a swap if no action is performed within the agreed duration using the brute force algorithm.The authors of [100] also present a commit-reveal scheme for atomic swaps based on adaptor signatures -verifiable partial signatures that allow revealing a secret once the full signature is published.We question the liveness guarantees of the protocol if one party halts participation midway.

V. PRIVACY MODEL FOR CROSS-CHAIN SYSTEMS
Most permissionless blockchains typically rely on unencrypted ledgers and pseudonymous addresses, which have proven to offer limited confidentiality and anonymity [141]- [145].With data analysis tools, it is possible to track transactional data and map those to real identities [145].Some initiatives have begun to address this issue by 1) developing privacy-preserving applications deployed to existing networks [146], or 2) launching entirely new blockchains with a strong emphasis on transaction unlinkability and onchain confidentiality [147]- [149].A noticeable fact is that many widely used blockchains, including Ethereum, lack these privacy properties by design, leaving users with suboptimal privacy levels.
Privacy and security are frequently intertwined, and in many circumstances, a secure system helps to safeguard its users' privacy.Likewise, guaranteeing privacy might also enhance a system's security -for example in the form of fairness.It is crucial to remember, however, that privacy and security are not synonymous, and one does not guarantee the other.A system may be safe in terms of avoiding unauthorized access but collecting and using personal information in ways that violate rights to privacy.
We break down cross-chain privacy into the privacy of bridge operators (at the IM level) and users [43].As seen in previous sections, operators play a crucial role in interoperability solutions.Their actions drive the security of the network and its end users.As the public keys of operators are disclosed they can become a target for coercion or resource exhaustion attacks [43].To neutralize these vulnerabilities, we highlight the importance of hiding identities (i.e., public keys) of operators through the use of privacy-enhancing technologies [127].As for user privacy, we deconstruct it into transactional data privacy and identity privacy -i.e., the confidentiality of  and anonymity of users.As for the first, data associated with cross-chain transactions might be sensitive and can reveal much about the entities holding the data [75], [147], [150].For the latter, solutions should uphold anonymity while enabling the identification or appropriate punishment of actors engaged in malicious activities.Striking this balance is vital: while privacy is essential, accountability is equally necessary to deter and penalize misconduct.Additionally, privacy is also mandatory to maintain fairness in cross-chain systems.Any interoperability mechanism can influence relaying, accepting or ordering of  [151] or can link local transactions issued on different chains.
Our comprehensive literature survey shows that privacy within cross-chain solutions is a relatively understudied do-main.In this section, we put forward the first definition and formalization of generic cross-chain privacy by decomposing it into three relevant properties and presenting a taxonomy of privacy-preserving techniques for cross-chain systems.We also discuss some vulnerabilities and attacks that threaten privacy in this domain.

A. Privacy Properties
In this section, we formalize three relevant properties of cross-chain privacy-preserving systems: unlinkability (of ), anonymity (of users and operators) and confidentiality (of transactional data).
Unlinkability.Single-chain unlinkability is tied to the traceability of funds in transactions issued by the same or related addresses within the same blockchain.Unlinkability must guarantee the actions performed by the same user in the network are not related to each other and that it is not possible to infer properties of those actions from one another -i.e., an account  and a transaction  are said to be unlinked if it is not possible to infer that  produced  based on the information available to the observer, for example, through other transactions issued by .We extrapolate this definition of unlinkability to a cross-chain scenario: where it is not possible to link a transaction in a source blockchain to a transaction in a target blockchain (e.g., lock-mint; crosschain contract call), or link the addresses that issued those transactions.
Definition 5 (Cross-Chain Unlinkability).Consider a cctx between two related accounts  1 and  2 , where  1 might be equal to  2 .Transactions  and  ′ issued by  1 and  2 , on the source and destination chain, respectively, are said to be unlinked if it is not possible to infer that  and  ′ are related to each other.
External parties can infer relationships between transactions using pre-trained models and heuristics which can be queried using functions  (,  ′ ) that return a similarity factor  -i.e., the probability of two transactions being linked.Heuristics can be related to transaction amounts, certain types of asset profiles, reused addresses, transaction patterns, payment of gas fees, and so on.It should be noted that a cross-chain protocol fundamentally needs linkability to allow for a transaction on one chain to be executed based on a transaction on another.However, it is crucial that this linkability is not observable from an external perspective to protect users' privacy.Trust must be placed in third-party entities or cryptographic mechanisms to guarantee these properties.We elaborate upon this in this section.
Anonymity.Unlinkability in a blockchain is tied to guaranteeing users' anonymity or pseudonymity.An example of pseudonymity is Bitcoin, where users sign transactions with their private key and thus are identified by their public key -i.e., if one can identify the real-world identity behind such key, it is possible to link all the transactions in which it was involved.We provide cross-chain pseudonymity and anonymity definitions.Confidentiality.Data associated with cross-chain transactions might be sensitive and can reveal much about the entities holding the data.Confidentiality guarantees that critical information is not disclosed and accessible to external entities in or off the network; buyer-supplier relationships in supply chain management systems and medical records are some examples of applications [75], [147], [150].

Definition 8 (Cross-Chain Confidentiality). Cross-Chain confidentiality holds if the content of any cross-chain transaction
1 issued by an address  1 is indistinguishable from the content of any other cross-chain transaction  2 issued by  1 or any other address, i.e., the transactional data cannot be seen.

Formally,
cross-chain confidentiality guarantees that for any payload  1 and  2 , the content of two  is indistinguishable ≈, i.e., Similarly to the above, the payload can be an asset amount to be transferred or a generic cross-chain message.

B. Privacy-Preserving Approaches
In this section, we summarize the main privacy-preserving techniques in the literature, to guarantee at least one of the identified properties.
1) Zero Knowledge Proofs: Mixing services were the first solutions to break the linkability of transactions in blockchains using zero-knowledge technology.Similarly, they can facilitate guaranteeing ' unlinkability [82].Multiple users transfer funds to a smart contract, which triggers transactions to one or multiple destination addresses that account for the same amount.To withdraw funds, users provide zero-knowledge proof attesting that a certain amount was previously deposited into the contract.A centralized IM can function as transaction mixer [76], [77], [83] -however, this approach can risk user privacy as these links are known to the IM [11], [152].A solution is multiple chained mix services, providing unlinkability in each hop [153].Alternatively, the IM can function normally and deposit funds in a mixing contract in the target chain, or to shielded addresses [93], [154].Transaction mixers incur higher overhead and higher mixing and transaction fees.It is worth noting that, primarily, these techniques are employed to obfuscate traces of illicit activities and launder money obtained through, for instance, cross-chain attacks.Various projects offering mixing services have faced government sanctionse.g., from the Office of Foreign Assets Control (OFAC) in the Note: The table categorizes multiple privacy-enabler approaches (PAs) in blockchain interoperability studies.The first column provides the approach classification.The "Implementations" column references studies or implementations that employ the particular approach.Finally, on the right end side, there is a quantification of the number and percentage of studies adopting each method, visually represented using cell shading.This classification aids in discerning the emphasis of the research community on different privacy strategies.
US -for their role in facilitating money laundering originating from online criminal activities [155].ZKP can also help guarantee confidentiality and unlinkability by proving actions without disclosing actual transactions [156].Proofs can validate that coin commitments are well-formed and not double-spent [92].ZKP can be used by internal or external mechanisms to assert that the transactional data respects the defined cross-chain rules, without disclosing the parties involved, transaction amounts, or exchange prices [83], [96].To guarantee a tradeoff between confidentiality and accountability, ZKP might also be used to prove that auditors can decrypt a commitment if there is suspicious activity [94].This tradeoff is worth exploring in future work.The authors do not explain who would take the auditor role, which is crucial to evaluate the solution.It would be possible to decrypt every  if colluding entities control all auditors.Interoperability protocols based on permissioned blockchains usually require a trusted IM that needs to access the internal state of each network.Leveraging ZK, one can prove transactions without giving access to the internal state of private chains [76].
2) Blind Signatures: In cross-chain, signature-based protocols allow extending atomic exchanges to ledgers without scripting capabilities [42], [105].Blind signatures (BS), initially proposed in [157], allow one user to obtain a signature from a third party such that the third party does not learn anything about the message.Each produced signature represents the same value.Therefore, the third party generates N signatures for a user that escrows N tokens.IMs can issue blind signatures to users.Users present the blind signature in the target chain, and if it is correct, corresponding actions are performed [105].Since every blind signature is worth the same, BS guarantees  unlinkability and anonymity since one cannot link transactions on both chains (not even the IM).Even though the literature does not explore the application of BS to other interoperability modes besides asset exchanges or permissioned environments, we find relevance in this research direction.In permissioned blockchains, BS ensures confidentiality, unlinkability, and anonymity of .BS promotes fairness through shielding against centralized surveillance, removing the possibility of custom ordering.IMs can still censor by not issuing BS to some addresses.Appendix G1 presents an asset transfer protocol using BS.
3) Ring Signatures: Ring signatures provide set anonymity -users are hidden among a ring of k users, where the probability of one having its identity disclosed is 1/k [158].However, since ring signatures do not rely on a trusted centralized server, anonymity revocation is impossible -i.e., if there is misbehaviour, that party is not identifiable.Any group of users form a ring by themselves without additional setup, which makes the solution immediately applicable without any previous setup.We acknowledge the existence of different ring signature protocols with trade-offs between, for example, traceability, anonymity and linkability [159].
Ring signatures have been used in privacy-preserving blockchains such as Monero [160] to protect the stealth addresses of users when issuing/receiving transactions.Monero, for example, blends the sender's identity with a set of other identities and generates an unspent transaction to a unique onetime address.In cross-chain protocols, solutions can be similar to the ones proposed in Group Signatures (cf.Section G3)an address is blended among a ring of other user addresses that wish to bridge assets to another chain.Since there is no way of determining the signer (assuming a vanilla Ring Signature protocol), the destination address needs to be in the transactional data in the source chain.An IM sends proof to the target chain, which is used to mint the corresponding asset.The problem with this approach is that it makes both transactions linkable due to sharing that destination address -which does not guarantee unlinkability and anonymity.Other variations, such as Verifiable Ring Signatures [161], can offer different guarantees.
Interestingly, our research yielded limited results on crosschain protocols reliant on Ring Signatures.Among the few that employ this primitive, Wanchain [127] uses it to conceal the transaction sender address, and Bool Network [43] leverages it to shield the identities of the selected committee members, safeguarding against potential threats like DoS attacks.Notably, the committee members rotate constantly, protecting against cryptographic key compromises and guaranteeing perfect forward secrecy.However, this approach safeguards the operators but does not protect the users, who maintain the anonymity level provided by the underlying chains.
4) Adaptor Signatures: Adaptor signatures allow one party to generate a pre-signature on a message associated with a secret, which is guaranteed to provide the secret once the full signature is published [104].It resembles an atomic reveal scheme (ARS) [100] (also called commit-reveal scheme) that underlies HTLCs for asset exchanges.The authors show that an adaptor signature protocol implies an ARS protocol for two parties and thus enables cross-chain atomic swaps.The overall idea is that when party A commits a transaction to collect party B's assets, it reveals a secret that allows B to also A's assets.An alternative to adaptor signatures is running a simple Diffie-Hellman key exchange protocol, which also avoids publishing the shared secret hash that makes HTLCs not guarantee unlinkability.In either approach, applied to permissionless blockchains, it is possible to analyze on-chain transaction amounts.However, it is unlikely that one can link transactions without knowing the cryptocurrencies exchanged and the exchange rate agreed upon off-chain by both parties.
5) Homomorphic Encryption: Similarly to Adaptor Signatures, one can use homomorphic encryption (HE) to solve commit-reveal schemes linkability problems.Both [101] and [102] proposed an atomic swap solution based on HE where different secrets are deployed in each chain, attaining transaction unlinkability.While there are existing tools for performing basic operations on encrypted data, further research is required to enable more intricate computations and allow general data transfers while guaranteeing confidentiality.Moreover, these protocols typically come with high on-chain computational costs, heavily influenced by the selected homomorphic functions.Appendix G2 presents a specific algorithm for atomic exchanges using HE.
6) Trusted Execution Environments: TEEs allow computation on private data without leaking details outside the secure enclave [120].For confidentiality, the TEE takes user input, executes pre-defined computation (checking compliance with cross-chain rules [75]), reads from blockchains and outputs transactions accordingly [79].Ideally, transactions issued to the blockchains will not leak sensitive data input to the TEE.However, even though computation within the TEE is confidential, a  might not be if one is interoperating two public chains as public transactions on both chains can still be linked.It is unclear how unlinkability could be guaranteed for these use cases when the underlying chains do not guarantee confidentiality.We reckon that a possible approach to guarantee unlinkability is to leverage the TEE as a mixing service [77].However, no previous work provides a specific algorithm to do so.For interoperability solutions supported by evolving notary committees [43] or some solutions with PoS light clients [91], one can use TEEs to protect keyhandover procedures.TEEs come with tradeoffs such as additional overhead, limited scalability, and lack of flexibility and composability due to possible vendor lock-in.We note that for asset exchange protocols with confidential order matching algorithms [69] it might be easier to guarantee unlinkability due to the exchange rates not being public.

VI. STATUS QUO OF SECURITY AND PRIVACY
In this section, we present the results of our work and extensively discuss the most relevant insights.

A. Comparison Framework
We classify 51 academic papers and 6 industry solutions deployed in production (that account for more than 75% of the TVL in cross-chain bridges [25]) in light of the security and privacy models presented in the previous sections.A distribution of the years of the papers classified is depicted   Guarantees some privacy properties even though there is no privacy approach employed.It is due to being built on top of private chains and leveraging trusted communication channels (e.g., TLS).Guarantees privacy at the application layer, not at the cross-chain level -the approach protects the order matching protocol to guarantee fairness in the order matching, but transactions are published normally to blockchains Has several open-source implementations in different technological stacks, enhancing decentralization.With considerable liquidity in the TEE [156] we can classify it as •.

THE TABLE IDENTIFIES THE INTEROPERABILITY MODE USED BY EACH STUDY (IMODE), INDICATING WHETHER IT SUPPORTS ASSET TRANSFERS (AT), DATA TRANSFERS (DT), OR ASSET EXCHANGES (AE). ADDITIONALLY, IT NOTES IF THE SOLUTION IS INDEPENDENT OR NOT OF PRIVACY PRIMITIVES IN THE UNDERLYING CHAINS (PC) AND IF AN IMPLEMENTATION IS AVAILABLE (IMPL). PAPERS MARKED AS (-) DO NOT FOCUS ON THE SPECIFIC PROPERTY. THE LAST TWO ROWS OF THE
One of the few solutions being standardized in reputable standardization bodies [56] Strong dependency on price oracle.Can be classified as • if the oracle is robust and decentralized [47] Provided it has a sufficiently large anonymity set in Figure 6.We show that more than half (54%) of the classified papers were published since 2022, which highlights the timeliness of this work.The classification can be seen in Table VI.Additionally, we classify each solution based on a set of performance and usability metrics relevant to both the project maintainers and platforms' users.
1) Classification Criteria: Next, we classify the relevant IMs according to security, privacy, governance and performance metrics, and miscellaneous properties.For each IM, we attribute security and a privacy approaches, ordered by relevance.
Security Properties: • Integrity (In).Integrity is enforced by the underlying cryptographic primitives which are based on the hardness of well-known problems (e.g., computing the discrete logarithm) (•); integrity is enforced under strong assumptions (e.g., trusted hardware, rational participants, parties abiding by laws) (◑); integrity cannot be guaranteed under misbehaving parties (○).• Availability (Av).It requires a decentralized network, but there is at least one honest off-chain party (•); availability can be temporarily compromised if any party misbehaves (◑); it is based on a centralized architecture, hence, there are serious concerns over availability (○).• Accountability (Ac).The misbehaving party is identifiable and automatically punished (e.g., programmatically) (•); malicious party is identifiable, but there is no punishment or needs to be enforced by a third party (◑); misbehaving parties are neither identifiable nor punished (○) (the notion of accountable safety [91]).
Privacy Properties: • Unlinkability (Un).It is cryptographically infeasible to link transactions or addresses (•); it is possible to link transactions or addresses through heuristics (◑); no mechanism is in place to unlink transactions or addresses across domains (○). • Anonymity (An).Both users' and operators' identities are concealed (•); users' anonymity or operator's anonymity is enhanced (e.g., through set anonymity approaches) (◑); at most pseudo-anonymity is provided for users, and operators are known (○).
• Confidentiality (Cf).Data confidentiality is enforced through cryptographic primitives (•); conditional confidentiality -i.e., can be revoked under some circumstances, or verified by auditors.Note that IMs based on private chains partially guarantee this property (◑); there is no confidentiality (○).Governance and Performance Properties: We extend our classification of solutions with governance [168] and performance [32], [47] properties, as they are factors that intrinsically influence security and privacy [7].We collect insights from related literature to define: • Decentralization (Dc).fully distributed system with a consensus algorithm to settle different views on information [55] or control relies on the end-user (•); limited decentralization of the system, being run by a small set of verifying parties (◑); control of the system resides in less than 4 ‡ parties (can be distributed or centralized) (○).
• Latency (Lat).Latency of a cross-chain transfer is settled before finalization time (optimistic approach) (•); Latency of a cross-chain transfer is finalized right after the finalization time of the slowest chain (◑); Latency of a cross-chain transfer is more than the finalization time of the slowest chain, due to extra processes ran before (e.g., special account setup) or thereafter (e.g., extra transactions needed) (○).• Cost (Co).there are no protocol fees (for the user); can be run with low-tier commercially available hardware (for IM operator) (•); variable fees depending on search and demand with an upper bound lesser or equal than 1% of the bridged value (for the user); requires at most mid-tier hardware (for IM operator) (◑); variable fees depending on search and demand with more than 1% of the bridged value (for the user); requires above mid-tier and/or specialized hardware for the IM operator (○).Miscellaneous (Misc.):We provide information that complements our assessment.IMode shows the main interoperability mode the IM supports.PC indicates if the IM requires a privacy-enhanced chain or permissioned blockchain (✗) to operate in optimal conditions, i.e., a dependency (otherwise, ✓).Impl.refers if the project has an open-source implementation and evaluation (✓), a not-open source implementation (±), or no implementation (✗).

Insights
We now present a list of insights taken from the analysis of the literature.
• Insight 1: A conspicuous deficit exists in the literature regarding the empirical assessment of protocol performance and associated costs.This observation is consistent with findings from other studies [7], [169].While many solutions appear to delegate computationally intensive tasks to off-chain procedures [44], further investigation in this domain remains paramount.
• Insight 2: Each study we reviewed ensures a degree of integrity, predominantly upheld by cryptographic mechanisms.It is imperative to meticulously scrutinize these mechanisms.The count of assumptions embedded within a protocol significantly determines its integrity metric.
Research that confines its scope to specific adversarial behaviors, such as rational actors, typically exhibits diminished integrity levels.• Insight 3: Within the academic domain, security often takes precedence over privacy, as evidenced by the limited literature addressing privacy properties (15 studies, 30%).In parallel, projects dominating over 75% of the market share seem to neglect cross-chain privacy.This suggests a prevailing apprehension regarding bridge security, relegating privacy to a subordinate design objective.• Insight 4: Zero-knowledge proofs ( 1 ) emerge as the predominant approach (50% of IMs with a privacy approach) for guaranteeing privacy in cross-chain systems, which allows shifting trust from third parties to cryptographic protocols.Nonetheless, we believe there is still much work on this front.• Insight 5: The prevailing academic literature primarily emphasizes asset exchanges and transfers between blockchains, with a conspicuous absence of studies addressing general data transfers.This academic trend contrasts with industry developments, which have observed a surge in bridges facilitating data transfers (also called arbitrary message-passing bridges [7]).• Insight 6: For cross-chain anonymity, it is imperative that two distinct transactions remain indistinguishable when originating from the same sender and targeting the same recipient.This condition is attainable exclusively when unique addresses are generated for each , epitomized by the mechanism of stealth addresses [154].• Insight 7: The predominant trend in the literature underscores achieving optimal accountability via stakeslashing mechanisms.In contrast, a smaller subset of research advocates for leveraging the legal identification of involved parties, necessitating an ancillary identity service.Such methodologies are predominantly found in centralized frameworks or within permissioned network configurations where nodes possess identifiable attributes.• Insight 8: The privacy dynamics in cross-chain contexts are intricately linked to the privacy paradigms inherent to their foundational domains.Our analysis elucidates that cross-chain unlinkability, in AT and DT-based protocols, can be feasibly realized solely when the foundational chains intrinsically ensure confidentiality.A rigorous formalization of this observation is delineated in Appendix E. For AE protocols, unlinkability can be achieved through cryptographic primitives such as Adaptor Signatures.Additionally, we emphasize the need to research heuristics to break privacy [101], [170] and respective protections against them.• Insight 9: Privacy is expensive.Privacy in interoperability is mostly implemented with a small set of techniques, which bring considerable overhead on the latency and trust assumptions of the protocol.For example [77] is one of the solutions providing confidentiality and unlinkability but relies on trusted hardware.• Insight 10: Asset exchange protocols, with confidential order matching algorithms [69], [79], by themselves, do not offer cross-chain privacy.They protect and ensure the correctness of order matching at the application layer, guaranteeing fairness.However, the actual transactions are public and executed on-chain -i.e., the order matching protocol acts as a fair public forum where people advertise their intentions to buy or sell cryptocurrencies.

B. Vulnerabilities, Attacks, and Mitigations on Interoperable Systems
In this section, we present vulnerabilities found in crosschain.Figure 7 lists and maps each identified vulnerability to corresponding cross-chain attacks and mitigations.Table VI-B presents all relevant mitigations.Due to its extension, we present the complete explanation of each vulnerability in Appendix H.
Honest Mining Assumption ( 1 ).Networks that employ consensus mechanisms with probabilistic finality are subject to forks.A single party that controls more than the security threshold of miners or validators, can authorize invalid , double-spending assets [89].These can be the underlying networks or any intermediary network that serves as IM.Parties holding more power than the predefined security threshold can validate  that violate the cross-chain rules.
Absence of Identity Verification ( 2 ).The absence of identity verification can lead to one party forging multiple identities and gaining more power than perceived in the network [37], [88], [89].
Network Isolation ( 3 ).Relayers can be intentionally isolated from the rest of the relay network during a period and misled to accept the attacker's chain as the longest [92].Additionally, packets can be intercepted or dropped causing transactions to not settle in some networks [79], [89].This can also happen in optimistic-based solutions, even though the attack duration would need to surpass several days or a week, which is practically infeasible [50].

Outdated Light Client State ( 4 ).
Having light clients with outdated information can cause unavailability to respond to SPV requests or inaccurate transaction validation on the destination chain.This can be caused by high relaying costs [89], data unavailability [171], or message delays [68].
Wrong Main Chain Identification ( 5 ).Relayers can submit conflicting block headers to the target chain smart contract to perform a chain reorganization in the source chain light client [6], [89], [92].There must be identification mechanisms so that the light client can correctly respond to SPV requests based on the main chain and not on conflicting forks.
Incorrect Event Verification ( 6 ).Events emitted on blockchains drive interoperability (cf.Section II-C).The incorrect verification of events might cause the bridge to validate  transactions on the target chain based on forged source chain events (or vice versa) [32], [172]- [174].

Acceptance of Invalid Consensus Proofs ( 7
). Malicious actors may attempt to construct invalid blocks, not adhering to the consensus rules, or include illegitimate transactions within valid blocks and submit them to the light client implemented in the target chain [130].

Absence of Chain Identification ( 8 ).
One user might try to submit the same proof to multiple destination chains to mint multiple representations of the same locked token, causing to double-spend assets [175].

Submission of Repeated Inclusion Proofs ( 9
). Attackers can repeatedly submit the same inclusion proof over and over again to try to prove a statement more than once.Numerous unbacked assets can be created, or multiple tokens can be unlocked, triggered by a single burn event [75], [89], [92], [130], [176].
Counterfeiting Assets ( 10 ).Failing to map actions on the destination chain based on events on the source chain may lead to minting assets out of thin air [89], [92], [177].

Involuntary Timelock Expiry ( 11 ).
Due to the synchronous nature of some cross-chain protocols, such as HTLCs, parties  [90] Wait full confirmation time according to the source chain consensus mechanism  2 [89] Insertion of block maturity periods  3 [55] Usage of blockchain views  4 [175] Add chain identification mechanisms  5 [89] Synchronize smart contract state on multiple destination chains  6 [50] Increase transaction settlement time  7 [65] Physical decentralization of infrastructure  8 [69] Usage of a trusted centralized authority to mediate   9 [178] Integration with Self Sovereign Identity (SSI) mechanisms  10 [37] Make the creation of identities expensive (e.g., a high stake per identity)  11 [88] Reward creating fewer identities with more stake  12 [173] Listen to events only from whitelisted smart contracts  13 [174] Deploy runtime monitoring modules  14 [82] Employ multiple different monitoring strategies at the same time  15 [91] Enable verifiability of state updates in light clients for different consensus mechanism  16 [171] Insertion of a data availability layer  17 [92] Unique nonce/id generation per request  18 [89] Use and develop new main chain identification mechanisms  19 [92] Trigger automatic liquidations of collateral  20 [89] Use Collateralization / Over-Collateralization techniques  21 [135] Usage of external incentivized watchers that attest actions/events  22 [179] Embedded rules in third party network consensus mechanism  23 [103] Usage of Distributed Signature Schemes between untrusted users and operators  24 [180] Parallelizing transaction verification  25 -Insert independent computational-heavy transactions into multiple blocks  26 [181] Separate entities that create and verify blocks  27 [95] Usage of Premiums  28 [181] Usage of Verifiable Timed Commitments  29 [80] Provide support for periods of asynchrony in the execution of the protocol  30 [42] Use pre-deployed refund transactions/contracts triggered upon failures  31 [138] Model and analyze user behaviour through game-theory principles  32 [182] Protocol architecture decentralization  33 [50] Increase the number of parties and scatter mining power among them  34 [99] Usage of MEV to front-run misbehaving transactions  35 [97] Parallel asset locking  36 [97] Reduce time window for users to observe price fluctuations  37 [89] Over-collateralization to account for slippage  38 [89] Adjust the amount locked according to the updated exchange rates  39 [89] Trigger automatic liquidations to avoid getting uncollateralized  40 [182] Merge multiple sources of data  41 [183] General mitigations for (MEV), such as confidential mempools  42 [184] Enforce predefined transaction ordering rules  43 [180] Overlap capabilities between multiple parties  44 [43] Employ evolving committees rather than static ones  45 [185] Hide one public key among multiple keys of other users/operators  46 [65] Other usual web2 infrastructure backdoor mitigations  47 [65] Decentralization at the operational level (e.g., key management and monitoring) Label Ref Mitigation description  49 [48] Use redundant nodes or deploy logic in the blockchain (i.e., in smart contracts)  50 [65] Usual web2 practices (e.g., rate limiting, challenge-response tests)  51 -Multiple rounds of smart contract audits, preferably by different parties  52 [56] Standardization of cross-chain bridge design (e.g., for proper access control)  53 [186] Do not issue approvals for more funds than what is strictly necessary  54 [187] General smart contract vulnerabilities mitigations  55 -Submit codebases to thorough code reviews before production  56 -Ensure there are rigorous testing guidelines being enforced  57 -Just like on-chain smart contracts, off-chain programs and infrastructure must be audited  58 [188] Avoid library version auto-upgrades and audit code before upgrading  59 -Linting tools to raise warnings for unused code  60 [189] Improve cryptographic key management (e.g., usage of hardware or cold wallets)  61 [77] Increase of the number of validators and thresholds in multi-signature wallets  62 [65] Employ further authentication mechanisms to protect keys  63 [65] Accept incoming connections only from whitelisted IP addresses  64 [65] Authenticate requests made to RPC nodes through rotating keys  65 [190] Require setting gas limits for   66 -Performe deep optimizations once the industry and the project have reached stability  67 [44] Dispose of private inputs used to generate the CRS in zk-based solutions  68 [32] Monitor on-and off-chain infrastructure  69 [179] Set appropriate withdrawal limits and implement a freezing functionality  70 [186] Do not give excessive permissions to individual external entities  71 [191] Check inputs in arbitrary message passing bridges for function signatures' hash collision  72 -Treat critical fixes internally before pushing them to public repositories  73 -Make sure critical components are updated before an audit, not afterwards  74 -Do not launch projects on top of existing ones without knowing the inner details  75 -Fix bugs as soon as they are detected, not just leaving for the future  76 [7] Follow standard practices, such as RFCs. 77 -Increasing the awareness of all involved actors  78 [192] Attest the security of external packages using analysis tools and third-party auditors  79 [193] Follow coding practices according to the programming language being used  80 [188] Apply the same (or compatible) compiler version across the whole project  81 [194] Follow standard code/testing architectures to prioritize understandability of the code  82 [175] Update the internal state of a contract before making an external call to another one  83 [188] Document critical state changes and -e.g., one event should be emitted for each one  84 [195] Reuse code for the definition of messages for components that interact with one another  85 [172] Enforce transaction ordering between L1s and L2s  86 [175] Follow standards for the usage of storage gaps within upgradeable smart contracts  87 [196] Use (e.g., static) analysis tools to warn the absence of checks on inputs and operations  88 [197] Force documentation and comments to be updated once pull requests are accepted  89 -Providing a user-agnostic and random string as input for the ZK trusted ceremony phase  90 [160] Use unique addresses -e.g., using primitives such as stealth addresses  91 -Rely on alternative atomic-reveal schemes -e.g., Diffie Hellman and Adaptor Signatures  92 [141] Educate users for privacy-preserving practices -e.g., address reuse and unique gas prices  93 [170] Note: The table displays various security and privacy vulnerability mitigations.We have included references to indicate the source of each vulnerability and marked our proposals with "-".may incur financial losses if they crash for more than predefined durations [38], [80].
Unset Withdrawal Limits ( 12 ).Cross-chain bridges, especially ones that rely on lock-mint patterns, maintain assets in escrow in the source chain, a honeypot for attackers.Multiple attacks have drained such escrows by not setting withdrawal limits based on the usual asset flow [175], [198].
Unspecified Gas Limit ( 14 ).Protocols that allow arbitrary message passing are vulnerable to fund draining if gas limits are unset.If relayers execute invalid retryable [190] transactions until success (which will never happen), they will eventually be out of funds.
Resource Exhaustion ( 15 ).Instead of inducing abnormal behaviour in the system, attackers may focus on disrupting the availability of a cross-chain solution, for example, by compromising a centralized interoperability mechanism.
Single Point of Failure ( 16 ).The failure of components that compromise the liveness of a cross-chain solution are single point of failure.These can be oracles used to fetch prices [194], or centralized components in the architecture [175], [188].
Publicly Identifiable Operators ( 17 ).Solutions, where operators are public and identifiable, are vulnerable to multiple attack vectors, as attackers can focus their efforts on attacking powerful entities or organizations securing the system -Bribery, Collusion, DoS, and Phishing are some examples [43].These can compromise both the safety and liveness of a cross-chain bridge.
Misaligned Incentive Mechanisms ( 18 ).Incentivization is paramount in decentralized systems.In the BAR behaviour model [200], Rational players follow strategies that increase their profits -i.e., they might choose to deviate from the protocol rather than following the rules due to the more attractive economic incentives.If protocols do not guarantee attractive rewards, adversaries might be more incentivised to misbehave rather than follow the protocol [50], [77], [82], [138], [201], [202].
Verifier's Dilemma ( 21 ).The Verifier's Dilemma, initially proposed by [205], shows that rational blockchain miners benefit from skipping the verification of blocks to gain an advantage in proposing subsequent blocks.The probability of such behavior increases when blocks contain computationally expensive transactions.We acknowledge that cross-chain solutions based on third-party networks also suffer from this vulnerability, where a  might not be fully validated.

Manipulation of Exchange Rates ( 22
). Token prices from external sources are inserted into blockchains by oracles.Oracles can be manipulated to send an erroneous price feed [22], [206]- [209].Bridges, or users themselves can therefore use the wrong exchange rates leading to unfair or unrealistic trades.
Unfair Transaction/Event Ordering ( 23 ).Transaction ordering techniques enforced by blockchain miners through MEV are also found in a cross-chain scenario [82].Similarly to the unfair ordering in the miners' mempool, the interoperability mechanisms that relay block headers, events, or any other type of proofs between blockchains, can also be subject to custom order based on the maximum extractable profit.

Lack of Access Control ( 24
).With the rapid evolution of decentralized applications' development, the complexity of such apps has increased exponentially.However, the absence of access control policies when accessing certain functionalities (e.g., usually implemented as smart contracts) has originated multiple attacks in these components [191], [210]- [214].
Conceed Approvals to Third Parties ( 25 ).The usage of functions such as approve(), permit() and transferFrom() available in some token standards such as ERC20, make users vulnerable to fund theft [173], [215].The baDAPProve problem, found in the Multichain bridge hack [186], refers to the users permitting the bridge contract to spend tokens on their behalf to save gas fees.If the bridge gets hacked, all user funds are drained.
Dead Code ( 28 ).A noteworthy vulnerability behind the Qubit and Multichain hack is the presence of dead code within the deployed smart contracts, allowing attackers to execute malicious operations (cf.Table J).
Usage of non-standard/conventional naming ( 29 ).Different programming languages use specific rules.Some examples are naming conventions for the names of variables and functions, or the usage (or not) of curly brackets [192], [194].
Inconsistent smart contract engine version ( 30 ).Multiple audits have found that, within the same project, smart contracts are using different versions of smart contract engines [175], [188], [193].
Unconventional code/testing architecture ( 31 ).Unconventional architectures at the protocol and implementation levels present a challenge to building secure and scalable bridges.At the implementation level, it is difficult for auditors to evaluate the codebase and for practitioners to understand the different components' locations.
Reentrancy ( 32 ).This vulnerability is found when a smart contract calls an untrusted contract, and the latter recursively calls the initial one to manipulate its internal state [175].
No emission of events upon critical state changes ( 33 ).Cross-chain systems revolve around events.Off-chain mechanisms listen for events that indicate state changes and sometimes forward them to other chains.Not emitting [172], [197], or emitting wrong events [188] upon state changes can risk the integrity of the bridge.
Inconsistent bridge contract interfaces ( 34 ).Bridges are composed of multiple components that must communicate with one another through standardized interfaces [195].Not guaranteeing consistent bridge contract interfaces may cause an indefinite loss of funds, due to messages sent by one party are not understood by the other.

Out of order transaction execution ( 35
).An auditability to Arbitrum's code has found a vulnerability where an attacker can exploit the absence of an ordering mechanism to deny a user access to its assets [172].
Absence of storage gaps for upgradeable smart contracts ( 36 ).Not following the storage gaps pattern [216] does not allow for inserting new state variables in the future without compromising the storage compatibility with existing deployments.
Integer overflow and underflow ( 37 ).Attempting to store values higher or lower than the largest and least value supported by a data type incurs an overflow or underflow, respectively.This vulnerability might allow an attacker to drain a bridge by convincing the bridge that the value is within the expected range when it is not [172], [188], [192], [198].
Absence of Sanity Checks ( 38 ).Throughout the codebase, there must be checks to ensure the bridge functions as intended, safeguarding its integrity.We provide some examples.Make sure an address received as input is what is expected -i.e., an EOA address, a contract address with a predetermined function [172], [175], [198]), checking function return types [188], operations for arithmetic errors [192], ensuring there are no operations on null addresses [172], [194], [198], inconsistent data type conversions [188], [194], and the size of the payload being transferred in the bridge [192].
Uninitialized variables ( 40 ).Uninitialized variables, mainly done to save gas fees [217] can lead to the internal state believing it has not been initialized.Attackers can then initialize the contract by passing attacker-controlled addresses as whitelisted contracts.

Leakage of ZK private inputs ( 41 ). As introduced in
Section IV-D3b, the CRS used to create and verify ZK proofs is computed using private inputs provided to an MPC scheme.The leakage of these inputs can lead to an adversary being able to forge proofs and generate cross-chain state transitions that violate the defined cross-chain rules.
Other Smart Contract Vulnerabilities ( 42 ).We do not explore all smart contract-related vulnerabilities due to their extension.Rather, we point the reader to an extensive work surveying vulnerabilities in this context [187].We present some bridge-related vulnerabilities.These range from signature verification bypass in the Wormhole hack [193], incorrect usage of modifiers [172], [188], unauthorized smart contract calls in the first PolyBridge hack [191] and wrong function visibilities [188].
Inadequate Key Management ( 43 ).The compromise of cryptographic keys is one of the main sources of hacks in cross-chain bridges [110], [173].Even worse than compromising a single key, is compromising multiple keys, which has happened more than once (cf.Table J).
Physical Infrastructure Backdoors ( 44 ).Infrastructure backdoors create numerous potential attack vectors, such as reaching blockchain nodes through the RPC or HTTP ports which can be used to transmit malicious transactions or perform DDoS attacks [65].
Social Engineering-related Vulnerabilities ( 45 ).Attacks such as Phishing or Ransomware Attacks can be performed through social engineering practices, usually in social media or untrusted websites [185], [215].

C. Real World Cross-Chain Bridge Hacks
Attacks against cross-chain bridges have proliferated in the last couple of years.Table VI-C presents a classification of 14 of the most impactful attacks in the industry since July 2021, that account for more than 94% of the total value stolen from cross-chain bridges (cf.Table J).
1) Classification Criteria: We present general attack information, incident response-related data, the components targeted by the attackers, and the vulnerabilities behind each.In the table, we mark as No Information Available (-) the data points to which we could not gather data -i.e., the corresponding team did not respond or provide the data.Appendix J presents further information and mitigations for each.Interestingly, the number of cross-chain hacks plummeted in 2023, which can be explained by the drop in token prices during the bear market [230].
Security Approach (SA).The security approach used by the bridge.
Date.The date of the first transaction exploiting a vulnerability in the protocol.
Amount.The amount in USD stolen from the cross-chain bridge.We don't include any collateral losses in other protocols.

Attacker Type (AT).
There may be one or multiple attackers taking advantage of a vulnerability.We classify them as black or white hats based on whether they returned the funds (or  • >= 6 days -No information available / Team did not respond † Still to be confirmed both if there is at least one attacker of each type).Attackers that restituted the funds, excluding agreed bounty fees, are also considered white hats in our analysis.

Number of Transactions (Txs).
A range of the number of transactions issued by the attackers to exploit the bridge, encompassing both external and internal transactions, which are transactions issued directly by the user or as a consequence of another contract execution, respectively.It does not include transactions issued before or after the attack to exchange or launder funds using DEXes (e.g., Uniswap) or mixing services.

Usage of Mixers (Mix).
The usage of transaction mixers (e.g., Tornado Cash) by the attacker to launder funds either before or after the attacks to break the linkability of transactions.

Discovery Time (DT).
The time it took maintainers to discover the attack and trigger the corresponding incident response mechanism.Given that this information is internal to each team, we asked all 14 projects to provide us with data.

Communication Time (CT).
The time it took maintainers to communicate the exploit to the community.This communication was performed solely as Tweets.This value is the difference between the timestamp of the Tweet and the timestamp of the first exploit transaction.
In terms of vulnerabilities, our classification encompasses both the vulnerabilities associated with each attack and the specific components of our model where these vulnerabilities were found.We also found it important to note that in some cases, funds may be taken from different components than where the vulnerability exists.

Vulnerability Location (VL).
We identify the location of each vulnerability (cf Section X).Possible locations are: in the Source Chain Smart Contract -the component with the bridging logic in the source chain, responsible for escrowing funds; in the Target Chain Smart Contract -the element with the bridging logic in the source chain, responsible for verifying inclusion proofs; or in the Interoperability Mechanismthe off-chain component that enables interoperability, usually composed of validators/relayers.

Exploit Location (EL).
One vulnerability in one location can originate exploits in others.As an example, in the Ronin bridge hack, compromising the private keys of the off-chain relayers (functioning as Interoperability Mechanism) allowed the attacker to unlock funds in the Source Chain SC.Therefore, besides VL, we classify the exploit location as follows: in the Source Chain Smart Contract if the attacker stole escrowed funds; in the Target Chain Smart Contract if the attacker minted unbacked funds; or in the Business Logic Smart Contract if the attacker stole funds by exploiting the business logic contract -usually because users approved a bridge-controlled contract to manage their funds (e.g., through the approve() function in the ERC20 token standard).

Insights
We present a list of insights taken from the analysis of crosschain bridge hacks.The pNetwork hackers did not use any mixer and still retain funds in their addresses [232].In the PolyBridge hack, the hacker returned a noteworthy portion of the 611M USD after negotiations [233].We believe these highlight the difficulty of money laundering in blockchain environments compared to conventional theft due to the inherent traceability of blockchain transactions [234].• Insight 5: We find that the lock-mint model for asset transfer bridges is riskier than other approaches.Attackers target escrowed funds in the source chain.Eight hacks drained funds from the escrow in the source chain, accounting for 1.8B USD (62%).Using native tokens instead of wrapped assets is a solution allowing developers to implement one-way flowsburn-mint models.An example is Circle's USDC announcement in October 2023.USDC is now burned in Ethereum and minted natively on Polygon [235].• Insight 6: The collected data indicates that the Thorchain and pNetwork teams took 5 and 13 minutes, respectively, to detect the incidents.However, the Ronin bridge team took a significantly longer period of 6 days.This emphasizes the need for improvement in achieving fast incident discovery.Furthermore, the substantial amounts stolen from these protocols raise concerns regarding the possibility of implementing withdrawal limits.Such limits could act as a safeguard by halting withdraws if the withdrawal amounts exceed a certain threshold.In the literature, there is little research and information on incident response.We refer the reader to [47], which serves as a foundational paper to decide which interoperability solution to choose, and thus, realize a possible threat model and appropriate incident response framework.Ad-ditionally, the mechanisms to identify incidents need to be thoroughly studied.Work has been done designing cross-chain models to identify and visualize such deviations [32], [174], [236].

D. Recommendations to Cross-Chain Bridge Operators
We divide the different guidelines for cross-chain systems into three different domains.
1) Implementation Level: Like any computer program, smart contracts are vulnerable to attacks [26], [187], [237], [238].As we speak, attacks originated in vulnerabilities identified long ago have been happening [239].To address these vulnerabilities, developers must implement secure coding practices, use Continuous Integration practices, and use tools to identify and mitigate potential security issues.Some of these include static analysis (e.g., Slither [196], Mythril [240], Mythx [241]), formal verification [242], fuzz testing (e.g., Echidna [243], Harvey [244]), vulnerability detection at runtime (e.g., Scribble [245]), and more recently AI tools to identify vulnerable patterns and perform analysis of control/data flow graphs [26].These are run directly against the codebase or at the bytecode level.Properly testing cross-chain applications is challenging as sometimes checks depend on the current state of other networks -mocking behaviour is a solution.A more trustworthy approach -but less practical and scalable -is spinning up DLT nodes or leveraging existing test networks, which guarantees a higher level of integration [199].We highlight that code and testing infrastructure in interoperability projects are ad-hoc designed [194], [246].
2) Protocol Level: As demonstrated in Table VI-C, decentralization is an essential requirement for cross-chain solutions -an infrastructure backdoor or a key compromise can be fatal for a solution that presents a single point of failure.Centralized IMs should be less trusted and not manage assets directly.A solution is to insert a higher dependency on the user-or Dappspecific inputs provided directly to the target chain [82].
Authentication and proof verification mechanisms are crucial components of cross-chain protocols -they must be audited and carefully managed to avoid significant consequences [247].Access control to contracts with critical functionality must be guaranteed by a studied cross-chain model and architecture and not on ad-hoc practices as it has been until now.Furthermore, we emphasize the importance of architectural decisions such as employing correct incentivization and slashing mechanisms, setting withdrawal limits, and stoploss procedures.Additionally, our recommendations include the usage of formal frameworks to prove the correctness of protocols (e.g., using UC, TLA+, or game theory).
We also highlight a relevant discussion on the contrast between shared and isolated security models [119].Shared security entails tokens or apps on a given infrastructure adhering to the infrastructure's security requirements, like L2 solutions.In contrast, isolated security allows each app to define its security independently, as seen in user applications built on messaging layers.While isolated security may seem more tailored to specific cases, it raises significant concerns about end-user risk, as users must individually assess the risks associated with each app.
3) Operational Level: After designing and implementing a cross-chain protocol, the next step is guaranteeing its correct operation.One must protect the system from external malicious parties and maintain the source code updated and bug-free.At the forefront of cross-chain hacks is inadequate key management (USD 1.6B stolen, 55%).Rotating validators' keys or watchers' validation mechanisms can help mitigate the risk of having a centralized single point of failure.Some practices to safeguard private keys are Hardware Security Modules (HSM), Key Management Systems (KMS), or hardware wallets.Setting daily withdrawal limits can also help prevent large-scale losses in the event of an attack.A bug bounty is an attractive option for incentivizing ethical hackers to identify and report vulnerabilities in open-source code (as demonstrated by Table VI-C hackers prefer stealing rather than reporting).For example, a white hacker identified an 850M USD vulnerability in the Polygon Plasma bridge resulting in a 2M USD bug bounty [248].However, open-source software can expose internal mechanisms of a protocol and potential security flaws [249].Examples include the Wormhole and Thorchain attacks where activity in their public repository (a patch and a comment in the code, respectively) made it easier for attackers to exploit the protocols.Nonetheless, we believe open-source is the way forward to gather efforts from the community.Projects such as LayerZero [118] or Celer [250] have only recently made the code of the Relayer and Validator Network, respectively, open-source.Developers must strike a balance between promoting transparency and collaboration while also protecting the system.An additional measure that can be implemented is the creation of an insurance fund that is a certain percentage of the TVL.This fund can reimburse users in a security breach or other unforeseen events.Naturally, it is also important to leverage good cybersecurity practices and transversal to the IT sector.Furthermore, we advocate for the assurance that multiple accredited entities verify smart contracts.As an illustration, L2Beat [25] identifies and validates bridge contracts, offering concise project summaries encompassing risk assessments and the most relevant smart contract addresses along with an explanation.

E. Future Research Directions
In this section, we lay out future research directions. 1) Monitoring in Cross-Chain Systems: Given the inherent vulnerabilities in software systems, enhancing the robustness of cross-chain solutions becomes paramount.Initial efforts should focus on the formal verification of cross-chain protocols using an array of tools to augment the likelihood of their correctness.Concurrently, establishing rigorous security and engineering practices for both on-chain and off-chain components is essential.This includes the implementation of automated tests and the meticulous security scrutiny of software dependencies.Proactive prevention can be achieved through the continuous monitoring of all components.Although the Hephaestus framework presents an intriguing direction [32], empirical benchmarks in real-world contexts remain an essential avenue for exploration.
2) Frameworks for Incident Response in Cross-Chain Contexts: Software platforms interfacing with the internet, especially those governing sensitive tasks like cross-chain bridges, necessitate dedicated cybersecurity oversight.The current research landscape underscores the need for enhanced operational security.Preliminary metrics for detecting bridge discrepancies exist [251], yet manual or automated responses each present their challenges.Mistaken detections, for instance, can result in bridge suspensions, impacting user experience and revenue.To date, comprehensive incident response frameworks for generic cross-chain systems remain largely uncharted, despite some industry-specific endeavours.
3) Cross-chain Privacy in Heterogeneous Systems: Our findings suggest that cross-chain privacy is predominantly maintained within underlying chains that inherently support privacy-enhancing features.The development and exploration of techniques to ensure unlinkability and anonymity across diverse ledgers remain areas of underexplored research within the scientific community.
4) Blockchain interoperability design patterns: Design patterns serve as structured frameworks, enabling developers to craft secure solutions with augmented efficacy.Although each interoperability context possesses distinct characteristics, discerning common challenges and pitfalls inherent to specific interoperability solutions can yield invaluable insights.While blockchain design patterns have undergone rigorous scrutiny, a comprehensive examination of design patterns across multifarious blockchain applications remains nascent in the current research landscape, reflecting the evolving nature of this domain.
5) Data models for blockchain interoperability: Data models are fundamental to interoperability, streamlining complex mappings and varied data formats.Abstract models facilitate a semantic perspective for developers, mirroring the role of SDKs in emphasizing business logic over implementation nuances.Notable strides towards a universal data model are evident through ERC-5164, the ISO model (as adopted by Overledger), SATP Gateways, and IBC.However, the path to full standardization remains under exploration, with multiple standards emerging concurrently.The preference for open standards is evident and is crucial for achieving technical interoperability.The importance of this is underscored by initiatives such as BUNGEE [55].

6) Empirical Investigations:
The research landscape reveals a notable gap in empirical studies addressing the detection of theoretical attacks and associated mitigation strategies identified in our analysis.Additionally, there seems to be a scarcity of in-depth examinations focusing on specific IMs.A couple of research trajectories stand out in terms of their pertinence and potential impact.Firstly, the identification of cross-chain Miner Extractable Value (MEV) is becoming increasingly salient due to the rapid expansion of blockchain bridges, coupled with substantial investments to enhance their usability and facilitate the onboarding of newcomers.Secondly, the empirical exploration of oracle manipulation within the crosschain context [82], [252], [253] presents a promising direction for future investigations.

F. Summary:
The importance of comprehensive security in cross-chain operations cannot be understated.Despite the extensive research conducted on cross-chain security, ensuring protection across the entire stack remains imperative.Given the vast attack surface, solely relying on preventive measures, such as continuous monitoring and proactive security, is insufficient.We strongly recommend practitioners bolster their defences by integrating reactive security measures, including robust incident response frameworks.
Regarding privacy, current research appears to be relatively underexplored.However, as interoperable central bank digital currencies gain traction -evidenced by references like [57], [254] -we foresee a more substantial impetus driving advancements in cross-chain privacy solutions.
Full unlinkability in a permissionless cross-chain scenario is hard to achieve since at least one entity needs to perform the mapping between transactions on both the source and destination chains.We envision that protocols filling this gap will emerge especially with the recent evolution of zero-knowledge technology.In practice, transaction mixers do not yield a high degree of privacy to users due to their naive practices.Solutions circumventing these limitations are necessary.Additionally, existing mixers are being used for malicious activities.Therefore, we highlight the importance of researching how privacy can be guaranteed in regulated and auditable environments.VII outlines studies that delve into the security and privacy of blockchain interoperability, juxtaposed with our research.Our study is distinct in the following capacities: 1) We adopt a systematic survey methodology grounded in recognized principles; 2) We fuse both security and privacy dimensions, introducing essential properties requisite for an exhaustive analysis; and 3) We integrate findings from both the gray literature and the industrial sector, essential for comprehensive and rigorous scrutiny.Our research aims to provide developers with pragmatic insights to augment the robustness and privacy of their systems.

A. Interoperability and cross-chain rules
During the first five years of research in this field, a significant and influential body of literature has been established.Noteworthy surveys within this realm encompass [3], [7], [10], [47], [256].The concept of cross-chain rules stands as a foundational pillar for our exploration into the security and privacy intricacies of interoperability.Multiple methodologies have been proposed for the enforcement of these rules.For instance, Ganguly et al. [257] introduce a runtime verification approach that assesses partially synchronous distributed computations, leveraging an SMT-based formula.Within this context, they delineate cross-chain rules through metric temporal ✓ -Satisfies criteria ✗ -Does not satisfy criteria P -Identifies relevant properties A -Real-World attacks or leakages M -Identifies or proposes mitigations R -Number of relevant references V -Identifies cross-chain vulnerabilities IM -Number of interoperability mechanisms systematically studied -Not specified by the authors logic formulas.Conversely, Hephaestus [32] provides a formal definition of cross-chain rules, positing them as datalog rules upheld by off-chain relayers and smart contracts.This study further lays the groundwork for constructing on-chain use cases adhering to diverse cross-chain logic.Zhang et al. [174] formulate cross-chain rules specifically aimed at detecting discrepancies within the lock-unlock bridge mechanism.While certain studies implicitly address cross-chain rules, others offer more overt definitions, as seen in works discussing oracles [258], [259], bridges [134], and gateways [56].
In the present manuscript, our focus is on the security of IMs, bearing in mind the influence of the security frameworks of the foundational infrastructure.

C. Blockchain Privacy
Our investigation into blockchain privacy is informed by seminal research on privacy attributes, specifically anonymity, unlinkability, and confidentiality [276], [277].The advent of blockchain privacy research coincided with the introduction of the inaugural privacy-centric blockchains [278].Examples of these pioneering systems include private permissioned networks, such as Fabric [279], privacy-enhanced permissionless blockchains like ZCash and Monero, and applications designed with privacy in mind, such as Tornado Cash.Within the realm of interoperability, a significant portion of privacy research has been concentrated on asset exchanges.Our conceptual model is fundamentally based on the framework proposed by [100].We have endeavored to broaden this framework to encompass all modes of interoperability.

D. A Call for Collaboration
The questions and problems raised here concern the scientific and engineering problems of safely interoperating sets of distributed systems, being safely (and privately) sharing data, or exchanging assets atomically.We believe that blockchain, a powerful technology that brings lots of new possibilities, needs to accommodate today's complex security and privacy landscape.An interdisciplinary approach to the problems referred to in this work has the potential to advance our comprehension of those issues and create a more secure and private ecosystem of ecosystems.We would like to encourage the community to get involved in such efforts.We suggest our open-source repository as an initial point for discussion and exchange of ideas: https://github.com/RafaelAPB/SoKSPBlockchainInterop.

VIII. CONCLUSION
This paper systematized relevant security and privacy properties and approaches in blockchain interoperability research.Our study correlates theoretical vulnerabilities and 14 crosschain bridge hacks, collectively responsible for 94% of the total hacked value up to date.Regarding privacy, our survey reveals a prevalent reliance on zero-knowledge technology.While this method holds promise, it requires extensive additional research before widespread adoption.We collect and propose mitigations for identified vulnerabilities and outline various research pathways, such as reliable monitoring of IMs, frameworks for incident response, the need for empirical studies, and further exploration of cross-chain privacy.

A. Cross-Chain Concept Formalization
We represent a local transaction in one blockchain as  = ⟨, , , ,    (, , , )⟩, where id is the local transaction identifier, ts is the transaction timestamp, target is the state key to which the transaction refers, payload is the transaction payload, and    (, , , ) is the signature issued party i, the initiator of the transaction.A transaction  is considered final in a ledger  according to a security parameter  of that network (e.g., the block containing the transaction has a minimum height), and is represented as    () → {0, 1}.
A local transaction yields a state change in the form of a key-value pair.We represent a state change as () = ⟨  ,  , ⟩, where   corresponds to the target of t, and  , its new value.The execution of local transactions emits events.Events act as labels or wrappers for state changes caused by local transactions.As an example, a local event targeting transaction  is represented as ⟨  , , ⟩, where   represents the identifier of the transaction ,  is the type of state change (e.g., the lock of an asset), and  is a key-value store representing the new state after executing .

Definition 9 (Cross-Chain Event). A 𝑐𝑐𝑒𝑣𝑒𝑛𝑡 gives a crosschain meaning to a local event. It extends a local event with metadata, representing a state change in a certain ledger.
We denote e ∈  () a cross-chain event that represents a state change of type type against ., in domain , emitted by transaction , such that    () = 1.
In our model, a  is only created when the transaction that emits the corresponding local event is considered final.However, it might be valid or not according to  that defines the expected behaviour.

𝑡𝑦𝑝𝑒 (𝑡) is deemed valid if and only if it follows the defined cross-chain rules related to it.
Note that the validity of an event emitted by a local transaction does not imply the validity of the corresponding cross-chain event because the latter might not comply with the defined cross-chain rules.
Formally, a cctx is then a composition of  ordered crosschain events  across multiple ledgers  with the same , such that  = {e The validity of a cross-chain transaction is given by the conjunction of the validity of every cross-chain event in , that is evaluated against a set of rules .We consider blockchain rules  to be a composition of predicates  = { 1 (),  2 (), ...,   ()} over a set of events .
Cross-chain models are a set of metrics, that evaluate  against cross-chain rules, formalized in [32].

B. Survey Methodology
In this section, we present further details on our systematic survey methodology.Figure 8 presents the PRISMA diagram for our survey.
1) Data Sources: Blockchain interoperability research has been rapidly evolving in the last couple of years.Yet, academic and peer-reviewed work alone falls short of delivering the most up-to-date facts on interoperability, particularly in the analysis of cross-chain hacks.We pay attention to a significant amount of material available as grey literature in online databases such as Rekt and Slowmist, and online audit reports by reputed companies in the area such as Certik, Chainsecurity and Trail of Bits.We also find that many incident reports are divulged through unstructured and informal means of communication, namely blog or social media posts [28].We strive to uphold the integrity of the findings presented in this work, diligently cross-referencing information whenever possible.Therefore, to the best of our knowledge, the material presented is the most reliable and up-to-date.
2) Threat Model Taxonomy: In this study, we present vulnerabilities identified in multiple contexts.Sometimes these vulnerabilities were seen in previous attacks, audit reports, bug bounty reports, or academic papers.Attacks encompass every action, intentional or not, that breaks the liveness or safety of a cross-chain protocol.An attacker is an entity that performs an attack and might be motivated either to increase profit or just to harm the system, having an arbitrary behavior.
3) Paper Classification: Out of the chosen papers, only a fraction were categorized according to the specified security and privacy attributes.Specifically, 51 papers are classifiable due to their inclusion of security-enhancing or privacypreserving solutions.However, the remaining papers cannot be classified since most are either surveys or concentrate on modeling architectures.

C. Crpytographic tools
We refer the reader to the formalization of cryptographic primitives such as digital signatures, blind signatures, Adaptor Signatures and non-interactive proof systems (Appendix A of [105]).We highlight the importance of other building blocks to construct secure interoperability solutions.Namely, we assume protocols use pre-image resistant hash functions, unforgeable digital signature schemes, and trusted communication channels (e.g., TLS) between blockchain nodes and bridge operators.
1) Multi Party Computation: Multi-party computation (MPC) is a widely used cryptographic primitive that allows multiple untrusted parties to perform joint computation on participants' private inputs [103].Consider a group of participants  1 , ...,   , where every participant   has a piece of data   that must remain private.MPC allows all participants to publicly compute the value of a function  ( 1 , ...,   ), while   remains private to each party.A higher level of security is achieved by combining MPC with other cryptographic primitives, such as secret-sharing schemes -e.g., Shamir Secret Sharing (CITE).These allow a secret key  to be split into multiple fragments (also called shares)  1 , ...,   that are randomly distributed between the participants.This way, no party has the ability to perform operations on its own because it does not own the whole key.2) Threshold Signature Schemes: Using threshold signature schemes (TSS), a secret  can only be reconstructed if a threshold of the  parties collaborate.The secret  can be used to sign a message on behalf of a whole group, without each individual party revealing their secret shares.In a (m,n)threshold signature scheme, assuming that there are at most  − 1 dishonest parties,  parties are enough for a signature to be deemed valid.

D. Privacy Properties -Example
For simplicity let us consider a cross-chain transaction composed of two local transactions  1 and  2 in ledgers  1 and  2 , respectively.The first transaction locks an asset X in  1 by transferring it from the user  1 to the bridge contract  2 , whereas the second transaction transfers (or mints) a representation of that asset from the bridge contract to the user's address in the target chain.Additionally, consider  = ( 1 ,  2 , , ) a local transaction on ledger .The above  can then be represented by ⟨( 1 ,  2 , ,  1 ), ( 2 ,  1 , ,  2 )⟩.Crosschain anonymity guarantees that for any parties  ′ 1 and This formalization abstracts the payload being transferred, and the role of the entities in the transfer.It can be an asset, a token, or general data, and the entities involved in the  can be both final users, smart contracts, or the bridging entity.Bear in mind that if a user holds full anonymity in one chain, yet the in-teroperability mechanism does not guarantee the unlinkability of transactions, that degree of anonymity (cross-chain wise) decreases.

E. Confidentiality as a requirement for Cross-Chain Unlinkability
From our research, we show that the degree of linkability, and consequently anonymity, yielded by an interoperability solution is tied to the capacity to keep local transactions' content confidential.This idea is also supported by [281].We study the requirements for cross-chain unlinkability to be achieved and propose Lemma A.1, which is proved below.We denote confidential systems as  and non-confidential systems as .Confidential systems are either private blockchains (e.g., Hyperledger Fabric, Quorum, DAML's Canton) or public blockchains that are hardened by a privacy-preserving mechanism that hides transactional data (e.g., ZCash, Monero).Nonconfidential systems are typical layer-one blockchains with no concern over privacy (e.g., Ethereum, NEAR).We denote an interoperation process (e.g., asset transfer/data transfer) by →.

Lemma A.1. Cross-chain unlinkability is unlikely to be achieved without confidentiality on the underlying chains.
Proof.Interoperability inherently relies on linkability between transactions on a source and target blockchain.However, one must consider that this linkability is undesirable for general users, as it compromises the degree of privacy yielded by the protocol.We identify a direct relation between the confidentiality guarantees offered by one blockchain and the cross-  → : Firstly, let us assume the source chain does not guarantee confidentiality, but the target chain does.On the source chain, transaction data (such as the amount, sender, and recipient) is open to everyone.However, since the destination chain is private or has privacy-preserving primitives, only a set of authorized parties can see and link this transaction to the one issued on the source chain (might be a whole blockchain, one party [154], or a set of parties that share a private channel [279].To issue transactions on a permissioned network, there must be a trusted and identified IM with access to the ledger and, optionally, to private channels.Assuming trust in this entity it does not disclose this information, and therefore, external parties cannot link transactions.Transaction unlinkability is guaranteed.
 → : Secondly, consider a private source chain and a non-private-concerned target blockchain.Transaction amounts and addresses are unknown to unauthorized parties within the source chain.The key challenge here is that there must be a way for the target blockchain to know if one action took place in the source one.The two options are a light client in the target chain, where the user presents a way of decrypting source blockchain data or an interoperability mechanism that has access to the blockchains and acts as a trusted party.In the former alternative, an option might be the usage of zero-knowledge proofs, which can be verified while maintaining data confidentiality.In the latter case, linkability is possible only if the trusted IM discloses information.A trusted IM can access this information, verify its validity and issue transactions on the public chain accordingly.Since the IM must be trusted, there is cross-chain unlinkability under these conditions.
 → : Assuming both blockchains are confidential, only authorized parties can link transactions, including a trusted IM with access credentials on both the source and target chain.Applying the same logic above, an external observer cannot link transactions in each chain.
 → : Assuming there is no confidentiality on the underlying ledgers -i.e., these are permissionless networks where information is widely open.Analysis of various heuristics, such as transaction amounts, addresses, or shared secrets, can enable linking transactions across multiple blockchains [82], [92].Mixing services (cf.Section V-B1) help cover traces and break transaction linkability.In an ideal setting, these systems achieve their goals perfectly.However, in the real world, these have been studied and are shown not to be effective [145].
Note that there needs to be always some trusted party to enable interoperability.In centralized settings, this entity can hold records of transactions and corresponding mappings.Therefore, privacy concerns may arise, such as the leakage of private information or, in the worst-case scenario, sold [150].With a trusted centralized entity that removes outdated records and does not keep track of transactions, there is full unlinkability without the risk of being compromised.A possible safeguard is cryptographic methods such as blind signatures, where a message is blindly signed by the trusted party (cf.Section).We derive a direct consequence from the above Lemma A.1: since cross-chain anonymity depends on the unlinkability of , we extend our initial thoughts in Lemma A.2.

Lemma A.2. Cross-chain anonymity is unlikely to be achieved without confidentiality on the underlying chains.
Proof.Cross-chain anonymity is driven by cross-chain unlinkability, and cross-chain unlinkability is unlikely to be achieved without the confidentiality of the underlying chains.Therefore, cross-chain anonymity is unlikely to be achieved without confidentiality on the underlying chains due to the incapacity to provide cross-chain unlinkability under those conditions.
We derive the main consequence of the above ideas in Corollary A.2.1.

Corollary A.2.1. The privacy level offered by the interoperability solution is upper-bounded by the intersection of the privacy levels of the underlying chains.
F. Security Approaches -Extended Version 1) Permissionless Networks: We provide further explanations on atomic exchange protocols based on intermediary networks and on the design of the Blockchain Engines approach.
Decentralized atomic swap protocols, namely HTLCs and variants, require synchronous communication between parties.Therefore, they do not guarantee atomicity under longstanding crashes due to relying on a pre-defined timelock.Herlihy et al. [36] show that any atomic swap protocol that tolerates periods of asynchrony (i.e., under a semi-synchronous model) must rely on a third-party system or network that enforces the ordering of events.Hence, the authors propose the addition of a coordinator blockchain that counts commit and abort votes from the involved parties, who then extract proofs based on whether all parties voted to commit or abort the deal.Similarly, AC 3 WN [80] also proposes a third-party witness blockchain that attests to the state of an atomic swap and decides whether it must be committed or aborted.The witness blockchain contains light client implementations for the supported chains and verifies inclusion proofs on the relayed block headers.The authors assume that participants relay block headers and are always valid if they follow the source chain consensus rules, which might not happen in fork-prone chains (cf.Section IV-A).
Blockchain Engines (or Blockchains of Blockchains) rely on a relay chain that provides shared security and composability in an interconnected environment.These networks are called zones, parachains and subnets in Cosmos [60], Polkadot [61] and Avalanche [115], respectively.All these projects have a custom messaging mechanism that allows arbitrary communication between networks within the same ecosystem, standardizing cross-chain communication within each ecosystem (we still need to address inter-ecosystem interoperability).These messaging protocols have different tradeoffs regarding customization and shared security with the main chain.Cosmos uses Inter Blockchain Communication (IBC), whereas Polkadot relies on Cross-Chain Message Passing (XCMP).IBC allows finer-grained control over the customization of the different zones.Therefore, their security is dependent on the specific design and implementation.Because it was built on top of Tendermint, it only connects chains.Polkadot and XCMP do not have those constraints.Individual chains share state with the entire system, which acts as a shared security layer, and  can go directly to the destination chain, which aims at providing more scalability.Avalanche's Warp Messaging mechanism relies on a shared state of the primary chain to maintain whitelisted validator sets of each custom subnet.Topos [59] achieves a higher level of security through the proposed zkVM, where validity is delegated to the proving system, allowing the removal of trust assumptions on the validators of the blockchains for state validity.In this case, all The Topos zkVM verifies the subnets' state transitions.Computational proofs are then publicly verifiable by users in other subnets, allowing seamless interoperability between networks in the ecosystem.
2) Inclusion Proofs: The first mechanism proposed to validate transactions of  1 in  2 relied on Merkle proofs. 2 requires a light client implementation of  1 , which means that there is a way of verifying  1 's consensus mechanism within  2 [89].It also relies on external entities, the relayers, who only relay block headers from  1 to  2 , without producing any kind of proof.It is easier to verify the block headers of PoWbased chains because consensus verification only depends on the block headers assuming a trusted state initialization (i.e., either the genesis block was set manually, or any other final block) [90].On the other hand, Chains based on PoS require the current validators' keys to be available in the 2.Keys can be stored in 2 and constantly updated, or they can be submitted with every new block header [91].Knowing the cost of storage on the destination chain, transaction fees, the size of the validator set (and consequently the size of all keys), and the periodicity of each validator set election, one can design a solution that best fits their requirements and needs.Westerkamp et al. [91] calculate the cost of storing information on-chain for the Ethereum sync committee (groups of 512 randomly elected validators every ~1 day which is used to validate Ethereum consensus) as being more than 300 USD § .The authors also propose a cheaper solution which resubmits all public keys with each update, avoiding storage costs even though it increases the transaction size.Boneh-Lynn-Shacham (BLS) multi-signatures have been used in multiple protocols to generate an aggregated digital signature built to prove the consensus mechanism of the source chain on the target.
Both [51] and [91] propose light client protocols for interoperating proof of stake blockchains based on signature aggregation techniques, namely applying Boneh-Lynn-Shacham (BLS) multi-signatures.We reckon that the cost of these protocols is mainly driven by the construction of the aggregated signature of the sync committee.They have some potential liveness issues, due to requiring at least one block from each epoch (once every ~27 hours) to be submitted to the destination chain to guarantee the correct transition of validation sets.The authors do not calculate the probability of such an event.
3) Off-Chain Communication Channels: a) Hashlocks & Timelocks: Hash Time-Locked Contract (HTLC) [10], [38], a commit-reveal scheme based on hash locks and time locks, is a decentralized protocol to exchange assets.Parties agree on certain parameters off-chain and have predefined periods in which they must act to complete the protocol.The involved participants also need to observe state changes directly, i.e., without an intermediary relaying information.The security of these protocols relies on both the cryptographic primitives employed (e.g., the cryptographic hash function used for the hash locks) and on the off-chain communication channel used.
HTLCs function as follows.Assume that entities  1 and  2 want to swap asset X for asset Y, which are in  1 and  2 respectively.Entity  1 starts by generating a secret , and publishes a smart contract on  1 with hashlock ℎ(), where ℎ is a collision-resistant hash function.This smart contract contains a withdrawal function that transfers  to  2 if the solution of the hashlock is provided -i.e. if a value  in which ℎ() = ℎ().By the properties of collision-resistant hash functions,  must be the secret .Additionally, there is a duration Δ 1 (the timelock) in which the asset can be claimed by  2 , otherwise, asset  is returned to  1 .Then,  2 , verifies the deployment of the smart contract on  1 and deploys a smart contract on  2 with timelock Δ 2 and the reverse operationtransferring  to  1 if  is provided. 1 starts by redeeming  on  2 within Δ 2 , which reveals  to  2 . 2 can now use the secret to redeem  from  1 .We refer the reader to [38] for details and discussions about the strengths and limitations of HTLCs [282].
The difference between the timelocks deployed by  1 and  2 (in this case Δ 1 − Δ 2 = Δ) is key to guaranteeing the atomicity of the protocol.If Δ is too small,  2 might not have enough time to redeem  on the source chain.This timelock must account for the network communication time between parties, the finality times on both blockchains and possibly § value updated on 27th June 2023 -ETH price: 1872.15USD, Gas Price: some network delay or downtime.However, if Δ is too high and  2 abandons the protocol just after  1 locked  on the source chain,  will remain locked for Δ 1 .This is known as the Sore Loser Attack [95].
Some protocols have been proposed to solve the aforementioned issues.The majority alter the synchronous communication assumptions [80], [87], while the ones that retain that property focus on the usage of premiums [40], [95], [137].A premium is a value staked as collateral before the execution of the actual protocol.It must be a value acceptable by the victim as a possible compensation for locking up assets for the duration of the protocol.Simultaneously, it needs to be small enough so that parties engage in the swapi.e., accept the risk of losing this value.There are multiple game-theoretical analyses of HTLCs or simple variations such as [38], [40], [99], [138].In particular, [138] proves that the protocol has a higher chance of being successful (instead of being aborted) under these collateralized models or employing dynamic exchange rate adjustments.However, since premiums are deployed before the actual protocol, they are also vulnerable to Griefing Attacks (even though these are usually much smaller amounts than the initial values to swap).XCC [98] proposes the usage of timelocks in an overcollateralized model, where the escrowed assets are only transferred to the vault (bridge contract on source chain) once the corresponding assets are transferred to the target chain.This has a clear benefit of not transferring ownership of assets directly to the escrow, completely relying on correct behaviour.
b) Time-Based Cryptography: Relying on explicit time intervals is challenging when each permissionless blockchain has different time management mechanisms, usually implemented at a very coarse grain level (in the order of hours or days).Therefore, primitives such as Verifiable Timed Commitments (VTC) [139] or Verifiable Timed Signatures (VTS) [140] can mitigate the problem above.
Considering parties  1 and  2 , the VTC scheme allows a committer to compute a cryptographic commitment  of a value  and a difficulty level , and prove to the verifier that it is possible to open  either by having  (revealed by the committer), or by executing 2  sequential computation steps -i.e., if one party decides not to reveal the value behind the commitment, it can be brute forced by the victim in a predefined amount of time driven by .The difference for vanilla HTLCs is that instead of having a hashlock and a timelock, there is a more powerful hashlock which can also be opened with a certain number of computation steps.The authors of [106] propose an HTLC-based protocol, where the value committed to is a hash pre-image just like in HTLCs, which extends VTC with ZK cryptography to prove arbitrary attributes for the timed commitment.c) Signature-based Locks: On the other hand, VTS allow a committer to produce a commitment of a signature  on a value, and prove to the verifier that the  is valid and revealable in time  .[42] proposes an atomic swap protocol, extensible to multiple parties, where the sender and the recipient share ownership of smart contracts on the source and destination chain, through joint key generation algorithms.As such, parties can use TVS on previously generated signatures from jointly signed refund transactions, which allows one to abort a swap if no action is performed within  , using the brute force algorithm.This is done by learning the other party's key (or key share) and gaining full control over the escrow address.Additionally, the authors of [100] present a commit-reveal scheme for atomic swaps based on adaptor signatures.These are verifiable partial signatures, that allow the revealing of a secret once the full signature is published.We question the liveness guarantees of the protocol if one party halts participation midway.Li et al. [104], also leverage adaptor-signatures and the involved parties first share and presign revoke transactions such that one party can successfully abandon the protocol if the other halts participation.Finally, the security of Sweep-UC [105] is given by the security of a blind signature protocol between users and a third party who issues them.We also question the liveness of the solution since there is no incentive mechanism for the third party to engage in the protocol.Nevertheless, we acknowledge that these solutions pave the way for interoperability in script-minimal blockchains, with only signature verification functionality.

G. Privacy Approaches -Extended Version
1) Blind Signature Protocol: We provide an example of a suitable protocol using blind signatures.
1) The client generates a message  and applies a blind factor value, that originates  ′ .2) The client sends the blinded message  ′ to the IM, who signs it, producing a blind signature ( ′ ).
3) The IM issues a transaction to the source chain, locking 10 tokens, and sends the blinded signature ( ′ ) to the client.4) The client can unblind the signature using the blind factor previously applied to obtaining a valid signature on the original message, ().5) This signature can now be presented as proof of locking 10 tokens so that the equivalent is minted in the target chain.6) The IM must keep track of already accepted messages so that blind signatures are not used to trigger multiple transactions on the target chain.If it haa not been accepted previously, the IM triggers a transaction minting 10 tokens in the target chain.2) Homomorphic Encryption-based Protocol: We present a concrete example.[102] considers a homomorphic hash function ℎ that satisfies ℎ( 1 ) + ℎ( 2 ) = ℎ( 1 +  2 ), for any 256 bit values  1 and  2 .Alice generates secrets 1 and 2, and sends to Bob ℎ(1), ℎ (2), and  = 1 +  2 .Alice deploys a smart contract with hashlock ℎ( 1 ), which is easily verifiable by Bob, given that Bob was sent ℎ(1).In turn, Bob deploys a smart contract in the other blockchain with hashlock ℎ( 2 ).Therefore, Alice can redeem Bob's funds by presenting 2.Bob accepts this given that he can now compute  1 =  −  2 , which hash needs to match ℎ( 1 ) received initially from Alice, allowing him to redeem Alice's assets.
By deploying both smart contracts with different values, they are no longer linkable unless  is disclosed.
3) Anonymity based on Group Signatures: Much like Blind Signatures, Group Signatures (GS) also rely on a centralized party.In this scheme, users can sign messages on behalf of a group, with the centralized authority assuming the role of a group manager [144].When utilizing this system, anyone possessing the group's public key can efficiently verify and authenticate signatures confirming that they originate from a group member.However, it does not reveal who signed the message.Importantly, the group manager wields the authority to oversee group membership, enabling actions like revoking membership or disclosing a signer in case of misconduct or, for instance, for auditing purposes.This capability to revoke anonymity becomes crucial when anonymity is worked for illicit purposes.GS safeguard anonymity while ensuring accountability, which holds significance for various entities, including government bodies, bolstering their trust in the technology.This capacity to transparently revoke anonymity can enhance security and promote fairness within networks.We suggest adaptations to this protocol.One can employ a decentralized group manager, where decisions and actions are executed upon consensus among a quorum of participants, potentially leveraging a consensus mechanism for governance.
We present two possible cross-chain protocols employing GS for anonymity assurance.In the first approach, a consortium of trusted notaries anonymously sign a , resembling a Ring Signature protocol.It safeguards the operator's anonymity while also allowing for anonymity revocation in the event of suspicious activity on behalf of the operator.Alternatively, a user can sign a lock transaction on the source chain, blending in with a group of users interested in locking assets on a bridge.External entities can verify the locking of funds without uncovering the user's true identity.A trusted IM, acting as the group manager, privately executes the anonymity revocation algorithm to identify the user who locked the funds and mint tokens on the counterparty blockchain.The destination address could be passed through a confidential off-chain channel to the IM, such that only it could establish the link between transactions/addresses on both chains.If the IM deletes this link, unlinkability is guaranteed.Note that the source chain transaction's data could contain the destination address -but it would directly link those addresses.In the bestcase scenario, users could achieve cross-chain pseudonymity using this final approach.
As of now, there are no cross-chain solutions based on group signatures.We believe this trade-off between privacy and accountability is worth exploring.

H. Listing of Vulnerabilities, Attacks, and Mitigations
Here, we provide further details on each vulnerability identified.Additionally, we summarize all mitigations in Table VI-B.
Honest Mining Assumption ( 1 ).This is an inherent vulnerability present in all networks that employ probabilistic finality, regardless of whether they serve as the foundational chains or as a relay chain facilitating interoperability.In networks with probabilistic finality, the consensus is not reached immediately, therefore, there is a period when transactions are not considered final and can be reverted.A single party that controls more than the security threshold of miners or validators, can authorize invalid .Additionally, updates to the core blockchain protocol can lead to soft or hard forks when a threshold of nodes does not adopt the changes.These might lead to the full reversion of transactions, or censorship [6].In the worst-case scenario, BFT-based blockchains can completely halt under this scenario.Forks on a source chain may cause the smart contract on the destination chain to be unable to distinguish the main chain from the forks.It creates an opportunity for a Double Spending Attack, wherein an attacker can lock an asset  on the source chain and then mint  on both smart contract instances, one in each destination chain [89].This vulnerability opens the door to various other attacks, such as Sybil Attacks, 51% Attacks, or Relay Poisoning Attacks.As it is a fundamental assumption of permissionless blockchains with probabilistic finality consensus, one must always consider its implications.The literature proposes some mitigations, such as setting an appropriate security parameter based on the required number of confirmations ( 1 ) [80], [90], which makes the probability of a block being reverted become negligible [173].Also, one can insert maturity periods, i.e., time windows in which the block is not used for SPV ( 2 ) [89].To solve disputes, one can rely on blockchain views ( 3 ) [55], [283].As for a fork on the destination chain, potential solutions include explicitly specifying a destination chain where each fork would have a unique identifier ( 4 ) [175] or synchronizing smart contracts from both instances of the destination chain through other cross-chain mechanisms ( 5 ) [89].
Absence of Identity Verification ( 2 ).A selfish miner (or colluding ones) can engage in a Sybil Attack where they control various identities in a network gaining more power than what is perceived, and thus increasing the level of centralization.For instance, invalid  are accepted by the target chain just because a threshold of the network of validators is controlled by the same entity.Similarly, the absence of identity verification mechanisms also paves the way for Collusion Attacks, where apparent unrelated nodes collude to harm a bridge.Previous work showed that this vulnerability is impossible to mitigate without a centralized authority [284].Hence, the first approach is a trusted authority that performs identity verification on the participants ( 8 ) [96].Other decentralized solutions require identity verification/mapping mechanisms using, for example, Self-Sovereign Identity ( 9 ) [178] or making the creation of new identities expensive ( 10 ).The latter is done usually through staking a high amount of funds when joining a network which is slashed in case of misbehavior [37], [88], [89].The overall goal is to make the barrier to conduct such an attack higher than the potential profit.Single identities with higher stakes must be prioritized over splitting the stake between multiple identities, just like in PoS networks ( 11 ).Note that a balance needs to be struck between these mechanisms and the adoption of a system because it might introduce a barrier to new users that do not want to stake so much funds [88].Even though these mechanisms do not protect against Sybil Attacks performed by non-rational parties, performing this attack in networks with slashing mechanisms is very expensive and, therefore, unlikely.
Network Isolation ( 3 ).In smaller networks, relayers can be intentionally isolated from the rest of the network during a period and misled to accept the attacker's chain as the longest [92].These are called Eclipse Attacks.Actions according to this state are then issued against the target chain, violating the system's integrity.It is also present in centralized systems where an attacker with physical server access can interfere with its normal behaviour.Packets can be intercepted or dropped causing transactions to not settle in some networks [79], [89].Additionally, some optimistic-based solutions [50] guarantee safety through challenges within predetermined time windows.If the attacker submits invalid block headers and isolates watchers for this duration, the target chain will eventually accept submitted block headers.The key to ensuring integrity is choosing an appropriate time window with an increased settlement time ( 6 ), usually in the order of days or weeks.This introduces a tradeoff with usability.Additionally, to guarantee the liveness of the system, one can opt for the physical decentralization of infrastructure ( 7 ).
Outdated Light Client State ( 4 ).If source chain block headers are not relayed to the target chain, a light client may fall out of date, which can be due to an Eclipse Attack or the high costs of relaying information [89].[68] calls Liveness Attacks to the ones where messages can be delayed.However, this compromises liveness of an interoperability solution and can cause unavailability or inaccurate transaction validation on the destination chain.Long-term solutions might encompass the usage of projects directed towards solving data availability problems, such as Celestia [171], which provides a modular approach to providing data that could be used for interoperability purposes ( 16 ).
Wrong Main Chain Identification ( 5 ).In a Relay Poisoning Attack, relayers can submit conflicting block headers to the target chain smart contract in an attempt to perform a chain reorganization in the source chain light client [6], [89], [92].The problem surges when relayers submit valid source chain block headers (in terms of consensus rules) but with invalid transactions to the target chain which is tricked into accepting these blocks.If the hash rate of the submitting party is higher than the source chain's, the receiving smart contract has no way to distinguish which one is the real main chain, i.e., light client mechanisms must have ways to cope with 51% Attacks, and Long Range Attacks on the source chain.However, if this is not the case, then it is possible to employ main chain identification mechanisms based on the consensus mechanism of the source chain ( 18 ) -e.g., based on block difficulty in PoW or the number of block attestations in PoS.Note that the networks' consensus mechanisms are crucial here.Light clients of chains with instant finality will not suffer from this vulnerability or source chain forks [91].
Incorrect Event Verification ( 6 ).As stated in Section II-C, interoperability is driven by events emitted on both blockchains.In particular, in cross-chain bridges, the interoperability mechanism captures events emitted on the source chain and performs corresponding state changes on the destination chain.Correctly monitoring smart contracts and identifying events on the source chain is critical.Otherwise, one might be issuing transactions on the target chain without a corresponding event on the source chain, or the other way around [172].The underlying causes range from the incorrect recognition of events emitted by malicious contracts [32], [173] or accepting events from tokens with similar names [174].This vulnerability might originate Event Forgery Attacks.Solutions should listen to events from only whitelisted smart contracts ( 12 ) [173], runtime monitoring modules ( 13 ) [32], [174], or employing Distributed Signing Schemes where each party uses different monitoring strategies ( 14 ) [82].
Acceptance of Invalid Consensus Proofs ( 7 ).Malicious actors may attempt to construct invalid blocks, not adhering to the consensus rules, or include illegitimate transactions within valid blocks [130].To address this, secure and upto-date light client mechanisms promptly discard such block headers by verifying their consensus properties [89].In Proofof-Work (PoW) based clients, the block hash, current difficulty and difficulty adjustment policies are usually sufficient to detect these vulnerabilities.On the other hand, Proof-of-Stake (PoS) based light clients must keep track of epochs and sync committee information.Alternatively, in light clients of other consensus mechanisms, particularly where consensus participants are known a priori, corresponding keys must be updated in the smart contract ( 15 ).

Absence of Chain Identification ( 8
). Cross-chain bridges built for Data Transfers, i.e., that allow arbitrary message passing, may enable interoperability between multiple chains [175].One user might try to submit the same proof to multiple destination chains, to mint multiple representations of the locked token.Messages and proofs should maintain the source and destination chains' identifiers, to avoid integrity breaches in the form of Replay Attacks, or the submission of inclusion proofs from different and invalid contexts ( 4 ).

Submission of Repeated Inclusion Proofs ( 9
). Attackers might try to repeatedly submit the same inclusion proof over and over again to try to prove a statement more than once [75], [89], [92], [130], [176] -i.e., a Replay Attack.For instance, after locking an asset  on the source chain, the attacker might present the corresponding Merkle proof multiple times to mint multiple representations of  on the destination chain.The same might happen the other way around when a user submits a Burn proof multiple times on the source chain to drain the escrow contract on the source chain (e.g., pNetwork hack in Table J).Bridge Sapling [92] solves this issue using a unique nonce generated in the locking phase when creating the zeroknowledge note commitment ( 17 ).However, the solution is still vulnerable to collusion between the user and the relayer.The user can reuse the same input to the commitment note generator function ( 41 ).XClaim [89] proposes the introduc-tion of unique identifiers for each lock and mint transactions, synchronized between the target chain and the block headers submitted to the source chain light client.Rollups face the same challenge.Multiple transactions may be triggered on the L1, with only one withdrawal transaction initiated on the L2.As an example, this vulnerability was reported in the Polygon bridge in 2023 [248].
Counterfeiting Assets ( 10 ).To guarantee safety, creating new assets on a destination chain through a cross-chain bridge must always be tied to events on the source chain.Failing to do so may lead to minting assets out of thin air [89], [92].In a nutshell, the value of the assets in escrow on the source chain must not be lower than the value of all assets minted on the destination chain.A possible first mitigation strategy is having automatic liquidations of collateral once the risk factor decreases below a certain threshold ( 19 ) [92], similar to DeFi lending protocols.Additionally, the protocol may employ mandatory staking making the misbehaving parties get slashed, yielding negative utility for those entities ( 20 ) [89].These solutions should be enforced by the overall protocol architecture -i.e., guarantee atomicity by design.It can be either enforced by decentralized watchers ( 21 ) [50], [135], centralized systems ( 8 ) [37], [72], [176], third-party networks with custom rules built-in to the consensus mechanism( 22 ) [179], or cryptographic primitives set up jointly between users and operators ( 23 ) [73], [98], [103], [105].This vulnerability can also be inserted through a buggy smart contract implementation.In April 2022, Aurora Labs received a white hat bug report that could have minted more than $200M in unbacked assets through misuse of the DelegateCall solidity function due to preserving the original context of the caller [177].
Involuntary Timelock Expiry ( 11 ).Due to the synchronous nature of some cross-chain protocols, if parties crash during a period may incur financial losses [38].In HTLCs, if one party crashes and cannot provide the secret to the hashlock function until the timelock expires, the assets are returned to the other party.[80] relaxes the synchrony assumption using a witness network that maintains the state of the atomic swap, which is resilient to crashes from any party ( 29 ).More work needs to be done to find a middle ground needs to be found between this and the last vulnerability, i.e., the chosen timelock should allow parties to redeem their assets within the specified period without being exposed to  13 ( 30 ).
Unset Withdrawal Limits ( 12 ).Cross-chain bridges, especially ones that rely on lock-mint patterns, maintain assets in escrow in the source chain.The sum of all these assets reaches billions of USD for most used bridges, which is naturally a honeypot for attackers.As we have been showcasing throughout this work, a simple bug in the business logic implemented in smart contracts can allow attackers to completely drain a bridge.Setting withdrawal limits for appropriate time windows is critical.These limits are tailored to specific bridges depending on the usual asset flow (e.g., hourly or daily) [175], [198].Transactions get reverted, and bridge operators are warned and stop the bridge upon reaching a predefined threshold.Even though it is impossible to mitigate an attack with this measure, it is possible to maintain the eventual loss of funds limited to the defined value using withdrawal limits based on the usual flow of the bridge ( 69 ).
Action Withhold / User starvation ( 13 ).An attacker may intentionally abort a protocol execution, withhold an action to harm other parties or increase the possibility of profitability.For instance, when engaging in an asset exchange protocol using HTLCs,  2 might refuse to lock funds after  1 locked funds causing  1 's funds to be locked for the duration of the timelock.Additionally, both the initial and the refund transactions consume gas fees.Hence, in case of a revert, the victim still loses funds.These kinds of vulnerabilities are seen in Griefing or Sore Loser Attacks [40], [95], [199].It can happen if the economic conditions (e.g., exchange rates) are suddenly not favourable to the attacker; or to mount a DoS attack on the counterparty [40].The usual mitigation is the usage of premiums (cf.Section F3a) ( 27 ) [40], [95].
Reference [106] proposes an adaption to HTLCs using Attribute Verifiable Timed Commitments where all parties can immediately abort a swap without waiting for the predefined timeouts ( 29 ).Other mitigations are either using a trusted party to mediate the cross-chain swap ( 8 ) [78] or an untrusted third party that engages in distributed signature scheme protocols ( 23 ).

Unspecified Gas Limit ( 14 ).
A vulnerability [190] was found in Arbitrum.When withdrawing funds from the L2, the bridge contract on the L1 did not have the gas limit for the transaction set, and the user was not forced to set one and the contract on the L1 did ( 65 ).Additionally, the transaction was marked as retryable -i.e., the relayer in charge would retry the transaction as many times as needed until running out of funds.This vulnerability can provoke DoS, Eclipse, or Fund Draining Attacks on bridge operators.
Resource Exhaustion ( 15 ).Instead of inducing abnormal behaviour in the system, attackers may focus on disrupting the availability of a cross-chain solution.Centralized solutions are easily susceptible to Denial-of-Service (DoS) attacks.On the other hand, attackers might target single components in distributed networks.However, as the system becomes more decentralized, compromising the liveness of the entire bridge becomes increasingly challenging.We assess the vulnerability level based on whether a single component crash can compromise the correct functioning of the system.Additionally, we have already covered Griefing or Sore Loser Attack, where a user may be constantly starting a new swap without terminating the last one, leaving the other party with funds locked for the timelock duration.These are actually performing a DoS on the counterparty.
We go over some mitigations.Firstly, the protocol design should account for the possibility of DoS through the decentralization of components ( 32 ) -e.g., leveraging a network of multiple relayers instead of only a couple of entities.Industry protocols such as CCIP, Axelar, and Wormhole follow this approach.Secondly, one must harden systems against DoS attacks employing rate-limiting strategies or, if applicable, challenge-response tests ( 50 ).Ultimately, components that are suitable for on-chain design and implementation (as contracts) should be developed as such, such that executing a Denial-of-Service (DoS) attack on that component necessitates a DoS attack on the entire network ( 49 ) [89].
Single Point of Failure ( 16 ).Single points of failure can be analysed in multiple dimensions.Firstly, at the infrastructure level, a protocol centralized on a single machine is subject to failures and might compromise the liveness of the solution.Additionally, there might be a single point of failure from an architectural perspective, where one application crashes if one entity (that might control several pieces of physical infrastructure) is compromised.Centralized relayers [79] or operators [203] are vulnerable.The most common mitigation is decentralization both physically ( 7 ), architecturally ( 32 ) and operationally ( 47 ).By relying on a decentralized network, denying service to one component requires denying service to all replicas of that component [79], [89].
Publicly Identifiable Operators ( 17 ).Solutions where operators are public and identifiable are vulnerable to multiple attack vectors -Bribery, Collusion, DoS, and Phishing are some examples.These can compromise both the safety and liveness of a cross-chain bridge.Bool Network [43] puts a step forward by introducing an interoperability mechanism composed by an evolving committee that changes every epoch ( 44 ).Each member is also hidden among a ring based on a Ring VRF, making linking one member to a digital signature impossible ( 45 ).It not only protects the privacy of operators, as well as their security given that these mechanisms act as a barrier for attackers.Moreover, the usual cybersecurity practices applied in web2 should also be followed ( 46 ).

Misaligned Incentive Mechanisms ( 18
). Incentivization is paramount in decentralized systems.In the BAR behaviour model [200], Rational players follow strategies that maximize their profits -i.e., they might choose to deviate from the protocol rather than following the rules due to the more attractive economic incentives.Collusion and Bribery Attacks are some examples of attacks.
In Asset or Data Transfers, centralized components such as TEEs [77], or decentralized relayers can collude, for example, to inject forged Merkle Tree Roots into the destination chain [82].Additionally, one can intercept and drop packets from other relayers.In this latter case, instead of adding invalid transactions to new blocks, relayers can submit only a subset of updates to induce an inconsistent state in the target chain.In optimistic fraud-proof-based solutions, watchers can collude and not dispute any illegal headers for the duration of the time window [50].
In Bribery Attacks [201], the briber and bribee can profit from withholding the announcement of new blocks until the briber successfully mines and announces the new block to a network.If the number of relayers is small enough, an attacker can bribe them to relay block headers which allows the attacker to double spend funds.This idea is similar to censorship attacks, where miners are incentivized to ignore transactions from certain addresses [202].
There are multiple mitigation strategies proposed in academia.Firstly, there is a need to study the best way to align incentive mechanisms to make these attacks less probable and less profitable.Some examples leverage gametheory principles applied to asset exchanges [138] or asset transfers [77] ( 31 ).For more centralized solutions, where collusion can happen between fewer parties, but usually each has more power, decentralization is an option ( 32 ) [182], introducing more and different parties to make the attack more expensive ( 33 ) -as the number of participants increases, a higher number also needs to be convinced to follow the attack [50].We add that the mining power needs to be distributed accordingly to that growth.On the other hand, employing regulatory authorities that ensure parties are accountable for their actions might be a solution ( 8 ) [69].Another area of research has been the exchange of assets co-owned by multiple parties, which are vulnerable to collusion [103].Some protocols engage in distributed signature schemes between users and operators ( 23 ).MAD-HTLC [99] presents an interesting solution.It shows how to secure HTLCs using MEV ( 34 ).By choosing which transactions go into which blocks, miners can accept transactions that yield more profit than the "normal" transaction selection process.The protocol ensures that if one party misbehaves, both lose their assets (the mutually assured destruction principle).The main limitation of this work is assuming all blockchain miners are rational and always follow the most profitable path, which might not be totally realistic.
We believe more research on the analysis of the strategy followed by rational players who maximize profit in cross-chain is needed, which must guarantee strong Nash equilibrium [39].
Token Price Volatility ( 19 ).Cryptocurrency-based bridges (AE, AT) also suffer from the high volatility in token prices which can lead to unfair trades [43], [92].Decentralized Finance protocols inherit this vulnerability, which cannot be entirely eliminated.In HTLCs, if a sudden cryptocurrency devaluation occurs, one party might cease participation midway because the initial conditions that were agreed upon are no longer valid [95].Lilac [97] proposes each party to lock assets in parallel which reduces the duration of the swap ( 35 ) and consequently reduces the time window for users to observe price fluctuations ( 36 ).However, it is still vulnerable to Collusion and Sore Loser Attacks.
For bridge-based protocols, we find that the security of a bridge is highly dependent on the valuation of the assets in escrow, which, if not secured, can cause the issuance of unbacked tokens, or trigger massive liquidations [92].Consider an asset  that is used as collateral to mint an asset  on the destination chain.If suddenly  loses valuation, then  might become uncollateralized -i.e., the new value of  does not cover the value of  .XClaim [89] proposes three solutions: 1) over-collateralization to account for some slippage ( 37 ), 2) enable the adjustment of the amount locked according to the updated exchange rates ( 38 ), or 3) introduce automatic liquidations so that it becomes impossible to have the locking party getting uncollateralized ( 39 ).XCC [98] points out that over-collateralization is not scalable and not attractive to vaults.Therefore, the assets are in a timelock jointly controlled by the user and the vault, and these funds are only transferred to the vault in some checkpoint periods when the commitment needs to be renewed.
Multi-chain networks can also suffer from this vulnerability.Platforms, where the token that guarantees economic security is endogenous to the network, might see their economic security decrease because of a sudden devaluation [124].
Centralized Power ( 20 ).Centralization must be evaluated across different layers.Protocols can rely on centralized infrastructure [79] or on distributed infrastructure but are still mainly controlled by a single entity [203].As an example, protocols might have a decentralized architecture but rely on centralized governance procedures [179] or centralized computation conducted by L2 bridge operators [65], [204].Possible consequences are liveness compromise, transaction censorship or transaction reordering.The first problem we identify is liveness compromise.If a centralized system crashes or halts temporarily, the whole protocol will stall for the same duration.Even though this might be irrelevant for some protocols, it is crucial for time-sensitive ones that rely on performing actions within a certain amount of time [202].The most straightforward solution in these cases is decentralization ( 32 ) [48], [182].Moreover, protocols can be the target of Censorship Attacks.In such attacks, the miners of one blockchain may not insert a transaction in a block [36], rollup operators may exclude L2 transactions from batches submitted to the L1 [108], [203], or relayers choose to drop  instead of forwarding them to the target chain [82].From the BAR classification of actors, the motivation to engage in such an attack may vary.On the one hand, the attacker might want to harm the system by censoring at their own will, behaving as Byzantine.On the other end of the spectrum, attackers might be rational and choose a path that yields external gains, such as leveraging (cross-chain) MEV opportunities.Nevertheless, the ability to censor might also have some benefits.Blacklisting functionalities are censorship actions that protect the protocol against pre-known users/contracts associated with some form of illegal activity (e.g., having used the US-sanctioned protocol Tornado Cash).Instead of relying on centralized architectures, protocols can have defined governance procedures to implement these changes.However, we acknowledge that there have also been several governance attacks [206], [285]- [287].In rollups, usually, there is always a way to bypass censorship performed by sequencers, by issuing transactions directly to the Layer-1 contract [180] as done in StarkEx and ZkSynci.e., multiple components have overlapping capabilities ( 43 ).
Verifier's Dilemma ( 21 ).The Verifier's Dilemma, initially proposed by [205], shows that rational blockchain miners benefit from skipping the verification of blocks to gain an advantage in proposing subsequent blocks.The probability of such behaviour increases when blocks contain computationally expensive transactions.We acknowledge that cross-chain solutions based on third-party networks also suffer from this vulnerability, where a  might not be fully validated.A possible solution is parallelizing the verification of non-conflicting transactions within the same block to decrease verification time ( 24 ), or dividing computational-heavy transactions into multiple blocks ( 25 ).However, it is not clear how to guarantee atomicity under the latter scheme.Alternatively, one can assign entities with different responsibilities, separating the verification from the computation logic ( 26 ) [181].

Manipulation of Exchange Rates ( 22
). Token prices from external sources are written into blockchains by oracles.Oracles can be manipulated to send an erroneous price feed [206]- [209].Bridges can therefore use the wrong exchange rates leading to unfair or unrealistic trades.In the worst-case scenario, a protocol may fail to maintain proper collateralization of the assets issued.Furthermore, similarly to  19 , during the lock period in HTLCs, one party might either manipulate oracle data or influence the market by valuing or devaluing a token after the first party locked assets.We call these Exchange Rate Poisoning Attacks.In April 2023, Allbridge [288] suffered a ~500k USD hack after a liquidity pool's swap price manipulation [22].Miners who exploit MEV opportunities can also front-run transactions to profit from these (de)valuations.The usual mitigation to address oracle manipulation is to base transactions on multiple sources of data, not single oracles, nor controlled by the same entity ( 40 ) [182].Multiple works have studied the consequences and mitigations for the fluctuations caused by MEV ( 41 ).Some examples are confidential transactions [184], or employing confidential mempools [183].We refer the reader to [204], [206], [289]- [295], for more information on MEV.Liquidity pool-based bridges can also suffer from manipulation of swap prices.
Unfair Transaction/Event Ordering ( 23 ).Transaction ordering techniques enforced by blockchain miners through MEV are also found in a cross-chain scenario [82].Similarly to the unfair ordering in the miners' mempool, the interoperability mechanisms that relay block headers, events, or any other type of proofs between blockchains, can also be subject to custom order based on the maximum extractable profit.Just like blockchain miners, consider a decentralized network of relayers that relay , where the default ordering strategy is based on the received fees.If relayers are incentivized to choose one  over another some fairness issues arise.The same happens in protocols based on synchronous communication between parties (e.g., HTLCs), that might have their transactions stalled, and, in the worst-case scenario, enter a block after the defined timeout.The most straightforward solutions are guaranteeing the confidentiality of , in a way an adversary cannot peek at other users' transactions ( 41 ), or enforcing a predefined transaction ordering policy ( 42 ) [82], [184].

Lack of Access Control ( 24
).With the rapid evolution of decentralized applications' development, the complexity of such apps has increased exponentially.Inherently, components responsible for managing locked funds or creating new assets become prime targets for hackers.Consequently, it is crucial to enforce robust access control policies to manage access to these contracts effectively.Unauthorized access to critical smart contracts causing the transfer of tokens to attacker-controlled addresses or whitelisting an attackercontrolled address as valid escrows have been the cause of cross-chain hacks (cf.Section VI-C).Some examples are Qubit, Meter, Thorchain, Nomad, Poly, and BNB, where the attackers could replace whitelisted relayers' keys and execute smart contracts with arbitrary business logic [191], [210]- [214].We present two mitigations.Firstly, contracts should go through multiple iterations of audits before being deployed on a chain ( 51 ).Also, considering the requirement for continuous code upgrades, one must plan and perform a coherent lifecycle of audits.Ultimately, we reckon that the recurrence of similar attacks is primarily attributable to the absence of a standardized architecture and design pattern for developers to construct cross-chain bridges while ensuring robust access control ( 52 ).For now, the bridge design remains an ad-hoc approach, with each bridge operating on a distinct architecture, making it susceptible to errors and hindering technological advancement.
Conceed Approvals to Third Parties ( 25 ).The usage of functions such as approve(), permit() and transferFrom() available in some token standards such as ERC20, open the door to novel attacks [173].The baDAPProve problem, found in the Multichain bridge hack [186], refers to the users permitting the bridge contract to spend tokens on their behalf, which allows them to save gas fees.The main problem surged when the bridge contract was compromised, causing the attacker to drain funds directly from user accounts.The evident mitigation is not issuing approvals for more funds than what is strictly necessary ( 53 ).
Outdated third-party library version ( 26 ).Vulnerability X warns against automatic library upgrades to prevent unintended code behaviour.However, infrequent updates may leave security patches unapplied [192].We emphasize the importance of reviewing packages and making sure they were subject to recent audits ( 78 ).
Unsafe Third Party Modules ( 27 ).As usual in software development, code relies on third-party modules or libraries.These libraries can insert vulnerabilities into the codebase, which may weaken the source code [172], [175], [188], [194].For example, the BNB bridge was hacked due to a bug in the digital signature verification method outsourced to a vulnerable third-party module [214].Ensuring third-party libraries are bug-free is critical, therefore, check how long ago that code was reviewed by a specialized team.All audit reports reviewed assume that external libraries are correct, which seems acceptable due to the limited scope one has.However, teams should review previous audit reports performed by other companies ( 78 ).Another usual mitigation is the absence of library version auto-upgrades ( 58 ), which might unwillingly introduce breaking changes in the code.
Dead Code ( 28 ).Codebases are consistently being updated and upgraded as knowledge evolves.A noteworthy vulnerability behind, at least, the Qubit and Multichain hack, is the presence of dead code within the deployed smart contracts which allowed attackers to execute malicious operations (cf.Table J).IDEs usually have linting tools embedded that allow for identifying unused functions and raising warnings to users ( 59 ).
Usage of non-standard/conventional naming ( 29 ).Different programming languages use specific naming conventions for the names of variables, functions [193], or the usage of curly brackets.The developer should be aware of the best practices to code in the respective languages and follow them flawlessly to help developers, clients, and auditors ( 79 ).
Inconsistent smart contract engine version ( 30 ).Multiple audits have found that, within the same project, smart contracts are using different versions of smart contract engines [175], [188], [193].Versions differ in their functionalities.Therefore, to maintain the codebase coherent, applying the same version across different files is advisable to avoid incompatibilities and maintain standardization ( 80 ).
Unconventional code/testing architecture ( 31 ).Unconventional architectures at the protocol and implementation levels present a challenge to building secure and scalable bridges.At the implementation level, it is difficult for auditors to evaluate the codebase and for practitioners to understand the different components' locations.Additionally, test-wise, having uncommon test structures or architectures makes it harder to understand the testing methods and the functionality under evaluation [192], [194].Even though static analysis tools can perform code coverage analysis, understandability is the most crucial factor for a robust codebase ( 81 ).
Reentrancy ( 32 ).Reentrancy Attacks are very common in smart contracts (still happening in 2023 [239]).The overall idea is that a smart contract calls an untrusted contract, and the latter recursively calls the initial one to manipulate its internal state.This vulnerability was found in one reviewed audit [175].The most common mitigation for this vulnerability is to update the internal state of a contract before making an external call to another contract ( 82 ).
No emission of events upon critical state changes ( 33 ).Cross-chain systems revolve around events.Off-chain mechanisms listen for events that indicate state changes and sometimes forward them to other chains.Not emitting events upon state changes can have serious consequences [172], [197].Firstly, it might jeopardize the integrity of the bridge.Secondly, off-chain monitoring mechanisms cannot understand what is happening within the smart contract.Finally, it hardens the job of debugging and auditing the code by third parties.Worse than not emitting events is emitting events with wrong data [188], which may cause an attacker to drain the bridge.The emission of events is crucial and should be assured to guarantee the integrity of the bridge ( 83 ).
Inconsistent bridge contract interfaces ( 34 ).Bridges are composed of multiple components that must communicate with one another through standardized interfaces [195].Not guaranteeing consistent bridge contract interfaces may cause an indefinite loss of funds, such that messages sent by one party are not understood by the other.We emphasize the need for standardizing code architectures, such that the same code package is shared between multiple components instead of duplicating code ( 84 ).

Out of order transaction execution ( 35
).An auditability to Arbitrum's code has found a vulnerability where an attacker can exploit the absence of an ordering mechanism to deny a user access to its assets [172].The vulnerability exploits the way retryable tickets are implemented in the bridge.Mechanisms that guarantee the atomicity and transaction ordering from the L1 to the L2 are still to be implemented ( 85 ).
Absence of storage gaps for upgradeable smart contracts ( 36 ).A recent recommendation for the development of upgradeable smart contracts is the addition of storage gaps to allow for additional storage variables in the future ( 86 ).The main advantage of using this pattern is to allow for inserting new state variables in the future without compromising the storage compatibility with existing deployments [216].
Integer overflow and underflow ( 37 ).Attempting to store values higher or lower than the largest and least value supported by a data type incurs an overflow or underflow, respectively.This vulnerability might allow an attacker to drain a bridge by convincing the bridge that the value is within the expected range when it is not.Static analysis tools suffice to mitigate this vulnerability ( 87 ).
Absence of Sanity Checks ( 38 ).Throughout the codebase, there must be checks to ensure the bridge functions as intended, safeguarding its integrity.This encompasses validating inputs (e.g., make sure an address is either an EOA address or an authorized contract address with a predetermined function [172], [175], [198]), function return types [188], operations for arithmetic errors [192], ensuring there are no operations on null addresses [172], [194], [198], inconsistent data type conversions [188], [194], and the size of the payload being transferred in the bridge [192].There may also be application-specific checks to guarantee that addresses provided as input are not part of critical infrastructure -e.g., an attacker might provide an infrastructure contract as input to attempt an attack -or make sure that there is no possibility of having the same validator registered in the bridge contract twice [193].Multiple static analysis and runtime analysis tools might help mitigate and lower the incidents related to these vulnerabilities ( 87 ).
Mismatch between code and comments/documentation ( 39 ).Several audits have revealed occasional inconsistencies between the code and its accompanying comments [175], [193], [197] or documentation [188], [192]- [194].We acknowledge the possibility of human error during the implementation phase.However, such discrepancies should be diligently prevented, as they can mislead both developers and auditors.Solutions range from running checks once pull requests are about to be accepted to the usage of AI tools to detect inconsistencies ( 88 ).
Uninitialized variables ( 40 ).In September 2022, a white hat found a massive vulnerability in the Arbitrum bridge [217].When analysing the source code, the hacker noticed that there was an address variable uninitialized, which was purposely wiped after initialization (through an upgrade function) to save gas fees.Any user could call the initialize() function passing a controlled address, which would serve as the new escrow contract.To mitigate these exploits based on this vulnerability, we should take security as paramount, and optimizations as the next step ( 66 ).We believe the industry is not at that stage yet.A similar vulnerability was found in the Wormhole bridge contract with an uninitialized proxy [296].The white hackers received 500k and 10M USD respectively for reporting these bugs through bug bounty programs.
Leakage of ZK private inputs ( 41 ).As introduced in Section IV-D3b, the CRS used to create and verify ZK proofs is computed using private inputs provided to an MPC scheme.The leakage of these inputs can lead to an adversary being able to forge proofs and generate cross-chain state transitions that violate the defined cross-chain rules.This vulnerability has not been observed in a hack.However, it is crucial to guarantee integrity in ZK-based bridges.Once used, private inputs must be immediately disposed of ( 67 ) [44].
Other Smart Contract Vulnerabilities ( 42 ).We do not explore all smart contract-related vulnerabilities due to their extension.Rather, we point the reader to an extensive work surveying vulnerabilities in this context [187].Nonetheless, we present some bridge-related vulnerabilities found.These range from signature verification bypass in the Wormhole hack [193], incorrect usage of modifiers [172], [188], unauthorized smart contract calls in the first PolyBridge hack [191] and wrong function visibilities [188].Another significant concern is the existence of non-reverting fallback functions.These functions are invoked when a contract receives a function call that does not correspond to any defined function.The absence of proper revert statements in these fallback functions allows invalid transactions to succeed, resulting in inconsistent state changes.We refer to all smart contract vulnerabilities' mitigations as  54 [187].We outline three mitigations, namely conducting thorough code reviews ( 55 ), implementing rigorous testing ( 56 ), and regularly conducting security audits ( 51 ).
Inadequate Key Management ( 43 ).The compromise of cryptographic keys is one of the main sources of hacks in cross-chain bridges [110], [173].Even worse than compromising a single key, is compromising multiple keys, which can cause multi-signature account hijacking [82].In the Ronin bridge hack, an entity with access to several keys was compromised, allowing the attackers to control the system.In the Harmony Bridge hack, the attacker exploited two keys in a 2 out of 5 multi-sig.In Anyswap's hack in 2021, there were two signatures generated using the same random value for the ECDSA signature generation algorithm, which allowed retrieving the underlying private key, due to a primitive implementation.RFC 6979 [297] already presented a solution to this problem.The BXH hack happened because the attacker accessed the administrator's private key through a phishing attack.In July 2023, the Poly Network was hacked for the second time due to a 3 out of 4 multi-signature compromise (not represented in Table VI-C).Projects need to improve key management strategies, for example, with the usage of hardware wallets ( 60 ) [189].Other mitigations are the increase of the number of validators and thresholds in multi-signature wallets ( 61 ), and decentralization ( 47 ), where one entity should not have access to multiple cryptographic keys.Additionally, keys can be protected with additional authentication procedures, be it symmetric keys, or passwords ( 62 ) [65].
Physical Infrastructure Backdoors ( 44 ).Infrastructure backdoors create numerous potential attack vectors.However, assessing the extent of harm to the system proves challenging, as it relies on the level of control the compromised component wields over the system, primarily influenced by factors such as decentralization and deployment methods (e.g., on-premises or cloud infrastructure).Nevertheless, remote blockchain nodes can be reachable by RPC or HTTP ports which can be used to transmit malicious transactions or perform DDoS attacks [65].Firewalls should be set up to only accept connections from identified IP addresses ( 63 ), or the use of symmetric keys to authenticate requests ( 64 ) [65].Usual mitigations for infrastructure backdoors should also be applied here ( 46 ).
Social Engineering-related Vulnerabilities ( 45 ).Attacks such as Phishing or Ransomware Attacks can be performed through social engineering practices, usually in social media or untrusted websites.Vulnerable files or hyperlinks with attractive messages are disseminated through these platforms or email [215].Such attacks have targeted cross-chain solutions multiple times, the last being in March 2023 [185].The usual mitigations for this type of vulnerability are applied here, more related to increasing the awareness of actors for these attacks ( 77 ).

I. Privacy Leaks of Interoperable Systems and its Mitigations
In this section, we provide insights on the main privacy leaks of interoperability systems and how to mitigate them.
Zero-Knowledge-based IMs.In systems using zeroknowledge proofs for interoperability, there may be a trusted ceremony (for some proof systems like Groth16 [298]).In those, a common reference string is shared to create the proving and verification keys.Depending on the input information, one could potentially reveal confidential information about the participants or the transactions being conducted, violating privacy guarantees.For example, a user provides their address or private key as input to the ceremony.A mitigation includes providing a secure random string as input to the trusted ceremony, such as a UUID v4.
Inference Attacks.Zclaim [92] mentions the possibility of parties inferencing the identity of users through the amounts in lock and release transactions in which they are involved.Proposed mitigations are using a splitting strategy [92], where the amounts to be bridged are split into several transactions, and using ZK proofs [156] to prove there is a correct transaction without disclosing the specific transaction.Other work [76] proposes a virtual address generator function () so that the real sender address is not disclosed outside the blockchain.However, these simple mitigations can be countered by employing relatively simple heuristics (for example aggregating information about certain user transactions, namely the destination address and amounts).
Common Secret Deployment.In HTLCs, the hash of the secret generated by Alice is published both in the source chain and in the target, by Alice and Bob respectively.Therefore, local transactions in different blockchains can be linked together as belonging to the same , which breaks unlinkability.[100] presents a novel protocol for atomic swaps by utilizing the Diffie-Hellman key exchange (an open source implementation available here [282]).The protocol aims to establish a shared key without publishing it on the blockchains.In addition to this key exchange, the authors propose an algorithm that employs Adaptor Signatures.Similarly, Cai et al. [101] use Parllier homomorphic encryption, leveraging its additive homomorphism property.The protocol involves establishing a shared secret through off-chain agreement and performing computations on this shared secret.One of the main advantages of solutions based on Timed Commitments or Timed Signatures covered in Section IV-D4 is that no timelock is deployed on-chain, which preserves the fungibility of transactions [42] -i.e., it is not possible to distinguish transactions from an atomic swap protocol and normal intra-blockchain transactions, which helps to guarantee  unlinkability.
Internal Privacy Leaks.Privacy leaks may be voluntary or involuntary, and those include revealing, for example, mappings between addresses and real-world identities (which the majority of regulated cryptocurrency exchanges have); mappings between two related on-chain accounts [156], or simply operational information (for example, one can map the provided Endpoint contracts with the LayerZero operator [299].This mapping allows discovering what is the revenue by addresses probably controlled by LayerZero).
User-Generated Privacy Leak.In multiple situations, users leverage insecure practices in privacy-preserving applications or platforms, such as mixing services (e.g., Tornado Cash) or privacy-preserving blockchains (e.g., Monero).It has been shown by multiple previous works that the privacy level offered by these solutions can be jeopardized by multiple factors [141]- [145].

J. Real World Cross-Chain Bridge Hacks
We provide further details on past cross-chain bridge hacks.

3 2 1 Fig. 4 .
Fig. 4. The underlying chain's security influences the security of the interoperability solution.Additionally, there must be effective fork resolution mechanisms to cope with less secure source chains.

Fig. 6 .
Fig. 6.Distribution of classified studies by year.Around 75% of the resources classified in this paper are from 2021 onwards, which highlights the relevance and timeliness of this work.

Fig. 7 .
Fig. 7. Mapping between cross-chain vulnerabilities, attacks and corresponding mitigations.For each vulnerability, we highlight in grey the location where the vulnerability can be found (Chains -Underlying Chains; SC -Source Chain Smart Contract; TC -Target Chain Smart Contract; IM -Interoperability Mechanism)

TABLE I TWO
TIER CLASSIFICATION OF SECURITY APPROACHES IN BLOCKCHAIN INTEROPERABILITY ACADEMIC STUDIES Definition 6 (Cross-Chain Pseudonymity).Pseudonymity of  holds when  cannot be linked to transactions  1 , ...,   it has produced in both ledgers, however, any   and   , ∀,  ∈ [1, ] can be linked to one another.Definition 7 (Cross-Chain Anonymity).The full anonymity of  holds when  cannot be linked to transactions  1 , ...,   it has produced in both ledgers and   and   , ∀,  ∈ [1, ] are cross-chain unlinkable.
TABLE SUMMARIZE THE CLASSIFICATION.WE PRESENT A VISUAL REPRESENTATION OF 1) THE NUMBER OF STUDIES ADDRESSING EACH METRIC AND 2) THE NUMBER OF STUDIES CLASSIFIED USING • OR ✓.

TABLE IV LIST
OF MITIGATIONS COLLECTED IN THE LITERATURE AND PROPOSED BY OUR ANALYSIS (MARKED WITH -)

TABLE V CLASSIFICATION
OF MOST PROFITABLE CROSS-CHAIN BRIDGE HACKS GROUPED BY SECURITY APPROACH.THE AMOUNTS ARE PRESENTED IN USD.THE CELLS WITH THE VULNERABILITY NUMBER ARE FILLED WITH THE COLOR ACCORDING TO THE LAYER THEY BELONG TO (CF.SECTION IV-B).WE ADD A "SUMMARY" ROW THAT AGGREGATES INFORMATION.SPECIFICALLY, WE USE CELL SHADING TO SHOW THE PERCENTAGE OF HACKS IN WHICH EACH VULNERABILITY WAS FOUND.
65.8% of the total value stolen originated in bridges associated with SA 22 .Projects choose SA 22 to have finer control over the bridge.However, it also eases hackers' efforts to gain control over the infrastructure.3 hacks were performed on solutions with SA 11 and SA 22 (26.8% and 0.5% of the total value, respectively); and two projects based on SA 33 (6.9%).SA 4 approaches do not enter the leaderboard.Notably, in 14 of the hacks authored by black hats, transaction mixers were used 5 times before the attack (35.7%) and 11 times after the attack (78.6%).

TABLE VI COMPARATIVE
ANALYSIS OF THIS PAPER AND OTHER STUDIES FOCUSING ON SECURITY OR PRIVACY OF BLOCKCHAIN INTEROPERABILITY.All labels apply to systematizations.
Table J presents the date and amount of hacks that account for more than 3 billion USD.Additionally, we describe in detail each analyzed hack and propose a set of mitigations in table VI-C.