Cross-chain Hacked Again: Deep Product-level Analysis of Cross-chain Track Design Logic
TechFlow Selected TechFlow Selected
Cross-chain Hacked Again: Deep Product-level Analysis of Cross-chain Track Design Logic
Recent frequent cross-chain security issues have attracted widespread market attention. This article aims to explain from a product design perspective why security problems are so prevalent in this sector.
Navigating Web3 tides with focused insightsAuthor: 0xOar
Produced by: Seer Labs
Preface:
Recent frequent cross-chain security incidents have drawn widespread market attention. This article aims to explain from a product design perspective why there are so many security issues in this sector. It should be clarified that the problems pointed out in this article do not exist in every project—most of them already have corresponding mitigation strategies designed in advance. The main purpose is to help more people understand the complexity of this field.
Let us first walk you through how general-purpose cross-chain bridges are designed, and then explain the potential security issues these bridges may face.
01 The Unchanging Core of Cross-Chain Solutions
Previous reports have already explained several different types of information-crossing schemes. Regardless of their final form, from a product design standpoint, there are only three fundamental mechanisms: sidechains (in a broad sense—in this article, rollups are also categorized as sidechains, don't argue), hash time-lock contracts, and notary-based models.
(1) Sidechain
Among these three approaches, the sidechain solution offers the highest level of security—for example, various rollups and Polkadot's parachains.
The main chain and sidechain share security. However, sidechain solutions typically require the source and target chains to be homogenous, significantly limiting applicable use cases. This is precisely why Vitalik Buterin supports multi-chain ecosystems but does not endorse cross-chain interoperability, because cross-chain solutions that cannot share security inherently come with too many problems.
(2) Hash Time-Lock Contract (HTLC)
This approach claims to offer peer-to-peer, highly decentralized cross-chain functionality for heterogeneous blockchains, but it comes with high costs and long user waiting times, resulting in low adoption rates today. Moreover, when we still need a third party to act as an exchange intermediary, we also require a so-called intermediate consensus layer to meet requirements for both security and decentralization.
(3) Notary-Based Mechanism
This is currently the most widely used solution for heterogeneous cross-chain bridges. Most products on the market share a common origin; from a product design perspective, they are almost indistinguishable. The differences mainly lie in methods of information verification, consensus algorithms among notaries, and signature algorithms for custodial wallets. Differences in user experience and security are generally small. Therefore, from a security standpoint, the risks faced are largely similar.
This article will focus on summarizing and analyzing some common security risks associated with notary-based cross-chain bridges.
02 Product Logic Flow of the Notary-Based Model
Before understanding the various risks associated with the notary-based model, we must first grasp its core product design logic.
(1) Overview
From a design philosophy standpoint, this model is actually very simple. When addressing the need for cross-chain transfers of heterogeneous assets, the most intuitive solution is "mapping." Mapping means that when User A wants to transfer ETH from Ethereum to Fantom, we don’t need to physically move the asset or reissue it on Fantom (which isn't feasible). Instead, we first deposit User A’s ETH into an immutable address, and then issue a corresponding 1:1 mapped token on Fantom based on the amount deposited. This mapped token represents the usage rights of those ETH locked on the original Ethereum chain. Because of the 1:1 peg, users on Fantom recognize the value of this asset.
The most simplified cross-chain flow:
(2) Design Challenges
There are many issues here, with the biggest being the management of multi-signature wallets. When transferring ETH from Ethereum to Fantom, it involves depositing funds (deposit), but if User A later wants to bring the funds back, withdrawal (withdrawal) becomes necessary.
Decentralization and security during deposits and withdrawals become the primary challenges.
1. Who manages the funds? 2. Who initiates transactions? 3. Who listens for incoming transactions? 4. How do we confirm that a user has indeed sent funds? 5. How do we verify that a withdrawal request truly comes from the rightful owner? 6. How to prevent replay attacks? 7. How to resubmit failed transactions? 8. What if multi-sig managers act maliciously? 9. What happens during system downtime?
It’s overwhelming—the more you think about it, the more complex it gets. Cross-chain bridge technology involves not just multi-signatures, but also token issuance, cross-chain monitoring, asynchronous validation, and sometimes even requires launching a separate intermediate consensus layer (a new chain).
To simplify user understanding, I’ll break down the entire cross-chain process into two parts: deposit and withdrawal, to help clarify the mechanics.
(3) Further Breakdown of the Process
1. Deposit
Let me clarify: the following process diagram reflects my own speculative design after analysis. It hasn’t been rigorously validated and is intended solely to explore potential security issues within the design logic. Do not treat this as a production-ready solution—it's purely hypothetical.
As shown in the figure, a deposit transaction from the source chain to the target chain would ideally include the following steps:
(1) User deposits funds to the custodial address
(2) After the listener detects the transaction, a BP (consensus node and also a multi-sig admin) initiates the transaction
(3) The contract verifies the correctness of the BP's signature
(4) Check whether the fault-tolerant mechanism among nodes has been satisfied
(5) If not passed, reject; if passed, credit the corresponding amount to the user’s address on the target chain based on the mapping relationship
(6) BP confirms this deposit transaction
(7) After Byzantine consensus, transfer the mapped tokens to the user’s address on the target chain
Note: This process is designed for general heterogeneous cross-chain scenarios. Compared to solutions like Anyswap, an extra step is added where users bind their address relationships on an intermediate consensus layer. This is because different heterogeneous chains handle attached transaction data differently. To standardize processing, we assume users pre-bind their mapping relationships. For EVM-compatible chains, this step is unnecessary—users can directly attach the target chain address during transaction initiation.
Back to the topic: from step two onward, various logical validation issues and edge-case handling problems arise.
Key validation logic includes:
(1) Validation of the initiation of asset mapping and the outgoing transaction to User A’s target chain address after detecting the incoming transaction
(2) Initiation and result verification of the target chain transaction
In addition to the above, validations should also include checks for fake token deposits and special handling required when interacting with different token implementations.
To better summarize potential security vulnerabilities later, let’s now examine the withdrawal process.
2. Withdrawal
The withdrawal process illustrates the logic of exchanging mapped tokens on the target chain back into native assets on the source chain. It’s important to note that many tokens now exist natively across multiple chains. As such, many bridge projects maintain liquidity pools. When pool funds are sufficient, users won’t even notice the existence of mapped tokens like anyDAI—they simply receive the native version of the token on the target chain. However, this doesn’t alter the underlying logic. Let’s continue the analysis.
As shown, a withdrawal transaction from the target chain back to the source chain follows these steps: (1) User initiates a transaction (transferring an equivalent amount of mapped tokens to the custodial wallet on the target chain); (2) BP identity is verified, and a specific BP initiates the withdrawal request; (3) Withdrawal permissions and signatures are confirmed; (4) Upon achieving Byzantine consensus, the request is executed to withdraw funds from the custodial wallet on the source chain to User A; (5) In case of node validation errors or system downtime, rollback and re-initiation may be required.
From this flow, the main validation logic involved includes: (1) Verification of initiation and signing authority; (2) Fault tolerance mechanisms when issues occur.
(4) Security Risks
1. Security Issues in Design Logic
After a careful review of cross-chain bridge designs, we can see that numerous challenges exist at the design logic level. These can be summarized into three major categories (related theft incidents are noted at the end of each issue):
(1) Deposit
a) Vulnerabilities in deposit contract permissions allowing deposited funds to be immediately drained. This is a silly mistake common to nearly all smart contract projects. b) Fake token deposit issues—some projects fail to verify the authenticity of cross-chain tokens, enabling fakeTOKEN → realTOKEN swaps (Anyswap). Frankly, this is also quite dumb. d) Fake ETH deposits—native assets like ETH differ from ERC20 tokens. Many attacks exploit improper handling of ETH-specific behaviors, leading to fakeETH → realETH conversions. This is exactly why wrapped assets like WETH became popular (Thorchain). c) Even though many tokens follow the ERC20 standard, their implementations vary—some include additional logic (e.g., rebasing, fallback functions). Developers often fail to account for these during integration. Tokens like WETH, PERI, OMT, WBNB, MATIC, AVAX may invoke custom fallback functions in the sender after transfer, increasing the complexity for cross-chain bridge validation (Anyswap 2022.1.18).
(2) Cross-Chain Message Transfer
Between completing a deposit on Chain A and receiving assets on Chain B, the bridge operates like an independent blockchain system requiring a consensus mechanism—typically DPoS. Below are key considerations assuming DPoS (though I suspect all nodes are controlled by the project team, introducing centralization risk): a) Who initiates the cross-chain processing proposal upon detecting a deposit? Randomly? In rotation? Based on block order in the intermediate consensus layer? b) How do multiple notaries verify deposit correctness? If all data sources rely on providers like Infura, Infura becomes a single point of failure. The safest approach—each notary running its own node—is extremely costly. c) How to confirm completion of the cross-chain process (i.e., funds received on Chain B)? Failure scenarios include: i. The bridge never initiated processing ii. Processing started but consensus failed iii. Consensus passed but no transaction was submitted on Chain B iv. Transaction exists on Chain B but failed (insufficient funds or other reasons)
(3) Multi-Signature Verification Issues
A frequent hotspot for vulnerabilities—mostly stemming from code logic flaws: a) 3-out-of-5 signing: arbitrarily constructing a signature not in the multi-sig list still counts as +1 vote (ChainSwap). b) Centralization: nominally multi-signature, but keys fully controlled by the project team, posing massive centralization risk. c) Signature verification method: development patterns differ across chains, making integration errors likely. Example: Wormhole on Solana—the signature verification function resides in a system contract. Normally, the system contract address should be hardcoded. However, they passed it as a parameter. Attackers exploited this by providing a fake system contract address during withdrawal, bypassing signature verification and successfully draining funds.
(4) Refund Mechanisms
a) As discussed in (2)-c, cross-chain states can be ambiguous. Users must always have a refund option regardless of failure mode. For example, Anyswap first issues anyToken on the source chain, then on the target chain, and finally burns the source chain anyToken. This ensures users can prove ownership via anyToken holdings no matter where the failure occurred. With 3 chains (source, target, bridge) and 4 assets (original tokens and anyTokens on both chains), code logic bugs become highly probable. b) Thorchain’s vulnerability exposed on 2021.7.23: hackers exploited a logic flaw to create a massive fake deposit. Since the bridge couldn’t process it, the refund mechanism triggered, allowing the attacker to claim a huge payout.
2. Other Security Risks
However, issues visible through logical flows represent only business logic flaws—not the full picture. From a security standpoint, we must also consider three additional risk dimensions:
(1) Systemic Risks
For instance, a deposit succeeds on the source chain but is later rolled back due to a chain reorganization. This poses a serious problem—Vitalik once discussed a scenario where assets move from Solana to Ethereum, but Solana later rolls back, effectively doubling the user’s assets. There is no known fix. However, layer-2 solutions like rollups that share security with Ethereum do not suffer from this issue.
(2) Frontend Risks
a) Phishing websites—e.g., oxdao.fi, 0xdao.fi, oxdai.fi b) XSS (Cross-Site Scripting) attacks—code injection via URLs like www.xxxx.finance/?params=hackerscode12345. Although the domain appears legitimate, injected scripts execute if frontend defenses are weak, tricking users into signing unauthorized fund transfers. Never open suspicious links. c) CORS (Cross-Origin Resource Sharing) misconfigurations: Under strict same-origin policies, browsers only allow content and API calls from the same domain. But most projects enable cross-origin calls (e.g., xxxx frontend calling QuickSwap’s API), which introduces convenience—and risk. Suppose you visit xxxx.finance and sensitive data is cached. Then you visit a malicious site—if xxxx.finance lacks proper CORS restrictions, the malicious site could steal your cached data.
(3) Risks from Additional Features
Some cross-chain bridge projects go beyond asset transfers and support cross-chain contract calls—adding significant complexity. For example, an attacker initiates a call from Chain A to execute a function on Contract X on Chain B. The bridge blindly executes the call without validating X. Unbeknownst to them, X is actually the bridge’s own multi-sig wallet on Chain B, and the call changes its owner to the attacker’s address. Once executed, the hacker gains full control over the bridge’s funds on Chain B (Poly Network).
03 Conclusion
1. The purpose of this report is to help users clearly understand the security risks inherent in cross-chain bridges—not to maliciously exaggerate how easily they can be attacked.
2. Among existing solutions, the notary-based model currently offers the best user experience, widest applicability, and lowest cost. Moreover, all products evolve from a rough start toward maturity. Blockchain product attacks are usually rooted in “logical flaws.” With time and accumulated experience, these systems will inevitably improve.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
