The use of distributed ledger technologies (DLTs) and blockchains is rapidly expanding across multiple sectors, including finance and governance. Although numerous blockchain frameworks and networks exist to support different use cases, a major challenge remains: enabling seamless communication between these diverse frameworks, protocols, and ledgers. As blockchain adoption accelerates, the need for effective interoperability solutions is becoming increasingly critical to deliver greater value to users. This study explores the design of current blockchain bridges and evaluates common security threats and mitigation strategies within the realm of interoperability. A threat model is introduced to examine the key components, vulnerabilities, risks, and corresponding safeguards involved in blockchain interoperability. Security concerns-such as excessive trust centralization and flaws in smart contracts-are identified and categorized based on the type of bridge component, along with recommended countermeasures. Different interoperability approaches-including relays, Hash Time-Locked Contracts (HTLCs), notary schemes, and smart contract-based solutions-are analyzed in detail. Ultimately, this research aims to help developers better understand the security challenges in blockchain interoperability and highlights the importance of establishing standardized practices in this area.
The decentralized wallet system is a digital ledger framework that is both distributed and
decentralized, allowing multiple parties to share and update a common database without depending
on any central authority. Initially developed as the backbone for cryptocurrencies like Bitcoin, this
technology has since expanded its reach into industries such as finance, healthcare, supply chain
management, voting systems, and identity verification [
As decentralized wallet systems gain widespread adoption, challenges and risks continue to
emerge—particularly regarding interoperability and system integration. Interoperability refers to
the ability of decentralized wallet systems or blockchains to communicate, exchange information,
and interact either with each other or with external systems. In simpler terms, it enables one ledger
to trigger actions or respond to events occurring on another ledger, a process known as
interoperation. To achieve interoperability, several approaches are commonly used, including
Bridges, Direct Connections, Connectors, and others. Each approach serves different technical
requirements and use cases, but all share the goal of enabling seamless communication while
preserving the decentralized nature of the systems [
Despite these solutions, achieving complete interoperability is still difficult. Key concerns
include ensuring atomicity in cross-ledger transactions, maintaining decentralization in
communication channels like bridges, and addressing vulnerabilities in smart contracts [
Although numerous Blockchain frameworks have been developed, no single network can satisfy
the diverse requirements of all applications. This has created a pressing need for mechanisms that
enable different Blockchains to communicate and share data effectively. However, the fundamental
design of Blockchain technology makes seamless interaction between networks inherently
challenging [
Even with existing solutions such as bridges and other integration mechanisms, crossBlockchain data exchange often depends heavily on the reliability and security of these systems. With the total market capitalization of Blockchain assets surpassing $3 trillion as of August 2022— and growing demand for asset transfers across multiple chains—it has become essential to identify the common security risks linked to Blockchain bridges and to design robust countermeasures.
Despite the availability of various frameworks and protocols, knowledge about achieving
effective interoperability remains scattered. The severity of security threats was made evident by
the high-profile attack on the Wormhole Blockchain bridge, which enables asset transfers between
the Ethereum and Solana networks. Exploiting a vulnerability in the bridge contract, hackers stole
assets worth $690 million, demonstrating the significant risks posed by bridge-based
interoperability [
As the phrase goes, “Interoperability is key to survivability.” Therefore, it is vital that interoperability solutions—particularly bridges—adhere to stringent security standards to safeguard assets and preserve user trust.
This study focuses specifically on interoperability between two Blockchains, assessing existing interoperability frameworks to uncover security vulnerabilities and risks.
A threat model analysis is employed to evaluate system complexity, pinpoint potential attack vectors, and prioritize threats based on their severity. A six-step case flow analysis is then used to rank threats and propose appropriate mitigation strategies. 3. The goals of this research provide a clear review of current Blockchain interoperability needs and associated risks. perform threat analysis and evaluate the security risks in Blockchain bridge design patterns. recommend countermeasures to mitigate identified security risks.
examine the limitations and potential challenges of the proposed methods.
Interoperability refers to the ability of different software systems to exchange information and use
it effectively. Vernadat described interoperability as the capability of two or more systems to
provide or accept services from one another and accurately share data. In the context of distributed
ledger systems, interoperability can also be defined as the ability of one ledger to process
transactions originating from another, even if they use different identity management systems,
cryptographic methods, consensus mechanisms, or smart contract functionalities.
Cross-chain communication, on the other hand, is the process through which two independent
blockchains interact to maintain synchronized and consistent data. Essentially, it allows different
types of blockchains to communicate at the interchain level. One example is the Interledger
Protocol, which enables value transfer between two separate chains. However, designing a
crosschain communication protocol is challenging because each blockchain has unique structural and
operational characteristics [
One of the most significant challenges, known as the cross-blockchain proof problem, arises
when one blockchain needs to verify the state or transaction records of another chain. It is often
difficult—if not impossible—to confirm data recorded on one chain simply by observing information
shared from another. This means the receiving chain cannot always fully verify the intended
changes or authenticate the transaction. Consequently, blockchains cannot communicate with each
other directly [
To overcome this limitation, trusted third-party solutions have been developed to facilitate data transfers between blockchains. However, relying on third parties contradicts one of blockchain technology’s core principles—decentralization—as such solutions can introduce single points of failure. Therefore, interoperability frameworks must ensure that information and value are exchanged in a secure and trustless manner.
Researchers have observed that cross-blockchain transactions often do not directly alter the state of the other chain. Instead, they trigger specific functions on the target chain, which may subsequently change its state. Interoperable solutions can be categorized based on integration type, consensus mechanism, level of decentralization, or design rationale.
Buterin’s classification of cross-chain solutions falls into three main categories: 1.
Centralized or Multi-signature Attestation Methods—A group of trusted parties verifies and acts on the destination chain when triggered by the source chain.
Data Forwarders—Systems where one blockchain can read and interpret data from another. Hash-locking Method—Two blockchains interact using a cryptographic hash trigger to verify and execute transactions. Further studies also discuss concepts like Blockchain of Blockchains (BoB) and Hybrid Connectors, along with variations of sidechains, such as centralized two-way pegs, federated two-way pegs, and simplified payment verification proofs. Bridge solutions may combine multiple mechanisms to achieve seamless cross-chain communication.
Let’s mathematically describe the method of interaction between Decentralized Ledger Systems
(DLS). I will formulate this as an interaction model suitable for cross-chain communication [
Let’s say we have a set of decentralized ledgers (blockchains):
L = { L1 , L2 , … , L n , }
Li= ( S i , T i , C i )
f ij : T i →T j where Li is the ith decentralized registry.
where: S is a set of states, T is a set of transactions, C is a consensus mechanism. Interaction between two registries Li and L j can be presented as a reflection: where f ij is a function that transforms a transaction from one register to the format of another. Correctness Condition For a transaction from Li to be accepted in L j, the following must hold: C j ( f ij (t ))= True , ∀ t ∈ T i
Where C j is the consensus mechanism of ledger L j, which validates the transaction after transformation.
To represent data exchange, we can define the operation
Li ⊕ L j= { f ij ( t ) /t ∈ T i , C j ( f ij ( t ) )= True } Hash-Time Lock Contracts (HTLC) For security, a hash function H and a timelock τ are added:
HTLC (t )= { f ij (t ) , if H ( s )= h∧ t < τ , ∅ ot h erwise }
This ensures that the transaction will only be executed if the secret sss is revealed (such that H ( s )= h) and within the allowed time window.
Here is a mathematical model of the interaction between Decentralized Ledger Systems (DLS). Mathematically, it can be described as follows: Let Li is a decentralized ledger. f ij ( t ) is the transformation function of transactions between Liand L j, at time t. For correct interaction, the following is performed: which means that the state of book L j is updated based on events in book Li.
Let’s add mathematical equations and formalism for the security and atomicity of cross-chain
transactions between Decentralized Ledger Systems (DLS) [
Condition for correctness of transaction acceptance: Transaction T i with Li after transformation must be validated in L j:
L j (t + 1 )= f ij ( Li ( t )
C j ( f ij (T i ))= True .
That is, only if the consensus recognizes the converted transaction as valid will its state be applied.
Proof verification (Merkle/Proof verification) whenL j receives proof p about the existence of a transaction/state in Li:
V E R I F I j ( p ROOT i )= True is a valid proof (Merkle/POW/POA) for ROOT i. Without correct V E R I F I j − L jshould not be equal to Li: Atomicity: formalization (general condition): Let’s call the commit/rollback boolean variables: The atomicity of a cross-chain operation requires: That is means, the operation must either be performed on both books or on neither.
COMMIT i , COMMIT j ∈ { 0,1 } .
COMMIT i⟺ COMMIT j.
HTLC provides conditional commit via the secret sss and timeout τ\tauτ. Formally:
HTLC i (T i ; h , τ )= { execute T i , if s is presented ∧ H ( s )= h before τ refund T i , if τ h as passed ∧ s was not provided .
L j locks asset B under the same h until τj (with τj < τi for safety). 3. If a party reveals son L j before τj , then Li can verify s and redeem B. Otherwise, after τ a refund occurs.
Formally, atomicity:
( H ( s )= h ∧ t < τj ) ⇒( COMMIT i ¿ C OMMIT j= 1 ) .
Otherwise, if t ≥ τj , both refund:
t ≥ τj ⇒COMMIT i ¿ COMMIT j= 0.
Notaries (multi-sig / validator threshold)—trust-minimized formalism Validator/notary model: a set V with weights wv. Threshold Θ .
Acceptance condition for a message/attestation: This formalizes: if there are enough signatures/votes, the action is executed.
Security requires that an attacker cannot gather the threshold: is:
For blockchains with probabilistic finality (e.g., PoW), the required number of confirmationsk where p is the probability that a single block is reorganized (roughly dependent on attacker share), and is the target risk level (e.g.,10− 9). In practice, k is set based on a risk assessment, after which a transaction is considered final oncek blocks have confirmed it.
Safety and liveness conditions
Safety: under the assumed conditions (e.g., <50% adversarial validator weight or sufficient confirmations), no interaction leads to an invalid state: t : C j ( f ij (T i ))= True ∧ (the transaction was fraudulent). ∑ v∈ V approve
wv ≥ Θ →accept .
P r ( ∑ v∈ V malicious
wv ≥ Θ )is small . Liveness: if participants follow the protocol, the operation completes (commit or refund) within a finite time Tmax.
The full condition for a correct and atomic cross-chain operation between Li and L j:
VERIFY j ( pi , R OOT i )= True ∧ C j ( f ij (T i ))= True ∧ (an atomicity mechanism is specified ,e.g., HTLC or threshold notary) ∧ (sufficient confirmations k are ensured for Li and L j)
⇒COMMIT i⟺ COMMIT j
HTLC timeouts: τj < τi and τi− τj ≥ ∆, where ∆ is a safety margin to complete refund paths.
Threshold schemes: choose Θ such that Θ > maximum plausible adversarial weight.
Confirmations: selectk considering the attack model and desired ϵ .
This is the first diagram showing the atomic interaction between two Decentralized Ledger
Systems (DLS) using Hash Time-Lock Contracts (HTLC) [
Ledger L 1 locks asset A under hash h until timeout τ1.
Ledger L 2 locks asset B under the same hash h, but with a shorter timeout τ2 < τ1. To complete the exchange, one participant reveals the secret s such that H ( s )= h.
This allows the other ledger to verify the transaction and finalize the exchange.
If the timeout expires before the secret is revealed, a refund (return of assets) occurs. Thus:
COMMIT i⟺ COMMIT j meaning that the transaction is executed on both chains simultaneously, or not executed at all.
This is the second diagram—it illustrates the notary model of interaction (multi-sig / threshold) between two Decentralized Ledger Systems (DLS):
This event is verified by a set of notaries/validators V. Each notary provides a signatureσv. If the threshold condition is met:
∑
v∈ V approve
then the transaction is considered confirmed [
wv ≥ Θ ,
After that, a commit occurs in Ledger L 2
Thus, without a sufficient number of honest validators, the transaction cannot proceed, which ensures secure atomicity in the notary model.
Look at the comparative diagram of the two approaches:
HTLC (Hash Time-Lock Contracts) are trustless mechanisms where assets are locked on both ledgers with a common hash h and timeouts (τ1, τ2), one participant reveals a secret s such that H ( s )= hto trigger symmetric execution on both ledgers, and if the secret is not revealed within the time limits, assets are refunded—offering the advantage of no third-party reliance but the disadvantage of practical complexity due to timeouts and risks of delays.
In the Notary Model (Multi-sig / Threshold Validators), a transaction event on Ledger L 1
is verified by a group of notaries. If the number of signatures or votes exceeds the threshold Θ, the
transaction is confirmed and a corresponding record (commit) is created in Ledger L 2. This model
offers simpler implementation but carries the drawback of centralization of trust, with potential
risks of collusion among notaries [
High: requires smart contracts, time locks, coordination Lower: only signature collection and verification needed
Trust Level Security Atomicity Execution Speed Implementation Complexity Flexibility Drawbacks Use Cases
Trustless, fully cryptographically secured High (based on hash functions and time locks) Guaranteed mathematically: either execution on both ledgers or none Slower due to timeouts and block confirmations Works with any blockchain that supports smart contracts Risk of delays, complex setup Atomic swaps (e.g., BTC ↔ ETH)
Semi-centralized—relies on trusted notaries Depends on the honesty of the majority of notaries Guaranteed if threshold of signatures Θ is reached Faster, depends on collecting notary signatures Works where reliable validators/notaries are available Centralization of trust, risk of collusion among notaries Cross-chain bridges with validators (e.g., Cosmos, Polkadot)
So we can conclude that HTLC is best suited for scenarios where decentralization and
trustlessness are critical but Notary Model is more practical when speed and simplicity are
preferred, even if partial trust centralization is introduced [
Bridge smart contracts are pieces of code that run on blockchains to enable communication between different chains. They handle tasks like locking, burning, and unlocking tokens so that assets can be transferred securely from one chain to another.
Because they control important state changes in the system, vulnerabilities in their code can be dangerous. One example is a reentrancy vulnerability. In this case, an attacker exploits the time gap during a state change to repeatedly call the contract before the final state is settled, allowing them to manipulate the process.
Bridge contracts often lock tokens on one chain while creating or unlocking them on another. But if the contract responsible for unlocking or redeeming the tokens is destroyed (for example, if the Ethereum Virtual Machine executes a SELFDESTRUCT), those funds may be stuck permanently. This means the tokens remain locked forever, with no way to recover them.
The diagram illustrates how a Bridge Smart Contract operates between two ledgers ( L 1 and L 2), enabling cross-chain flows such as lock → mint/unlock. However, it also highlights key vulnerabilities, including reentrancy attacks that exploit intermediate states to repeatedly call the contract. Another risk is SELFDESTRUCT, where destroying the unlocking contract could leave tokens permanently locked.
The second diagram showing a safe design pattern (e.g., using validator thresholds or additional checks).
The diagram illustrates how a Bridge Smart Contract operates between two ledgers ( L 1 and L 2), enabling cross-chain flows such as lock → mint/unlock. However, it also highlights key vulnerabilities, including reentrancy attacks that exploit intermediate states to repeatedly call the contract. Another risk is SELFDESTRUCT, where destroying the unlocking contract could leave tokens permanently locked.It is assumed that the blockchains being discussed already have strong security foundations and reliable consensus mechanisms. For the case study, the focus is placed on an everyday or common use case, which serves as the basis for examining potential security risks. The diagram shows participants, the flow of a cross-chain transfer, and key vulnerabilities:
In a cross-chain asset transaction model, the main components include Chain A and Chain B
(where transfers occur), participants on each chain, a relayer that forwards events, a client
interacting with smart contracts, and the smart contracts themselves that execute
locking/unlocking logic. This setup faces vulnerabilities such as relayer trust issues, malicious
clients submitting false proofs, and smart contract bugs like reentrancy or SELFDESTRUCT, all of
which expose potential attack surfaces. To enable secure transfers, each cross-chain transaction
must specify the type of transaction, the amount being moved, and an embedded proof of lock
showing that assets are secured on the source chain.Relay Messages [
Messages sent through the relayer do not transfer assets directly but instead carry information needed to validate cross-chain transactions. Each relay message includes the chainId, blockNumber, and transaction data. In this way, a message acts as proof passed from one chain to another, enabling the receiving chain to validate the client’s submission. Threat Model
To understand possible vulnerabilities, we use a threat model. This allows us to analyze the risks involved for a given transaction flow and network setup, and then test whether proposed countermeasures can effectively mitigate these risks. The goal is to improve security and sustainability for blockchain projects.
The transaction flow begins with a call to a smart contract requesting an asset transfer, followed by the contract validating the submitted data. Subsequent steps involve the relayer, client, and corresponding smart contract logic to complete the cross-chain process. A practical Solidity example demonstrates how a bridge can lock Ether on the source chain and emit proofs for relayers or validators before releasing assets on the destination chain.
1) Minimal “Event-Based Locker” (single relayer/agent releases on target chain) // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; /// @notice Educational-only Ether locker that emits a lock event for off-chain relayers. contract EthLocker { event Locked( address indexed sender, uint256 indexed dstChainId, address indexed dstRecipient, uint256 amount, bytes32 lockId ); } mapping(bytes32 => bool) public consumed; // prevent replay of the same lockId /// @dev User locks ETH on the source chain; relayer listens to the event. function lock(uint256 dstChainId, address dstRecipient, bytes32 lockId) external payable { require(msg.value > 0, "No ETH sent"); require(!consumed[lockId], "lockId used"); consumed[lockId] = true; // prevent duplicates on the source chain // ---- LOCK HAPPENS HERE ---// ETH stays held by this contract's balance until an admin-controlled refund flow occurs. emit Locked(msg.sender, dstChainId, dstRecipient, msg.value, lockId); /// @notice Simple owner-based refund (for demonstrations only; real bridges avoid single admin trust).
address public owner = msg.sender; function refund(address payable to, uint256 amount) external { require(msg.sender == owner, "not owner"); (bool ok, ) = to.call{value: amount}(""); require(ok, "refund failed"); receive() external payable {} What it shows: } }
The lock is simply ETH held by the contract (msg.value).
A Locked event provides data (lockId, dstChainId, dstRecipient, amount) that a relayer can use on the destination chain to mint/unlock the corresponding asset.
HTLC (Hash Time-Lock Contract) for trustless ETH locking. // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; /// @notice Simple ETH HTLC: funds can be claimed with a preimage s (H(s)=h) before deadline, or refunded after. contract EthHTLC { struct Lock { address sender;
address receiver; // often a bridge agent or the user's address on the target chain representation uint256 amount; bytes32 hashlock; // h = keccak256(s) uint256 timelock; // UNIX time; after this sender can refund bool withdrawn; bool refunded; mapping(bytes32 => Lock) public locks; event Locked(bytes32 indexed id, address indexed sender, address indexed receiver, uint256 amount, bytes32 hashlock, uint256 timelock); event Withdrawn(bytes32 indexed id, bytes preimage); event Refunded(bytes32 indexed id); /// @dev Create a lock: send ETH + specify hashlock h and timelock.
function lock(bytes32 id, address receiver, bytes32 hashlock, uint256 timelock) external payable { require(msg.value > 0, "no ETH"); require(locks[id].amount == 0, "id used"); locks[id] = Lock(msg.sender, receiver, msg.value, hashlock, timelock, false, false); emit Locked(id, msg.sender, receiver, msg.value, hashlock, timelock); /// @dev Claim with preimage s before timelock. function withdraw(bytes32 id, bytes calldata preimage) external {
Lock storage L = locks[id]; require(!L.withdrawn && !L.refunded, "done"); require(block.timestamp < L.timelock, "timed out"); require(keccak256(preimage) == L.hashlock, "bad preimage"); L.withdrawn = true; (bool ok, ) = payable(L.receiver).call{value: L.amount}(""); require(ok, "send failed"); emit Withdrawn(id, preimage);
The example shows that ETH remains locked until either the preimage is revealed for
withdrawal or the timeout passes for a refund, ensuring atomicity when paired with an HTLC on
the destination chain. To make bridge lockers secure, developers must guard against reentrancy
with proper patterns, avoid reliance on selfdestruct-dependent contracts, enforce replay protection
with unique lockIds, and wait for sufficient block confirmations before release. Additional
safeguards include using EIP-712 signature domain separation, setting transaction limits, and
implementing a pausable mechanism for incident response [
Clean, drop-in formulas plus concrete BTC↔ETH and BTC↔Solana examples of
C X ( k )= confirmation/finality wait on chainX for kblocks (or finality epochs). I X = inclusion delay for a single tx on chain X (≈ one block).
S quorum= notary/validator quorum signing time. δ net= cross-chain relay/propagation delay (usually seconds). ϕproof = proof gen/verification overhead (SPV/merkle proof etc., HTLC-style bridges).
HTLC-style (proof-based) Notary / Threshold-signer T HTLC, A →B = C A( k A) + ϕproof + I B + δ net T Notary, A →B = C A( k A) + S quorum + I B + δ net
Time until you (the side receiving on B) get assets on B:
T HTLC-swap, receive on B = C A( k A) + C B ( k B ) + I B + δ net Claim on A by the counterparty happens after, and doesn’t delay your receipt on B.
Bitcoin (BTC): I BTC ≈ 10 minper block; common k A= 3 ∼ 6 ⇒C BTC ≈ 30 ∼ 60 min. Ethereum (ETH): I ETH ≈ 12 s; common policies: “light” confirmations ~12 blocks⇒C ETH ≈ 2.4 min, or full finality≈ 12 – 13 min.
Solana (SOL): I SOL ≈ 0.4 – 0.6 s; finalityC SOL ≈ 2 – 5 s.
Overheads: δ net ∼ 1 – 5 s; S quorum ∼ 1 – 3 s(well-peered validators); ϕproof can be seconds to a minute+ depending on proof size/verification gas and relayer cadence.
A) BTC → ETH Notary model (one-way lock & mint) Choose k BTC= 3(exchange-class fast path): C BTC ≈ 30 min I ETH ≈ 12 – 36 s(1–3 blocks)
C BTCsame as above. ϕproof (BTC SPV relay + on-chain verify) ≈ 20–90 s (design-dependent).
I ETH ≈ 12 – 36 s, δ net ≈ 2 s.
T HTLC ≈ 30 – 60 min + ( 0.5 – 1.5 min ) ≈ 30.5 – 61.5 min
Takeaway (BTC→ETH): Notary and HTLC are both dominated by BTC confirmations; Notary typically shaves off the proof overhead, saving ~0.5–1.5 minutes and some gas.
C BTC= 30 – 60 min(3–6 confs) I SOL ≈ 0.4 – 0.6 s, finality2 – 5 s
δ net ≈ 2 s
ϕproof (BTC proof relay → Solana verifier) ≈ 10–60 s I SOL ≈ < 1 s, δ net ≈ 2 s
C BTC= 30 – 60 min
T HTLC ≈ 30 – 60 min + 10–60 s
Takeaway (BTC→SOL): Again dominated by BTC. Solana’s sub-second inclusion means the Notary advantage is mostly the missing proof cost.
BTC↔ETH (receive on ETH):
T ≈ C BTC( 3 – 6 )+ C ETH ( policy )+ I ETH ≈ 30 – 60 min + 2.4 – 13 min + 12 – 36 s ⇒32 – 73 min. BTC↔SOL (receive on SOL): T ≈ 30 – 60 m in + 2 – 5 s+ ¿ 1 s ⇒30 – 60 min + seconds.
Both models must trust BTC finality; that’s the wall-clock bottleneck.
Notary avoids ϕproof (heavy proofs/on-chain verification), replacing it with tinyS quorum.
On fast destination chains (ETH w/ light confirms, Solana), Notary often “wins by seconds–a minute,” not by tens of minutes—because BTC dominates.
BTC - ETH (3 conf) Notary BTC - ETH (3 conf) HTLC BTC - ETH (6 conf) Notary BTC - ETH (6 conf) HTLC BTC - SOL (3 conf) Notary BTC - SOL (3 conf) Atomic BTC - ETH (recv on ETH) Atomic BTC - SOL (recv on SOL) HTLC HTLCswap HTLCswap 1828 1886 3628 3686 1805 1833 1970 1806
BTC 3 conf (~30m), quorum ~2s, ETH inclusion ~24s BTC 3 conf (~30m), proof ~60s, ETH inclusion ~24s BTC 6 conf (~60m), quorum ~2s, ETH inclusion ~24s BTC 6 conf (~60m), proof ~60s, ETH inclusion ~24s BTC 3 conf (~30m), quorum ~2s, SOL inclusion ~1s BTC 3 conf (~30m), proof ~30s, SOL inclusion ~1s BTC 3 conf + ETH ~2.4m + ETH inclusion ~24s BTC 3 conf + SOL ~3s + inclusion ~1s
The research provides a detailed analysis of blockchain bridge frameworks, including relay schemes, HTLCs, notary models, and smart contracts, highlighting their risks, vulnerabilities, and mitigation strategies. A general threat model and case studies are presented to show how weaknesses can be identified and countered, helping developers make informed design choices and strengthen bridge security. Practically, the study offers developers concrete steps to mitigate risks and gives users clearer insight into how cross-chain solutions function and the safeguards applied.
The research highlights the importance of standardizing frameworks for blockchain interoperability and developing a unified cross-chain communication model. It also stresses the need to define recommended cryptographic protocols and create unified templates for building bridges. Together, these steps would help establish a more secure and reliable blockchain ecosystem.
The paper applies a component-based threat analysis along with a case study but suggests that future research could also use methodologies like STRIDE and DREAD. Incorporating these approaches would expand the scope of security evaluation for blockchain bridges. Such efforts would foster collaboration between academia and industry, ultimately enhancing the protection and efficiency of cross-chain transactions.
Declaration on Generative AI While preparing this work, the authors used the AI programs Grammarly Pro to correct text grammar and Strike Plagiarism to search for possible plagiarism. After using this tool, the authors reviewed and edited the content as needed and took full responsibility for the publication’s content.