Content uploaded by Minfeng Qi
Author content
All content in this area was uploaded by Minfeng Qi on Oct 12, 2024
Content may be subject to copyright.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and
Future Outlook
NINGRAN LI, Swinburne University of Technology, Australia
MINFENG QI, City University of Macau, China
ZHIYU XU, Swinburne University of Technology, Australia
XIAOGANG ZHU, Swinburne University of Technology, Australia
WEI ZHOU, Swinburne University of Technology, Australia
SHENG WEN, Swinburne University of Technology, Australia
YANG XIANG, Swinburne University of Technology, Australia
Cross-chain bridges, one of the foundational infrastructures of blockchain, provide the infrastructure and solutions for
interoperability, asset liquidity, data transfer, decentralized nance, and cross-chain governance between blockchain networks.
However, because cross-chain bridges oen have to handle communication and asset transfers between multiple blockchains,
they involve complex protocols and technologies. is complexity increases the likelihood of vulnerabilities and potential
aacks. In order to ensure the security and reliability of cross-chain bridges, this paper launches a thorough investigation of
existing cross-chain bridge projects, clarifying bridging mechanisms, bridge types, and security features. e following part
goes into the subject of security and sheds light on the considerable challenges faced by cross-chain bridges. It conducts a
thorough analysis of security aws, covering problems like smart contract vulnerabilities, centralization risks, liquidity issues,
and oracle manipulations. Furthermore, this study promotes a compendium of security solutions and best practises, pointing
the way towards a cross-chain bridge scenario that is more secure.
CCS Concepts: • Security and privacy
→
Distributed systems security; • General and reference
→
Surveys and
overviews; • Computer systems organization →Peer-to-peer architectures.
Additional Key Words and Phrases: Blockchain, cross-chain bridges, security, smart contract vulnerabilities
1 INTRODUCTION
is section examines the core concepts of blockchain technology and its development, with a particular focus
on the crucial function of cross-chain bridges in modern blockchain applications. With the ongoing expansion
of blockchain technology, the need for smooth communication and interaction between dierent blockchain
networks is becoming increasingly crucial. Cross-chain bridges have provided the seamless ow of assets and
data across dierent blockchain ecosystems.
Although cross-chain bridges are crucial, their development also presents signicant security challenges.
ese security aws can lead to vulnerabilities and aacks that compromise the integrity and reliability of the
Authors’ addresses: Ningran Li, ningranli@swin.edu.au, Swinburne University of Technology, Melbourne, Australia; Minfeng Qi, mfqi@cityu.
edu.mo, City University of Macau, Macau, China; Zhiyu Xu, zhiyuxu@swin.edu.au, Swinburne University of Technology, Melbourne, Australia;
Xiaogang Zhu, xiaogangzhu@swin.edu.au, Swinburne University of Technology, Melbourne, Australia; Wei Zhou, weizhou@swin.edu.au,
Swinburne University of Technology, Melbourne, Australia; Sheng Wen, swen@swin.edu.au, Swinburne University of Technology, Melbourne,
Australia; Yang Xiang, yxiang@swin.edu.au, Swinburne University of Technology, Melbourne, Australia.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that
copies are not made or distributed for prot or commercial advantage and that copies bear this notice and the full citation on the rst page.
Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permied. To copy
otherwise, or republish, to post on servers or to redistribute to lists, requires prior specic permission and/or a fee. Request permissions from
permissions@acm.org.
© 2024 Copyright held by the owner/author(s).
ACM 2769-6480/2024/10-ART
https://doi.org/10.1145/3696429
Distrib. Ledger Technol.
2 • Li, et al.
blockchain network. For instance, the well-known $600 million assault on the Poly Network in 2021 brought
aention to the signicant dangers linked to cross-chain bridges [111]. In this case, an aacker took advantage
of a weakness to divert money, causing a loss of trust in these systems.
is study specically examines the current and changing security threats that cross-chain bridges encounter,
which can have substantial repercussions for the broader blockchain ecosystem. e primary objective of this
study is to address the pressing requirement of improving the security of inter-chain bridges and ensuring their
dependable and secure functioning inside a blockchain seing. Our goal is to tackle these security concerns
to encourage the creation of stronger and more resilient cross-chain solutions, eventually promoting greater
condence and acceptance of blockchain technology.
Overall, this study examines the elements that need enhancing the security of cross-chain bridges and empha-
sizes the signicance of the conclusions in this article for resolving these concerns.
1.1 Background of Blockchain Technology and the Growing Importance of Cross-chain Bridges
In recent years, the prominence of cryptocurrencies such as Bitcoin [
76
] has spurred an explosion of research into
the blockchain technology that underpins them. Blockchain technology is essentially a decentralised, distributed
ledger that facilitates peer-to-peer transactions and collaboration and guarantees data integrity and security via
data encryption, timestamps, distributed consensus, and economic incentives [
74
]. Bitcoin has been the most
successful blockchain application scenario since 2009. As it has been applied to various situations and industries
[
33
,
38
,
110
,
117
], blockchain technology has adapted consequently and spawned numerous additional blockchain
platforms, such as Ethereum [30], Ripple [97], and Polka [112].
As the blockchain ecosystem continues to develop, the need for interoperability between blockchain platforms
increases. Cross-chain bridges are a solution that facilitates the cross-chain transfer of assets and the cross-chain
execution of smart contracts by constructing bridges between multiple blockchains, thereby facilitating the
transfer and exchange of assets and data between blockchain networks [
68
]. rough cross-chain interfaces,
users and developers can use various blockchain platforms to more easily transfer assets and interact across
chains. Cross-chain Bridge eectively addresses the problem of blockchain network isolation (oen referred to as
“blockchain silos”) by facilitating interoperability. It eliminates barriers between various blockchains, allowing
the blockchain ecosystem as a whole to genuinely connect and collaborate.
Cross-chain bridges have played an increasingly important role in recent years, due to the rise of decentralized
nance (DeFi) [
109
] and irreplaceable tokens (NFT) [
106
]. To maximize liquidity, revenue, and eciency, DeFi
platforms need to interact with multiple blockchains, while NFTs need to be transferred between platforms.
Cross-chain bridges have become an important part of the decentralized ecosystem, supporting new use cases
and fostering innovation.
However, as the popularity and adoption of cross-chain bridges grow, security becomes an increasingly
important issue [
37
,
65
,
66
]. Security vulnerabilities and aws in design and implementation can be very costly to
users and undermine trust in the technology. erefore, enhancing the security of cross-chain bridges is crucial
for researchers, developers, and the broader blockchain community to promote a more robust and interconnected
blockchain ecosystem.
1.2 Securing Cross-chain Bridges
e increasing need for interoperability among diverse blockchain platforms has led to the proliferation of
cross-chain bridges. ese bridges are being utilised in various domains, including asset exchange, transfer, and
data sharing, to facilitate seamless cross-chain operations [115]. Given that these applications entail signicant
assets and sensitive data, the maer of security risks assumes paramount importance. Upon being subjected
to an aack, there is a potential for signicant ramications. us, it is imperative to prioritise the security of
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 3
cross-chain bridges. is section provides a concise overview of the rationale behind emphasising the importance
of cross-chain bridge security.
Cross-chain bridges involve the transfer of digital assets such as tokens and NFTs between dierent blockchain
networks. As such, any security vulnerability in the bridge can lead to the loss, the, or unauthorized access
of these assets, causing signicant nancial damage to users [
69
]. According to Chainalysis [
101
], a total of $2
billion worth of cryptocurrency has been stolen in 13 distinct cross-chain bridge hacks, with the majority of
these incidents occurring in 2022. e incidents of bridge aacks have contributed to 69% of the overall amount
of assets that have been unlawfully taken (Fig. 1).
Fig. 1. Hacked Value Stolen From Bridge Protocols [101]
Apart from digital assets transfer, cross-chain bridges facilitate the transfer of data between dierent blockchains.
ey act as intermediaries and follow a specic process to ensure that data is accurately and securely transferred
[
79
]. Ensuring data consistency in cross-chain bridges is a challenging undertaking owing to the decentralized
and asynchronous characteristics of blockchain systems. Dierent block generation intervals and transaction
processing speeds across blockchains can result in discrepancies in the state of data at any given moment, thereby
constituting one of the reasons [
87
]. An additional plausible explanation is that the inability of a transaction
to be completed on a single chain necessitates the reversal of the entire process across all chains, which can be
challenging to coordinate. Tampered or inconsistent data can lead to incorrect transaction processing.
In addition, the stability of blockchain networks is contingent upon the essential factors of cooperation and
consensus among the nodes that are involved [
103
]. e security of cross-chain bridges is of paramount importance
in ensuring the stability of the participating nodes, given their role as intermediaries between disparate blockchain
networks. e security of the cross-chain bridge is of paramount importance as any potential threat or compromise
may result in the instability of the participating nodes. is instability can disrupt the cooperative relationship
between the nodes and have a ripple eect on the entire interconnection network [
113
]. e vulnerability
or malicious aack of a cross-chain bridge has the potential to cause network failure or disruption, thereby
signicantly impacting the regular functioning of the blockchain ecosystem. Hence, it is imperative to prioritize
the security of cross-chain bridges to guarantee the consistent functionality of the network. Such vigilance can
Distrib. Ledger Technol.
4 • Li, et al.
assist us in identifying and resolving potential security threats, ensuring the stability of participating nodes, and
ensuring the integrity of the entire blockchain ecosystem[32].
1.3 Objectives and Contributions of this Paper
e primary objective of this paper is to analyze potential issues and challenges of blockchain cross-chain bridges
from a security perspective, as well as to present solutions and optimal use cases. In addition, the future prospects
and emergent trends in cross-chain bridge security will be examined. e principal contributions of this paper
consist of:
1)
Comprehensive Security Analysis: is paper provides an in-depth analysis of security issues related to cross-
chain bridges, including smart contract vulnerabilities, centralization risks, liquidity issues, and oracle manipu-
lations. is comprehensive scope is broader and more detailed compared to existing surveys [
19
,
27
], which
oen focus on specic aspects such as smart contracts or interoperability without providing a holistic view of
security challenges.
2)
Detailed Case Studies: Unlike previous surveys, this paper includes detailed case studies of signicant cross-
chain bridge aacks, such as the ChainSwap, Poly Network, and Cellframe Network incidents. ese case
studies provide valuable insights into real-world vulnerabilities and aack vectors, helping future developers
and researchers understand the practical implications of security aws.
3)
Proposed Security Solutions: e paper presents a wide range of security solutions and best practices, including
formal verication, upgradable smart contracts, multi-signature governance, and decentralization of oracles.
e depth and breadth of these proposed solutions distinguish this paper from other surveys [
45
,
67
] that oen
provide general suggestions without delving into detailed and actionable recommendations.
4)
Future Outlook and Trends: is paper oers a forward-looking perspective on the trends and future directions
in cross-chain bridge security, providing guidance for researchers on emerging challenges and opportunities.
is aspect is oen briey mentioned or entirely missing in other surveys [
27
,
67
], making this paper a valuable
resource for anticipating and preparing for future developments in the eld.
To highlight the unique contributions of this paper, we compare it with existing surveys in Table 1. is
comparison underscores the comprehensive security analysis, detailed case studies, extensive security solutions,
and future outlook provided by this paper, seing it apart from other literature in the eld. Overall, this paper
oers an academic perspective on the blockchain industry, providing valuable insights into upcoming trends and
emerging markets for cross-chain bridge security. e information presented serves as a crucial reference point
for researchers seeking to clarify future research and development directions.
2 CROSS-CHAIN BRIDGE TECHNOLOGY: AN OVERVIEW
Section II introduces the working principle of cross-chain bridges and provides an overview of dierent types of
cross-chain bridges. e section also features a summary of various cross-chain bridge projects, categorizing
them as centralized, decentralized, or hybrid, and lists their respective security features.
2.1 Working Principle of Cross-chain Bridges
Cross-chain bridges are decentralized protocols that enable seamless communication and asset transfers between
dierent blockchain networks [
114
]. ey allow users to move their digital assets, such as cryptocurrencies,
tokens, and NFTs, from one blockchain to another while maintaining their original properties and value. By
facilitating interoperability, cross-chain bridges help overcome the limitations posed by isolated blockchain
networks and unlock the potential for a truly interconnected ecosystem [83].
It is important to note that the working principles of cross-chain bridges can vary depending on the specic
bridge implementation and the blockchain networks involved. Some cross-chain bridges may use additional
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 5
Table 1. Comparison of This Survey with Existing Literature
Feature is Paper [19] [27] [45] [67]
Scope of
Security
Analysis
Comprehen-
sive, covering
various
vulnerability
aspects
Focuses on
smart
contracts
only
Broad
overview,
less detailed
in specic
areas
Emphasis on
interoperabil-
ity challenges
Primarily
technical
aspects, less
on practical
solutions
Case Studies
Detailed case
studies of
real-world
aacks
None Limited None None
Proposed
Solutions
Extensive list
of solutions
Mentioned
but not
detailed
General
suggestions,
no deep dive
Some
solutions, but
not compre-
hensive
Focus on
technical
solutions,
lacking
practical
insights
Future
Outlook
Insights into
future trends
and research
directions
Briey
mentioned
Not covered Briey
mentioned
Not covered
mechanisms, such as oracles [
12
], relayers [
39
], or validators, to facilitate the transfer process and ensure the
accuracy and security of the asset transfers. However, it still can be broadly summarized into the following steps
[19]:
•Step 1: Asset Locking. When a user wants to transfer an asset from one blockchain (source chain) to another
(destination chain), the asset is rst locked or temporarily removed from circulation on the source chain. is
process is usually facilitated by a smart contract or a multi-signature wallet, ensuring that the locked assets
cannot be accessed or spent by the user during the transfer process.
•
Step 2: Proof of Asset Locking. Aer the asset is locked on the source chain, a proof of asset locking is generated.
is proof typically includes the transaction details, such as the asset’s locked amount, the sender’s address,
and the intended recipient’s address on the destination chain.
•
Step 3: Asset Minting. e proof of asset locking is then relayed to the destination chain, where a corresponding
amount of the asset is minted or created on the destination chain. is newly minted asset is oen referred to
as a “wrapped” or “pegged” version of the original asset, as it represents the same value and properties as the
locked asset on the source chain.
•
Step 4: Asset Distribution. Once the asset is minted on the destination chain, it is transferred to the intended
recipient’s address, eectively completing the cross-chain transfer process.
Distrib. Ledger Technol.
6 • Li, et al.
•
Step 5: Asset Unlocking. When the user wants to move the asset back to the source chain, the process is
reversed. e wrapped asset is locked on the destination chain, a proof of asset locking is generated, and the
original asset is unlocked and released to the user on the source chain.
Fig. 2. Working Principles of Cross-chain Bridges
2.2 Types of Cross-chain Bridges
Cross-chain bridges can be classied into three main types based on their architectural design and governance
models: centralized [
1
,
16
,
25
], decentralized [
5
,
6
,
9
,
92
], and hybrid [
2
,
8
,
62
,
112
]. Each type oers a distinct set
of benets and limitations concerning security, speed, and user-friendliness.
2.2.1 Centralized cross-chain bridges. Centralized cross-chain bridges are operated and controlled by a single
entity or a group of entities, which manage the asset transfers between dierent blockchain networks [
80
]. Users
are required to trust the central operator to lock, mint, and distribute assets during the cross-chain transfer
process. e central operator also manages the collateral, if required, to back the value of the minted assets on
the destination chain.
Centralized cross-chain bridges bring both signicant advantages and potential challenges. On the upside,
such bridges tend to oer faster transaction processing. is speed is aributed to the absence of decentralized
consensus mechanisms, which oen require a signicant amount of time to validate transactions across multiple
nodes. Additionally, these bridges oen promise easier integration and setup [
63
]. is streamlined process is
made possible by the central operator’s ability to coordinate the transfer process and reduce the complexities
arising from decentralized entities.
However, these advantages are not without their corresponding downsides. A prominent issue pertains to
the single point of failure that is intrinsically present in centralized systems [
45
]. e operational integrity of
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 7
the bridge can be compromised by a security breach, operational malfunction, or central operator downtime,
resulting in a disruption of its overall functionality. In such instances, the consequences may vary from temporary
diculties to substantial economic ramications for the users. Moreover, the authority given to the central
operator poses a heightened potential for censorship. e operator wields a considerable degree of control
over the operations of the bridge, as they possess the power to either approve or deny transactions at their
discretion. is concentration of power can be concerning in scenarios where the operator’s interests don’t
align with those of the users [
32
]. Finally, it is possible that centralized bridges could encounter regulatory risks
[
99
]. Due to their resemblance to conventional centralized nancial institutions, they may be subject to more
rigorous regulatory examination in contrast to their decentralized equivalents. e examination may result in
supplementary obligations for compliance, which have the potential to impede the bridge’s activities or even
result in its cessation.
2.2.2 Decentralized Cross-Chain Bridges. Decentralized cross-chain bridges distribute the control and manage-
ment of asset transfers among multiple independent nodes or participants in the network [
54
]. ey typically use
consensus mechanisms, smart contracts, and cryptographic techniques to facilitate secure and trustless asset
transfers between blockchain networks.
e utilization of a decentralized cross-chain bridge presents numerous noteworthy benets. e distributed
nature of the system notably augments its security and diminishes the likelihood of a single point of failure [
11
].
Furthermore, the decentralized approach employed in this context reduces users’ dependence on a centralized
institution, as they are not required to rely on a centralized entity to oversee their assets. Decentralized cross-chain
bridges have the potential to enhance resistance to censorship and regulatory risk.
However, we must also be aware of the obstacles decentralized cross-chain bridges present. In particular,
there is the possibility that the eciency of decentralized consensus mechanisms may not match the eciency
of centralized systems [
64
], resulting in lengthier transaction processing times. On the other hand, due to the
need to adapt and incorporate multiple networks and participants, the integration and establishment process of
cross-chain bridges may also be more complicated [116].
2.2.3 Hybrid Cross-Chain Bridges. Hybrid cross-chain bridges integrate features of centralized and decentralized
architectures, with the aim of achieving an optimal balance among security, speed, and user-friendliness [
67
]. e
bridges may employ a hybrid approach that involves central operators, decentralized consensus mechanisms, and
multi-signature wallets for the purpose of facilitating asset transfers across diverse blockchain networks [105].
e hybrid approach exhibits a notable advantage in terms of enhanced security when compared to centralized
bridges. e integration of decentralized components into its structure results in signicant mitigation of the
risks that are commonly associated with a single point of failure. Furthermore, this particular model accelerates
transaction processing in contrast to bridges that are entirely decentralized [
90
]. e aforementioned advantage
is of utmost signicance, given the escalating need for transactions that occur in real time across a wide range of
blockchain use cases. Additionally, the hybrid model has an important advantage in terms of its inherent exibility
and adaptability [
54
]. e proposed model oers the capacity to customize the level of trust and decentralization
according to the particular requirements or preferences of individual users. is feature can cater to a broader
range of use cases, enhancing its applicability across various blockchain ecosystems.
While the hybrid model may oer signicant benets, it is crucial to consider any possible limitations. An issue
of importance pertains to the potential trade-o between security, speed, and user-friendliness [
48
], whereby
one aspect may be compromised in favor of another. Given that the hybrid model aims to achieve equilibrium
among these variables, prioritizing one could conceivably undermine the remaining factors. As an illustration,
the implementation of enhanced security protocols may impede the pace of transactional processing or present
complexities to the end-user’s interaction with the model. Moreover, the complexity of the hybrid model could
be a challenge [
72
]. Achieving a bridge that eectively integrates the favorable aributes of centralized and
Distrib. Ledger Technol.
8 • Li, et al.
decentralized models is a signicant undertaking. e development process necessitates careful architectural
strategizing and strong coding practices, both of which can present considerable obstacles for developers.
2.3 Popular Cross-chain Bridge Projects and Their Security Features
Within the blockchain ecosystem, various prominent cross-chain bridge initiatives have garnered signicant
interest due to their inventive methodologies for facilitating asset transfers across disparate networks. is
section presents several popular projects for each cross-chain bridge type, emphasizing their security features
and justifying their inclusion.
e security features summarized in Table 2 were identied and compiled through a thorough review of
technical documentation, white papers, and existing literature on each cross-chain bridge project. e justication
for each security feature is based on the specic mechanisms employed by these projects to ensure secure and
reliable cross-chain transactions. Each feature was selected for its signicance in enhancing the security and
resilience of the cross-chain bridge against potential vulnerabilities and aacks.
2.3.1 Centralized cross-chain bridge projects. e current landscape of centralized cross-chain bridge projects
reects a signicant aspect of the blockchain industry, balancing eciency and control with security and trust
issues. We present a summary of four widely recognized centralized cross-chain projects.
Wrapped Bitcoin. e Wrapped Bitcoin (WBTC) is a token that operates on the Ethereum blockchain and
conforms to the ERC-20 standard [
29
]. It is designed to maintain a xed exchange rate of 1:1 with Bitcoin. e
project is classied as centralized cross-chain due to the involvement of a consortium of organizations, namely
BitGo, Ren, and Kyber Network, in the supervision of the wrapping and unwrapping of Bitcoin. e security of
WBTC is ensured through regular smart contract audits, which help identify and mitigate vulnerabilities in the
code. ese audits are conducted by reputable third-party rms to ensure transparency and reliability.
Liquid Network. e Liquid Network [
4
] is a selement network designed for traders and exchanges, which
operates on the basis of a sidechain. e system functions under a federation model, wherein a cluster of
authorized nodes managed by exchanges, brokers, and other trusted entities authenticate and verify transactions.
is federation model enhances security by distributing trust among multiple reputable entities.
Binance Smart Chain. e Binance Smart Chain (BSC) [
25
] operates concurrently with the Binance Chain and
is specically engineered to facilitate the implementation of smart contracts, as well as the staking mechanism
for Binance Coin. e platform supports cross-chain transfers and interoperability, thereby enabling users to
eortlessly exchange assets across Binance Chain, Binance Smart Chain, and other compatible networks. BSC
employs the Proof of Staked Authority (PoSA) consensus mechanism [
21
], where validators are selected based on
their BNB token holdings. is model ensures high security while maintaining minimal transaction costs, as
validators have a nancial stake in the network’s integrity.
Paxos Standard. Paxos Standard (PAX) [
1
] is a centralized cross-chain stablecoin designed to maintain a 1:1
parity with the US Dollar. For every unit of PAX in circulation, there’s a corresponding dollar held in reserve by
the Paxos Trust Company. PAX ensures security through regular audits and verications, conrming that each
PAX token is backed by an equivalent amount of USD held in reserve.
2.3.2 Decentralized cross-chain bridge projects. e current industry of decentralized cross-chain bridge projects
is experiencing signicant growth and innovation, reecting the broader trend towards decentralization in the
blockchain space. ese projects are pivotal in enhancing interoperability between dierent blockchain networks,
a key factor in the broader adoption and utility of blockchain technology. We have chosen and detailed four
widely-known decentralized cross-chain bridge projects.
Orbit Bridge. Orbit Bridge is an interchain communication protocol (IBC) that allows communication between
heterogeneous blockchains [
6
]. e system aains full decentralization by managing the consensus mechanism
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 9
Table 2. Summary of Cross-Chain Bridge Projects and Their Security Features
Type Project Security Features
Centralized WBTC [29] - Ethereum smart contract audits
Liquid [4] - Federation of authorized nodes
BSC [25] - PoSA consensus
Paxos [1]
- Regular token backing verication
Decentral-
ized
Orbit [6] - Multi-signature
- Vault governance
VoltSwap [9] - 3 out of 5 relayer signatures
Multichain
[5]
- SMPC nodes
Avalanche
[92]
- Majority relayer signatures
Hybrid
Polkadot
[112]
- Shared safety of Polkadot
Cosmos [62] - IBC protocol
- “slashing”
Wanchain [2] - SecRand
- TSS
- Secret sharing
THORChain
[8]
- Tendermint
- GG20 TSS
in a transparent manner, without establishing any o-chain components. Orbit Bridge uses a multi-signature
authentication system, requiring multiple validators to approve transactions. is reduces the risk of single-point
failures. e vault governance model ensures that asset management is decentralized and governed by a group of
operators and validators.
VoltSwap. VoltSwap [
9
] represents the rst decentralized exchange (DEX) within the Meter ecosystem. It is a
completely community-driven bridge project. VoltSwap employs a group of ve cross-chain relayers, namely
Protore, Hashquark, Wetez, InntyStones, and Meter, who possess signicant expertise in this area. VoltSwap
enhances security by requiring signatures from at least three out of ve cross-chain relayers for transaction
approval. is multi-signature approach mitigates the risk of fraudulent or unauthorized transactions.
Multichain. e Multichain protocol is an open-source cross-chain router protocol (CRP) that facilitates the
bridging of tokens across multiple blockchains [
5
]. Multichain employs a dual approach for token bridging.
Initially, a smart contract is employed to secure tokens on a particular blockchain and generate wrapped tokens
on a distinct blockchain. If this method is not feasible, a network of cross-chain liquidity pools is used to trade
the bridged tokens. e security of Multichain is ensured through a network of nodes referred to as Secure
Distrib. Ledger Technol.
10 • Li, et al.
Multiparty Computation (SMPC) [
51
]. e aforementioned nodes are autonomous units that have the ability to
jointly endorse transactions. Each node independently owns a portion of the private key, ensuring that no single
node can compromise the system’s security.
Avalanche Bridge. e Avalanche Bridge [
92
] is a decentralised cross-chain bridge that facilitates the transfer of
assets between the Ethereum and Avalanche blockchains. e Avalanche Bridge utilises a group of intermediaries
who monitor and facilitate the transfer of transactions across dierent blockchain networks. e execution of a
transaction occurs upon obtaining signatures from a majority of the relayers. is conguration guarantees the
security of the bridge’s operation.
2.3.3 Hybrid cross-chain bridge projects. Hybrid cross-chain bridge projects represent an innovative approach in
the blockchain industry, combining elements of both centralized and decentralized architectures. ese projects
aim to harness the strengths and mitigate the weaknesses of each system to oer a more balanced solution. We
present an overview of four hybrid cross-chain bridge projects.
Polkadot. Polkadot [
112
] is a novel multi-chain architecture that aims to interconnect diverse blockchain into a
unied network. e bridges within the Polkadot ecosystem function as distinct types of parachains, facilitating
the linkage between Polkadot’s relay chain and external blockchain networks. e operational mechanism of
Polkadot bridges is based on the principle of light-client verication, and they derive advantages from the shared
safety of the Polkadot network [
20
]. is implies that the security of the bridges is equivalent to that of the
Polkadot relay chain, thereby mitigating the security responsibility of individual bridge validator sets.
Cosmos. e Cosmos comprises independent blockchains that connect via a unique interoperability protocol
known as Inter-Blockchain Communication (IBC) [
62
]. e IBC protocol ensures a secure and trust-minimized
mode of communication among diverse blockchains. Every IBC client monitors the status and validates proofs of
other chains, ensuring the security of all cross-chain communication. In addition, the Cosmos network implements
a mechanism referred to as “slashing” that entails the deduction of a fraction of a validator’s stake in the event of
malevolent actions or inadequate execution of their responsibilities. is serves as a potent preventive measure
against any endeavours to undermine the integrity of the network’s security.
Wanchain. Wanchain oers cross-chain capabilities that include the secure locking of cross-chain assets and the
validation of cross-chain data [
2
]. e Wanchain 5.0 protocol employs a stochastic variable as the input for its
grouping algorithm, thereby aaining a state of unpredictability and resistance to bias. e random number is
generated through the utilisation of SecRand [
43
] to ensure a secure and reliable generation process. Additionally,
Wanchain utilises a threshold-optimal threshold secret sharing (TSS) scheme to enhance the complexity of
collusion and guarantee the security of assets in secured accounts. e TSS scheme’s Shamir’s secret sharing is
augmented by Feldman secret sharing, thereby guaranteeing the public veriability of data exchanged between
Storeman nodes.
THORChain. e THORChain protocol is a hybrid liquidity protocol that facilitates cross-chain transactions. It
utilises the Tendermint consensus engine, Cosmos-SDK state machine, and GG20 reshold Signature Scheme
(TSS) [
8
]. In order to mitigate the risks of double-spend aacks and reorganisations on non-instant nality
chains, THORChain users employ conformation counting for particular chains while receiving incoming value.
THORChain implements varying degrees of network halt controls that are controlled by either Mimir values or
nodes, contingent upon their type and level. In addition, the code has been added with security events that trigger
automatically upon the occurrence of specic conditions, such as node slashing for unauthorised transactions or
exceedingly large withdrawals.
3 SECURITY CHALLENGES AND RISKS IN CROSS-CHAIN BRIDGES
As we discussed in the rst section of this paper, the security of cross-chain bridges merits consideration due to
the potential threats they may pose. Cross-chain bridges are a crucial element that facilitates the transfer of assets
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 11
and transmission of data between various blockchain networks. e existence of security vulnerabilities within
cross-chain bridges may result in signicant ramications, including but not limited to asset loss, fraudulent
activities, and network disruption [
88
]. Hence, it is imperative to prioritize the security concerns pertaining to
cross-chain bridges in order to establish user condence, safeguard assets, and foster the enduring advancement of
blockchain technology. e present section provides a condensed overview of the primary security vulnerabilities
associated with cross-chain bridges. ese vulnerabilities include smart contract vulnerabilities [
95
], centralization
risks [
96
], liquidity issues [
81
], and oracle manipulations [
70
]. e subsequent section will oer comprehensive
solutions to address these vulnerabilities.
3.1 Smart Contract Vulnerabilities
Smart contracts are computer programs that are implemented on the blockchain to dene and enforce the
rules and conditions governing the interactions between parties [
107
]. ey allow for trusted transactions and
protocol execution without the need for intermediaries. e subject of smart contract vulnerabilities has garnered
signicant aention within the realm of blockchain research in recent times, and is instrumental in ensuring
the safety of decentralized applications (dApps [
22
]). Since the development of cross-chain bridges includes the
design and execution of smart contracts, smart contract vulnerabilities are also present in the implementation of
cross-chain bridges. e presence of these vulnerabilities may result in loss, manipulation, and unauthorized
access incidents during the transfer of assets across chains [
120
], thereby posing a signicant threat to the security
and dependability of the entire cross-chain bridge infrastructure. Hence, it is imperative to recognize, evaluate,
and rectify potential security vulnerabilities in smart contracts within the cross-chain bridge domain.
In this study, following an examination and analysis of existing vulnerabilities in cross-chain smart contracts,
we categorize them into three distinct groups: vulnerabilities related to the blockchain platform itself, those
associated with the architecture of smart contracts, and vulnerabilities inherent in the programming languages
used. rough the analysis of these classications, we adopt a structured approach to comprehend and tackle
various security issues. is allows us to develop a more comprehensive understanding of the factors inuencing
cross-chain bridge security concerns and devise more robust solutions.
3.1.1 Blockchain Platform (chains) Vulnerabilities. Depending on their underlying consensus mechanisms, net-
work architectures, and design principles, various blockchain platforms present distinct and unique security
challenges. In addition, each blockchain platform has its own execution environment for smart contracts, and
some vulnerabilities may originate from defects in the blockchain platform itself. Ethereum faces security risks
associated with its public memory pool, which could expose transactions to preemptive trading aacks [
27
].
Additionally, Ethereum’s dependence on timestamps could potentially create vulnerabilities in smart contracts
that are susceptible to time manipulation [
34
]. rough a comparative analysis of the security features inherent
in dierent blockchain platforms, researchers can detect vulnerabilities that are specic to each platform and
devise tailored solutions to bolster the security of cross-chain interactions. is approach also guarantees the
soundness of smart contracts across diverse applications.
3.1.2 Smart Contract Architectures Vulnerabilities. Smart contract architectures play a crucial role in determining
the potential aack surface and risk exposure. Common vulnerabilities such as reentrancy aacks and recursive
calls oen stem from design aws in the smart contract architecture. For example, the DAO hack [
31
] was
caused by a reentrancy vulnerability resulting from a poorly designed withdrawal function. Analyzing the
architectures of various smart contracts can provide valuable insights into the origins of vulnerabilities and
inform the development of best practices for secure smart contract design.
Distrib. Ledger Technol.
12 • Li, et al.
Regardless of the specic language used for writing smart contracts, there are several common vulnerabilities
that can arise due to the inherent complexity of smart contract logic, the immutability of deployed contracts, and
the public nature of blockchain data. Here are some of the most common types of vulnerabilities:
Table 3. Summary of Smart Contract Vulnerabilities
Vulnerability Description
Uncontrolled Access
Unauthorized manipulation due to access discrepancies.
Decient Logic Deciencies in business logic leading to exploitation.
Recursive Calls Vulnerabilities like the re-entrancy aack.
External Dependencies Risks from changes or removal of external contracts.
DoS Risks Aacks due to reliance on external actions.
Upgrade Risks Disruptions or vulnerabilities from upgrades.
Input Validation Aack vectors from poor input validation.
Race Conditions Vulnerabilities from altered states during external calls.
Uncontrolled Access Rights: A crucial facet of smart contract architecture pertains to the control of access
rights. Discrepancies in this domain may lead to unauthorized actors gaining the ability to manipulate privileged
functions [
60
]. An optimally constructed access control mechanism is one that delineates distinct roles (such as
owners, administrators, and users) and their respective rights with precision.
Decient Business Logic Implementation: e quality of a smart contract’s architecture heavily relies on the
accuracy and robustness of its embedded business logic [
121
]. Any deciencies in the logic related to operations
such as token transfers, conditional checks, and other business-related procedures could open avenues for
exploitation and unintended behaviors.
Recursive Call Exposure: A non-trivial aspect of smart contract architecture involves function interactions
[
73
]. When function A, for instance, calls function B, and function B triggers a return call to function A prior to
the termination of function A, this can create a potential vulnerability. e infamous re-entrancy aack embodies
this concept.
Dependence on External Contracts: Contracts that maintain dependencies on external contracts can inadver-
tently expose themselves to a host of vulnerabilities [
95
]. ese vulnerabilities could materialize if the external
contract is altered, deprecated, or removed entirely. is underscores the importance of ensuring that contract
interactions are designed to be resilient in the face of changes in external contracts.
Denial of Service (DoS) Susceptibility: If a contract’s functioning is contingent on actions by external entities,
it might fall prey to a DoS aack if the required actions are indenitely postponed or deliberately withheld
[
59
]. is emphasizes the importance of including safeguards against the indenite postponement of necessary
external actions.
Risks in Contract Upgradeability: e ability to upgrade contracts aer deployment is a double-edged sword
[
94
]. While upgrades can facilitate the rectication of bugs and the introduction of new features, they can
also cause disruption if the contract’s state is not preserved during the upgrade process or if the upgrade
unintentionally introduces new vulnerabilities.
Insucient Input Validation: e architecture of a smart contract is required to include robust mechanisms
for validating inputs, particularly when these inputs are supplied by external users or contracts [
56
]. An absence
of rigorous input validation measures can lead to a variety of aack vectors.
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 13
Race Condition rough External Contract Calls: A smart contract can be susceptible to race conditions if
its state can be altered while it is in the process of making calls to another contract [
41
]. In such scenarios, the
contract’s behavior can be manipulated to serve the interests of an aacker.
ese vulnerabilities underscore the necessity of meticulous design, comprehensive testing, and regular
auditing in the development of smart contracts. ey further highlight the need for continued research into
new security paradigms and the development of more sophisticated tools for ensuring the robustness of smart
contract architectures.
3.1.3 Programming Languages Vulnerabilities. e choice of programming language for smart contract develop-
ment can signicantly impact the security of the resulting contracts. Solidity, the most widely used language
for Ethereum smart contracts, has been associated with numerous vulnerabilities, including integer overows
and underows, delegate call vulnerabilities, and issues related to function visibility [
61
]. By examining the
features and limitations of dierent programming languages, researchers can identify language-specic risks and
develop tools, libraries, and guidelines for writing secure smart contracts. Table 4 summarizes the vulnerabilities
in dierent languages and more details are discussed as follows:
Table 4. Summary of Programming Languages Vulnerabilities in Dierent Blockchains
Language Blockchain Vulnerabilities
Solidity Ethereum - Arithmetic Over/Underows
- Unchecked Return Values
Vyper Ethereum - Limited Functionality
- New and Less Reviewed
Rust/Ink! Polkadot - Complexity
C++ EOS - Memory Management
- Complexity
Rholang RChain - Concurrent Execution
- Less Common Language
Solidity (Ethereum). Solidity is the primary language for Ethereum smart contracts. It’s similar to JavaScript
and is known for its ease of use, but it has several potential vulnerabilities. 1) Arithmetic Over/Underows [
93
]:
An overow or underow happens when an operation aempts to store a number that is outside the range of
the target data type. Solidity does not handle arithmetic overows and underows by default. Developers must
manually check for these situations to handle these cases correctly. 2) Unchecked Return Values [
49
]: External
calls to other contracts could fail silently, as Solidity does not automatically check their return values.
Vyper (Ethereum). Vyper is another language for Ethereum that emphasizes security and simplicity. Its potential
vulnerabilities include two types. 1) Limited Functionality: Vyper intentionally restricts some features to increase
security. is can sometimes lead to workarounds that introduce vulnerabilities. 2) New and Less Reviewed: As a
relatively new language, Vyper has been less scrutinized than Solidity, so there could be undiscovered issues[
52
].
Rust and Ink! (Polkadot and Substrate). Rust is a system programming language that prioritizes safety and
performance. Ink! is a Rust-based smart contract language for Polkadot and Substrate. Vulnerabilities include the
type caused by complexity. Rust and Ink! can be more dicult to learn and use correctly than other languages.
Mistakes could lead to vulnerabilities[58].
Distrib. Ledger Technol.
14 • Li, et al.
C++ (EOS). EOS uses C++ for its smart contracts. It is a powerful language, but it comes with potential pitfalls
[
118
]. 1) Memory Management: C++ requires manual memory management, which can lead to vulnerabilities if
not handled correctly. 2) Complexity: e wide range of features and exibility of C++ can lead to complex code
that is more prone to errors and vulnerabilities.
Rholang (RChain). Rholang is a reective high-order process language used in RChain. Some potential issues
exist in using Rholang [
35
]. 1) Concurrent Execution: Rholang is designed for concurrent execution, which
can lead to complex race conditions if not managed properly. 2) Less Common Language: As Rholang is less
commonly used, there are fewer resources available for developers, and potential language-specic vulnerabilities
may not be as well understood.
3.2 Centralization Risks
e risk of centralization in cross-chain bridges refers to the potential vulnerabilities and challenges posed by
relying on a single or small group of entities to manage, validate, or forward transactions between dierent
blockchain networks. Centralization in cross-chain bridges can lead to several problems:
3.2.1 Single point of failure. A single point of failure (SPOF) in cross-chain bridging is a component or entity
in the bridging architecture that, if compromised or fails, can cause the entire system to become inoperable or
unreliable. Single points of failure are of particular concern in cross-chain bridging, as they can lead to potential
asset loss, transaction disruption, or a loss of trust in the security of the bridge.
Some cross-chain bridges utilize a centralized custodian to hold and manage assets that are transferred between
dierent blockchains. If the custodian is compromised, hacked, or goes oine, users’ assets can be lost or frozen,
rendering the bridge inoperable. An example of this scenario is the 2020 hack of the centralized bridge service
Furucombo [119], which resulted in the loss of $15 million in user assets due to a smart contract vulnerability.
Cross-chain bridges may rely on a single or a handful of centralized oracles to provide critical data, such as
exchange rates or asset balances. If a prophecy machine is compromised or provides incorrect data, the bridge
could execute transactions based on false information, resulting in lost assets or incorrect transfers [
122
]. In
some cross-chain bridge designs, a single validator or relay is responsible for validating and relaying transactions
between chains. e bridge may not be able to process transactions or may process fraudulent transactions if
that entity is compromised, goes oine, or starts acting maliciously.
3.2.2 Manipulation and fraud. Manipulation and fraud in the context of cross-chain bridges refers to the various
ways in which malicious actors can exploit a bridge’s design, vulnerabilities, or centralized components for their
own benet, oen at the expense of other users. ese actions can undermine the trust, security, and reliability
of a cross-chain bridge and result in signicant nancial loss to users. Some examples of manipulation and fraud
in cross-chain bridges include:
In a centralized or semi-centralized bridge, controlling entities may have the right to change transaction details
or selectively process transactions, allowing them to prioritize their own transactions or those of their aliates.
is can lead to price manipulation or the of prot opportunities in cross-chain transactions, such as arbitrage.
Malicious actors could exploit vulnerabilities in a bridge’s smart contracts, oracles, or other components to steal
or misappropriate assets held in the bridge. For example, a compromised custodian could transfer a user’s assets
to their own account or manipulate asset valuations to their advantage.
Cross-chain bridges typically involve the minting and destruction of wrapped or pegged tokens to represent
assets on dierent blockchains. Malicious actors may manipulate the bridge’s minting or destruction mechanism
to fraudulently create or destroy tokens, resulting in an imbalance in token supply and potential nancial loss to
users. By monitoring pending transactions and submiing their own transactions at higher gas fees or prioritizing
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 15
their own transactions, malicious actors can get ahead of other users’ transactions, leading to price manipulation
or the of prot opportunities.
3.2.3 Censorship and control. Censorship and control in cross-chain bridges refers to the potential ability of a
central authority or a small group of entities to exert undue inuence over the operation of the bridge, selectively
process transactions, impose restrictions on users or even freeze assets. ese actions undermine the core
principles of decentralization, trust-free, and permission-free that are essential to the blockchain ecosystem.
Some examples of censorship and control issues in cross-chain bridging are introduced below.
A central agency or group of entities in collusion may have the authority to decide which transactions to
process and which to neglect, eectively verifying particular users or transactions [
86
]. is can result in a lack
of transparency bridge operations. Centralized authorities may impose arbitrary restrictions on users, such as
limiting the categories of assets that can be transferred, capping the volume of transactions, or even blacklisting
particular users or addresses. ese restrictions may restrict the accessibility and utility of cross-chain bridges
for many users. In extreme circumstances, central authorities may be able to suspend or conscate assets held
within a bridge, either in response to regulatory pressure or for malevolent purposes. is poses a substantial risk
to users, whose assets may become inaccessible or disappear without recourse. Users of centralized cross-chain
bridges may be required to submit personal information or undertake authentication procedures, which may
contribute to surveillance and privacy concerns. In addition, centralized institutions may be able to monitor the
transaction data and paerns of users, which may compromise their nancial privacy.
3.3 Liquidity Issues
In the context of a cross-chain bridge, liquidity refers to the quantity and availability of assets that can be
transmied between blockchains using the bridge. Cross-chain bridges allow for the transmission of assets
between blockchain networks. ey function by securing the original assets to their native blockchain and
releasing the corresponding tokens on the target blockchain [
46
]. erefore, the liquidity of a cross-chain bridge
is dependent on the number of locked and transferable original assets.
Liquidity is crucial to the ecient operation of a cross-chain bridge. A bridge with high liquidity can facilitate
larger transfers and provide users with beer pricing. A bridge with insucient liquidity, on the other hand, may
not be able to support large transactions, and users may experience price slippage and incur losses. erefore,
liquidity issues in cross-chain bridges can pose signicant risks and challenges. We categorize liquidity issues
into the following aspects.
3.3.1 Imbalanced liquidity. Imbalanced liquidity in a cross-chain bridge is a situation in which the availability of
assets on either side of the bridge diers signicantly. Ideally, an equal number of liquid assets on both sides
of the bridge is required to ensure the seamless transmission of assets in both directions. Nonetheless, if users
have a consistent tendency to transfer assets in one direction, this can result in a liquidity imbalance [
120
]. For
instance, if many users transfer assets from blockchain A to blockchain B, but few make the reverse transfer, this
may result in an asset surplus on blockchain B and a shortage on blockchain A.
is imbalance can cause some risks. For instance, users may encounter delays or even errors when transferring
assets. It may also result in price discrepancies between two blockchains. erefore, arbitrageurs can take
advantage of the price discrepancies resulting from the liquidity imbalance to purchase low and sell high on a
given blockchain.
3.3.2 Flash loan aacks. Flash loan aacks have emerged as a signicant security risk in the decentralized
nance (DeFi) space, including cross-chain bridges [
89
]. ey take advantage of the ability of DeFi protocols
to perform multiple actions in a single blockchain transaction. Flash loans are a DeFi feature where users can
borrow assets without collateral, provided the loan is returned within the same transaction block. If the loan is
Distrib. Ledger Technol.
16 • Li, et al.
not repaid, the entire transaction (including everything done with the borrowed funds) is invalidated and rolled
back as if it never happened. is mechanism allows borrowing large amounts of funds without risk because
they are guaranteed to get their money within the same block.
In a typical ash loan aack, the aacker borrows a large amount of assets through ash loans. Aackers then
use these assets to manipulate the market price of certain tokens on a decentralized exchange (DEX), usually by
buying large quantities of tokens, articially inating the token’s price due to a sudden increase in demand price
[
28
]. Aer the token price was articially inated, the aacker used the overpriced token as collateral to take
out a loan on another platform. As the platform thinks the collateral is worth more than it really is (due to price
manipulation), aackers can borrow more assets than they should. e aacker then repays the original ash
loan and keeps the excess funds from the second loan as prot. All of these steps happen in one transaction, so
it’s hard to prevent, or even detect aer the fact.
In the context of cross-chain bridges, if the bridge uses market prices to determine the amount of assets locked
or minted, a ash loan aack could manipulate these prices, causing the bridge to lock or mint the wrong amount
of assets. is could drain the bridge’s uidity and cause signicant damage.
3.3.3 Liquidity withdrawal aacks. Liquidity withdrawal aacks, also known as “Rug Pull” aacks [
26
], are a
particularly prevalent form of security threat in the decentralized nance (DeFi) world, including cross-chain
bridging. In a typical scenario, some platforms enable users to lock or “stake” assets in exchange for dierent
assets or rewards. e collateralized assets represent the liquidity pool of the platform, enabling it to operate and
provide services.
A liquidity extraction aack occurs when a large amount of collateralized assets in a liquidity pool is suddenly
and unexpectedly withdrawn, usually by several parties or even a single party. Such rapid withdrawals would
drastically reduce the available liquidity in the pool, thereby destabilizing the platform, resulting in a large
reduction in remaining users and potentially huge economic losses. Whale exit is one of the typical behaviors,
which refers to a large player (whale) on the platform who controls a large share of staking assets suddenly
withdraws all of its assets. Such an exit, if large enough, would drain the liquidity pool, aecting the stability of
the platform and the value of the token. Rug pulls are a variant of this aack, which occurs when a developer
or insider of a DeFi project suddenly drains the liquidity pool and disappears, leaving other participants with
worthless tokens. Additionally, in more complex scenarios, aackers can exploit vulnerabilities in the smart
contracts that manage liquidity pools to drain assets. is could involve manipulating the contract to allow
unauthorized withdrawals, tricking the contract into releasing more assets than it should, or exploiting other
contract loopholes to gain control over collateralized assets.
3.4 Oracle Manipulations
Oracle manipulation is a signicant security risk in blockchain systems and smart contract applications that
rely on external data or oracles for functionality [
23
]. Oracles serve as intermediaries between the blockchain
and real-world data sources, allowing smart contracts to access and use o-chain data. Nevertheless, when an
oracle is compromised or manipulated, it can provide incorrect, fraudulent, or malevolent data to smart contracts,
resulting in negative outcomes and potential vulnerabilities.
Oracle manipulation encompasses a variety of malevolent actions designed to deceive or manipulate the data
supplied to smart contracts. ese activities may consist of:
3.4.1 Data deed manipulation. An adversary is able to manipulate the data feed supplied by the oracle in order
to alter or falsify the information communicated to the smart contract. By providing inaccurate or misleading
information, they can mislead the contract’s decision-making process and initiate unintended actions or results.
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 17
3.4.2 Oracle identity the. Unauthorized actors may aempt to impersonate an authorized Oracle by posing as a
reliable source of information. By assuming false identities, they can inject fraudulent data into smart contracts,
resulting in incorrect results and potentially malignant behavior.
3.4.3 Sybil aacks. An adversary creates multiple fraudulent identities or nodes within the Oracle network
in order to exert undue inuence on the consensus or decision-making process. By commanding a signicant
portion of the Oracle network, an aacker can manipulate the data presented to a smart contract, resulting in
biased or compromised outcomes.
4 CASE STUDIES: ANALYZING CROSS-CHAIN BRIDGE SECURITY INCIDENTS
4.1 ChainSwap Aack
On 11/07/2021, the decentralised cross-chain asset bridge project, ChainSwap, has experienced another instance
of aack. e cross-chain bridge, which has over 20 projects deployed on it, has been targeted resulting in a loss
of over $8 million. e emergence of cross-chain asset bridge initiatives is becoming increasingly relevant in the
context of a multi-chain smart contract environment, as there is a growing demand for token exchange across
dierent chains. Centralised services, such as Shapeshi and ChangeNOW, are commonly utilised as traditional
cross-chain asset bridges. Decentralisation has given rise to the emergence of various decentralised cross-chain
asset bridge projects, among which ChainSwap stands out as a notable service provider.
e primary challenge associated with the development of a cross-chain asset bridge pertains to the verication
of transactions across disparate chains. In order to mitigate this issue, ChainSwap has implemented the Proof of
Authority (PoA) mechanism. Prior to conducting an analysis of the code and the aack, it is necessary to provide
an overview of the implementation mechanism employed by ChainSwap.
•
ChainSwap is a cross-chain asset bridge that employs a Factory model to oversee and retrieve subordinate
items. Specically, it facilitates the identication of cross-chain coins on the Ethereum main chain.
•
ChainSwap oers a matching service for projects seeking to enable cross-chain functionality for their tokens.
is involves the creation of a TokenMapped by ChainSwap, which serves to represent the mapping of the
token to the corresponding chain.
•
e ChainSwap protocol employs a nomenclature wherein validators are referred to as Signatories and are
subject to a ota system. is system imposes a restriction on the number of transactions that a validator can
validate within a given time frame. e initial quota allocated to the signatories is subject to accumulation
over time.
4.1.1 Aack Analysis. e following pseudo-code outlines the core logic of the receive function that was exploited
during the ChainSwap aack. Typically, following the transmission of a Token by a user to ChainSwap on a
distinct chain, the signer will authenticate the transaction. Subsequently, the user may relay the verication
details to the ChainSwap contract on the primary Ethereum chain, which will eectuate the transfer of the Token
to the user upon successful verication. e process of receiving is facilitated by the aforementioned method.
e execution of this function entails a higher level of complexity, commencing with an initial charge of 0.05
ETH facilitated by the _chargeFee internal function. Subsequently, the contract solicits a parameter from the
ChainSwap Factory to obtain the minimum number of signatures, denoted as “minSignatures”, and subsequently
validates the number of signatures provided. e value of 1 can be found in the transaction log, which means that
only one signature of the signatory is required for a cross-chain transaction to pass. e process for altering this
parameter will be expounded upon subsequently. e utilisation of the Signatory parameter is solely employed
in tandem with the ecrecover function for the purpose of validating the signature of the message by Signatory.
Stated dierently, it is possible for anyone to produce a signature.
Distrib. Ledger Technol.
18 • Li, et al.
1fu n ct i on re c ei v e ( fr o mC ha i nI d , to , n on ce , v ol um e , s i gn a tu r e s ) {
2chargeFee();
3if ( t r an sa c ti o n a lr e ad y w it h dr a wn )
4th r ow `` w i th d ra w n a lr e ad y " ; // I ss u e : Do e s no t c he c k a ut h e nt i ci t y o f Si g na t o ry
5
6N = nu mb e r of s i gn a tu r es ;
7if ( N < re q ui re d s i gn a tu r es )
8th r o w ` ` to o f ew si g n at u r e s " ; / / I s su e : M i n im u m n u mb e r o f s ig n a t ur e s m a y be t o o
low
9
10 fo r e a ch si g n atu r e i {
11 fo r e a ch si g n atu r e j {
12 if (signatory of signature i == signatory of signature j)
13 th r ow `` r e pe t it i ve si g n at o ry " ;
14 }
15
16 st r u ct H as h = h as h ( f ro m Ch a in Id , to , no n ce , v ol um e , s i gn a t ur e i ) ;
17 di g es t = h as h ( s tr u ct H a sh ) ;
18 si g n ato r y = r ec o v e rS i g n at o r y ( d ig e st , s i gn a t ure i ) ;
19
20 if ( s i gn at o ry is i n va li d )
21 th r ow `` i n va l id si g n at u re ";
22
23 if ( s ig n at o ry i s u na u th o ri z ed )
24 th r ow `` u n au t ho r iz e d " ;
25
26 d ec r ea s e Au t ho r i za t i on ( s i gn at o ry , v o lu m e );
27 em i t Au t ho r iz e ( f ro mC h ai nI d , to , n on ce , vo l um e , s ig n at o ry ) ;
28 }
29
30 ma r k tr a ns a ct i on as r e ce i ve d ;
31 ex e cu t e r ec e iv e ( to , v ol u me ) ;
32 em i t Re c ei v e ( fr o mC h ai nI d , to , n on ce , v ol u me ) ;
33 }
Listing 1. Receive Function
In summary, the receive function’s entire process does not verify the authenticity of the incoming Signatory.
Hence, an aacker can deceive ChainSwap and obtain a signature for themselves by simply creating a random
address and its corresponding signature. Furthermore, as a result of a aw in the implementation logic of
authotaOf (as shown in the following pseudo-code), an excessively large value is generated in instances where
the Signatory is not deemed legitimate, thereby facilitating the aforementioned aack. e aack’s essence lies
in the absence of verication of the mapping index’s value. e absence of error triggering in Solidity when a
mapped key is non-existent necessitates the implementation of a crucial check, given that the determination
of key existence is solely reliant on the return value being 0. e absence of such verications resulted in the
assault that incurred a nancial loss exceeding $8 million.
1fu n ct i on _d e c re a se A ut h Qu o ta ( a dd r es s s ig na t or y , u i nt d e cr e me n t ) {
2up d a te A ut o Qu o ta ( s i gn at o ry ) ;
3qu o ta = _ a u th Q u ot a s [ s i gn a to r y ] . su b ( d e cr e me n t ) ;
4_a u t hQ u ot a s [ si g na t or y ] = q uo ta ;
5em it D ec re as eA ut hQuo ta ( si gn at or y , de crem ent , qu ota );
6}
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 19
7
8mo d if i er up d a te A ut o Qu o ta ( a d dr e ss si g na t or y ) {
9ui n t qu o ta = a u th Qu o ta O f ( si g na t or y ) ;
10 if ( _ a ut h Qu o ta s [ s i gn a to r y ] != q uo t a ) {
11 _a u t hQ u ot a s [ si g na t or y ] = q uo ta ;
12 l as t t im e U pd a t eQ u o ta O f [ s i gn a t or y ] = no w ;
13 }
14 _;
15 }
16
17 fu n c ti o n a ut h Qu o t aO f ( a dd r es s si g na t or y ) p ub l ic vi e w r et u rn s ( u in t q uo t a ) {
18 qu o ta = _ a ut h Qu o ta s [ si g na t or y ] ;
19 ui n t ra t io = a u to Q uo t aR a ti o ! = 0 ? au t oQ u ot a Ra t io : F a ct o ry ( f ac t or y ) . ge t Co n fi g (
_autoQuotaRatio_);
20 ui n t pe r io d = a ut o Qu o ta P e ri o d != 0 ? a ut o Qu o ta P er i o d : Fa c to ry ( f a ct o ry ) . g et C on f ig (
_a u to Q uo t aP e ri o d_ ) ;
21 if ( r a tio = = 0 || pe r io d = = 0 || per i od == u i nt ( -1) )
22 re t ur n q u ot a ; / / I ss u e : No v er i f ic a ti o n of ma p pi n g in de x ' s v al u e
23
24 ui n t q uo t a Ca p = c ap ( ) . mu l ( r at i o ) . di v (1 e1 8 ) ;
25 ui n t d el t a = qu o ta C a p . mu l ( n ow . s ub ( l a s t ti m e Up d a te Q u ot a O f [ s ig n a to r y ] ) ). d i v ( pe r io d ) ;
26 re t ur n M a th . m a x ( qu ot a , M a th . m i n ( qu ot a Ca p , q uo t a . ad d ( d el t a ) )) ;
27 }
Listing 2. Auth ota Functions
4.2 Poly Network Aack
Poly Network, a cross-chain bridge initiative, suered a security breach on August 10, 2021, resulting in a loss
of more than $600 million. e comprehensive assault encompassed diverse blockchain platforms and entailed
intricate interplays among contracts and Relayers. e aack was bifurcated into two primary stages, namely
the alteration of custodian signatures and the subsequent retrieval of cryptocurrency. In the subsequent stage,
given the alteration of the keeper signature, the perpetrator is enabled to create a malevolent transaction for the
withdrawal of coins without any intermediaries.
According to Ontology’s on-chain transaction address
0𝑥 𝑓 771𝑏𝑎61......𝑓 𝑓 𝑓 280𝑐
, there are several reasons why
Keeper could be modied:
•
Ontology’s relayer does not do semantic checksum on the upchain transactions, so malicious transactions
containing modied keepers can be packed onto the poly chain
•
Although the relayer on the target chain (Ethereum) veries the transactions, the aacker can directly call the
EthCrossChainManager contract on Ethernet and eventually call the EthCrossChainData contract to complete
the signature modication
•
e aacker carefully nds a function signature that can cause a hash conict and calls putCurEpochConPub-
KeyBytes to nish modifying the signature.
e aacker rst initiates a cross-chain transaction in Ontology, which contains an aack payload. e
transaction is then received by the Ontology Relayer. Since there is no very strict checksum here, the transaction
is successfully uploaded in Poly Chain through Relayer. However, the transaction was rejected by Ethereum
Relayer. e reason for this is that Ethereum Relayer has a checksum on the target contract address and only
allows LockProxy contracts as the target address, while the aacker passes in the EthCrossChainData address.
erefore, the aacker’s path to aack is broken here.
Distrib. Ledger Technol.
20 • Li, et al.
Fig. 3. Cellframe Token Record
e aacker manually initiates a transaction by calling the verifyHeaderAndExecuteTx function in the EthCross-
ChainManager contract, taking as input the aack transaction data saved in the Ploy Chain block in the previous
step. Since the block is a legitimate block on the poly chain, it can pass the checks for signature and merkle proof in
verifyHeaderAndExecuteTx. en execute the putCurEpochConPubKeyBytes function in the EthCrossChainData
contract to modify the original 4 keepers to the address specied by itself.
Aer the keeper is modied, the aacker directly calls the verifyHeaderAndExecuteTx function on the target
chain (without going through the poly chain - because the keeper has been modied, the aacker can arbitrarily
sign blocks on the poly chain that seem reasonable to the target chain), and nally calls the Unlock function
(which belongs to the LockProxy contract), transferring a large amount of money and causing serious losses to
the project.
4.3 Cellframe Network Aack
On June 1, 2023, it is believed that Cellframe Network experienced a lightning credit aack on the Binance Smart
Chain as a result of token count discrepancies that arose during the liquidity migration process. e aackers
were able to obtain a prot of 245 BNBs. In Fig 4, the hackers acquired a sum of 1000 Binance Coins (BNBs)
through the employment of DPP’s ashloan mechanism, following which they utilized the ashloan functionality
of Pancake v3 to procure 500,000 units of New Cell tokens. Ultimately, the aackers concluded their assault by
converting 900 Binance Coin units into Old Cell tokens. According to Fig 3, we can see that the aacker adds the
liquidity of Old Cell and BNB before the aack to obtain the LP.Subsequently, the perpetrator proceeds to invoke
the liquidity migration procedure. Currently, the new pool contains a negligible amount of BNB tokens, while
the old pool holds an insignicant quantity of Old Cell tokens.
e process of migration primarily comprises the subsequent steps. Initially, the removal of liquidity from the
previous pool is executed, and the user is reimbursed with the corresponding amount of tokens. Subsequently,
the addition of fresh liquidity is carried out in a manner that is proportional to the new pool. Due to the scarcity
of Old Cell tokens in the old pool, the removal of liquidity results in an increase in the quantity of BNBs acquired,
accompanied by a decrease in the number of Old Cell tokens.
To enhance liquidity, users may deposit a nominal quantity of Binance Coin (BNB) and New Cell tokens, and
subsequently withdraw any surplus BNBs and Old Cell tokens. Subsequently, the migration process is reiterated.
Ultimately, the perpetrator withdraws the liquidity from the recently established pool and exchanges the migrated
Old Cell tokens for Binance Coins (BNBs). At present, the former pool possesses a considerable quantity of Old
Cell tokens sans BNBs, and the perpetrator proceeds to convert the Old Cell tokens into BNBs to realize the prot.
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 21
Fig. 4. Cellframe Aack Step
When formulating the migration liquidity plan for this event, it is imperative to consider the alterations in the
token count between the old and new pools, as well as the prevailing token valuation. Additionally, it is feasible
to manipulate the computation of the two coins’ quantity by executing transactions directly.
5 SECURITY SOLUTIONS AND BEST PRACTICES FOR CROSS-CHAIN BRIDGES
In this section, various strategies and solutions (as shown in Table 5) are outlined to address key security concerns
in cross-chain bridge projects.
5.1 Solutions for Smart Contract Vulnerabilities
Smart contract vulnerabilities pose signicant risks to cross-chain bridges. Here are several security solutions
specic to mitigate these risks.
5.1.1 Formal Verification. Formal Verication is a mathematical methodology that is employed to check and
prove the correctness of soware systems, including smart contracts, against a predened set of specications
[75]. is methodology is a pivotal technique used in mitigating the vulnerabilities of smart contracts.
In the context of smart contracts, Formal Verication methods enable developers and auditors to mathematically
prove that a contract meets its specication. is technique is particularly benecial when working with high-
value contracts where the potential risks of a aw are signicant. e Formal Verication process includes the
following steps:
(1)
Dene Specications. e rst step involves dening precise specications for the smart contract. ese
specications outline the desired behavior and the expected outcomes of the contract.
(2)
Mathematical Modeling. In this step, a mathematical model is constructed of the smart contract. is model is
an abstraction of the smart contract that includes all possible states the contract can reach.
(3)
Proof Construction. e last step is to construct a proof that demonstrates that the model of the smart contract
satises the specications under all possible conditions. If the proof can be constructed successfully, this means
that the smart contract does meet its specications.
Formal Verication uses techniques from logic and discrete mathematics. Tools that are commonly used for this
process include theorem provers and model checkers. eorem provers [
77
] are tools that are used to construct
and check the validity of mathematical proofs, whereas model checkers are tools that are used to automatically
check that a model of a system satises a set of properties. However, it’s worth noting that Formal Verication
can’t guarantee to nd all vulnerabilities, especially those that lie outside the dened specications or those that
come from an inaccurate specication. Hence, it is essential to use it in conjunction with other methods like
Distrib. Ledger Technol.
22 • Li, et al.
Table 5. Security Solutions for Cross-Chain Bridges
Security Concern Solutions
Smart Contract Vulnerabilities •Formal Verication
•Upgradable Contracts
•Error Handling
Centralization Risk •Multi-Signature
•Token Governance
Liquidity Issues •Imbalanced Liquidity
•Flash Loan Aacks
•Withdrawal Aacks
Oracle Manipulations •Decentralization
•Reputation Systems
•Data Fluctuation Limits
•Anti-Manipulation Measures
security audits, manual code reviews, and automated testing to ensure the maximum security of cross-chain
smart contracts.
5.1.2 Upgradable Smart Contracts. Upgradable Smart Contracts are contracts that can be altered post-deployment
[
15
], thereby allowing developers to rectify discovered aws or add new functionalities. ey provide a signicant
method to mitigate cross-chain smart contract vulnerabilities, and with proper design, they can maintain system
integrity and ensure consistent behavior. e implementation of upgradable smart contracts typically involves a
two-contract system: (1) Logic Contract. e logic contract houses the main business logic of the application. Its
code contains the rules and processes required for executing the application’s functionalities; (2) Proxy Contract.
e proxy contract manages access to the logic contract and handles data storage. It also contains an upgrade
mechanism that permits a designated address to switch the logic contract it points to.
When a user interacts with the contract, the call is sent to the proxy contract, which then delegates the
call to the logic contract. is indirection allows the logic contract to be swapped out for a dierent one if
upgrades or bug xes are required. It’s important to note that only the logic of the contract can be altered,
while the state, including the balances and data, remain consistent. However, it’s crucial to ensure that this
upgrade mechanism does not become a security vulnerability itself. Proper authorization checks and timelocks
are essential to prevent unauthorized upgrades. e ability to upgrade contracts can greatly improve the security
of a contract by allowing known vulnerabilities to be patched. But, it introduces an additional layer of complexity
and potential centralization, so careful thought must be given to who has the power to perform upgrades and
under what conditions.
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 23
5.1.3 Consistent Error Handling. When it comes to cross-chain environments, developers should be aware of
the unique diculties associated with the consistent handling of errors across multiple chains, which may have
distinct behaviors and practices. ey need to ensure that error-handling practices are consistent across all chains
and compatible with their respective standards and procedures. Here are three key considerations in ensuring
consistent error handling across cross-chain smart contracts.
•
Revert Operations: in the blockchain, a rollback operation is a mechanism that undoes all modications to a
contract’s state in the event of an error or exception. If an operation cannot be completed eectively, it is crucial
that the contract is not le in an inconsistent or improper state. is is crucial in a cross-chain environment
where a transaction may span multiple chains. If an error occurs on one chain, the eects of that transaction
must be restored on all other chains. is necessitates a coordinated, cross-chain recovery operation, which
can be dicult to execute due to the independence of the various chains. It is essential to design contracts and
cross-chain communication mechanisms so that recovery on one chain can initiate recovery operations on all
participating chains.
•
Fallback function: the fallback function is a function included in the smart contract. ere are undened
functions or no data in the transaction when the contract is invoked. ese operations will be performed. It
is a crucial error-handling mechanism that prevents unanticipated behavior. In a cross-chain environment,
the failsafe function might be even more important. If a contract on one chain invokes a function on another
contract that does not exist on the chain, the transaction requires proper handling to avoid failing silently or
behaving unexpectedly. A well-dened failsafe function is essential to be activated instead. Designing and
administering these fallback functions across various chains is challenging, as it requires knowledge and
management of the distinct behaviors and conventions of each chain.
•
Error Propagation: if an error occurs on one chain when a function is invoked across chains, the error must be
propagated to the originating chain. e originating chain must be informed of the unsuccessful transaction
and its reason. Without appropriate error propagation, the originating chain may erroneously conclude that
the transaction was successful, resulting in incorrect contract states and potential security issues. To propagate
errors across chains, a communication protocol that can transmit error messages across chains must be designed.
is protocol must be secure, dependable, and compatible with the diverse technologies and standards of each
chain.
5.2 Solutions for Centralization Risk
Centralization risk can lead to a range of problems as introduced in Section III. Here are some solutions to mitigate
centralization risk in cross-chain bridges.
5.2.1 Multi-Signature and Threshold Schemes. Multi-Blockchain technology’s signature schemes are a crucial
component of its security and are especially well-suited for cross-chain bridging. ese techniques make it more
dicult for malevolent parties to control by requiring several keys to allow transactions.
e multiple signature feature [
55
] in cross-chain bridges can be used in the following ways. (a) Multiple party
consent is required for transactions via the bridge. (b) e transaction must be “signed” by a minimum number of
“signers” in order to be accepted. ese signatories can represent various blockchain initiatives or communities
that are involved in the cross-chain bridge. With this plan, there is far less chance of a single point of failure and
malicious behavior because numerous parties would have to work together to corrupt the system.
Alternative methods of decentralized control in cross-chain bridges include threshold approaches. A multiple-
signature technique known as a threshold scheme requires “m” out of a total of “n” signatures to complete a
transaction. is can be referred to as a threshold system (m, n), where “m” is the minimum number of signatures
needed to complete an operation and “n” is the total number of participants. e exibility oered by the threshold
approach is its principal benet. For instance, any two of the three parties can validate the transaction in the
Distrib. Ledger Technol.
24 • Li, et al.
(2, 3) threshold scheme. is strikes a balance between fault tolerance (the system can still function even if one
side is unavailable) and security (no one entity can control the bridge). Dierent network veriers may act as
signatories in the case of a cross-chain bridge. Only when a predetermined number of these veriers arm a
transaction can we consider it genuine. By carefully selecting the appropriate thresholds, the requirement for
decentralization can be matched with pragmatic factors like eciency and fault tolerance.
In order to lessen the risk of centralization, multi-signature and threshold systems both make it more dicult
to unilaterally disrupt the system. Proper construction of these functions is essential to account for the unique
requirements and characteristics of cross-chain bridges, as they can complicate transactions and slow them down.
5.2.2 Token-based governance. Token-based governance [
82
] is a decentralized governance model where decision-
making power in the system is linked to the number of governance tokens held by an individual or entity. It
represents a form of stakeholder governance that is especially suited to blockchain-based systems and can play a
crucial role in mitigating the centralization risk associated with cross-chain bridges. In a token-based governance
model, the governance tokens are typically distributed among many participants, making it dicult for a single
party to control the majority of the tokens. is ensures a more democratic process, reducing the possibility
of any single entity or small group controlling the decision-making process. e distribution of governance
tokens also gives token holders voting rights on proposals that can shape the future direction and strategy of the
platform. ese rights are typically implemented and enforced through a smart contract. Each governance token
held equates to one vote. is “1 token = 1 vote” rule is enforced through a smart contract on the blockchain. e
smart contract can be designed to count the number of tokens held in a user’s wallet at the time of voting to
determine the number of votes they are allowed to cast.
To encourage participation in the governance process, various incentives can be designed into the Token-based
governance model. Token staking or locking serves to incentivize user participation and align the interests of
users with the long-term success of the platform. e staking contract species a period during which the tokens
are locked. Users would only be able to withdraw their staked tokens aer the specied staking duration ends.
Besides, token holders who actively participate in the governance process can be rewarded with additional tokens.
is can be implemented through a reward distribution smart contract which tracks voting participation and
distributes rewards accordingly. Another way to encourage participation is through the implementation of a
reputation system. Token holders who regularly participate and contribute to the governance process can gain
reputational scores or badges, which can come with various benets. Conversely, slashing mechanisms can be
implemented as a punitive measure. If a user behaves maliciously or does not fulll their network obligations,
some or all of their staked tokens can be slashed or forfeited. In addition, some token holders may not have
the time, interest, or knowledge to actively participate in governance. Delegation allows these token holders to
delegate their voting power to a trusted party who votes on their behalf.
5.3 Solutions for Liquidity Issues
In blockchain systems, liquidity issues involve complications in swily converting digital assets into cash without
aecting market prices. ese complications arise from imbalances in supply and demand for specic assets,
causing inecient transactions, high slippage, and potential transaction failures, as detailed in Section 3. e
following sections present proposed solutions to these issues.
5.3.1 Imbalanced liquidity. e challenge of imbalanced liquidity in cross-chain bridges has aracted the aention
of numerous researchers and industry experts due to the systemic risks that arise from over-reliance on a single
chain, thus creating a single point of failure. Several countermeasures, both functional and security-related, have
been proposed to address these risks. Among the myriad of proposed solutions, three stand out due to their
potential impact and practicality: Smart Contract Controls, Multi-Signature Processes, and Regular Audits.
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 25
Smart Contract Controls serve as regulatory frameworks within the blockchain environment, enforcing
predened rules to control and stabilize liquidity across various chains. ese automated contracts limit the
volume of asset transfers between chains within specied timeframes, thereby preventing large, precipitous shis
in liquidity that could destabilize the system. Multi-Signature Processes introduce an additional layer of security.
By requiring multiple, trustworthy entities to approve large transactions or changes in asset distribution, these
processes add an additional hurdle for potential malicious activities, reducing the likelihood of destabilizing
actions that could lead to liquidity imbalances.
Lastly, the role of Regular Audits in maintaining balanced liquidity cannot be overstated. By systematically
reviewing the operations and liquidity distributions of cross-chain bridges, potential issues can be detected
early and addressed promptly. Automated audits, in particular, can provide regular checks on liquidity balances,
contributing to the stability of the system. While these solutions oer a robust defense against imbalanced
liquidity, a comprehensive approach tailored to the unique architecture and design of each specic cross-chain
bridge is crucial to ensure long-term stability. It is also worth noting that this eld continues to evolve, and new
solutions to address imbalanced liquidity are continually being explored and developed.
5.3.2 Flash loan aacks. In response to the prominent threat of ash loan aacks [
104
] within the decentralized
nance (DeFi) landscape, particularly within cross-chain bridges as detailed in Section 3, it is essential to delve
into potential mitigating strategies. In the context of cross-chain bridges, an eective approach prominently
encompasses three countermeasures: the deployment of Price Oracles, the introduction of time delays on price
updates, and the execution of regular audits.
Price Oracles serve as a fundamental line of defense against market price manipulation, a common feature in
ash loan aacks. By sourcing accurate and timely price data from a multitude of platforms, these oracles furnish
a more comprehensive and robust picture of asset prices. Such a mechanism diminishes the feasibility of single-
point price manipulation, thereby curtailing the potential success of ash loan aacks. Next, the incorporation
of time delays on price updates represents a strategic disruption to the typical modus operandi of ash loan
aacks. ese aacks necessitate the completion of several actions within a single transaction block. Introducing
a time delay can impede this swi execution, thereby weakening an aacker’s ability to articially alter prices
eectively within the requisite timeframe. Finally, the practice of regular audits emerges as a critical component
in maintaining secure cross-chain bridges. Regular audits, particularly those employing automated tools, facilitate
the early identication and rectication of potential vulnerabilities that could be exploited in ash loan aacks.
In conclusion, while numerous strategies can be deployed in the defense against ash loan aacks, the triad
of Price Oracles, time delays on price updates, and regular audits stand out in their combined ecacy and
proactive approach. As the DeFi ecosystem continues to evolve, so do its threats, necessitating continual vigilance,
assessment, and adaptation of these and other security measures.
5.3.3 Liquidity withdrawal aacks. In response to the Liquidity Withdrawal or ’Rug Pull’ aacks outlined in
Section 3, two key countermeasures present themselves as notable defenses in the context of cross-chain bridges:
Multi-Signature Processes and Reputation Systems. Implementing Multi-Signature Processes serves as an eective
control mechanism, imposing an additional layer of security. is process necessitates the concurrent authorization
of multiple trusted entities, particularly for sizeable transactions, thereby curtailing the feasibility of sudden,
large-scale withdrawals. On the other hand, the deployment of Reputation Systems acts as a preventative deterrent
against potential ’Rug Pull’ aacks. ese systems assign trust scores to liquidity providers, predominantly based
on their historical contributions and performance. High scores, correlating with consistent, reliable behavior, are
challenging for potential aackers to achieve. Consequently, this reduces the likelihood of them being able to
execute a large-scale withdrawal.
In brief, these two strategies, in conjunction with vigilant and dynamic system monitoring, form a robust
defense against Liquidity Withdrawal aacks, thereby enhancing the stability and integrity of cross-chain bridges.
Distrib. Ledger Technol.
26 • Li, et al.
5.4 Solution for Oracle Manipulations
To confront the considerable risk of oracle manipulation within cross-chain bridges, as mentioned in Section 3, a
comprehensive strategy is essential. e following discourse oers an exhaustive analysis of the most signicant
solutions to this security concern.
5.4.1 Decentralization of oracles. is concept refers to the distribution of authority across a network of multiple
data providers or oracles, as opposed to a single, central oracle. By design, a decentralized oracle network is
less susceptible to a single point of failure or manipulation, thus providing enhanced security and resilience.
e principle of decentralization rests on distributing the task of data provision across numerous oracles. is
approach eectively reduces the system’s reliance on any single oracle, diversifying the potential risk associated
with any single data source.
When addressing the issue of oracle manipulation in a cross-chain context, decentralization plays a critical role.
If an oracle were to be compromised or manipulated, the presence of multiple, independent oracles ensures that
the system can identify and diminish the inuence of anomalous data. When one oracle deviates signicantly
from the others in data provision, the system can disregard this anomaly or reduce its weight in computations. As
a result, the decentralized approach bolsters the system’s resilience against specic oracle manipulation, ensuring
a more secure, reliable data feed for the cross-chain bridge.
5.4.2 Oracle reputation systems. is concept alludes to a method employed within the blockchain milieu,
assigning a comparative ranking or ’credit score’ to each oracle predicated on its history of supplying accurate,
consistent data. e operative principle of Oracle Reputation Systems rests upon the balance of reward and
penalty. In these structures, oracles undergo perpetual assessment, with their ranking being contingent upon
their historical performance and data reliability. Oracles that maintain a standard of accuracy are conferred a
higher ranking as a reward, whereas those identied with a record of inconsistency or inaccuracy incur a lower
ranking as a penalty. is established ranking subsequently informs the weight accorded to the data each oracle
supplies within the system. Oracles of higher rank, possessing a veried record of reliability, have their data
accorded increased weight within the system.
In the context of mitigating oracle manipulation issues in cross-chain bridges, Oracle Reputation Systems
present a potent tool. By fostering accurate reporting via incentives and deterring inconsistency or manipulation
via penalties, these systems act to dissuade oracles from supplying manipulated data. Should an oracle be
compromised and commence the delivery of inaccurate data, its ranking would experience a swi decline,
thereby reducing the inuence of its manipulated data within the system. In contrast, oracles of higher rank that
consistently deliver accurate data present a formidable challenge for malicious actors seeking to impersonate or
manipulate them. Consequently, the security of the cross-chain bridge and the integrity of its operations are
bolstered.
5.4.3 Data fluctuation thresholds and limits. is term signies predened benchmarks within a blockchain
system that set acceptable ranges for data variability. It acts as a safeguard to maintain the integrity of the data
supplied by oracles and prevents extreme uctuations that could indicate manipulation or inaccuracies. e
way these thresholds and limits work is by seing an allowable range for data inputs from oracles. If the data
provided by an oracle exceeds these predetermined boundaries, it can be agged for potential anomalies. is
could indicate manipulation or a malfunction in the oracle, prompting the system to react accordingly.
In terms of mitigating oracle manipulation issues within cross-chain bridges, Data Fluctuation resholds
and Limits serve as an eective preventative tool. When an oracle’s data breaches these predened limits, it can
trigger protective measures within the system. For example, the system might pause transactions to prevent
potential damage, or disregard the data from the suspicious oracle until further investigation. is mechanism, in
essence, provides an early warning system that alerts to potential manipulation. By enabling timely intervention,
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 27
it helps to preserve the integrity of the system’s operations and prevent potential risks associated with oracle
manipulation.
5.4.4 Anti-manipulation measures. In the analysis of potential solutions for tackling the security issues outlined
in Section 3, namely Data Feed Manipulation, Oracle Identity e, and Sybil Aacks, it is pertinent to explore
the application of Decentralization of Oracles, Oracle Reputation Systems, and Data Fluctuation resholds and
Limits. e ensuing discourse seeks to elucidate how these strategies contribute to mitigating the aforementioned
security concerns in the context of cross-chain bridges.
Data Feed Manipulation. e practice of Decentralization of Oracles emerges as a viable solution to this
problem. By dispersing the responsibility of data provision amongst multiple oracles rather than relying on a
singular entity, the system drastically diminishes the risk associated with a single point of manipulation. Each
oracle functions independently, thus any signicant deviation in data from one oracle can be identied and
handled appropriately. is decentralization presents a robust countermeasure against data feed manipulation,
ensuring data integrity by cross-verifying data inputs across numerous oracles.
Oracle Identity e. e implementation of Oracle Reputation Systems proves instrumental in combating
this type of aack. ese systems work on the basis of assigning a trust score or rank to oracles based on their
performance history. A high-ranking oracle, by virtue of its consistent and reliable data provision, establishes
a level of trust that is hard for a malicious actor to replicate. Consequently, any aempt to impersonate a
high-ranking oracle can be eectively identied and neutralized, thus thwarting oracle identity the.
Sybil Attacks. In the case of Sybil aacks [
100
], where a malicious actor creates multiple false identities to
dominate the network, both Decentralization of Oracles and Oracle Reputation Systems can be leveraged for
defense. e decentralized model reduces the impact of any single oracle, thereby limiting the potential damage
inicted by a Sybil aack. On the other hand, Oracle Reputation Systems prevents malicious actors from gaining
inuence since it would require a substantial amount of time and consistency to earn a high trust score.
In conclusion, the combination of decentralization of oracles, oracle reputation systems, and data uctuation
thresholds and limits oers a comprehensive strategy to eectively address the security risks of data feed
manipulation, oracle identity the, and Sybil aacks in cross-chain bridges.
rough a close examination of Decentralization of Oracles, Oracle Reputation Systems, and Data Fluctuation
resholds and Limits, it becomes clear that each oers unique strengths in addressing dierent aspects of oracle
manipulation threats. When these measures are integrated eectively, they have the potential to provide a robust
defense against Data Feed Manipulation, Oracle Identity e, and Sybil Aacks. However, it is essential to
recognize that oracle manipulation threats are dynamic and ever-evolving. As such, these measures are not
static solutions but components of a proactive and multi-layered approach that requires ongoing adjustment
and optimization. It is incumbent upon system operators to continually monitor and adapt these mechanisms in
response to the evolving threat landscape inherent in the blockchain ecosystem.
6 CHALLENGES AND OPEN RESEARCH ISSUES
e integration of trustless cross-chain bridges and layer-2 solutions poses several challenges that must be
addressed to ensure secure and ecient blockchain interoperability. is section outlines the primary challenges
and explores the open research issues essential for advancing these technologies.
6.1 Challenges and Limitations
6.1.1 Security of trustless cross-chain bridges. e development and deployment of trustless cross-chain bridges
present numerous challenges and limitations. ese challenges span across security, operational complexity, and
technical execution.
Distrib. Ledger Technol.
28 • Li, et al.
Challenge 1: Complexity of Implementing Trustless Mechanisms. Implementing trustless mechanisms
in cross-chain bridges is inherently complex due to the need for sophisticated cryptographic techniques and
protocols. Trustless cross-chain transactions aim to minimize or eliminate reliance on third-party veriers or
intermediaries. To achieve this, advanced mechanisms such as hash-locked transfers [
47
] and state channels [
78
]
are employed. ese techniques must be meticulously designed and rigorously tested to ensure they can securely
manage the transfer of assets between dierent blockchains without introducing vulnerabilities. For example,
ensuring the correct implementation of hash-locked transfers involves handling cryptographic hash functions
securely and managing the lifecycle of locks and secrets eectively.
Challenge 2: Security of Cross-chain Contracts. Traditional liquidity swap mechanisms [
24
,
44
] require
users to lock liquidity in a contract on the originating chain, creating potential points of vulnerability. ese
contracts are prime targets for aacks, as evidenced by past security incidents involving Chainswap [
7
] and
Multichain [
5
], where vulnerabilities were exploited to steal funds. e proposed model aims to mitigate these
risks by eliminating the need for cross-chain contracts to hold funds. However, this introduces new security
considerations, such as ensuring the integrity and security of hash-locked transfers and the node addresses
involved in the transactions. Robust security measures must be in place to protect against unauthorized access
and manipulation.
Challenge 3: Security of Cross-chain Messaging Mechanisms. e cross-chain messaging mechanism
[
91
,
98
] is crucial for coordinating asset transfers between chains, but it also poses signicant security challenges.
Vulnerabilities in the messaging system can be exploited to forge fraudulent messages or compromise the private
keys of veriers, leading to unauthorized transactions and nancial losses. Ensuring the security and reliability of
the cross-chain messaging mechanism requires robust cryptographic solutions and multiple layers of verication
to prevent such aacks. For instance, using decentralized or multi-signature verication processes can enhance
security but also adds complexity to the system [
108
]. Additionally, ensuring the timely and accurate delivery of
messages across dierent blockchain networks is a persistent challenge.
Challenge 4: Reliance on External Veriers. Even in trustless systems, there are scenarios where external
veriers are necessary. is reliance introduces additional risks and complexities. Ensuring that these external
veriers operate securely and that the messages they deliver are authenticated and tamper-proof is crucial.
Techniques such as multiple checksums [
13
], decentralized verication processes [
71
], and rigorous validator
selection criteria [
10
] can help mitigate these risks. However, implementing these solutions can be resource-
intensive and may require sophisticated coordination among multiple parties. Additionally, the potential for
collusion among veriers or the compromise of a majority of veriers poses a signicant threat to the integrity
of the cross-chain bridge.
6.1.2 Integrating cross-chain bridging protocols with layer-2 solutions. Combining cross-chain bridging protocols
with layer-2 solutions has gained signicant aention recently. Layer 2 solutions aim to alleviate scalability issues
by processing transactions o the main chain (Layer 2) and then posting the results onto the main chain (layer
1) [
42
]. When combined with cross-chain bridges, it allows for scalable and ecient transfer of assets between
dierent blockchains. However, it presents several challenges and limitations that need to be addressed to realize
their full potential. ese challenges are multifaceted and span across technical and security domains.
Challenge 5: Diversity of Layer-2 Solutions. Each layer-2 solution, such as Optimistic Rollups [
57
], zkRollups
[
102
], and Plasma [
84
], utilizes dierent mechanisms to achieve scalability, which complicates the integration
process. Each solution has unique characteristics and operational requirements, making it dicult to select
the most suitable one for a specic use case. e decision largely depends on the specic needs of the cross-
chain bridging use case, such as the priority given to transaction speed, cost-eciency, or enhanced security.
Additionally, ensuring that the chosen layer-2 solution can interoperate seamlessly with the existing cross-chain
bridge infrastructure is complex, given the lack of standardized protocols across dierent layer-2 solutions.
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 29
Challenge 6: Customization of Cross-chain Bridging Protocols. Customization of cross-chain bridging
protocols to accommodate layer-2 solutions poses another signicant challenge [
83
]. Integrating a layer-2 solution
oen necessitates modications to existing smart contracts or the creation of new ones, tailored to the specic
operational models of the layer-2 solutions. is process can be resource-intensive and prone to errors. Moreover,
cross-chain bridges typically rely on validators and relays to facilitate transactions between dierent blockchains.
Adjusting these components to ensure eective interaction with the layer-2 protocols is essential but challenging.
Developing interfaces that allow seamless interaction between the cross-chain bridge and the layer-2 solution
is also crucial. is includes designing APIs and middleware capable of handling the specic communication
protocols and data formats used by layer-2 solutions.
Challenge 7: Security Considerations. One of the primary concerns with layer-2 solutions is ensuring data
availability. Since o-chain transaction processing is a core feature of layer-2 solutions, it introduces risks related
to data integrity and accessibility [
40
]. If data is not reliably available, it can compromise the security and
functionality of the cross-chain bridge. Maintaining consistency across multiple blockchains and layer-2 solutions
is also a complex challenge, as any inconsistency can lead to discrepancies in transaction records, potentially
resulting in nancial losses or system vulnerabilities. Furthermore, integrating layer-2 solutions with cross-chain
bridges may introduce new aack vectors [
50
]. e interaction between dierent consensus mechanisms and
security models can create unforeseen vulnerabilities that malicious actors could exploit. Implementing robust
security protocols to safeguard against these new threats is crucial, but ensuring that these protocols are both
eective and ecient remains a signicant challenge.
6.2 Open Research Issues (ORI)
Developing trustless cross-chain bridges and layer-2 integrated solutions presents numerous open research issues
that need to be addressed to enhance their security, scalability, and operational eciency. e following research
areas are crucial for advancing the state of the art in cross-chain bridge technologies.
6.2.1 Enhancing trustless cross-chain bridges. Enhancing trustless cross-chain bridges involves addressing various
technical and security challenges. Several open research issues are critical for advancing the development of
trustless cross-chain bridges.
ORI 1: Advanced Cryptographic Techniques. ere is a need for continued research into advanced crypto-
graphic techniques that can support trustless mechanisms in cross-chain bridges. Existing works, such as the
implementation of hash-locked transfers in the Lightning Network [?] and state channels in Celer Network [
3
],
provide foundational techniques for secure and ecient o-chain transactions. Future research ought to focus on
optimizing these techniques to handle large volumes of transactions securely and eciently, minimizing the risk
of vulnerabilities and ensuring seamless interoperability between dierent blockchain networks.
ORI 2: Formal Verication Methods. e complexity of trustless mechanisms necessitates the use of formal
verication methods to ensure their correctness and security. Existing research on formal verication of smart
contracts, such as the work by Bhargavan et al. on verifying Ethereum smart contracts [
18
], highlights the
potential for reducing vulnerabilities through rigorous analysis. Future research could explore the application
of formal verication techniques to cryptographic protocols and smart contracts used in cross-chain bridges,
helping to identify and mitigate potential vulnerabilities before they can be exploited.
ORI 3: Robust Cross-chain Messaging Protocols. Ensuring the security and reliability of cross-chain messaging
mechanisms is a signicant challenge. Protocols like Interledger [
36
] provide a foundation for secure cross-chain
communication. Future research could aim to develop robust messaging protocols that incorporate multi-layered
security measures, such as decentralized or multi-signature verication processes. Additionally, exploring new
cryptographic methods to secure message delivery and prevent fraudulent activities is essential.
Distrib. Ledger Technol.
30 • Li, et al.
ORI 4: Enhanced Verier Security. Given the reliance on external veriers in some scenarios, it is crucial to
enhance their security. Techniques such as multiple checksums and decentralized verication processes have been
proposed in existing works, like the Tendermint consensus algorithm [
14
]. Research is suggested to investigate
techniques to improve the resilience of veriers against aacks, including studying the potential for verier
collusion and developing countermeasures to prevent it.
6.2.2 Facilitating Layer-2 solution with cross-chain. Integrating layer-2 solutions with cross-chain bridges is a
promising approach to enhancing scalability and eciency. Several future research directions were identied to
ensure seamless and secure integration.
ORI 5: Standardization of Layer-2 Protocols. Existing standardization eorts, such as the Plasma framework
[
84
] and zk-Rollup implementations [
102
], provide initial steps toward standardizing layer-2 protocols. Research
should focus on the standardization of protocols across dierent layer-2 solutions to facilitate seamless interoper-
ability with cross-chain bridges. Establishing common standards and interfaces will help reduce complexity and
improve the eciency of integration eorts.
ORI 6: Dynamic Customization Techniques. Modular and exible smart contract architectures, as explored
in the Arbitrum protocol [
53
], oer potential solutions for the customization of cross-chain bridging protocols.
Research could explore dynamic customization techniques that can adapt to the specic requirements of dierent
layer-2 solutions, facilitating easier integration and reducing the likelihood of errors.
ORI 7: Data Availability and Consistency Solutions. Decentralized storage solutions like IPFS [
17
] and
mechanisms for maintaining data integrity, such as those used in the Filecoin network [
85
], provide valuable
insights for layer-2 solutions. Future research is suggested to investigate new methods for guaranteeing data
availability, even in o-chain environments, ensuring that cross-chain transactions remain secure and consistent.
7 CONCLUSION
e present research is focused on conducting a comprehensive investigation into the security concerns, and
corresponding remedial measures pertaining to cross-chain bridges within the blockchain domain. e overview
of the fundamental concepts, classications, and working principles underlying cross-chain bridges provides a
sucient theoretical foundation for the subsequent analysis and enables us to gain a deeper understanding of the
security characteristics of these prominent cross-chain projects.
In this study, we present a comprehensive analysis of the fundamental security obstacles that cross-chain bridges
encounter. ese challenges encompass vulnerabilities in smart contracts, risks associated with centralization,
liquidity concerns, and the potential for Oracle manipulations. For each risk, we provide the most innovative
solutions and defense strategies. Additionally, by analysing real-world cases, it has been observed that cross-chain
bridge initiatives, including ChainSwap, Poly Network, and Cellframe Network, have implemented a range of
security measures that have proven to be eective. For future work, we believe that cross-chain bridge integration
with Layer-2 and the security of trustless cross-chain bridges represent promising areas for further exploration
and research.
REFERENCES
[1] Paxos regulated blockchain. https://paxos.com/, 2012.
[2] Wanchain bridge. https://www.wanchain.org/, 2017.
[3] Celer network. https://celer.network/, 2018.
[4] Liquid network. https://liquid.net/, 2018.
[5] Multichain cross-chain router protocol. https://multichain.xyz/, 2020.
[6] Orbit bridge. https://bridge.orbitchain.io/, 2020.
[7] Chainswap cross-chain hub. https://chainswap.com/, 2021.
[8] orchain. https://thorchain.org/, 2021.
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 31
[9] Voltswap. https://voltswap.finance/home, 2022.
[10]
Hamra Afzaal, Muhammad Imran, Muhammad Umar Janjua, and Sarada Prasad Gochhayat. Formal modeling and verication of a
blockchain-based crowdsourcing consensus protocol. Ieee Access, 10:8163–8183, 2022.
[11]
Rahul Agrawal, Pratik Verma, Rahul Sonanis, Umang Goel, Aloknath De, Sai Anirudh Kondaveeti, and Suman Shekhar. Continuous
security in iot using blockchain. In 2018 IEEE international conference on acoustics, speech and signal processing (ICASSP), pages
6423–6427. IEEE, 2018.
[12]
Hamda Al-Breiki, Muhammad Habib Ur Rehman, Khaled Salah, and Davor Svetinovic. Trustworthy blockchain oracles: review,
comparison, and open research challenges. IEEE Access, 8:85675–85685, 2020.
[13]
Ahmed Alhussen and Engin Arslan. Rivachain: Blockchain-based integrity verication for le transfers. In 2020 IEEE International
Conference on Big Data (Big Data), pages 3255–3261. IEEE, 2020.
[14]
Yackolley Amoussou-Guenou, Antonella Del Pozzo, Maria Potop-Butucaru, and Sara Tucci-Piergiovanni. Correctness of tendermint-
core blockchains. In 22nd International Conference on Principles of Distributed Systems (OPODIS 2018). Schloss Dagstuhl-Leibniz-Zentrum
fuer Informatik, 2018.
[15]
Shaima AL Amri, Leonardo Aniello, and Vladimiro Sassone. A review of upgradeable smart contract paerns based on openzeppelin
technique. e Journal of e British Blockchain Association, 2023.
[16]
Fadi Barbàra and Claudio Schifanella. Bxtb: cross-chain exchanges of bitcoins for all bitcoin wrapped tokens. In 2022 Fourth International
Conference on Blockchain Computing and Applications (BCCA), pages 143–150. IEEE, 2022.
[17] Juan Benet. Ipfs-content addressed, versioned, p2p le system. arXiv preprint arXiv:1407.3561, 2014.
[18]
Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cédric Fournet, Anitha Gollamudi, Georges Gonthier, Nadim Kobeissi, Natalia
Kulatova, Aseem Rastogi, omas Sibut-Pinote, Nikhil Swamy, et al. Formal verication of smart contracts: Short paper. In Proceedings
of the 2016 ACM workshop on programming languages and analysis for security, pages 91–96, 2016.
[19]
MENG Bo, WANG Yibing, ZHAO Can, WANG Dejun, and MA Binhao. Survey on cross-chain protocols of blockchain. Journal of
Frontiers of Computer Science & Technology, 16(10):2177.
[20]
Je Burdges, Alfonso Cevallos, Peter Czaban, Rob Habermeier, Syed Hosseini, Fabio Lama, Handan Kilinc Alper, Ximin Luo, Fatemeh
Shirazi, Alistair Stewart, et al. Overview of polkadot and its design considerations. arXiv preprint arXiv:2005.13456, 2020.
[21]
Chaimade Busayatananphon and Ekkarat Boonchieng. Financial technology de protocol: A review. In 2022 Joint International
Conference on Digital Arts, Media and Technology with ECTI Northern Section Conference on Electrical, Electronics, Computer and
Telecommunications Engineering (ECTI DAMT & NCON), pages 267–272. IEEE, 2022.
[22]
Wei Cai, Zehua Wang, Jason B Ernst, Zhen Hong, Chen Feng, and Victor CM Leung. Decentralized applications: e blockchain-
empowered soware system. IEEE access, 6:53019–53033, 2018.
[23] Giulio Caldarelli. Understanding the blockchain oracle problem: A call for action. Information, 11(11):509, 2020.
[24] Agostino Capponi and Ruizhe Jia. e adoption of blockchain-based decentralized exchanges. arXiv preprint arXiv:2103.08842, 2021.
[25]
Federico Cernera, Massimo La Morgia, Alessandro Mei, and Francesco Sassi. Token spammers, rug pulls, and sniperbots: An analysis
of the ecosystem of tokens in ethereum and the binance smart chain (bnb). arXiv preprint arXiv:2206.08202, 2022.
[26]
Federico Cernera, Massimo La Morgia, Alessandro Mei, and Francesco Sassi. Token spammers, rug pulls, and sniper bots: An analysis
of the ecosystem of tokens in ethereum and in the binance smart chain (
{{{{{
BNB
}}}}}
). In 32nd USENIX Security Symposium
(USENIX Security 23), pages 3349–3366, 2023.
[27]
Huashan Chen, Marcus Pendleton, Laurent Njilla, and Shouhuai Xu. A survey on ethereum systems security: Vulnerabilities, aacks,
and defenses. ACM Computing Surveys (CSUR), 53(3):1–43, 2020.
[28]
Zhiyang Chen, Sidi Mohamed Beillahi, and Fan Long. Flashsyn: Flash loan aack synthesis via counter example driven approximation.
arXiv preprint arXiv:2206.10708, 2022.
[29]
Paul Cue. e role of the erc-20 token standard in a nancial revolution: the case of initial coin oerings. In IEC-IEEE-KATS Academic
Challenge, Busan, Korea, 22-23 October 2018. IEC-IEEE-KATS, 2018.
[30] Chris Dannen. Introducing Ethereum and solidity, volume 1. Springer, 2017.
[31]
Vikram Dhillon, David Metcalf, Max Hooper, Vikram Dhillon, David Metcalf, and Max Hooper. e dao hacked. Blockchain Enabled
Applications: Understand the Blockchain Ecosystem and How to Make it Work for You, pages 113–128, 2021.
[32]
Li Duan, Yangyang Sun, Wei Ni, Weiping Ding, Jiqiang Liu, and Wei Wang. Aacks against cross-chain systems and defense approaches:
A contemporary survey. IEEE/CAA Journal of Automatica Sinica, 10(8):1647–1667, 2023.
[33]
Pankaj Dua, Tsan-Ming Choi, Surabhi Somani, and Richa Butala. Blockchain technology in supply chain operations: Applications,
challenges and research opportunities. Transportation research part e: Logistics and transportation review, 142:102067, 2020.
[34]
Gabriel Estevam, Lucas M Palma, Luan R Silva, Jean E Martina, and Martin Vigil. Accurate and decentralized timestamping using
smart contracts on the ethereum blockchain. Information Processing & Management, 58(3):102471, 2021.
[35] Ede Eykholt, Lucius Gregory Meredith, and Joseph Denman. Rchain architecture documentation. Retrieve. Jan, 19:2019, 2017.
[36]
Ghareeb Falazi, Uwe Breitenbücher, Frank Leymann, and Stefan Schulte. Cross-chain smart contract invocations: a systematic
multi-vocal literature review. ACM Computing Surveys, 56(6):1–38, 2024.
Distrib. Ledger Technol.
32 • Li, et al.
[37]
Xiaotao Feng, Xiaogang Zhu, Qing-Long Han, Wei Zhou, Sheng Wen, and Yang Xiang. Detecting vulnerability on iot device rmware:
A survey. IEEE/CAA Journal of Automatica Sinica, 10(1):25–41, 2022.
[38]
Simon Fernandez-Vazquez, Rafael Rosillo, David De La Fuente, and Paolo Priore. Blockchain in ntech: A mapping study. Sustainability,
11(22):6366, 2019.
[39]
Philipp Frauenthaler, Marten Sigwart, Christof Spanring, Michael Sober, and Stefan Schulte. Eth relay: A cost-ecient relay for
ethereum-based blockchains. In 2020 IEEE International Conference on Blockchain (Blockchain), pages 204–213. IEEE, 2020.
[40]
Ankit Gangwal, Haripriya Ravali Gangavalli, and Apoorva irupathi. A survey of layer-two blockchain protocols. Journal of Network
and Computer Applications, 209:103539, 2023.
[41]
Alex Groce, Josselin Feist, Gustavo Grieco, and Michael Colburn. What are the actual aws in important smart contracts (and how can
we nd them)? In Financial Cryptography and Data Security: 24th International Conference, FC 2020, Kota Kinabalu, Malaysia, February
10–14, 2020 Revised Selected Papers 24, pages 634–653, 2020.
[42]
Lewis Gudgeon, Pedro Moreno-Sanchez, Stefanie Roos, Patrick McCorry, and Arthur Gervais. Sok: Layer-two blockchain protocols.
In Financial Cryptography and Data Security: 24th International Conference, FC 2020, Kota Kinabalu, Malaysia, February 10–14, 2020
Revised Selected Papers 24, pages 201–226. Springer, 2020.
[43]
Zhaozhong Guo, Liucheng Shi, and Maozhi Xu. Secrand: A secure distributed randomness generation protocol with high practicality
and scalability. IEEE Access, 8:203917–203929, 2020.
[44]
Ruchi Gupta, Mandeep Gupta, and Deepanshu Gupta. Role of liquidity pool in stabilizing value of token. Scientic Journal of Metaverse
and Blockchain Technologies, 1(1):9–17, 2023.
[45]
Panpan Han, Zheng Yan, Wenxiu Ding, Shufan Fei, and Zhiguo Wan. A survey on cross-chain technologies. Distributed Ledger
Technologies: Research and Practice, 2(2):1–30, 2023.
[46] Yutong Han, Chundong Wang, Huaibin Wang, Yi Yang, and Xi Wang. A study of blockchain-based liquidity cross-chain model. Plos
one, 19(6):e0302145, 2024.
[47] omas Hardjono. Blockchain gateways, bridges and delegated hash-locks. arXiv preprint arXiv:2102.03933, 2021.
[48]
Christopher G Harris. Cross-chain technologies: Challenges and opportunties for blockchain interoperability. In 2023 IEEE International
Conference on Omni-layer Intelligent Systems (COINS), pages 1–6, 2023.
[49]
Daojing He, Rui Wu, Xinji Li, Sammy Chan, and Mohsen Guizani. Detection of vulnerabilities of blockchain smart contracts. IEEE
Internet of ings Journal, 2023.
[50] Xiangyu Hu, Wanlun Ma, Chao Chen, Sheng Wen, Jun Zhang, Yang Xiang, and Gaolei Fei. Event detection in online social network:
Methodologies, state-of-art, and evolution. Computer Science Review, 46:100500, 2022.
[51]
Aida Ismailisu, Tomo Popović, Nenad Gligorić, Sanja Radonjic, and Stevan Šandi. A private blockchain implementation using
multichain open source platform. In 2020 24th International Conference on Information Technology (IT), pages 1–4, 2020.
[52]
Mudabbir Kaleem, Anastasia Mavridou, and Aron Laszka. Vyper: A security comparison with solidity based on common vulnerabilities.
In 2020 2nd Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS), pages 107–111. IEEE, 2020.
[53]
Harry Kalodner, Steven Goldfeder, Xiaoqi Chen, S Mahew Weinberg, and Edward W Felten. Arbitrum: Scalable, private smart
contracts. In 27th USENIX Security Symposium (USENIX Security 18), pages 1353–1370, 2018.
[54]
Niclas Kannengießer, Michelle Pster, Malte Greulich, Sebastian Lins, and Ali Sunyaev. Bridges between islands: Cross-chain technology
for distributed ledger technology. 2020.
[55]
Mostefa Kara, Abdelkader Laouid, and Mohammad Hammoudeh. An ecient multi-signature scheme for blockchain. Cryptology
ePrint Archive, 2023.
[56]
Zulqar Ali Khan and Akbar Siami Namin. Ethereum smart contracts: Vulnerabilities and their classications. In 2020 IEEE International
Conference on Big Data (Big Data), pages 1–10, 2020.
[57]
Arad Kotzer, Daniel Gandelman, and Ori Roenstreich. Sok: Applications of sketches and rollups in blockchain networks. IEEE
Transactions on Network and Service Management, 2024.
[58]
Moez Krichen, Mariam Lahami, and Qasem Abu Al-Haija. Formal methods for the verication of smart contracts: A review. In 2022
15th International Conference on Security of Information and Networks (SIN), pages 01–08. IEEE, 2022.
[59]
Prabhat Kumar, Randhir Kumar, Govind P Gupta, and Rakesh Tripathi. A distributed framework for detecting ddos aacks in smart
contract-based blockchain-iot systems by leveraging fog computing. Transactions on Emerging Telecommunications Technologies,
32(6):e4112, 2021.
[60]
Satpal Singh Kushwaha, Sandeep Joshi, Dilbag Singh, Manjit Kaur, and Heung-No Lee. Systematic review of security vulnerabilities in
ethereum blockchain smart contract. IEEE Access, 10:6605–6621, 2022.
[61]
Vladimir Kustov, Grokhotov Aleksey, Beksaev Nikolay, Selanteva Ekaterina, and Renjith V Ravi. ree sources of blockchain technology
vulnerabilities-how to deal with them? In 2022 Second International Conference on Computer Science, Engineering and Applications
(ICCSEA), pages 1–8, 2022.
[62] Jae Kwon and Ethan Buchman. Cosmos whitepaper. A Netw. Distrib. Ledgers, page 27, 2019.
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 33
[63]
Sung-Shine Lee, Alexandr Murashkin, Martin Derka, and Jan Gorzny. Sok: Not quite water under the bridge: Review of cross-chain
bridge hacks. In 2023 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), pages 1–14, 2023.
[64]
Dawei Li, Jianwei Liu, Zongxun Tang, Qianhong Wu, and Zhenyu Guan. Agentchain: A decentralized cross-chain exchange system. In
2019 18th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/13th IEEE International
Conference On Big Data Science And Engineering (TrustCom/BigDataSE), pages 491–498, 2019.
[65]
Wenkai Li, Jiuyang Bu, Xiaoqi Li, and Xianyi Chen. Security analysis of de: Vulnerabilities, aacks and advances. In 2022 IEEE
International Conference on Blockchain (Blockchain), pages 488–493. IEEE, 2022.
[66]
Wenkai Li, Jiuyang Bu, Xiaoqi Li, Hongli Peng, Yuanzheng Niu, and Xianyi Chen. A sur vey of de security: Challenges and opportunities.
arXiv preprint arXiv:2206.11821, 2022.
[67]
Lu Lin, Jiayi Li, Yuzhen Wang, and Qiong Wang. A survey on cross-chain asset transfer schemes: Classication, challenges, and
prospects. In 2023 International Conference on Networking and Network Applications (NaNA), pages 202–208, 2023.
[68]
Shaofeng Lin, Yihan Kong, and Shaotao Nie. Overview of block chain cross chain technology. In 2021 13th International Conference on
Measuring Technology and Mechatronics Automation (ICMTMA), pages 357–360. IEEE, 2021.
[69]
Shaofeng Lin, Yihan Kong, Shaotao Nie, Wenjia Xie, and Jia Du. Research on cross-chain technology of blockchain. In 2021 6th
International Conference on Smart Grid and Electrical Automation (ICSGEA), pages 405–408, 2021.
[70]
Torgin Mackinga, Tejaswi Nadahalli, and Roger Waenhofer. Twap oracle aacks: Easier done than said? In 2022 IEEE International
Conference on Blockchain and Cryptocurrency (ICBC), pages 1–8. IEEE, 2022.
[71]
Gunit Malik, Kshitij Parasrampuria, Sai Prasanth Reddy, and Seema Shah. Blockchain based identity verication model. In 2019
international conference on vision towards emerging trends in communication and networking (ViTECoN), pages 1–6. IEEE, 2019.
[72]
Hanyu Mao, Tiezheng Nie, Hao Sun, Derong Shen, and Ge Yu. A survey on cross-chain technology: Challenges, development, and
prospect. IEEE Access, 2022.
[73]
Alexander Mense and Markus Flatscher. Security vulnerabilities in ethereum smart contracts. In Proceedings of the 20th international
conference on information integration and web-based applications & services, pages 375–380.
[74]
Ahmed Af Monrat, Olov Schelén, and Karl Andersson. A survey of blockchain from the perspectives of applications, challenges, and
opportunities. IEEE Access, 7:117134–117151, 2019.
[75]
Yvonne Murray and David A Anisi. Survey of formal verication methods for smart contracts on blockchain. In 2019 10th IFIP
International Conference on New Technologies, Mobility and Security (NTMS), pages 1–6. IEEE, 2019.
[76] Satoshi Nakamoto. Bitcoin whitepaper. URL: hps://bitcoin. org/bitcoin. pdf-(: 17.07. 2019), 2008.
[77]
M Saqib Nawaz, Moin Malik, Yi Li, Meng Sun, and M Lali. A survey on theorem provers in formal methods. arXiv preprint
arXiv:1912.03028, 2019.
[78] Lydia D Negka and Georgios P Spathoulas. Blockchain state channels: A state of the art. IEEE Access, 9:160277–160298, 2021.
[79]
Markus Nissl, Emanuel Sallinger, Stefan Schulte, and Michael Borkowski. Towards cross-blockchain smart contracts. In 2021 IEEE
International Conference on Decentralized Applications and Infrastructures (DAPPS), pages 85–94, 2021.
[80]
Wei Ou, Shiying Huang, Jingjing Zheng, Qionglu Zhang, Guang Zeng, and Wenbao Han. An overview on cross-chain: Mechanism,
platforms, challenges and advances. Computer Networks, 218:109378, 2022.
[81]
Philipp Paech. Securities, intermediation and the blockchain: an inevitable choice between liquidity and legal certainty? Uniform Law
Review, 21(4):612–639, 2016.
[82]
Lesław Pietrewicz. Token-based blockchain nancing and governance: A transaction cost approach. In Entrepreneurship for the XXI
Century. Images and Perspectives” conference, November, pages 15–16, 2018.
[83]
Babu Pillai, Kamanashis Biswas, and Vallipuram Muthukkumarasamy. Cross-chain interoperability among blockchain-based systems
using transactions. e Knowledge Engineering Review, 35:e23, 2020.
[84] Joseph Poon and Vitalik Buterin. Plasma: Scalable autonomous smart contracts. White paper, pages 1–47, 2017.
[85]
Yiannis Psaras and David Dias. e interplanetary le system and the lecoin network. In 2020 50th Annual IEEE-IFIP International
Conference on Dependable Systems and Networks-Supplemental Volume (DSN-S), pages 80–80. IEEE, 2020.
[86]
Aleksei Pupyshev, Dmitry Gubanov, Elshan Dzhafarov, Ilya Sapranidi, Inal Kardanov, Vladimir Zhuravlev, Shamil Khalilov, Marc
Jansen, Sten Laureyssens, Igor Pavlov, et al. Gravity: a blockchain-agnostic cross-chain communication and data oracles protocol.
arXiv preprint arXiv:2007.00966, 2020.
[87]
Minfeng Qi, Ziyuan Wang, Qing-Long Han, Jun Zhang, Shiping Chen, and Yang Xiang. Privacy protection for blockchain-based
healthcare iot systems: A survey. IEEE/CAA Journal of Automatica Sinica, 2022.
[88]
Minfeng Qi, Ziyuan Wang, Fan Wu, Rob Hanson, Shiping Chen, Yang Xiang, and Liming Zhu. A blockchain-enabled federated learning
model for privacy preservation: System design. In Information Security and Privacy: 26th Australasian Conference, ACISP 2021, Virtual
Event, December 1–3, 2021, Proceedings 26, pages 473–489. Springer, 2021.
[89]
Kaihua Qin, Liyi Zhou, Benjamin Livshits, and Arthur Gervais. Aacking the de ecosystem with ash loans for fun and prot. In
International conference on nancial cryptography and data security, pages 3–32, 2021.
Distrib. Ledger Technol.
34 • Li, et al.
[90]
Kunpeng Ren, Nhut-Minh Ho, Dumitrel Loghin, anh-Toan Nguyen, Beng Chin Ooi, ang-Trung Ta, and Feida Zhu. Interoperability
in blockchain: A survey. IEEE Transactions on Knowledge and Data Engineering, 2023.
[91]
Yongjun Ren, Zhiying Lv, Neal N Xiong, and Jin Wang. Hcnct: A cross-chain interaction scheme for the blockchain-based metaverse.
ACM Transactions on Multimedia Computing, Communications and Applications, 2023.
[92]
Team Rocket. Snowake to avalanche: A novel metastable consensus protocol family for cryptocurrencies. Available [online].[Accessed:
4-12-2018], 2018.
[93]
Michael Rodler, Wenting Li, Ghassan O Karame, and Lucas Davi.
{
EVMPatch
}
: Timely and automated patching of ethereum smart
contracts. In 30th USENIX Security Symposium (USENIX Security 21), pages 1289–1306, 2021.
[94]
Mehdi Salehi, Jeremy Clark, and Mohammad Mannan. Not so immutable: Upgradeability of smart contracts on ethereum. arXiv
preprint arXiv:2206.00716.
[95] Sarwar Sayeed, Hector Marco-Gisbert, and Tom Caira. Smart contract: Aacks and protections. IEEE Access, 8:24416–24427, 2020.
[96]
Amanda J Schmi, Siyuan Anthony Sun, Lawrence V Snyder, and Zuo-Jun Max Shen. Centralization versus decentralization: Risk
pooling, risk diversication, and supply chain disruptions. Omega, 52:201–212, 2015.
[97]
David Schwartz, Noah Youngs, Arthur Brio, et al. e ripple protocol consensus algorithm. Ripple Labs Inc White Paper, 5(8):151, 2014.
[98]
Sisi Shao, Fei Chen, Xiaoying Xiao, Weiheng Gu, Yicheng Lu, Shu Wang, Wen Tang, Shangdong Liu, Fei Wu, Jing He, et al. Ibe-bciot:
an ibe based cross-chain communication mechanism of blockchain in iot. World Wide Web, 24(5):1665–1690, 2021.
[99]
M Staples, S Chen, S Falamaki, A Ponomarev, P Rimba, AB Tran, I Weber, X Xu, and J Zhu. Risks and opportunities for systems using
blockchain and smart contracts. data61. CSIRO), Sydney, 2017.
[100]
P Swathi, Chirag Modi, and Dhiren Patel. Preventing sybil aack in blockchain using distributed behavior monitoring of miners. In
2019 10th International Conference on Computing, Communication and Networking Technologies (ICCCNT), pages 1–6. IEEE, 2019.
[101] CHAINALYSIS TEAM. Vulnerabilities in cross-chain bridge protocols emerge as top security risk, 2023.
[102]
Louis Tremblay ibault, Tom Sarry, and Abdelhakim Senhaji Had. Blockchain scaling using rollups: A comprehensive survey. IEEE
Access, 2022.
[103]
Hangyu Tian, Kaiping Xue, Xinyi Luo, Shaohua Li, Jie Xu, Jianqing Liu, Jun Zhao, and David SL Wei. Enabling cross-chain transactions:
A decentralized cryptocurrency exchange protocol. IEEE Transactions on Information Forensics and Security, 16:3928–3941, 2021.
[104]
Dabao Wang, Siwei Wu, Ziling Lin, Lei Wu, Xingliang Yuan, Yajin Zhou, Haoyu Wang, and Kui Ren. Towards a rst step to understand
ash loan and its applications in de ecosystem. In Proceedings of the Ninth International Workshop on Security in Blockchain and Cloud
Computing, pages 23–28, 2021.
[105]
Jianghao Wang, Jieren Cheng, Yuming Yuan, Hui Li, and Victor S Sheng. A survey on privacy protection of cross-chain. In International
Conference on Articial Intelligence and Security, pages 283–296, 2022.
[106]
Qin Wang, Rujia Li, Qi Wang, and Shiping Chen. Non-fungible token (n): Overview, evaluation, opportunities and challenges. arXiv
preprint arXiv:2105.07447, 2021.
[107]
Shuai Wang, Yong Yuan, Xiao Wang, Juanjuan Li, Rui Qin, and Fei-Yue Wang. An overview of smart contract: architecture, applications,
and future trends. In 2018 IEEE Intelligent Vehicles Symposium (IV), pages 108–113. IEEE, 2018.
[108]
Zhuo Wang, Jian Li, Xiu-Bo Chen, and Chaoyang Li. A secure cross-chain transaction model based on quantum multi-signature.
antum Information Processing, 21(8):279, 2022.
[109]
Sam M Werner, Daniel Perez, Lewis Gudgeon, Ariah Klages-Mundt, Dominik Harz, and William J Knoenbelt. Sok: Decentralized
nance (de). arXiv preprint arXiv:2101.08778, 2021.
[110] Amy Whitaker. Art and blockchain: A primer, history, and taxonomy of blockchain use cases in the arts. Artivate, 8(2):21–46, 2019.
[111]
Tom Wilson and Alun John Barrera. How hackers stole $613 million in crypto tokens from poly network. Reuters, 2021. https:
//www.reuters.com/technology/how-hackers-stole-613-million-crypto-tokens-poly-network-2021-08-12/.
[112] Gavin Wood. Polkadot: Vision for a heterogeneous multi-chain framework. White paper, 21(2327):4662, 2016.
[113]
Zhihui Wu, Yang Xiao, Enyuan Zhou, Qingqi Pei, and an Wang. A solution to data accessibility across heterogeneous blockchains.
In 2020 IEEE 26th International Conference on Parallel and Distributed Systems (ICPADS), pages 414–421, 2020.
[114]
Yang Xiao, Ning Zhang, Wenjing Lou, and Y omas Hou. A survey of distributed consensus protocols for blockchain networks. IEEE
Communications Surveys & Tutorials, 22(2):1432–1465, 2020.
[115] Jiagui XIE, Zhiping LI, and Jian JIN. Cross-chain mechanism based on spark blockchain. Journal of Computer Applications, 42(2):519,
2022.
[116]
Tiancheng Xie, Jiaheng Zhang, Zerui Cheng, Fan Zhang, Yupeng Zhang, Yongzheng Jia, Dan Boneh, and Dawn Song. zkbridge:
Trustless cross-chain bridges made practical. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications
Security, pages 3003–3017, 2022.
[117]
Hang Xiong, Tobias Dalhaus, Puqing Wang, and Jiajin Huang. Blockchain technology for agriculture: applications and rationale.
frontiers in Blockchain, 3:7, 2020.
[118]
Brent Xu, Dhruv Luthra, Zak Cole, and Nate Blakely. Eos: An architectural, performance, and economic analysis. Retrieved June,
11:2019, 2018.
Distrib. Ledger Technol.
Blockchain Cross-Chain Bridge Security: Challenges, Solutions, and Future Outlook • 35
[119]
Zhuo Zhang, Zhiqiang Lin, Marcelo Morales, Xiangyu Zhang, and Kaiyuan Zhang. Your exploit is mine: Instantly synthesizing
counteraack smart contract. In 32nd USENIX Security Symposium (USENIX Security 23), pages 1757–1774, 2023.
[120]
Qianrui Zhao, Yinan Wang, Bo Yang, Ke Shang, Maozeng Sun, Haijun Wang, Zijiang Yang, and X He. A comprehensive overview of
security vulnerability penetration methods in blockchain cross-chain bridges. Authorea (Authorea), 2023.
[121]
Zibin Zheng, Shaoan Xie, Hong-Ning Dai, Weili Chen, Xiangping Chen, Jian Weng, and Muhammad Imran. An overview on smart
contracts: Challenges, advances and platforms. Future Generation Computer Systems, 105:475–491, 2020.
[122]
Xiaogang Zhu, Sheng Wen, Seyit Camtepe, and Yang Xiang. Fuzzing: a survey for roadmap. ACM Computing Surveys (CSUR),
54(11s):1–36, 2022.
Distrib. Ledger Technol.
