On February 14, 2026, the cross-chain protocol Hyperbridge in the Polkadot ecosystem suddenly paused operations. This news sparked considerable discussion within the community.
However, it is important to emphasize that this incident is not due to a hacker attack, nor was a vulnerability exploited, and there were no user funds lost.
The reason is that the Hyperbridge team discovered during the migration from the Parachain to the Parathread model that the current implementation of the Polkadot Runtime does not generate consensus finality proofs usable for cross-chain validation.
For a protocol that relies on Polkadot proof to validate cross-chain messages, this means the entire validation chain was interrupted. Therefore, to prevent users from sending cross-chain messages that may never be delivered, the Hyperbridge team chose to proactively pause the system until the issue is resolved.
From the outcome, this was a typical security-first engineering decision. But this incident also brought a bigger question to the forefront of the industry: Why do cross-chain bridges always become hotspots for security incidents?
In today's discussion, Seun from Hyperbridge also shared a very candid and even somewhat sharp opinion.
In his view, the root cause of many security issues is actually not complex: many people do not truly understand the system they are building.
Blockchain systems involve cryptography, distributed systems, and complex mechanism design, and are still a developing research field. However, at the same time, the motivation for many projects entering this industry is to quickly launch products and obtain profits. When the goal is to 'go live as soon as possible' rather than 'thoroughly understand the system', some technical decisions may become understandable but often lay the groundwork for security risks.
If you decide to build a protocol, you must truly understand it and take long-term responsibility for it. Because once the system goes live, the challenges will not only be technical issues but also security risks, fund security, and the trust of the entire ecosystem.
So in today's program, we will not only review what happened in the Hyperbridge incident but also further discuss several more fundamental issues:
Why do cross-chain bridge attacks continue to happen in the industry?
Auditing, AI auditing, and community auditing, which one is more effective?
And in an industry that is still rapidly evolving, how should developers truly take responsibility for security?
Today, we have invited Seun, a core member of Hyperbridge, to talk about the technical details behind this incident and some deeper thoughts on cross-chain security design.
Kristen: Welcome to PolkaWorld Live, in this episode we will focus on the topic of security. Today we have invited Seun from Hyperbridge to participate in the discussion.
On February 14, 2026, Hyperbridge paused the operation of its cross-chain bridge after discovering a technical limitation in the Polkadot Runtime. This issue was subsequently resolved, and operation was resumed on February 19, with no loss of funds during the entire process.
First, to help the audience better understand the background, I want to emphasize that this was not a vulnerability attack, nor a hacker intrusion, nor a failure event where the system was actually breached.
However, even so, this pause has raised some concerns in the community.
So to provide some background for the upcoming discussion, I would like to ask Sean to help us detail what exactly happened? How did the team resolve this issue?
Seun: Okay, thank you for the invitation. I am also glad to share some details about this incident, especially as it occurred during our transition from the parachain model to the parathread model.
In simple terms, Polkadot is a blockchain that can provide validation for other blockchains. I won't go into detail about how it specifically implements this, but overall, there is a 'protocol relationship' between Polkadot and the blockchains it validates.
That is to say, Polkadot's consensus mechanism, as well as the finality proofs it generates, can also serve as finality proofs for these validated chains. Whether these chains are parachains or parathreads, it should theoretically be so. I had previously participated in the development of the Polkadot protocol, so I am relatively familiar with its internal mechanisms.
When we migrated from the parachain model to the parathread model, our CTO David mentioned in the team chat that our Prover was no longer working. By the way, our Prover is open-source, and if anyone is interested, they can find it in our code repository.
The reason for the system error at that time was that Polkadot could not find our Para ID.
My first reaction at that time was: 'This is normal because we are no longer a parachain but a parathread.'
So I initially thought this was not a serious issue; it just meant we needed to adjust the way we obtain Polkadot proofs to fit the new parathread model. But upon further inspection, we discovered a more serious problem: one of our core assumptions had been broken.
The assumption is that Polkadot will provide finality proofs for the chains it validates (such as parachains).
But under the parathread model, this mechanism has actually been compromised.
To be frank, I usually do not frequently follow the updates in the Polkadot codebase. Because our team is currently focusing on our own infrastructure development, application development, integration work, and business expansion. From our perspective, the existing infrastructure is functioning properly. We typically only need to update tools like the Polkadot SDK periodically. In theory, we should not need to continuously track the development details of the Polkadot protocol itself.
However, upon further investigation, we found that in the current implementation of the Polkadot protocol, Parathreads are explicitly excluded from consensus proofs.
The moment we are no longer a parachain, Hyperbridge can no longer obtain proof from Polkadot. Remember, Hyperbridge is essentially a co-processor that performs a large amount of validation work on behalf of the connected networks. And for external networks to see what is happening on Hyperbridge or receive messages from Hyperbridge, they must first validate Polkadot's proof, which further proves that the state of Hyperbridge is valid.
Therefore, when this proof chain was interrupted, Hyperbridge was effectively stuck.
So, it is not that we actively 'paused' the system.
Of course, we do have the ability to pause contracts across all different networks to prevent applications from continuing to send messages, which is a security precaution.
In general, many smart contracts have a pause mechanism to protect the system in case of vulnerability attacks or unforeseen situations.
We had never used this mechanism before, but to guard against eventualities, we designed it in advance. To be honest, I did not really think we would have to use it, but during our security audit, the auditing team indeed suggested that we have such a mechanism, so we implemented it.
From the outcome, the situation at that time was: the bridge could no longer transmit messages between different networks.
Of course, you can still send messages to Hyperbridge, but Hyperbridge cannot forward these messages to the target chain because it can no longer prove the validity of these messages to the target network.
Therefore, the entire cross-chain bridge was effectively frozen. We then began to pause our contracts on all relevant networks to prevent users from continuing to initiate transactions.
In other words, if someone attempts to use tokens cross-chain, or if a third-party application tries to send cross-chain messages through Hyperbridge, our contracts will directly roll back these transactions, thereby preventing the messages from being sent.
The purpose of doing this is to avoid users sending messages that may never be delivered, at least until we resolve this issue.
Essentially, the core of this incident is that the 'protocol contract' between Polkadot and its upper-layer chains (parachains) was broken.
As for why Polkadot's Fellows and the development team decided to exclude Parathreads from the consensus mechanism, I cannot comment. I think this question is better directed to the Polkadot team itself.
Kristin: From the entire handling process, the Hyperbridge team actually responded very quickly; you quickly paused the cross-chain bridge, thereby avoiding potential financial losses.
So I want to ask further, is this pause mechanism a built-in feature of Hyperbridge to ensure its security? Under what circumstances would this mechanism be triggered?
Seun: On the Hyperbridge network itself (which is the Hyperbridge parachain), there is actually no mechanism to directly pause the entire bridge. In other words, we do not have any runtime-level pallets that can enforce a pause on all transactions. However, at the smart contract layer deployed on various networks, we can control that.
These contracts allow us to pause:
Sending messages
Receiving messages
Or pause both simultaneously
As I mentioned before, we had never used this mechanism before. And this mechanism exists precisely because of the auditing team's suggestion.
When the Hyperbridge protocol underwent security auditing, it was conducted by SR Labs. SR Labs is also the auditing agency for Polkadot, responsible for auditing the Polkadot protocol itself. During the audit process, they advised us to establish a system that could pause the cross-chain bridge to quickly protect user funds in the event of issues.
This was also the suggestion from the auditing team. They believe that for cross-chain bridge protocols and DeFi protocols, this is a standard practice.
The basic principle is very simple: as long as the protocol involves funds or assets, it should have the ability to pause contracts in the event of problems.
As I mentioned before, in the more than a year since the launch of Hyperbridge, we have never used this mechanism — until the incident on February 14.
Kristin: I want to ask a slightly sensitive question.
We know that Hyperbridge has undergone third-party audits, and the auditing agency pointed out some potential risks in advance. However, many large protocols in the industry undergo multiple rounds of security audits, yet some of the biggest hacking incidents in the history of the crypto industry have also occurred in projects that have been repeatedly audited.
So from your perspective, how effective is a security audit?
Seun: To be honest, we are quite cautious and even a bit skeptical about the auditing agencies themselves. That’s why we were very clear in choosing SR Labs as the auditing agency at that time. SR Labs is also the auditing team for the Polkadot protocol. We believe they have rich experience in auditing multi-chain protocols.
In fact, our own team is very knowledgeable about this system.
Personally, I used to work at Polkadot and later joined Composable Finance, where we built the first IBC protocol implementation outside of the Cosmos ecosystem. So in terms of multi-chain protocols, we have actually accumulated a lot of experience.
To some extent, we might even be more suited to audit others' multi-chain protocols.
From the actual operating data, in the more than a year since Hyperbridge went live, it has processed over 500 million dollars in transaction volume and completed nearly 100,000 transactions. And during this time, we have not experienced any security incidents.
In addition, our system is designed to be completely decentralized. In other words, anyone can submit messages to Hyperbridge.
Many people actually do not understand that the security of our system is very strong in its architecture.
Many external cross-chain bridges require:
Establish a whitelist
Only allow specific trusted nodes to submit messages
Declare which messages should be passed by these nodes
But Hyperbridge is completely different. Our system is fully open-source; you can see on the block explorer that there are now over 130 relayers.
The role of these relayers is to submit to Hyperbridge how messages should be forwarded, and the entire process is completed through cryptographic proof.
Therefore, from our experience, the best auditors are actually the people who write the code themselves. If you do not truly understand the system you are building, then you probably should not be building it. Especially in this era of 'AI writing code' and 'vibe coding'.
This is also the engineering philosophy of our team; you must be very clear about how your protocol works.
Kristin: Speaking of auditing, now besides traditional auditing, AI auditing tools have also begun to emerge. You just mentioned that developers themselves must understand their protocol. Do you think AI auditing will help improve protocol security?
If mature AI auditing tools become available in the future, would you consider using them?
Seun: From our perspective, the best auditing method is actually: audit competitions or bug bounty mechanisms. That is to say, we will set up a reward pool, and anyone who can find vulnerabilities in the protocol can receive rewards. I think this is one of the most effective auditing methods.
Many protocols conduct sufficient 'real-world testing' in this way before going live on the mainnet.
For example, Uniswap, one of the largest DeFi protocols by TVL. Before releasing Uniswap V4, they conducted a months-long audit competition; I remember the entire auditing process lasted about six months. During this time, many researchers found a large number of bugs, including some very serious vulnerabilities. These issues were all fixed before the mainnet launch.
So in the end, when the protocol went live on the mainnet, the security had already been thoroughly tested.
So from our point of view, the best auditing method is to involve the entire community in the audit, rather than relying solely on a few auditing agencies.
Many traditional auditing agencies merely apply common vulnerability patterns they have found in other protocols to your protocol, without truly analyzing your system deeply or considering how your protocol might be structurally exploited or attacked.
Kristin: I agree with your view. Community members often have more enthusiasm for the protocol itself, and to some extent, their understanding of the protocol may be deeper than that of third-party auditing agencies. Now the industry has both third-party audits and AI audits, and even community auditing competitions. But at the same time, cross-chain bridge attack incidents still occur frequently in the Web3 industry. It seems that lessons from the past have not truly been learned.
For example, this year we have already seen several major incidents. So from your perspective, why do cross-chain bridge attacks continue to occur? Why does the industry seem not to have truly learned lessons from past incidents? Structurally, what makes cross-chain bridges such favored targets for attackers?
Seun: I believe the reality is that many people do not truly understand what they are building. I know this may sound a bit arrogant, but the fact is that blockchain systems are still new research fields in many ways, such as cryptography, distributed systems, and mechanism design; these fields are inherently very complex. But many people developing products on blockchain do not truly understand the scale, complexity, and depth of the systems they are facing.
Many people enter this industry just to make quick money. When you look at the entire industry from this perspective, that is, when you realize that many people just want to make quick profits, you will find that many technical decisions made by projects become 'understandable'.
For developers, if you decide to build a protocol, you must take responsibility for it, as it will lead to a large number of security and operational issues.
This article is the first part of the live broadcast, and the second part will be published tomorrow!
Original video: https://x.com/i/broadcasts/1OGwblnyglvKB
PolkaWorld Telegram Group: https://t.me/polkaworld_org
PolkaWorld Youtube Channel:
https://www.youtube.com/c/PolkaWorld
PolkaWorld Twitter:
@polkaworld_org